Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:14:01
Eric Young (eay@cryptsoft.com)
Mon, 28 Sep 1998 16:45:24 +1000 (EST)
Ok, what I have definitly been able to find out...
On 28 Sep 1998, Niels Möller wrote:
> > Are the global registers preserved across function calls?
>
> Do you mean "unaffected by register window shifting" or "preserved by
> convention"? In any case, I think the answer is yes (that's more or
> less the definition of "global": They are unaffected by register
> window shifting, and not normally used for passing arguments).
Sorry, I should have said, are they callee or caller save-able. From code
I've seen emitted from SunC 4.2 under Solaris 2.6, they are neither. They are
temporary and can be used as such. What is interesting is that I've also seen
%g5 used as a temp. I also need to do some more testing to see if the in
registers that are not used for arguments can be trashed.
> The global registers could sensibly be used by the language
> environment (libc), but I don't think that is the case. (Kernel code
> does use a few of them that way, but that's not very relevant here).
> If you use them for local variables, you should of course make sure
> their old values are saved and restored properly before returning.
Again, not too much of an issue since there is the duplicate set of global
registers that are used in kernel mode.
> > Am I free to mutilate the input registers?, I assume yes.
> I think so too.
ok,... just checked this, and it appears the caller re-loads the out registers
before each call, so it is ok to trash the input registers.
> > My final question concerns the Sparc v9 chips. Rumour had it that solaris
> > does save the local registers as 64 bit quantities on context switches.
> > Is this true? Are any of the others saved as 64 bit number in the 32bit
> > Solaris OS?
> Depends on OS version. I think this is the situation:
> 2.5.x: Only the low 32-bits are saved.
> 2.6: A subset of the registers are saved as 64-bit values, but not
> all of them.
> 2.7: All registers are saved as 64-bit values.
Now this is where it gets weird. In a data structure, the places to save
the registers is declared as unsinged long long, but the macro to write the
values is
#define SAVE_GLOBALS(RP) \
stx %g1, [RP+G1*4]; \
stx %g2, [RP+G2*4]; \
etc, which indicates that while stx is a double word save, they are
doing the write at word boundaries, so only %g7 would not have its top
32 bits overwritten by the next saved register. This is all in
/usr/include/v9/sys/privregs.h.
Now where is also get weird is that I was able to get the C compiler to
issue mulx (64*64 -> 64) instructions, where the output register was always
%o1. So, are the header files wrong?.....
> Sorry for the vague answers. I don't have the sparc9 manual handy, and
> I don't think even that answers all of your questions. The above is my
> recollection of that manual and some other sources.
I have the manual and it does not help much :-(.
I had a look at the linux sparc header files, and it is %100 32 bit.
Thanks for the responses from people. Unfortunatly I have no option but to
definitly implement one version using the %y register, and perhaps when Sun
documents things correctly, play with the 64 bit instructions.
eric
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:14:01