Hi,
Tony Wyatt wrote:
What about some advice on coding habits?
Bah, I'm not a teacher :) And I don't have any skill sin teaching whatsoever... I can't even explain very well...
Much old 68k code is fast and efficient because it relies on parameters like library and structure pointers remaining persistent in allocated 68k registers, eg a2, a6 always point to particular structures. In a big module consisting of dozens if not hundreds of very small functions, only one or two registers are ever used for volatile data. Most parameters are passed in assumed registers, so loading of arguments is minimised.
Uh, I beg to differ. I think he old habbit of keeping certain registers set up with a default meaning is the worst you can do, /especially/ when you have so little registers as the 68k. You say loading of arguments is minimised, but that's wrong.
The effect is two-fold:
1. Since some registers are fixed, this results in lots of splilling of scratch registers. A lot of code is "just" about moving stuff from memory into registers, manipulating it, and storing it back. Sure, the 68k can do a lot of it's operations also in memory, but that's much slower. The result is that with fixed registers like this, theamount of availabele registers is decreased. 2. Fixing registers will make them hang around forever, even when they aren't used. What use is it to have a2 and a6 constantly setup when there's no need for them at the moment, and they could be reused for other stuff ?
Modern compilers make "lifeliness analysis" (sp?): They assume "virtual" registers, analyse their life cycle, and assign them to hardware registers. This is nearly optimal in modern compilers, and far bettern than you would do it in your hand-written assembly code.
So what is a good way to maintain this register shortcut in a C version of a big program originally written in assembler? Obviously I can specify parameters to be passed in 68k registers, but I am trying to write this thing in a portable fashion, machine-independent.
There's not really any way to enforce this in C on the PPC. You can not assign a register to a variable, for example, and as I explained above, I wouldn't do that. One of the things to remember about the PPC is that it is a pure load/store architecture: You can not, like on the 68k, manipulate data in memory. It _must_ be in registers to be processed. The compiler will do this optimally, it will also try to keep variables in registers where appropriate, based on it's analysis.
I have no experience with PPC code yet. Is there a way to ask gcc to use registers for certain parameters, in a platform-independent way? I want the C code to remain pure ANSI-compliant. It would be nice to leave the code unchanged from its present SAS/C environment to PPC and gcc.
ANSI-compliant and specifying registers doesn't really mix ;)
There's no way to specify the placement of parameters on OS4. It's fully System V.4 compliant.
System V.4 places integer and pointer parameters into r3 - r10, and floating point parameters into f1 - f10. Excess parameters (which doesn't happen that often) are put on the stack. The only exception to this in OS4 is the VARARGS68K attribute, which places all parameters on the stack, to cope with 68k compatibility.
BTW, Linux PPC also uses the System V.4 ABI, so if for example Kaffee already contains trampoline code for Linux PPC, you can re-use that, it won't be different in OS4.
So bottom line, the best way to do it on OS4 is not to specify the placement, and everything should fall into place. Plus, the compiler will definitely know better how to use registers.
Regards,