Re: GCC target-specific extension

[Fabio Alemagna <falemagn at studenti dot unina dot it>]

On Tue, 6 May 2003, Richard Henderson wrote:

> On Wed, May 07, 2003 at 12:10:32AM +0200, Fabio Alemagna wrote:
> > Right, guessed so. And would you be interested in helping me explore the
> > "hard" ways, if there are any?
>
> Not really.  Why are inline functions or macros not sufficient?

Inline functions aren't good because they need a global libbase (unless
you passed one to it as parameter, which again I want to avoid), and
macros are not sufficient because you can't have macros like this:

    #define function(x, y, z, k) (*real_function_ptr)(libbase, x, y, z, k)
    #define foo function(x
    #define end k)

and then do this:

    foo,
        y, z,
    end

That notation is widely used as a way to write GUIs in more than a couple
of frameworks in the AmigaOS/AROS/MorphOS environments. Right now we use
plain functions for that, but that carries the problem of requiring a
global libbase, and it gives a lot of headaches when dealing with vararg
functions on architectures which don't put all arguments on the stack by
default (for reasons which I'n not going to discuss here now).

Also, having the compiler be aware of such kind of functions would let us
automatically build a "vector table" for the library functions (and this
was the problem I addressed in one of the last 2 points in my original
email).

A vector table is much like a virtual table for C++ classes, which leads
me to think whether it could be a good idea putting support for this kind
of functions into the frontend, and let the backend generate the proper
code automatically.

Is that possible/advisable? If so, do you have any idea on where could I
at least start looking at?

Last but not least: would it be welcome a frontend feature which let
target-specific code "transform" declarations/definitions on the basis of
given attributes? Something like a "filter" which gets feeded with the
tree for the decl/def, and returns back another tree, possibly different
than the one it was feeded with. This would let any other targets cleanly
handle similar needs.

It could be implemented like this (pseudocode):

    struct frontend_attrib2filter_t
    {
        char           *attrname;
        filterfunc_ptr  func;
    };

    struct frontend_attrib2filter_t fe_a2f[] =
    {
        {"attribute1", func1},
        {"attribute2", func2},
        ...
        {"attributen", funcn}
    };

and then the frontend would automatically call the various functions each
time it encountred a decl/def with attached the attribute listed.

Of course the array above could be internally converted in a hash list, or
some other more efficient structure.

Hope it all made sense.

Regards,
Fabio Alemagna