Re: Integrating a new front end to GCC - avoiding flames later

[Tim Josling <tej at melbpc dot org dot au>]

Thanks for the feedback Geoff, much appreciated.

Can you point me to any doc/code on the garbage collection? Just
a starting point will do. I have downloaded the full 21 Dec
snapshot. Presumably its in there somewhere.

Certainly I would use the approved methods for allocating the
trees. 

But I will probably take a similar approach to f77 where I do my
own parse with my own symbol table and then at the end (of
function or the file, not sure) I then build the gcc back end
trees via the standard call . This would avoid having to retrofit
everything into the tree.h structure. I guess this could be done
later anyway.

COBOL has funny things like the fact that duplicate names are OK
as long as you don't reference them. Also the BCD data does not
map into the trees at all. Decimal numerics have attibutes of
number of digits, format (packed, ascii, binary!), signed or not,
sign a separate byte or not, sign leading or trailing or
"overpunched".

On the BCD, the x87 also does have some bcd instructions but they
were dropped in the merced chip. I'm not sure they are very fast
either. You also have to change the control bits to use them
effectively. Also the format supported is different from the IBM
mainframe format, which is mandated by the X/Open standard,

Tim Josling

Geoff Keating wrote:
> 
> You should look very carefully into garbage-collection issues before
> doing this.  The tricky bits are:
> 
> - If COBOL has global variables, which I expect it does, you will want
>   to keep the trees for the variables around between function compilation.
>   So you will need to be able to tell the GC that they are still used.
>   This may mean you need to explain to the GC how your symbol table works,
>   so it can find all the trees you have allocated.
> 
> - If you are using GC, you cannot allocate trees _without_ using the GC.
>   This would cause it to crash.
> ...
> Yes, this often happens.  That's fine.  BCD support is one of the
> things that GCC doesn't have yet, because so far no language has
> needed it.
> 
> The m68k has hardware support for this.  I think the x86 machines do
> too, although I'm not sure that it's fast.
> 
> - Geoffrey Keating <geoffk@cygnus.com>