>> It is likely that if we use the register passing conventions in the
>> kernel -- it'll be because there is a worthwhile improvement.  I haven't
>> seen a significant one -- YET.  If you see one -- let me know!!!

> The x86 just doesn't have enough registers for this to be worth
> much.  But for NetBSD, looking in a non-x86-specific direction:
>
> I experimented with this on 68030s running More/BSD (Mt.Xinu's
> version of the Utah port of 4.3bsd-Tahoe, or thereabouts) to hp300s.
> I measured worthwhile savings from both passing arguments
> in registers and using callee-pops for non-variadic functions.

Do you have any recollection of what kind of performance improvements
these changes made?

> That was with gcc 1.33; I don't know how much saving to expect from
> gcc2, if and when the -mregparm works again.  I'd definitely encourage
> the NetBSD people with access to m68k machines to try it, though.

There doesn't seem to be much left of m68k regparm support in the
current gcc sources.  Do you recall the calling conventions used in
this mode?  I suppose I could revive support such that it takes the
number of register parameters as an argument to the -mregparm switch
for experimentation purposes.

Jonathan> Are there better alternatives, these days, than rewriting
Jonathan> all the locore routines to use different calling convention?
Jonathan> Like maybe adding attributes to a declaration to disable -mrtd?

Gcc's i386 port has __attribute__((stdcall)).  It shouldn't be
difficult to add it to the m68k port as well.

	--jtc