
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'><div style="text-align: left;">Good, a happy customer. :)<br><br><pre>> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386<br>> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU<br>> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably  <br>> easy<br>><br>> Eh..I know, not great.. what do "minimally" and "maximally" mean.<br><br>I'm still fishing for anyone to provide answers to these<br>less important decisions that I have trouble with.<br>Otherwise maybe no NT Cygwin system.<br><br>TARGETs = { NT386, NT386GNU, NT386CYGWIN }?<br>TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?<br>TARGETs = { NT386 + GNU_MODE }?<br><br>The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a much larger jmpbuf than the others.<br>I think same TARGET implies code can be linked together, and I think varying jmpbuf implies otherwise.<br>So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.<br><br>I also do NOT like this ad-hoc naming style.<br>PPC_DARWIN, I386_DARWIN are much more to my style.<br>The names should be somehow hierarchical, except, I realize, there isn't necessarily one "path" of<br>stuff which to name platforms, though the GNU folks have settled on a way or two.<br>They have triples or quadruples -- processor-hardware-os or such, however this doesn't<br>clearly suffice.<br><br>Something that accomodates:<br>  NT386 + LLVM<br>  NT386 + Watcom, linker and/or backend and/or runtime<br>  NT386 + Digital Mars linker and/or backend and/or runtime<br>  A C generating backend, and then linker/runtime<br>  and similar IA64, AMD64 variants would be good.<br><br>To a large extent, these can be few platforms, subject to configuration, like if all<br>the linkers consume a common file format (not clear), and if all the jmpbufs are the same<br>size (known to be partly true, partly false).<br><br>Oh and another thing, the runtime dependency is very likely cuttable, however<br>PRESUMABLY real world applications (if there are any) link in a substantial amount of<br>C or C++, in which case, it isn't necessarily cuttable.<br>As well, if I can figure out a good way to do it, switching NT386 from awful slow<br>frequent TlsGetValue/TlsSetValue to manipulating the linked list in fs:0, that would be nice,<br>and might incur a C runtime dependency, but well worth it. The way Modula-3 works here<br>is terrible. Another compromise option is probably __declspec(thread), though there is trickiness there<br>in terms of being in a .dll that isn't used by the .exe.<br><br><br> - Jay<br></pre></div><br><hr id="stopSpelling">> CC: jkrell@elego.de; m3devel@elegosoft.com<br>> From: hosking@cs.purdue.edu<br>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<br>> Date: Sat, 19 Jan 2008 18:52:12 -0500<br>> To: jayk123@hotmail.com<br>> <br>> OK, that's what I had hoped.<br>> <br>> Sounds good!<br>> <br>> On Jan 19, 2008, at 1:35 PM, Jay wrote:<br>> <br>> > ps -- look at m3-sys/cminstall/src/config/NT386GNU.<br>> > While it is very very similar to NT386, and even outputs foo.lib  <br>> > and foo.lib.sa like NT386, it uses gcc for C compilation, linking,  <br>> > and m3cg for the backend.<br>> > It is very "GNU" in tools, but not runtime.<br>> ><br>> >  - Jay<br>> ><br>> > From: jayk123@hotmail.com<br>> > To: hosking@cs.purdue.edu; jkrell@elego.de<br>> > CC: m3devel@elegosoft.com<br>> > Subject: RE: [M3devel] [M3commit] CVS Update: cm3<br>> > Date: Sat, 19 Jan 2008 18:32:35 +0000<br>> ><br>> > It DOES use m3cc/ld/as, and mklib for building static .libs, though  <br>> > that could probably be gcc/ar/dlltools if I figured it out.<br>> > "Everything" except m3cc/m3gdb can be built with just MinGWin.<br>> > Building m3cc requires MSys as well.<br>> > Building m3gdb requires Cygwin.<br>> > m3cg is not dependent on cygwin1.dll, nor are any other Modula-3  <br>> > outputs. m3gdb is dependent on cygwin1.dll.<br>> ><br>> > Using Cygwin probably would work..and I could try it to see if it  <br>> > resolves the RTLinker problem.<br>> ><br>> > As well, we could have something like, in cm3.cfg you could set  <br>> > MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools  <br>> > are used, OR we can have some variable:<br>> ><br>> > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386<br>> > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU<br>> > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably  <br>> > easy<br>> ><br>> > Eh..I know, not great.. what do "minimally" and "maximally" mean.<br>> ><br>> > I think we have the problem of a) many viable choices b) want to  <br>> > make several of them available c) just don't know what to call  <br>> > things and what the interface should be. As well as an interop  <br>> > question, since jmpbuf does vary in size between cygwin1.dl and  <br>> > everything else.<br>> ><br>> > Further down the line, there are other linkers, other compilers,  <br>> > other runtimes. The design here and now might take them into  <br>> > consideration.<br>> > Gasp..I just realized, there is also another good backend option.  <br>> > parse.c's approach could probably be adapted to Open Watcom AND  <br>> > they might even take the changes (not that I have asked, I just  <br>> > thought of this). And that would net you progress toward a) 32 bit  <br>> > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux  <br>> > target, since the support all of them.<br>> > Other target possibilities include Digital Mars compiler/linker,  <br>> > CodeWarrior (I know, dead and all), etc. Open Watcom is probably  <br>> > the most interesting since it is open source...<br>> ><br>> >  - Jay<br>> ><br>> ><br>> ><br>> > > From: hosking@cs.purdue.edu<br>> > > Date: Sat, 19 Jan 2008 12:48:06 -0500<br>> > > To: jkrell@elego.de<br>> > > CC: m3devel@elegosoft.com<br>> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3<br>> > ><br>> > > So, I am very confused now. Does NT386GNU no longer mean use of the<br>> > > full set of GNU tools m3cc/ld/as, as would be available under<br>> > > Cygwin? I thought the point of this was to be able to run in as much<br>> > > of a GNU environment as possible. GNU to me means the whole<br>> > > toolsuite not just m3cc. To me, a GNU-based environment on Windows<br>> > > holds great attraction, since it consists of tools that I generally<br>> > > always install on Windows, that I know, and are similar to the other<br>> > > platforms I use.<br>> > ><br>> > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:<br>> > ><br>> > > > CVSROOT: /usr/cvs<br>> > > > Changes by: jkrell@birch. 08/01/19 04:11:34<br>> > > ><br>> > > > Modified files:<br>> > > > cm3/m3-libs/m3core/src/runtime/: m3makefile<br>> > > > cm3/m3-sys/cminstall/src/config/: NT386GNU<br>> > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3<br>> > > > cm3/m3-sys/m3middle/src/: Target.m3<br>> > > ><br>> > > > Log message:<br>> > > > m3-sys/m3middle/src/Target.m3<br>> > > > m3-libs/m3core/src/runtime/m3makefile<br>> > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3<br>> > > ><br>> > > > switch NT386GNU to be Win32 instead of POSIX<br>> > > > switch NT386GNU to _setjmp instead of setjmp<br>> > > > jmp_buf size still big like Cygwin<br>> > > > rewrite NT386GNU config file -- almost identical to NT386<br>> > > > mingwin required for building Modula-3 programs<br>> > > > mingwin AND msys required for building m3cc<br>> > > ><br>> > > > To boot:<br>> > > ><br>> > > > install Python (www.activestate.com)<br>> > > ><br>> > > > have a working NT386 system<br>> > > > get current source<br>> > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was<br>> > > > taken by Unix)<br>> > > ><br>> > > > get and install binary distribution (5.1.3 works, anything newer<br>> > > > should work)<br>> > > > I install to c:\cm3<br>> > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin<br>> > > > \cm3.cfg<br>> > > ><br>> > > > Have a Visual C++ toolset (cl and link)<br>> > > > and run the vcvars link on the start menu (this can/will be made<br>> > > > easier)<br>> > > > Almost any version should work.<br>> > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe<br>> > > > and get a newer from such as from the Platform SDK. Otherwise it<br>> > > > crashes.<br>> > > > This is not specific to NT386GNU, just that I recently removed the<br>> > > > Platform SDK<br>> > > > from my %PATH%.<br>> > > ><br>> > > > cd %CVSROOT%\scripts\python<br>> > > > .\upgrade<br>> > > ><br>> > > > install msys and mingwin from http://www.mingw.org (links to<br>> > > > SourceForge)<br>> > > > for mingwin, you only need the "base"<br>> > > > msys tells you to avoid mingwin make, in favor of msys make, and I<br>> > > > did that<br>> > > ><br>> > > > I install to the defaults<br>> > > > c:\msys\1.0<br>> > > > c:\mingw<br>> > > ><br>> > > > if you don't install to the defaults, add<br>> > > > <msys>\bin and <mingwin\bin to $PATH (in which order? I add<br>> > > > to the start, but which order between the two?)<br>> > > ><br>> > > > if you do install to the defaults, scripts\python will fix path<br>> > > > for you,<br>> > > > if there is no gcc/as/sh on our $PATH<br>> > > ><br>> > > > cd %CVSROOT%\scripts\python<br>> > > > upgrade && bootntgnu<br>> > > ><br>> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still<br>> > > > progress.<br>> > > ><br>> > > > These instructions inevitably to be further tested and refined and<br>> > > > placed elsewhere!<br>> > ><br>> ><br>> ><br>> > Need to know the score, the latest news, or you need your Hotmail�- <br>> > get your "fix". Check it out.<br>> > Connect and share in new ways with Windows Live. Get it now!<br>> <br><br /><hr />Need to know the score, the latest news, or you need your Hotmail�-get your "fix". <a href='http://www.msnmobilefix.com/Default.aspx' target='_new'>Check it out.</a></body>

</html>