[M3devel] sparc ta/setjmp/longjmp
Jay K
jay.krell at cornell.edu
Tue Nov 24 12:05:01 CET 2009
Tony,
Does this seem correct?
PROCEDURE SignalHandler (sig: int) =
VAR
...
old:
me.sp := SaveRegsInStack();
IF me.sp = NIL THEN me.sp := ADR(xx) END;
new:
SaveRegsInStack(); (* no return value *)
me.sp := ADR(xx); (* unconditional *)
void ThreadPThread__SaveRegsInStack(void)
{
#ifdef M3_REGISTER_WINDOWS
/* On "register window" architectures, setjmp/longjmp tends
to flush registers to the stack in a fairly portable not
too inefficient fashion, and saves us the need for
gnarly assembly. (ta 3 on Sparc, flushrs on IA64)
*/
jmp_buf jb;
if (setjmp(jb) == 0) longjmp(jb, 1);
#endif
}
You know -- was the stack pointer returned by SaveRegsInStack before really better/different than just ADR(xx)?
Consider:
# if defined(__arch64__) || defined(__sparcv9)
asm(" save %sp,-128,%sp");
asm(" flushw");
asm(" ret");
asm(" restore %sp,2047+128,%o0");
# else
asm(" ta 0x3 ! ST_FLUSH_WINDOWS");
asm(" retl");
asm(" mov %sp,%o0");
# endif
on 32bit, it just returns the unchanged %sp of its caller.
On 64bit, I suspect kind of the same thing, though I don't know what the 128 or 2047 are. 2047 is probably some "bias" builtin to the register and 128 I guess is required for flushw??
- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091124/9f2730d2/attachment-0001.html>
More information about the M3devel
mailing list