This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Registerized function parameters and related things.


Hello everyone,

I'm one of the developers of AROS (http://www.aros.org/) and I'm
attempting to port gcc to that Operating System. So far AROS has used the
linux version of gcc as a cross compiler, but now I'd like to build a
customized version of gcc for AROS, which would tackle AROS' specific
needs.

One of these needs, being AROS an AmigaOS clone, would be to be able to
tell the compiler to put certain function arguments in certain CPU
registers.

Now, the m68k-AmigaOS version of gcc already does this, but since AROS is
multi platform, this issue needs to be addressed in a more general way, so
I've come up with an idea that I'd like to implement, but I don't really
know where to put my hands right now, and I'm afraid it will take a long
time before I can really understand how does gcc work, so I'm hoping
someone of you guys will be able / will want to help me dispell some
doubts and shed some light on the right places.

First, a little background: so far AROS has dealt with the registerized
parameters issue by using some special macros, which would expand to
function declarations/definitions which would use registerized parameters
on machines where this feature is available (so far only
m68k-amigaos-gcc), and to normal function declarations/definitions (with
arguments on the stack - or whatever other convention the underlying
machine uses) in case this feature is absent.

As said, I'd like to provide a general AROS-specific ABI for this kind of
stuff, so I'd like to implement it this way:

    1) map certain 68k registers to certain real cpu registers.
    2) map the rest of the 68k registers to *fixed stack offsets*

For example, on the x86 architecture, I'd like to use this mapping:

    D0    -> eax
    D1    -> ebx
    A6    -> ecx

And then I'd put the rest of the register on the stack, at a fixed offset
from the beginning of the stack available to the current functions.

In C, it would be like doing something like this:

struct 68K_Registers
{
    void *A0, A1, A2, A3, A4, A5, A7; /* A7 wouldn't be really needed
                                         since it's the stack pointer
                                         and never a function parameter
                                      */
    long  D2, D3, D4, D5, D6, D7;
};

long general_registerized_function(long d0, long d1, void *a6,
                                   struct 68k_Registers regs)
                                   __attribute__((regparm(3)));

Of course all this should be transparent to the programmer, which would
declare and define its functions like this:

long my_registerized_function(long par1 asm("d0"), long par2 asm("a2"),
                              ...);

It should be possible to have functions with mixed register and stack
parameters.

I've looked at the gcc sources, and I found that the right place to start
fiddling with would be the macro FUNCTION_ARG(), defined in
gcc/config/<cpu>.h, but I found out that this function cannot specify at
which offset on the stack a variable should go. It's not _that_ vital to
be able to specify a precise offset, as long as the compiler produces
working code, but if it were possible to do so, it would allow for
functions declarations like these:

long my_registerized_function1(long par1 asm("d0"), long par2 asm("a2"),
                              ...);

long my_registerized_function2(long par2 asm("a2"), long par1 asm("d0"),
                              ...);

to be considered equivalent and to always produce the same code, which
makes a lot of sense, if you think of it.

I hope someone of you can help me find out where should I put my hands :)

Thanks,
Fabio Alemagna






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]