[M3devel] SaveRegsInStack

Sun Nov 22 20:02:55 CET 2009

Briefly: I am fine with setjmp/longjmp instead of assembler.

On 22 Nov 2009, at 00:02, Jay K wrote:

> The registers are spilled..to the stack right?..by virtue of longjmp issuing ta 3.
> Which, while I haven't thought it through, I bet must be done.
> You can see various refererences to flushrs in IA64 setjmp/longjmp as well.

I'm just concerned that setjmp/longjmp does more than we need.

> (In college Professer Teitelbaum tricked me on a test with "implement setjmp/longjmp for sparc." I implemented them years ago for the simple 65816 but I failed to consider register windows..)

Yeah, setjmp/longjmp is actually pretty simple for sparc.  The assembler routine was even simpler than setjmp/longjmp.

>  > http://www.sics.se/~psm/sparcstack.html
>  
>  
> "Writing a library for multithreaded execution is an example that requires explicit flushing, as is longjmp()."
>  
>  > http://blogs.sun.com/d/entry/flush_register_windows
>  
> "Note that setjmp and longjmp which are sometimes used as part of code to implement context switching already have the appropriate flushes in them. "
>  
>  
> So I contend:
>  
> void SaveRegsInStack(void)
> {
> #if defined(__sparc) || defined(__ia64__)
>   jmpbuf j;
>   if (!setjmp(j)) longjmp(j, 1);
> #endif
> }
>  
> It might not be ideal, but given that ta 3 is expensive anyway, and in one of the users there is already a setjmp call, I think it is pretty reasonable.
>  
>  
> Once things are working better, unless you disagree, I'll make this change in ThreadPThreadC.c and RTStackC.c.
> ThreadPThreadC.c already has a setjmp.
> The ProcessMe/ProcessLive interaction will change slightly.
> ProcessMe will pass stackbase to ProcessLive.
> stack_grows_down will be in C to be accessible to ProcessLive.
> I had this all written but have to back up and restore general health..
>  
>  
> I've seen code that does ta 83 instead of ta 3 on Linux.
> But I've also seen that that isn't right.
> This way we can sweep all these issues away fairly well, for all sparc32, sparc64, and ia64 targets.
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Sat, 21 Nov 2009 22:19:12 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] SaveRegsInStack
> 
> Are we sure that &jb is a sufficient sp?  What about other registers saved by the "ta 3"?  They don't necessarily end up in jb.
> 
> On 21 Nov 2009, at 20:11, Jay K wrote:
> 
> Tony,
> Looking at the disassembly of /usr/lib/libc.so and /usr/lib/sparcv9/libc.so, both longjmps contain ta  3.
> So how about:
> void *RTStack__SaveRegsInStack(void)
> {
>   jmp_buf jb;
>   if (setjmp(jb))
>   {
>     longjmp(jb, 1); /* contains ta 3 */
>     abort(); /* unreachable */
>   }
>   else
>   {
>     return &jb;
>   }
> }
>  
> Too wasteful?
>  
>  - Jay
> 
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sun, 22 Nov 2009 00:12:44 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] SaveRegsInStack
> 
> SOLsun doesn't like the current source:
>  
> C compiler failed compiling: ../src/runtime/SOLsun/RTStackC.c
> new source -> compiling ThreadPThreadC.c
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 310: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 316: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 317: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 325: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 326: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 327: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 349: cannot recover from previous
> 
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] SaveRegsInStack
> Date: Sat, 21 Nov 2009 23:45:42 +0000
> 
> (or RTMachineC.c)
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 21 Nov 2009 23:40:03 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] SaveRegsInStack
> 
>  > No, those don't have the desired effect on SPARC.
>  
> ok. I was somewhat guessing.
>  
>  > Why wouldn't SPARC* all have stack walkers?
>  
> Because I'm lazy and doubt anyone cares much about SPARC{32,64}_{LINUX,FREEBSD,NETBSD}, SPARC64_SOLARIS.
> ? But I can maybe try it at some point.
>  
> I also expect the way to go is use libunwind for nearly all targets, even probably SPARC*.
>  
>  > It would be good to have it in one place for *all* SPARC targets.  Where to put it
>  
> How about a new src/runtime/common/RTStackC.c, compiled on all platforms but with #ifdefs (the same #ifdefs as are currently used, but revisiting them at some point, the NETBSD and such seem suspicious).
> I think I'll do that shortly.
>  
> There is also TARGET_ARCH defined in the config files.
> We could do
> if exist(TARGET_ARCH/m3makefile)
>   include_dir(TARGET_ARCH)
> end
>  
> (similarly there is TARGET_OS).
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Sat, 21 Nov 2009 17:02:23 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] SaveRegsInStack
> 
> On 21 Nov 2009, at 15:38, Jay K wrote:
> 
> Tony, it bugs me that we have three copies of this code.
> Would it be reasonable and not very inefficient
> and maybe somewhat portable to replace it with
> setjmp or getcontext or alloca(1)?
> 
> No, those don't have the desired effect on SPARC.
> 
>  Or can we go back to having RTStack call RTMachine?
> (Imagine if SPARC* all had stack walkers, though I
> doubt that will happen, other than via libunwind.)
> 
> Why wouldn't SPARC* all have stack walkers?  Their stack frames are trivial to unwind.
> I agree that it is annoying to have multiple copies of this code.  It would be good to have it in one place for *all* SPARC targets.  Where to put it?
> 
>  
> 
>  - Jay
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091122/3cc1e194/attachment-0002.html>