<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>> but is there a great need for something between these two extremes?<BR><BR>
Unclear I agree. It was useful as a stepping stone to the other extreme. The problems with it were "portable", though<BR>
PM3 already solved one of them.<BR>
It's the closest thing *today* to NT386 that supports LONGINT and mitigates my guilt about that. :)<BR>
IN FACT, oh crap I thought I was done thinking about this.<BR>
In fact the NT386 distribution could include cm3cg/as and whenever source uses LONGINT, compile it with it.<BR>
Hacky. Hopefully to be avoided by really fixing the integrated backend.<BR>
There do exist MinGWin and MSys, so I'm not the one who thought of this in-between.<BR>There is even "GCW" but it seems stillborn.<BR>
<BR>
Anyway, I'm pretty sure this discusion can wind down now. :)<BR>
(I didn't say end, I said wind down. :) )<BR>
<BR>
Unless anyone really dislikes how I've structured the config files and my upcoming cm3 changes that I think will be very very very small. I'm thinking..TARGET will remain NT386, NT386GNU will all but go away, as a target, it will live on as a "configuration", of which cm3 knows nothing, OS_TYPE will vary, and it will determine jmpbuf size..is that sleazy? Integrated backend vs. non integrated backend will determine the calling convention issues. Backend mode is correct asis.<BR>
Alternatives to keying off of OS_TYPE in cm3:<BR>
<BR>
1) Key off a new variable called currently "CLibrary", usually ignored. But on NT386 has the values 0 and 1.<BR>
<BR>
2) Have the config file set jmpbuf size itself, and have cm3 know about that new variable. Hard to argue with that.<BR>
The config file already has the power to subtley destroy things through script, witness double alignment.<BR>
<BR>
3) look into why cygwin has a larger jmpbuf, if msvc*dll setjmp can be used instead, or m3core.dll can have its own m3_setjmp and export it. Might be better to call it something more abstract, like m3_try_for_except and m3_try_for_finally.<BR>
<BR>
4) Blow up the jmpbuf size unconditionally on NT386. Bigger than necessary should work fine, but is wasteful.<BR>
<BR>
#3 Looking into the cygwin jmpbuf is pretty much an absolute. Heck, maybe it's just padding for the future, or maybe only used depending on something...<BR>
<BR>
5) Abandon 386 and move on to AMD64. :)<BR>
<BR>
- Jay<BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>