1
Ideas / Re: Fat pointer syntax support for 1D array like structs
« on: December 30, 2020, 05:27:15 PM »
Yes!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Ideas / Struct wrapping (multi-dimensional) arrays
« on: December 18, 2020, 05:18:35 PM »
Gnu C extension allows:
void * foo (int n) {
struct S { int data[n]; };
int (*s)[n] = malloc( sizeof (int[n]) );
...
}
which is very convenient. It would be even better to allow support for the following:
struct S {
int n;
f32 (*data)[.n]; // the ".n" refers to the internal field
}
It would be even more awesome to allow wrapping multi-dimensional arrays:
struct S2 {
int m;
int n;
f32 (*d)[.m][.n];
}
struct S2 a2;
a2.m = 100;
a2.n = 50;
a2.d = malloc( sizeof( f32[a2.m][a2.n] );
(*a2.d)[0][0] = (*a2.d)[1][1] + (*a2.d)[2][3];
If we then combine with my previous suggestion of allowing array access syntax on "fat pointers" we could do:
(*a2)[0][0] = (*a2)[1][1] + (*a2)[2][3];
void * foo (int n) {
struct S { int data[n]; };
int (*s)[n] = malloc( sizeof (int[n]) );
...
}
which is very convenient. It would be even better to allow support for the following:
struct S {
int n;
f32 (*data)[.n]; // the ".n" refers to the internal field
}
It would be even more awesome to allow wrapping multi-dimensional arrays:
struct S2 {
int m;
int n;
f32 (*d)[.m][.n];
}
struct S2 a2;
a2.m = 100;
a2.n = 50;
a2.d = malloc( sizeof( f32[a2.m][a2.n] );
(*a2.d)[0][0] = (*a2.d)[1][1] + (*a2.d)[2][3];
If we then combine with my previous suggestion of allowing array access syntax on "fat pointers" we could do:
(*a2)[0][0] = (*a2)[1][1] + (*a2)[2][3];
3
Ideas / Fat pointer syntax support for 1D array like structs
« on: December 18, 2020, 04:39:20 PM »
It would be nice to allow the following type of syntax:
struct S {
int len;
f32 data[];
};
struct S *s = malloc( sizeof( struct S ) + 100 * sizeof( f32 ) );
s->len = 100;
(*s)[0] = (*s)[1] + (*s)[2];
So if a struct ends with a variable length array (or just a pointer type) then the array access syntax using [] is honored.
struct S {
int len;
f32 data[];
};
struct S *s = malloc( sizeof( struct S ) + 100 * sizeof( f32 ) );
s->len = 100;
(*s)[0] = (*s)[1] + (*s)[2];
So if a struct ends with a variable length array (or just a pointer type) then the array access syntax using [] is honored.
4
General Discussion / C function and type macros
« on: June 05, 2018, 07:59:24 PM »
I am trying to interface the C library lapacke to C2, however some of the functions and types in lapacke are defined to be macros. For example lapack_make_complex_float is a macro that takes 2 float arguments and returns a "complex" number whose type is the macro lapack_complex_float. Is there a way to handle these issues in the .c2i files? If the lapacke.h file could be #include'd in the generated C files this would be a solvable problem I think.
Otherwise I have to figure out the precise expansions of these macros on my platform and only write .c2i files for that.
Thanks.
--shiv--
Otherwise I have to figure out the precise expansions of these macros on my platform and only write .c2i files for that.
Thanks.
--shiv--
5
General Discussion / Re: VLA crash
« on: June 04, 2018, 11:49:02 PM »
Actually please ignore that request. I realized that C support for multidimensional arrays is broken anyway so I will just use the vanilla 1D arrays instead.
Thanks.
--shiv--
Thanks.
--shiv--
6
General Discussion / Re: VLA crash
« on: May 23, 2018, 07:04:26 PM »
I just installed C2 again and this issue does not appear to be fixed at least if I install c2 according to the installation instructions on the github home page. I know you said that you would fix this in another branch. If so, please let me know how to proceed and I will be happy to try it out. Thanks.
--shiv--
--shiv--
7
General Discussion / VLA crash
« on: March 08, 2017, 04:59:55 AM »
The following code:
module test;
import stdio;
public func int32 main () {
const uint64[2] Dims = {2, 3}
float32[Dims[0]][Dims[1]] p;
p[0][0] = 1;
p[0][1] = 2;
stdio.printf ("%g %g", p[0][0], p[0][1]);
return 0;
}
causes the following error:
c2c: /home/shiv/c2compiler/c2c/CGenerator/CCodeGenerator.cpp:485: void C2::CCodeGenerator::EmitDecl(const C2::Decl *, C2::StringBuilder &): Assertion `D' failed.
Aborted (core dumped)
Not sure what Assert 'D' is?
Thanks.
--shiv--
module test;
import stdio;
public func int32 main () {
const uint64[2] Dims = {2, 3}
float32[Dims[0]][Dims[1]] p;
p[0][0] = 1;
p[0][1] = 2;
stdio.printf ("%g %g", p[0][0], p[0][1]);
return 0;
}
causes the following error:
c2c: /home/shiv/c2compiler/c2c/CGenerator/CCodeGenerator.cpp:485: void C2::CCodeGenerator::EmitDecl(const C2::Decl *, C2::StringBuilder &): Assertion `D' failed.
Aborted (core dumped)
Not sure what Assert 'D' is?
Thanks.
--shiv--
8
General Discussion / Re: Diffs to C99 and C11
« on: March 07, 2017, 12:14:54 AM »
Looking through the source I see that "#define" is allowed. I also tried and noticed that "#include" is allowed too. Just with those two I can get some of functor like generics that I need.
--shiv--
--shiv--
9
General Discussion / Re: Complex numbers
« on: March 07, 2017, 12:03:09 AM »
In the standard (assuming we include complex.h) only "float/double complex" are allowed. GNU also allows "int complex".
All the arithmetic operators *,+,- are overloaded and ~ means complex conjugation.
If we include tgmath.h then we also get "generic" math functions like sin(), cos(), etc. So, it is actually quite nice!
I wonder if in c2 you should follow Rust's example and have separate modules named float32, float64, complex32, complex64, etc.,
and hide the functions inside each module. That way we could avoid names like sin, sinf, sinc, sinz, etc..
Not sure how to call C macros from C2; otherwise there might be another route though that might not work if you target llvm-ir (?) directly.
--shiv--
All the arithmetic operators *,+,- are overloaded and ~ means complex conjugation.
If we include tgmath.h then we also get "generic" math functions like sin(), cos(), etc. So, it is actually quite nice!
I wonder if in c2 you should follow Rust's example and have separate modules named float32, float64, complex32, complex64, etc.,
and hide the functions inside each module. That way we could avoid names like sin, sinf, sinc, sinz, etc..
Not sure how to call C macros from C2; otherwise there might be another route though that might not work if you target llvm-ir (?) directly.
--shiv--
10
General Discussion / Complex numbers
« on: March 06, 2017, 05:41:57 AM »
What would it take to support complex numbers in c2? I'm assuming c2 does not automatically overload the arithmetic operators so wrappers will have to be written? Thanks. --shiv--
11
General Discussion / Typo in manual
« on: March 06, 2017, 03:43:13 AM »
I just started trying c2 and I ran into an error in the manual. In "My First Project" it suggests using the following as recipe.txt
target hello
$warnings no-unused
$generate-c
hello.c2
end
However c2c complains that "Error: recipe: line 1 expected keyword executable|lib". Replacing "target" by "executable" did the trick for me.
--shiv--
target hello
$warnings no-unused
$generate-c
hello.c2
end
However c2c complains that "Error: recipe: line 1 expected keyword executable|lib". Replacing "target" by "executable" did the trick for me.
--shiv--
12
General Discussion / Diffs to C99 and C11
« on: February 15, 2017, 06:43:38 PM »
I have tried reading through the documentation carefully but I cannot find out what are the precise "evolutions/omissions" over existing standards.
I know that there seems to be discussions about C-style macros. Will the _Generic macro, or something equivalent, be supported? These are quite essential for numerical codes that seek to re-use code over single, double, single complex and double complex numbers. More generically, if macros and #include's are removed, will some other facility be provided for generic programming?
Also, will variable length arrays and multi-dimensional arrays be supported?
Finally, this is outside the standard, what about OpenMP directives?
Thanks.
--shiv--
I know that there seems to be discussions about C-style macros. Will the _Generic macro, or something equivalent, be supported? These are quite essential for numerical codes that seek to re-use code over single, double, single complex and double complex numbers. More generically, if macros and #include's are removed, will some other facility be provided for generic programming?
Also, will variable length arrays and multi-dimensional arrays be supported?
Finally, this is outside the standard, what about OpenMP directives?
Thanks.
--shiv--
Pages: [1]