[M3devel] sparc ta/setjmp/longjmp

[Tony Hosking]

On 24 Nov 2009, at 06:05, Jay K wrote:

> 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 *)

No.  The sp back from SaveRegsInStack may capture more state than ADR(xx).

>  
>  
>  
> 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/1d904131/attachment-0002.html>