C code generation

General discussion for topics related to the FreeBASIC project or its community.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: C code generation

Post by caseih »

If you want to learn C tricks, learn C tricks. But C can already be used directly in FB programs. I can trivially blend C and FB source code together just by using different files. If you're coding in a modular way you should already be breaking your code up into multiple files; it makes compiling a lot faster when you do that and make changes later on. So use C where it makes sense, use FB where it makes sense.

So just link in the C .o file.

If there was something that you just couldn't easily do with FB code, then the idea of embedding inline C code would have merit, much like embedding ASM code has merit in both C and FB.

Furthermore embedding C code is not as trivial as you make out. For example you couldn't just do this easily without significant processing by the FB compiler (which would make it a C compiler as well as an FB compiler):

Code: Select all

type MyType
    x as long
    y as long
end type

declare somefunc() as MyType Ptr

dim b as MyType Ptr

b = somefunc()

inlinec
    printf("%d, %d\n",b->x, b->y);
end inlinec
Any C reference to FB symbols would have to be processed and converted because there are differences in how the variables are actually named and referred to in the emitted C code. Just examine the C output from FBC and you'll see what I mean.

Personally if you're going to go to the work of making FB be able to parse C code, I'd far rather have FBC natively be able to include C header files (complete with preprocessing) in FB programs. That would make it trivial to interact with any and all C libraries out there without having to translate the header files.
Emil_halim
Posts: 48
Joined: Feb 19, 2007 21:59
Location: Alex, Egypt
Contact:

Re: C code generation

Post by Emil_halim »

Hi caseih,

that's exactly what i want , and thank you for your presentation.

but if we will make that with gcc back_end , we have not to force FBC to parse code just like c. because with gcc back_end we can just emit the inline c block within translated FBC basic code in one c file then gcc will do the rest.
Emil_halim
Posts: 48
Joined: Feb 19, 2007 21:59
Location: Alex, Egypt
Contact:

Re: C code generation

Post by Emil_halim »

here is an example

Code: Select all


declare function sum( byval a as integer, byval b as integer ) as integer 


Asm
	   
	   int sum( int a, int b ) 
	    { 
		      return a + b;
	    }
	
End Asm

print "1 + 2 ="; sum( 1, 2 )

compile it with this fbc -s console -asm intel -R -gen gcc

so if ASM End ASM can emit the block as is , i.g. without parsing it , so i can use this trick for inline c stuff without hacking the FBC itself.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: C code generation

Post by caseih »

Guess I'm not making myself clear. What you ask for is not trivial at all. My example was supposed to show that. Sorry I wasn't clear. You can't just drop C code into the output stream. Doesn't work that way because of the way symbol names are handled by FBC.

Here's a simple FB program followed by relevant portions of the C output:

Code: Select all

type TestType
    x as long
    y as long
end type

dim foo as TestType

foo.x = 3
foo.y = 4

print foo.x
print foo.y
Output:

Code: Select all

struct $8TESTTYPE {
        int32 X;
        int32 Y;
};
#define __FB_STATIC_ASSERT( expr ) extern int __$fb_structsizecheck[(expr) ? 1 : -1]
__FB_STATIC_ASSERT( sizeof( struct $8TESTTYPE ) == 8 );
void fb_PrintInt( int32, int32, int32 );
static void fb_ctor__test( void ) __attribute__(( constructor ));

__attribute__(( constructor )) static void fb_ctor__test( void )
{
        label$0:;
        struct $8TESTTYPE FOO$0;
        __builtin_memset( &FOO$0, 0, 8ll );
        *(int32*)&FOO$0 = 3;
        *(int32*)((uint8*)&FOO$0 + 4ll) = 4;
        fb_PrintInt( 0, *(int32*)&FOO$0, 1 );
        fb_PrintInt( 0, *(int32*)((uint8*)&FOO$0 + 4ll), 1 );
        label$1:;
}
As you can see, FBC would have to parse your C code and translate variable names to be compatible with the emitted FBC C code. Put in another way, UDT TestType is not simply struct TestType; It's struct $8TESTTYPE. And foo is FOO$0. FBC mangles variable names for certain reasons. Your inline C code would have to be mangled in a compatible way. To do that FBC has to parse the C code. That would make FBC essentially a C compiler as well as a FB compiler! I doubt you'll convince any of the volunteer developers to go down this route.

Furthermore you haven't made a case as to why you would want to do that. The trivial examples shown so far are 1:1 equivalent with their FB versions. So why need C at all? If one is to add C parsing capabilities to FBC, use them to parse .h files into the FB abstract syntax tree and symbol table. Far better to keep C code in completely separate object files and interact through calling functions and well-defined, aliased symbols.
multineu
Posts: 22
Joined: Oct 15, 2010 7:29

