[M3devel] [M3commit] CVS Update: cm3

Jay jayk123 at hotmail.com
Sun Jan 20 05:52:55 CET 2008 

Good, a happy customer. :)

> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386
> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU
> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably  
> easy
>
> Eh..I know, not great.. what do "minimally" and "maximally" mean.

I'm still fishing for anyone to provide answers to these
less important decisions that I have trouble with.
Otherwise maybe no NT Cygwin system.

TARGETs = { NT386, NT386GNU, NT386CYGWIN }?
TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?
TARGETs = { NT386 + GNU_MODE }?

The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a much larger jmpbuf than the others.
I think same TARGET implies code can be linked together, and I think varying jmpbuf implies otherwise.
So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.

I also do NOT like this ad-hoc naming style.
PPC_DARWIN, I386_DARWIN are much more to my style.
The names should be somehow hierarchical, except, I realize, there isn't necessarily one "path" of
stuff which to name platforms, though the GNU folks have settled on a way or two.
They have triples or quadruples -- processor-hardware-os or such, however this doesn't
clearly suffice.

Something that accomodates:
  NT386 + LLVM
  NT386 + Watcom, linker and/or backend and/or runtime
  NT386 + Digital Mars linker and/or backend and/or runtime
  A C generating backend, and then linker/runtime
  and similar IA64, AMD64 variants would be good.

To a large extent, these can be few platforms, subject to configuration, like if all
the linkers consume a common file format (not clear), and if all the jmpbufs are the same
size (known to be partly true, partly false).

Oh and another thing, the runtime dependency is very likely cuttable, however
PRESUMABLY real world applications (if there are any) link in a substantial amount of
C or C++, in which case, it isn't necessarily cuttable.
As well, if I can figure out a good way to do it, switching NT386 from awful slow
frequent TlsGetValue/TlsSetValue to manipulating the linked list in fs:0, that would be nice,
and might incur a C runtime dependency, but well worth it. The way Modula-3 works here
is terrible. Another compromise option is probably __declspec(thread), though there is trickiness there
in terms of being in a .dll that isn't used by the .exe.


 - Jay

> CC: jkrell at elego.de; m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> Date: Sat, 19 Jan 2008 18:52:12 -0500
> To: jayk123 at hotmail.com
> 
> OK, that's what I had hoped.
> 
> Sounds good!
> 
> On Jan 19, 2008, at 1:35 PM, Jay wrote:
> 
> > ps -- look at m3-sys/cminstall/src/config/NT386GNU.
> > While it is very very similar to NT386, and even outputs foo.lib  
> > and foo.lib.sa like NT386, it uses gcc for C compilation, linking,  
> > and m3cg for the backend.
> > It is very "GNU" in tools, but not runtime.
> >
> >  - Jay
> >
> > From: jayk123 at hotmail.com
> > To: hosking at cs.purdue.edu; jkrell at elego.de
> > CC: m3devel at elegosoft.com
> > Subject: RE: [M3devel] [M3commit] CVS Update: cm3
> > Date: Sat, 19 Jan 2008 18:32:35 +0000
> >
> > It DOES use m3cc/ld/as, and mklib for building static .libs, though  
> > that could probably be gcc/ar/dlltools if I figured it out.
> > "Everything" except m3cc/m3gdb can be built with just MinGWin.
> > Building m3cc requires MSys as well.
> > Building m3gdb requires Cygwin.
> > m3cg is not dependent on cygwin1.dll, nor are any other Modula-3  
> > outputs. m3gdb is dependent on cygwin1.dll.
> >
> > Using Cygwin probably would work..and I could try it to see if it  
> > resolves the RTLinker problem.
> >
> > As well, we could have something like, in cm3.cfg you could set  
> > MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools  
> > are used, OR we can have some variable:
> >
> > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386
> > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU
> > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably  
> > easy
> >
> > Eh..I know, not great.. what do "minimally" and "maximally" mean.
> >
> > I think we have the problem of a) many viable choices b) want to  
> > make several of them available c) just don't know what to call  
> > things and what the interface should be. As well as an interop  
> > question, since jmpbuf does vary in size between cygwin1.dl and  
> > everything else.
> >
> > Further down the line, there are other linkers, other compilers,  
> > other runtimes. The design here and now might take them into  
> > consideration.
> > Gasp..I just realized, there is also another good backend option.  
> > parse.c's approach could probably be adapted to Open Watcom AND  
> > they might even take the changes (not that I have asked, I just  
> > thought of this). And that would net you progress toward a) 32 bit  
> > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux  
> > target, since the support all of them.
> > Other target possibilities include Digital Mars compiler/linker,  
> > CodeWarrior (I know, dead and all), etc. Open Watcom is probably  
> > the most interesting since it is open source...
> >
> >  - Jay
> >
> >
> >
> > > From: hosking at cs.purdue.edu
> > > Date: Sat, 19 Jan 2008 12:48:06 -0500
> > > To: jkrell at elego.de
> > > CC: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> > >
> > > So, I am very confused now. Does NT386GNU no longer mean use of the
> > > full set of GNU tools m3cc/ld/as, as would be available under
> > > Cygwin? I thought the point of this was to be able to run in as much
> > > of a GNU environment as possible. GNU to me means the whole
> > > toolsuite not just m3cc. To me, a GNU-based environment on Windows
> > > holds great attraction, since it consists of tools that I generally
> > > always install on Windows, that I know, and are similar to the other
> > > platforms I use.
> > >
> > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:
> > >
> > > > CVSROOT: /usr/cvs
> > > > Changes by: jkrell at birch. 08/01/19 04:11:34
> > > >
> > > > Modified files:
> > > > cm3/m3-libs/m3core/src/runtime/: m3makefile
> > > > cm3/m3-sys/cminstall/src/config/: NT386GNU
> > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3
> > > > cm3/m3-sys/m3middle/src/: Target.m3
> > > >
> > > > Log message:
> > > > m3-sys/m3middle/src/Target.m3
> > > > m3-libs/m3core/src/runtime/m3makefile
> > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3
> > > >
> > > > switch NT386GNU to be Win32 instead of POSIX
> > > > switch NT386GNU to _setjmp instead of setjmp
> > > > jmp_buf size still big like Cygwin
> > > > rewrite NT386GNU config file -- almost identical to NT386
> > > > mingwin required for building Modula-3 programs
> > > > mingwin AND msys required for building m3cc
> > > >
> > > > To boot:
> > > >
> > > > install Python (www.activestate.com)
> > > >
> > > > have a working NT386 system
> > > > get current source
> > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was
> > > > taken by Unix)
> > > >
> > > > get and install binary distribution (5.1.3 works, anything newer
> > > > should work)
> > > > I install to c:\cm3
> > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin
> > > > \cm3.cfg
> > > >
> > > > Have a Visual C++ toolset (cl and link)
> > > > and run the vcvars link on the start menu (this can/will be made
> > > > easier)
> > > > Almost any version should work.
> > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe
> > > > and get a newer from such as from the Platform SDK. Otherwise it
> > > > crashes.
> > > > This is not specific to NT386GNU, just that I recently removed the
> > > > Platform SDK
> > > > from my %PATH%.
> > > >
> > > > cd %CVSROOT%\scripts\python
> > > > .\upgrade
> > > >
> > > > install msys and mingwin from http://www.mingw.org (links to
> > > > SourceForge)
> > > > for mingwin, you only need the "base"
> > > > msys tells you to avoid mingwin make, in favor of msys make, and I
> > > > did that
> > > >
> > > > I install to the defaults
> > > > c:\msys\1.0
> > > > c:\mingw
> > > >
> > > > if you don't install to the defaults, add
> > > > <msys>\bin and <mingwin\bin to $PATH (in which order? I add
> > > > to the start, but which order between the two?)
> > > >
> > > > if you do install to the defaults, scripts\python will fix path
> > > > for you,
> > > > if there is no gcc/as/sh on our $PATH
> > > >
> > > > cd %CVSROOT%\scripts\python
> > > > upgrade && bootntgnu
> > > >
> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still
> > > > progress.
> > > >
> > > > These instructions inevitably to be further tested and refined and
> > > > placed elsewhere!
> > >
> >
> >
> > Need to know the score, the latest news, or you need your Hotmail®- 
> > get your "fix". Check it out.
> > Connect and share in new ways with Windows Live. Get it now!
> 

_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080120/65c5d2ea/attachment-0002.html>

More information about the M3devel mailing list