RE: Variable passing C -> assembly, for m68k?

[David Korn <dkorn at pixelpower dot com>]

>-----Original Message-----
>From: Larry Gray [mailto:larry@greenmotor.com]
>Sent: 17 October 2001 14:37

>	I'm writing (and porting) some assembly language routines and need
to
>know how gcc handles variable passing.

  The name of this thing you are looking for is a "calling convention", or
an "ABI spec", so a websearch for something like "m68k calling convention
abi stack frame compiler" should get you some useful information (you might
need to match 'any words' rather than 'all words' though).
>I've read through "Using and Porting GCC", but can't find anything
>specific. It appears that in some architectures it uses the stack in others
>registers.

  And in many it uses both!

>I know I can use inline assembly and operand constraints, but would prefer
>to use standalone assembly programs that can be called from my C program.

  For major chunks of code, I'd say that is the right decision - all that
cruft in the gcc inline asm spec is so that assembly can be interleaved with
C and access all the same variables conveniently whilst giving gcc the info
it needs to track what variables are in what registers etc.  Because gcc
isn't generating any code that needs to be part of the asm routines you are
writing, this would all be unnecessary overhead.

>	Where could I find the specific details for how gcc handles this for
>the m68k? Did I overlook it?

  Nope, but it won't be in the gcc documentation: ABI specs tend to be very
large documents, and gcc covers dozens of them, and in any case the docs
that define an ABI are very often copyrighted by the manufacturer of the
chip or OS, so it's just not on.  It might be worth going straight to
www.sps.mot.com and trying a search of the motorola semiconductors
division's site.

  IIRC, it's something fairly close to:

  - pass the first (up to) two integer-type args (not floats or pointers)
    in d0, d1

  - pass the first (up to) two pointer-type args in a0 and a1

  - what happens about floating point depends on whether you have an FPU
  or not, I can't comment, but it might well use fr0 and fr1 when you have
  one or pass the floats in the d-regs if not.

  - you'll also have to fill in the details about how structs > 32 bits
  are passed by value

  - the remaining args are pushed on the stack in right-to-left order

  - the function can use d0-d1, a0-d1 in any way it likes and does not
  need to save/restore these registers, they are guaranteed to be free for
  use (once you've gotten your function args out from them, of course!)

  - all other registers MUST be saved on entry and restored on exit if they
  will be used during the course of the function, and a5 and a6 may be 
  entirely reserved for the compiler's use as a data segment base pointer
  and a frame pointer, respectively, so should perhaps not be modified even
  if you are planning to save/restore them  (depends on whether your asm
  routines might want to do function calls back into the C code, or whether
  a signal might be received while your asm is running and divert the task
  into a routine where it would expect a5/6 to be valid, and whether or
  not a5 is reserved might conceivably be variable depending on whether you
  are using PIC or absolute code).

  - results should be returned from the function in d0 or a0 for int types
  or pointers (fp and structs you'll have to figure out yourself)

   hth,
       DaveK
-- 
Burn your ID card!  http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!


>To: crossgcc@sourceware.cygnus.com
>Subject: Variable passing C -> assembly, for m68k?
>
>
>
>Thanks in Advance,
>Larry Gray
>larry@greenmotor.com
>
>------
>Want more information?  See the CrossGCC FAQ, 
>http://www.objsw.com/CrossGCC/
>Want to unsubscribe? Send a 
>note to crossgcc-unsubscribe@sourceware.cygnus.com
>


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com