<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I BELIEVE:<BR>
It is statically knowable:<BR>
msvcrt _setjmp uses 8 words<BR>
msvcrt _setjmp3 uses 16 <BR>
cygwin uses I think 13 -- their header is just wrong by a factor of 4 <BR>
You can tell from a mix of disassembly and source -- disassembly for msvcrt, disassembly and source for cygwin.<BR>
<BR>
It isn't runtime variables that make the difference.<BR>
(well, the 16 case might sometimes shrink, it appears)<BR>
<BR>
What is less clear is if _setjmp or _setjmp3 should be used.<BR>
It appears that any use of setjmp in C or C++ uses _setjmp3.<BR>
<BR>
The difference appears to be whether or not the generally expected interaction with C __finally and C++ destructors and exception handling occurs.<BR>
"generally expected' but also "generally unknown".<BR>
<BR>
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.<BR>
<BR>
The C/C++ behavior might also be affected by command line options. I'd have to experiment more..<BR>
<BR>
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.<BR>
Does the C++ destructor run or not?<BR>
With _setjmp probably not, with _setjmp3 probably.<BR>
<BR>
Similarly, imagine some C++ gives some Modula-3 a callback and the C++ raises an exception.<BR>
Do the Modula-3 FINALLY blocks run?<BR>
<BR>
Similar dilemna really on all platforms.<BR>
There relatively recently an ABI for C++ exception handling that maybe Modula-3 should use.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Sat, 3 May 2008 17:00:47 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] FW: NT386 jmpbuf size?<BR>> <BR>> If there is a chance that more bytes are actually used under<BR>> special circumstances, I'd vote to make the jmp_buf large enough<BR>> to avoid memory corruption. I'm not sure if the extra bytes<BR>> will have performance impacts on thread switching, but I think<BR>> a special instruction could be used for copying them so that<BR>> it should be not much difference. I'm no expert on the Intel<BR>> processors though...<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> <BR>> > truncated again...<BR>> ><BR>> > From: jayk123@hotmail.comTo: m3devel@elegosoft.comSubject: FW: NT386 <BR>> > jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000<BR>> ><BR>> ><BR>> > Does anyone mind wasting an extra 32 bytes of stack in functions <BR>> > with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you <BR>> > read the assembly, _setjmp doesn't use it all, and _setjmp3 might. <BR>> > The difference is whether not a situation in which Modula-3 calls <BR>> > longjmp "past" C or C++ code, does the C __finally and C++ <BR>> > destructors run.Presently I think with Modula-3, not.Like, if <BR>> > Modula-3 passes some C/C++ a callback and the callback raises an <BR>> > exception and the C/C++ wanted to do some cleanup as the exception <BR>> > "goes by". I think it's always been this and I guess nobody noticed, <BR>> > so maybe leave it alone and shrink the jmpbuf back to 32 bytes from <BR>> > 64? Inflating from 8 to 13 also does get you some possible interop <BR>> > between NT386 and NT386GNU. - Jay<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></body>
</html>