["Nathan J. Williams" <nathanw@wasabisystems.com>, replying to me]
>> (b) the Unix PALcode
> PALcode generally has its own set of implementation-dependent
> registers that you can't get to from non-PAL mode anyway.

[same attributions, another message]
> I think the short version is:
>> (a) hardware
> The zero register.
>> (b) palcode
> No registers in the ordinarly avaliable register set.

I'm sure I saw one reference that spoke of one register that the
PALcode made assumptions about in some cases.  I think it was $sp but
I'm not sure - I can't seem to find the reference now.  For my purposes
I have to support signal delivery, so $sp is reserved anyway, but I
wanted to make sure there weren't any other lurking surprises.

>> (d) compiler
> This is trickier.  AT and GP are the ones most likely to get you in
> trouble, but at this point you'll need to get a good sense for the
> ABI, and I'm not sure how you're planning for your asm code to
> interact with compiled code.  Within a leaf function, I think you can
> bash everything except sp (see above) and you only need to restore
> s0-s6 and ra.

I expect to be a leaf function in most respects.  If I do have to call
anything else, I'll either do it by returning and letting the C code
that called me handle it or I'll save my own state first and restore
something more like what I was called with.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B