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]

Re: Registerized function parameters and related things.


Ehm... sorry to repost the whole email, but is it really so that no one is
willing to/can answer to these my questions?

Any help would be appreciated, even just some docs to read, thanks.

Fabio Alemagna

On Sat, 30 Nov 2002, Fabio Alemagna wrote:

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