The calling convention is identical.  The normal function call mechanism
uses a relative branch instruction which has a 26 bit offset with the two
LSBs forced to zero, hence you can only jump forwards or backwards up to 16
MB (which leads to people saying that programs under 32 MB are not affected,
which is not precisely correct).  The "longcall" mechanism moves a full 32
bit value into a register and then jumps to the value contained in the
register.  Both mechansims support the LK bit to set the link register with
the effective address of the instruction following the bring instruction.

Also recall that there is no stack in the PowerPC programming environment,
all stack operations are purely software (and hence independant of the
hardware instruction used to call the function).  In NetBSD's case, the
stack is dictated by the SVR4 PowerPC ABI.

Gregory

> -----Original Message-----
> From: Todd Vierling [mailto:tv@wasabisystems.com]
> Sent: Monday, August 07, 2000 10:41 PM
> To: Bill Studenmund
> Cc: port-macppc@netbsd.org
> Subject: RE: Do LKMs work *at*all* on powerpc platforms?
> 
> 
> On Mon, 7 Aug 2000, Bill Studenmund wrote:
> 
> : > : > > I think adding something like -mlong-call and 
> __attribute__ ((short-call))
> : > : > > would be the most efficient thing. :-)
> : 
> : Oops! This option would ONLY be for the LKM's, not the 
> kernel compile. :-)
> 
> However, does this mean that there's a `different' calling 
> convention for
> the kernel vs. LKMs?  i.e. stack has `more' on it with one 
> method than the
> other, you can't just rts from long-call code into shortcall. 
>  An example of
> `incompatible' calling conventions is the m68020 CALLM/RTM 
> vs. the usual
> [JB]SR/RTS.
> 
> If the calling methods aren't directly compatible, the kernel 
> shouldn't be
> littered with attributes on functions, even in the LKM 
> itself.  One link
> unit should use one calling convention specified on only the 
> command line,
> wherever possible.  This probably means extra overhead inside the
> LKM-compiled code, but `you get what you pay for' wrt LKMs.
> 
> One other option is to use PIC.  Position-independent code 
> directs jumps and
> references through the PLT and GOT, which could(?) be a lower 
> overhead than
> -mlong-call--this would need to be tested.  PIC code can link 
> against a
> static binary such as `netbsd' fine; the PLT and GOT are 
> filled at link time
> with absolute addresses in that case.
> 
> : Also, could we teach all other ports about it, -mlong-call 
> (and to ignore
> : it), or make some sort of include file magic happen?
> 
> That's probably not the best idea; you're probably better off 
> adding it to
> <bsd.kmod.mk>, which is used by LKMs to build.  Additional 
> CFLAGS can easily
> be added there.
> 
> -- 
> -- Todd Vierling <tv@wasabisystems.com>  *  
http://www.wasabisystems.com/
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.