GCC target-specific extension

GCC target-specific extension

[Fabio Alemagna]

Hello Richard,

I'm sending this to you directly because I guessed you'd be the right guy
who could shed some light on my problem, being the manteiner of the C
frontend and gcc itself (if I got things right).

I'm merely referring to an email I sent to the list yesterday... seeing
the amount of traffic on the list, I had expected someone to answer.

The email I sent is this: http://gcc.gnu.org/ml/gcc/2003-05/msg00391.html

I know that if no answer has come so far it might be because no one is
interested in giving it to me, but if it's so, well, this is a way to make
sure of it :)

In any case, sorry if all this bothers you, and also sorry for the email I
sent you by mistake about 10 minutes ago.

Regards,
Fabio Alemagna

Re: GCC target-specific extension

[Richard Henderson]

On Tue, May 06, 2003 at 11:59:47PM +0200, Fabio Alemagna wrote:
> The email I sent is this: http://gcc.gnu.org/ml/gcc/2003-05/msg00391.html

There is no easy way to do this.


r~

Re: GCC target-specific extension

[Joe Buck]

On Tue, May 06, 2003 at 11:59:47PM +0200, Fabio Alemagna wrote:
> Hello Richard,
> 
> I'm sending this to you directly because I guessed you'd be the right guy
> who could shed some light on my problem, being the manteiner of the C
> frontend and gcc itself (if I got things right).
> 
> I'm merely referring to an email I sent to the list yesterday... seeing
> the amount of traffic on the list, I had expected someone to answer.

Your expectations need to be adjusted; you are expecting extremely busy
people to just jump because you say so.  Worse, you are calling on one
specific individual to jump.

> In any case, sorry if all this bothers you, and also sorry for the email I
> sent you by mistake about 10 minutes ago.

Please do not single out individual GCC developers to help you with problems.

Re: GCC target-specific extension

[Fabio Alemagna]

On Tue, 6 May 2003, Richard Henderson wrote:

> On Tue, May 06, 2003 at 11:59:47PM +0200, Fabio Alemagna wrote:
> > The email I sent is this: http://gcc.gnu.org/ml/gcc/2003-05/msg00391.html
>
> There is no easy way to do this.

Right, guessed so. And would you be interested in helping me explore the
"hard" ways, if there are any?

Would the front-end be the right place to hack (I know, that wouldn't make
it target-specific anymore, but better than nothing)?

Fabio Alemagna

Re: GCC target-specific extension

[Fabio Alemagna]

On Tue, 6 May 2003, Joe Buck wrote:
> > I'm merely referring to an email I sent to the list yesterday... seeing
> > the amount of traffic on the list, I had expected someone to answer.
>
> Your expectations need to be adjusted; you are expecting extremely busy
> people to just jump because you say so.

Gee, I knew someone would jump out of the dark just to say this. If you
had bothered reading the part you snipped, you'd have noticed that I
*accounted* for people not having the WILL to answer (because you
apparently found the TIME to answer, even if the answer is not the proper
one), but the only way to make sure was the one I took, or else I'd have
had to wait for an indefinite amount of time just to realize that
evidently no one cared to give me an answer. If that sounds like a good
strategy for you, well, it doesn't for me.

> Worse, you are calling on one specific individual to jump.

I thought that the MANTAINER list served exactly that purpose, doesn't it?

> > In any case, sorry if all this bothers you, and also sorry for the email I
> > sent you by mistake about 10 minutes ago.
>
> Please do not single out individual GCC developers to help you with problems.

I'd leave the individual GCC developer the right to decide whether that's
a good thing or a bad one, don't you think?

Regards,
Fabio Alemagna

Re: GCC target-specific extension

[Joe Buck]

On Wed, May 07, 2003 at 12:16:01AM +0200, Fabio Alemagna wrote:
> On Tue, 6 May 2003, Joe Buck wrote:
> > > I'm merely referring to an email I sent to the list yesterday... seeing
> > > the amount of traffic on the list, I had expected someone to answer.
> >
> > Your expectations need to be adjusted; you are expecting extremely busy
> > people to just jump because you say so.
> 
> Gee, I knew someone would jump out of the dark just to say this.

Answered off-list.

Re: GCC target-specific extension

[Richard Henderson]

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?


r~

Re: GCC target-specific extension

[Fabio Alemagna]

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

Re: GCC target-specific extension

[Fabio Alemagna]

On Wed, 7 May 2003, Fabio Alemagna wrote:
> 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.

