[Gd-hackers] Fixing up the C backend

[Rayiner Hashem]

Weird. I could'a sworn I remembered to attach it.

Let's try this: http://www.prism.gatech.edu/~gtg990h/c-backend- 
fixup.diff

On Nov 9, 2006, at 6:37 PM, Rayiner Hashem wrote:

> I spent some time this week fixing up OD's C backend. It was in  
> surprisingly good shape, all told.
>
> Attached is a preliminary patch against fundev trunk to fix and  
> enable the C backend. It allows you to run through a three-stage  
> bootstrap, ie: OD/C compiled with itself can compile itself cleanly.
>
> Below is a summary of the changes:
>
> 1) Bring c-run-time up to date, fixing compilation issues, and  
> giving it a Makefile.in modeled on the one in lib/run-time/pentium- 
> linux.
>
> 2) Make sure c-linker doesn't give the same variable both static  
> and extern attributes.
>
> 3) Fix illegal behavior in unix-interface.dylan that OD/HARP accepts.
>
> 4) Update the configure and jam scripts appropriately.
>
> A few things are worth considering:
>
> 1) How do you do backend selection? Currently, I have all backends  
> compiled-in, but selectable only via setting default-back-end().
>
> 2) The Jam changes are pretty ugly. I really don't know enough Jam  
> to do this elegantly.
>
> 3) c-run-time should probably be moved out of the dfmc directory.
>
> 4) My fix to c-emit-object.dylan is a hack. The basic problem is  
> that when the C and HARP back-ends encounter two lexical variables  
> with the same name, they rename them by appending the frame-offset  
> of the variable. However, implicit closure parameters created as a  
> result of lambda lifting appear with the same frame-offset (this  
> happens compiling harp/pentium-harp/bits.dylan).
>
> I'll have to think a bit to fix the last issue. Whether or not its  
> illegal for two lexical variables in the same function to have the  
> same frame-offset, the C backend doesn't otherwise care about frame- 
> offsets anyway, so it shouldn't be using them for variable renaming.
>
> 5) I'm using the dummy threads implementation in the C runtime.  
> I'll fix the pthreads implementation as soon as other things are in  
> better shape.
>
> I think that covers it. I'd appreciate any feedback you guys have  
> on the patch. Oh, and if you get compilation errors in the C code  
> saying that funny symbols are undefined, make sure the linker isn't  
> accidentally seeing OD/HARP-compiled libraries, because those are  
> incompatible.
>
> Sincerely,
>     Rayiner Hashem
>
>
> -- 
> Gd-hackers mailing list
> Gd-hackers at gwydiondylan.org
> https://www.opendylan.org/mailman/listinfo/gd-hackers