Re: C code generation

Post by multineu »

Maybe the final goal will be reached when llvm backend will be ready.
multineu
Posts: 22
Joined: Oct 15, 2010 7:29

Re: C code generation

Post by multineu »

My request of C code inline (I do again repeat) is simle:
GPU computational power is a sweet candy that no one can resist for a long while.
Having a cuda board into the pc withut using it for general purpose computational tasks is a shame.
C++ code of the cuda toolkit is powerful and not too complicated to learn.
An example of C cuda code:

__global__ void sum(int *a,int *b,int *c,int len) {
int i=threadIdx.x + blockDim.x*blockIdx.x;
if (i<len) c=a+b;
__syncthreads();
}

int len=65536;
int *a,*b,*c;
// here it goes cudaMalloc for the a b c arrays
sum<<<len/512,512>>>(a,b,c,len)
// here it goes cudaFree

as you can see it is very easy to do a simple sum of arrays in cuda.
Changing a bit the C backend and introducing new references on how to use the thread*** and block*** would be possible to generate C code using cuda. Am I fool?
Emil_halim
Posts: 48
Joined: Feb 19, 2007 21:59
Location: Alex, Egypt
Contact:

Re: C code generation

Post by Emil_halim »

okay , thanks again for your clarification. now i got it.

the best solution as you mentioned above is to use c code in separate module and compile it with gcc then later link to object file.
grindstone
Posts: 862
Joined: May 05, 2015 5:35
Location: Germany

Re: C code generation

Post by grindstone »

Maybe there could be implemented a kind of '#includeC' - statement for C - sources. But that wold be a challenge for the linker.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: C code generation

Post by caseih »

grindstone wrote:Maybe there could be implemented a kind of '#includeC' - statement for C - sources. But that wold be a challenge for the linker.
It would be a challenge for the compiler to interpret C symbols in a FB compatible way, but not for the linker. In fact from a linker perspective nothing would change over the current situation. Right now to use gtk+, I unclude the gtk .bi files, and then in the compile step I specify the appropriate libraries with -l. Or I could specify the libraries using the standard FB #inclib statements. For portability reasons, and compatibility with build/make systems, I think specifying libraries on the command line of fbc is better than using #inclib. Native C header import would not change this in any way.

However, having this feature isn't going to happen anytime soon for similar reasons as inline C code. FBC would have to be a C compiler essentially. Or be tightly integrated with one (LLVM perhaps).
multineu wrote:My request of C code inline (I do again repeat) is simle:
GPU computational power is a sweet candy that no one can resist for a long while.
Having a cuda board into the pc withut using it for general purpose computational tasks is a shame.
C++ code of the cuda toolkit is powerful and not too complicated to learn.
I don't think this request is simple, though, for the reasons already stated. Accessing FB symbols in the C code would be a challenge as the compiler mangles them. So FBC would have to parse C code and translate the symbol names for you, which means you essentially have to make FBC a C compiler too (the same is true of including C header files).

Perhaps the best bet is to take the C code emitted by FBC and compile it against your CUDA code in its own .C file with nvcc?
multineu
Posts: 22
Joined: Oct 15, 2010 7:29

Re: C code generation

Post by multineu »

Yes I did it: porting an FBC program in C, restructuring it to accomodate the CUDA contest and then recompile it.
It runs; ok but the procedure must be done once: the step to integrate CUDA context is not very easy.
Maybe FBC does not have to worry about C symbols and syntax: the user is responsible of what he types and the NVCC compiler (the one who calls the GCC afterwards).
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: C code generation

Post by marcov »

Emil_halim wrote: so if ASM End ASM can emit the block as is , i.g. without parsing it , so i can use this trick for inline c stuff without hacking the FBC itself.
Only if FB a maps to C a.
Emil_halim
Posts: 48
Joined: Feb 19, 2007 21:59
Location: Alex, Egypt
Contact:

Re: C code generation

Post by Emil_halim »

marcov wrote: Only if FB a maps to C a.
sorry i did not got it , can you please explain it.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: C code generation

Post by marcov »

Emil_halim wrote:
marcov wrote: Only if FB a maps to C a.
sorry i did not got it , can you please explain it.
I was wrong I think, parameters are used not global vars, that should work.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: C code generation

Post by caseih »

Emil_halim wrote:
marcov wrote: Only if FB a maps to C a.
sorry i did not got it , can you please explain it.
Like Marcov said, I see that your code refers to no FB variables. So in this limited case maybe it would work.
Post Reply