Hum... looking at struct attribute_spec right now... is the handler
supposed to be able to do just the above? At least this is what I
understand by reading the comments in the gcc/tree.h:


  /* Function to handle this attribute.  NODE points to the node to which
     the attribute is to be applied.  If a DECL, it should be modified in
     place; if a TYPE, a copy should be created. [...] */

Re: GCC target-specific extension

[Richard Henderson]

On Wed, May 07, 2003 at 01:33:44AM +0200, Fabio Alemagna wrote:
> 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),

Oh, I thought a parameter was where you were getting your 
libbase in the first place.

> 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?

No.  We have enough problems with moderately well-defined
extensions.  Arbitrary transformations are right out.


r~

Re: GCC target-specific extension

[Fabio Alemagna]

On Tue, 6 May 2003, Richard Henderson wrote:

> On Wed, May 07, 2003 at 01:33:44AM +0200, Fabio Alemagna wrote:
> > 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),
>
> Oh, I thought a parameter was where you were getting your
> libbase in the first place.

Implicitely, not explicitely. It's like a C++ virtual method call, the
libbase being the "this" pointer.

But anyway, if you had to do such a hack, where wouuld you start lokking
at? The frontend or the backend? (I see you've avoided answering this
question twice already, let's see if you answer now ;D)

Thanks for your help, though.

Fabio Alemagna

Re: GCC target-specific extension

[Richard Henderson]

On Wed, May 07, 2003 at 07:51:00AM +0200, Fabio Alemagna wrote:
> But anyway, if you had to do such a hack, where wouuld you start lokking
> at? The frontend or the backend? (I see you've avoided answering this
> question twice already, let's see if you answer now ;D)

I'd look at the linker.

You're clearly trying to implement shared libraries, only not
in any standard way, for some reason.  You should admit you're
implementing shared libraries and as such it's largely an
assembler/linker problem.  Yes, there's some amount of backend
work, but that's not the bulk of the problem.

You should also look at why you care that deeply.  If it really
is shared libraries you're after, why is the way you're trying
to do it better than what's implemented elsewhere.  Replicating
the mechanisms used by a 20 year old m68k OS for use on some 
other cpu is not an interesting reason, IMO.


r~

Re: GCC target-specific extension

[Fabio Alemagna]

On Wed, 7 May 2003, Richard Henderson wrote:
> On Wed, May 07, 2003 at 07:51:00AM +0200, Fabio Alemagna wrote:
> > But anyway, if you had to do such a hack, where wouuld you start lokking
> > at? The frontend or the backend? (I see you've avoided answering this
> > question twice already, let's see if you answer now ;D)
>
> I'd look at the linker.
>
> You're clearly trying to implement shared libraries, only not
> in any standard way, for some reason.

Ehum... That's the standard way shared libraries work on
AmigaOS/AROS/MorphOS, I cannot change that.


> You should admit you're implementing shared libraries and as such it's
> largely an assembler/linker problem.  Yes, there's some amount of
> backend work, but that's not the bulk of the problem.
>
> You should also look at why you care that deeply.  If it really
> is shared libraries you're after, why is the way you're trying
> to do it better than what's implemented elsewhere.  Replicating
> the mechanisms used by a 20 year old m68k OS for use on some
> other cpu is not an interesting reason, IMO.

It's for binary compatibility, source compatibility and also because it's
not a bad solution at all. Moreover, it's the only scalable solution on
systems without memory protection and virtual memory, like AROS (which I
work on) is.

Fabio Alemagna

Re: GCC target-specific extension

[Michael S. Zick]

On Wednesday 07 May 2003 12:51 am, Fabio Alemagna wrote:
> On Tue, 6 May 2003, Richard Henderson wrote:
> > On Wed, May 07, 2003 at 01:33:44AM +0200, Fabio Alemagna wrote:
> > > 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),
> >
> > Oh, I thought a parameter was where you were getting your
> > libbase in the first place.
>
> Implicitely, not explicitely. It's like a C++ virtual method call, the
> libbase being the "this" pointer.
>
Just lurking on the sidelines here, but perhaps that is a workaround
to consider:
Define a C++ "wrapper" for your library;
The entry points in your library as virtual methods;
Compile;
Do some linker magic to extract just the virtual method table.

Mike

PS: Too bad about "arbitrary transforms" being out of the 
question - no: C++ -> Basic allowed 
[GoSub( virtual-method, arguments...)].