Re: Registerized function parameters and related things.

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

On Mon, 2 Dec 2002, Fergus Henderson wrote:

> On 02-Dec-2002, Fabio Alemagna <falemagn@studenti.unina.it> wrote:
> > >
> > > 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.
>
> Why do you want/need that?
>
> I suppose on m68k you might need it for backwards binary compatibility with
> AmigaOS.  But why do you need it for non-68k systems?

Because it would make things more predictable, in the first place, and
would also give us more source compatibility.

Things would be more predictable because currently, on machines where
arguments are put on the stack sequentially, the order in which
registerized arguments are put _does_ matter, and that leads too often to
"impossible" bugs hard to track down.

Also, it would make it possible to build a 68k emulator on machines where
the endianess were not a problem, which would transparently jump from/to
68k code: say I want to call a native function from 68k code, in that case
the emulator has to know _where_ to put the arguments of that function,
but it would be just impossible to have the emulator be aware of every
possible function and the layout of its parameters, so the best solution
would be to map each register to something that is fixed for each
function.

Another reason is to speed up function calling, by putting the libbase in
a register. Granted, we could do that by using the libbase as 1st
parameter and using regparm(1), but that would put the libbase in eax,
whilst I want it to go in ecx because eax should be aliased to d0 (always
themost common register for 1st function parameters, and also the 1st
return register, just like eax) and ebx should be aliased to d1, for the
same reasons (just substitute 1st with 2nd).

I'd give  a lot of more examples why I'd do it that way, but those are the
most important ones.

> > > 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.
>
> What's wrong with that solution?

I think I explained it :)

Fabio Alemagna