[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