mframe on MacOS X/Darwin PPC

[Bill Northcott]

I have recently pitched in to try and fix the mframe code in Swarm to  
work properly on MacOS X.

This code is essentially identical to the code in GNUstep base and so I  
would appreciate any comments that people here may have on my  
understanding of how it should work before I spend the time to rewrite  
the code.

I reproduce below most of a message to the Swarm developers list.  My  
apologies to any of you who may have seen it there.

As far as I can see, there is no existing documentation. (Unless you  
know otherwise).

This is the way I think it works.
1. For a good description of the PowerPC argument frames see Apple's  
'PowerPC Calling Conventions' at
      
http://developer.apple.com/documentation/DeveloperTools/Conceptual/ 
MachORuntime/index.html
2.  From that document I gather the following:
     There are 8 integer registers (GPR3 - GPR10) available for  
arguments <= 4bytes.
     Small arguments are padded ON THE LEFT (different to AIX and PPC  
linux?)
         I think this is the cause of the Swarm (and GNUStep?) failures  
with small return values (char and small int).
     Large arguments like structures are padded on the right.
     There are 13 4-byte FP registers (FPR1-FPR13) available for floats  
and doubles.
     In the G4 and G5 there are 12 available vector registers.  I think  
mframe knows nothing of these.
     As arguments are read they are stored in the first available  
suitable register.  Floats require 1 FP reg
     and doubles require 2.
     Now for the tricky bit each FP register used will prevent the use  
of one GPR.
      ie r*@:difi  wil be stored as
      @ GPR3
      :    GPR4
      d   FP1 & 2  (disabling GPR5 & 6)
      i    GPR7
      f    FP3         (disabling GPR8)
      i    GPR9

     Finally  spaces are also allocated in the stack for all register  
variables.  This is so that the routine can store
     the registers  when calling a subroutine
     It seems that gcc debug builds may actually copy the registers  
into the stack by default or that may
        happen under gdb.

   It appears that the most of above was unknown to the original writer  
of the powerpc bits of mframe.h
       because the old versions (including the current one in GNUstep)  
are hopelessly wrong!

  3.  My futzing reveals that
        r*@:difi   should be rendered somewhat as  
{r*XX@+4:+8d+40i+20f+48}  where
         + indicates a register value and numbers greater than 32 are  
32+(bytes in FP registers).
         The + may actually be ignored or that may just be the debug  
builds.
         XX may be necessary, but I don't understand it yet.

4.  The MFRAME_FLT_IN_FRAME_AS_DBL macro appears both broken and  
unneccessary.
      Floats are actually half passed as doubles because they are  
occupying two FP registers but only one
      4 byte stack slot, which looks to me like a recipe for a crash.
     I propose to turn this off and rewrite mframe.h to handle floats  
and doubles properly.  Please scream
     if you think this change may be a problem elsewhere.

5.   The type encoding example given in all the GCC manuals I can find  
seems to be misleading and uses b999
       in the type strings.  I don't understand this.

I would appreciate it if anyone who knows or even thinks that some of  
the above may be wrong, could
let me know before I rewrite the mframe stuff.
It would also be good to receive any other wisdom on this topic.

My current version has fixed the register variable tests r*@:ifd ,  
r*@:idf , r*@:fdi, r*@:dfi and r*@:fdii.  It still breaks on r*@:ffdii   
where we run out of registers because the stack position is not being  
computed properly (or indeed at all!)

Bill Northcott

PS There may need to be changes for G5 and even more changes for 64bit  
OS on G5.