[M3devel] FW: NT386 jmpbuf size?

[Jay]

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

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