Re: Code Generation

[colin at field dot medicine dot adelaide dot edu dot au]

> > I think we're not agreed that including explicit functionality is
> > necessarily cleaner than including a functional reference.  If there
> > were a number of different applications which might make exclusive
> > use of the compiler's information (and I'm guessing there are) then
> > it seems to me to be semantically cleaner to provide the hook, and
> > decouple the implementation.
> 
> I use 'semantically clean' here to include 'generated code executes
> correctly'. This is a top requirement for compilers, and assembler
> macros certainly break that. If you fix that, you probably find that
> you can't do anything inside the macro except to call a function.

Assembler macros certainly can break that, they don't necessarily break it, of course, any more than adding complexity to a compiler necessarily makes it more labile.  There's a risk in both directions, but only one direction applies even to people who don't choose to use the added functionality.

There's one thing a macro can do that a function call can't, and that's conditionally generate no code at all.

> > I wanted to float the idea of opening up the back-end to people like
> > me, who really +don't+ want to tinker with compilers, or distribute
> > compilers, but who need access to some of the metadata in the
> > compiler.  I think the best way to do it, once and for all, is to
> > define an interface for the backend transfer of the metadata, and I
> > think the least intrusive way is as I've described.

> Well, go ahead. My other concern would be that the day you've
> implemented the macro generation, you find that a certain application
> that falls into the category 'access to compiler metadata' can't be
> implemented on top of your macros.

Yes.  I guess there's always metadata that one could collect and propagate that one has neglected.  Perhaps one way to find out what that might be would be to provide the facility, and see what's missing for a given application.

Given that one would have to find a C-addressable form for compiler metadata, should one choose to treat the generated hooks as function calls, it's more of a headache to add new arguments to a hook than to use the fairly limited but essentially free facilities available through a post-pass, be it m4, PERL, or gas.  So it would seem to me, anyway.

Assuming that the goal of openly supplying metadata to either a post-process, or the application itself, is worthwhile, and given that I'm fairly interested in having and or doing it, what do you really think is the best way to do it?

Colin.