🚀 go-pugleaf

In article <476@mntgfx.MENTOR.COM>, franka@mntgfx.MENTOR.COM (Frank A. Adrian) writes:
> In article <898@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes:
>>	a) save all registers
>>	b) have the caller save only the registers it is using
>>	c) have the callee save only the registers it will use
> Actually b can be much less efficient than c, because [...]

> int foo(a)
> struct foo_structure	*a;
> [example]

> Using scheme b, all registers which MAY be used in foo MUST be saved,
> while scheme c allows you to save registers only if a is non-null.

>> The method used has a large effect on whether setjmp/longjmp can put
>> the correct values back into register variables (SYSVID says they
>> may be unpredictable :-(.
> Sad, but true.

WHAT?!?!  I can't see any reason that longjmp can't get the registers
back - if it can't restore them easily on that architecture then just
have setjmp save them in the jmp_buf!  What's the problem?  This will
make longjmp basically useless, especially in the face of compilers
that optimize non-"register" variables into registers!

Note that the possibility of method (c) means that it won't even work
to avoid registers in the function calling setjmp because there have to
be no live registers at the time of the setjmp, which with method (c)
means no registers at all, because functions might not save them -
they'd still be live at the setjmp()!

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu