[M3commit] CVS Update: cm3

[Jay K]

If you are certain I'll put it back.
Arguably, but arguably :) such users should be using C++, restore the state in a destructor, and we should have good interop with them.
Do notice that sigjmpbuf is huge on I386_SOLARIS/AMD64_SOLARIS. Also that I've been "erring" this way a while, at least
once I understood what sigjmpbuf is. Before that I might have erred toward larger out of larger ignorance.
(See, I might still be ignorant, but I understand setjmp vs. sigsetjmp and I understand your point here. :) )


FloatMode isn't supported on any existing platform.
We could grow jmpbuf by one integer or so as we add support?
Really this might be part of the small jmpbuf anyway. Might.


Or, understood, you really think we might throw around a signal mask change?


Realize also that sigsetjmp or setjmp, whichever we use, is called incredibly often, and sigsetjmp is likely
much much slower. Also notice..this I'll have to check...have we ever called sigsetjmp?
Well, no, I doubt it. But maybe setjmp vs. _setjmp.
Again though, this can be significantly slow.


Ultimately as well...see..I started this email without a firm opinion, but now I'm "firming" toward the change I made.
Consider C++ exceptions. Consider libunwind. Consider the SPARC stack walker (which I have to look at).
Do they save/restore signal masks? I doubt it. Maybe. We can look into it. But I doubt it.


Raising an exception can indeed by slow. But entering a function with finally (or destructors) should not be overly so.


 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 8 May 2010 18:28:36 -0400
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> Ah, now I remember. sigjmpbuf is important for unwinding on exception to make sure that if we unwind through a frame where the programmer changed the signal mask that we also restore the signal mask of the caller. I think you also probably break things like FloatMode by not restoring the signal mask properly.
>
> On 9 May 2010, at 00:09, Jay Krell wrote:
>
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 10/05/09 00:09:58
>>
>> Modified files:
>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3
>>
>> Log message:
>> add SPARC32_SOLARIS
>>
>> correct jmpbuf sizes for I386_SOLARIS, AMD64_SOLARIS
>> notice again that jmpbuf is much much smaller than sigjmpbuf,
>> and this is jmpbuf; specifically:
>> I386_SOLARIS jmpbuf 40 bytes with 4 align
>> AMD64_SOLARIS jmpbuf 64 bytes with 8 align
>> I386_SOLARIS sigjmpbuf 512 bytes with 4 align
>> AMD64_SOLARIS sigjmpbuf 1024 bytes with 8 align
>>
>> remove some level of heap allocation of calling conventions
>>
>> accept all calling conventions for all targets
>> Only NT386 has calling conventions, and it *highly* likely
>> the only target ever to have them, therefore the mechanism
>> does not need to be further generalized. (MIPS32 has two
>> ABIs, but those will probably be two targets)
>> This might let us save some unnecessary forking of *.i3 files.
>> The initialization here can be further streamlined.
>>
>> shrink SOLgnu/SOLsun from sigjmpbuf to jmpbuf
>> I'm not sure we use this though since we have a stack walker.
>> fix SPARC64_SOLARIS too to be smaller
>>
>> SPARC32_SOLARIS
>> jmpbuf size: 48
>> sigjmpbuf size: 76
>> alignment: 4 4
>>
>> SPARC64_SOLARIS
>> jmpbuf size: 96
>> sigjmpbuf size: 152
>> alignment: 8 8
>