[M3devel] platform/build_dir is a big tuple?

[Jay]

> but is there a great need for something between these two extremes?
Unclear I agree. It was useful as a stepping stone to the other extreme. The problems with it were "portable", though
PM3 already solved one of them.
It's the closest thing *today* to NT386 that supports LONGINT and mitigates my guilt about that. :)
IN FACT, oh crap I thought I was done thinking about this.
In fact the NT386 distribution could include cm3cg/as and whenever source uses LONGINT, compile it with it.
Hacky. Hopefully to be avoided by really fixing the integrated backend.
There do exist MinGWin and MSys, so I'm not the one who thought of this in-between.There is even "GCW" but it seems stillborn.
 
Anyway, I'm pretty sure this discusion can wind down now. :)
(I didn't say end, I said wind down. :) )
 
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.
Alternatives to keying off of OS_TYPE in cm3:
 
  1) Key off a new variable called currently "CLibrary", usually ignored. But on NT386 has the values 0 and 1.
 
  2) Have the config file set jmpbuf size itself, and have cm3 know about that new variable. Hard to argue with that.
   The config file already has the power to subtley destroy things through script, witness double alignment.
 
  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.
 
  4) Blow up the jmpbuf size unconditionally on NT386. Bigger than necessary should work fine, but is wasteful.
 
#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...
 
   5) Abandon 386 and move on to AMD64. :)
 
 - Jay
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080123/2c3a9677/attachment-0002.html>