[M3devel] FW: NT386 jmpbuf size?

[Jay]

I BELIEVE:
  It is statically knowable:
    msvcrt _setjmp uses 8 words
    msvcrt _setjmp3 uses 16 
    cygwin uses I think 13 -- their header is just wrong by a factor of 4 
   You can tell from a mix of disassembly and source -- disassembly for msvcrt, disassembly and source for cygwin.
 
It isn't runtime variables that make the difference.
(well, the 16 case might sometimes shrink, it appears)
 
What is less clear is if _setjmp or _setjmp3 should be used.
It appears that any use of setjmp in C or C++ uses _setjmp3.
 
The difference appears to be whether or not the generally expected interaction with C __finally and C++ destructors and exception handling occurs.
"generally expected' but also "generally unknown".
 
One might argue that if C/C++ can afford the extra 32 bytes, then so can Modula-3 BUT C/C++ have MUCH more efficient exception handling mechanisms available and so setjmp is much less used there. They get by with around 3 words for a frame with exception handling on x86, and with zero overheard everywhere else.
 
The C/C++ behavior might also be affected by command line options. I'd have to experiment more..
 
To clarify, imagine Modula-3 gave a callback function to some C++ and that C++ has a local with a destructor, and the Modula-3 raises an exception.
Does the C++ destructor run or not?
With _setjmp probably not, with _setjmp3 probably.
 
Similarly, imagine some C++ gives some Modula-3 a callback and the C++ raises an exception.
Do the Modula-3 FINALLY blocks run?
 
Similar dilemna really on all platforms.
There relatively recently an ABI for C++ exception handling that maybe Modula-3 should use.
 
 - Jay



> Date: Sat, 3 May 2008 17:00:47 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: NT386 jmpbuf size?> > If there is a chance that more bytes are actually used under> special circumstances, I'd vote to make the jmp_buf large enough> to avoid memory corruption. I'm not sure if the extra bytes> will have performance impacts on thread switching, but I think> a special instruction could be used for copying them so that> it should be not much difference. I'm no expert on the Intel> processors though...> > Quoting Jay <jayk123 at hotmail.com>:> > > truncated again...> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386 > > jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000> >> >> > Does anyone mind wasting an extra 32 bytes of stack in functions > > with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you > > read the assembly, _setjmp doesn't use it all, and _setjmp3 might. > > The difference is whether not a situation in which Modula-3 calls > > longjmp "past" C or C++ code, does the C __finally and C++ > > destructors run.Presently I think with Modula-3, not.Like, if > > Modula-3 passes some C/C++ a callback and the callback raises an > > exception and the C/C++ wanted to do some cleanup as the exception > > "goes by". I think it's always been this and I guess nobody noticed, > > so maybe leave it alone and shrink the jmpbuf back to 32 bytes from > > 64? Inflating from 8 to 13 also does get you some possible interop > > between NT386 and NT386GNU. - Jay> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080504/518c9d47/attachment-0002.html>