
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>truncated again...<BR><BR><BR><BR><BR>

<BLOCKQUOTE>

<HR id=EC_stopSpelling>

From: jayk123@hotmail.com<BR>To: m3devel@elegosoft.com<BR>Subject: FW: NT386 jmpbuf size?<BR>Date: Sat, 3 May 2008 11:24:24 +0000<BR><BR>

<META content="Microsoft SafeHTML" name=Generator>

<STYLE>

.ExternalClass .EC_hmmessage P

{padding:0px;}

.ExternalClass body.EC_hmmessage

{font-size:10pt;font-family:Tahoma;}

</STYLE>

Does anyone mind wasting an extra 32 bytes of stack in functions with a "try" on NT386?<BR>jmpbuf is declared to be 64 bytes, but if you read the assembly, _setjmp doesn't use it all, and _setjmp3 might.<BR> <BR>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.<BR>Presently I think with Modula-3, not.<BR>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".<BR> <BR>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?<BR> <BR>Inflating from 8 to 13 also does get you some possible interop between NT386 and NT386GNU.<BR> <BR> - Jay<BR><BR><BR>

<HR id=EC_stopSpelling>

<BR>> Date: Sat, 3 May 2008 13:17:42 +0000<BR>> To: m3commit@elegosoft.com<BR>> From: jkrell@elego.de<BR>> Subject: [M3commit] CVS Update: cm3<BR>> <BR>> CVSROOT: /usr/cvs<BR>> Changes by: jkrell@birch. 08/05/03 13:17:42<BR>> <BR>> Modified files:<BR>> cm3/m3-sys/m3middle/src/: Target.m3 <BR>> <BR>> Log message:<BR>> fix and unify NT386 jmpbuf/setjmp<BR>> <BR>> it APPEARS jmpbuf was understated for Visual C++<BR>> though it was probably ok<BR>> it appears if you compile C/C++, the compiler generates a call<BR>> to _setjmp3, which indeed uses more of the declared-16 jmpbuf<BR>> but that if we call _setjmp directly, it only uses 8<BR>> <BR>> Cygwin was overstated because their setjmp.h<BR>> appears to confuse bytes and ints, it only uses 13.<BR>> <BR>> So unify the former 8 and 13 to 16.<BR>> <BR>> As well, Cygwin provides aliased setjmp and _setjmp, so<BR>> unify on _setjmp<BR>> <BR>> NOTE that using _setjmp3 for Visual C++ is probably desirable<BR>> but cross that bridge another time, perhaps we'll just stop<BR>> using setjmp entirely<BR>> <BR>> therefore making the three NT386 flavors much more similar<BR>> <BR><BR></BLOCKQUOTE></body>

</html>