[M3devel] [M3commit] CVS Update: cm3

Sun Jan 20 17:48:26 CET 2008

> the infrastructure. So I'd rather vote that only new targets get> more systematic names.
Of course, though the existing names suggest new names, and
not clear the value of the existing NT386GNU. Ie. is there a benefit
to keep it in use with some meaning or not?

Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin.
I think it holds sigaction state besides register state.

"NT" and "Win" seem redundant.
 I386_MINGWIN? 
 I386_CYGWIN? 
 NT386_GNU? 
 NT386_MINGNU? 

Ok, I admit that
  NT386_CYGWIN
  NT386_MINGWIN

despite the redundancy, clearly point to existing projects that probably have name recognition.
And building from NT386 is reasonable -- as was I saying about existing names influencing new names.

A C generating backend gets you perhaps easier retargeting as well.
I do see there is "MINGWIN64" out there, for AMD64.
Not sure what the state of IA64 is though...
(See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.)

I also would agree that creating one target instead of two is probably a good idea -- seems easier.

I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use?
If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.)

And thus the precedent for no underscore.
NT386MINGWIN ?
NT386MINGNU ?

I don't know if "MSYS" needs a place in this name.
It is needed for building m3cc.

I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise.

Hint for anyone trying out Cygwin and getting an odd mix of paths:
mkdir \cygdrive
get junction.exe from the former www.sysinternals.com
junction \cygdrive\c c:\
now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed.
If you have multiple drives, I guess just fully populate each one
c:\cygdrive\c => c:\
c:\cygdrive\d => d:\
d:\cygdrive\c => c:\
d:\cygdrive\d => d:\

etc. but I haven't tried that.
Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc.

 - Jay

> Date: Sun, 20 Jan 2008 15:56:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay <jayk123 at hotmail.com>:> > > 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 think a new target is called for if I have understood everything right.> We need one pure native target (NT386), one pure-Cygwin-based target> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin> (NT386_MINGWIN?).> > As NT386GNU already exists, we must decide if we want to use it as> we traditionally did (all Cygwin) or the mixed implementation> (Mingwin and much Windows RT).> > > 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.> > Well, yes, something more systematic would have been better, but> to break with the history will cause much trouble for all users and> the infrastructure. So I'd rather vote that only new targets get> more systematic names.> > > 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.> > I'm not sure that a C generating backend would really help matters.> This was done in the first implementation of DEC, and they soon> abandoned it as C had proven to be a bad choice as intermediate language.> I agree it would be great for cross-compilation etc.> > As far as C and RT dependencies of native Windows compilers go, I don't> see why this couldn't be just a question of another cm3.cfg setup.> > > 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).> > Yes, jmpbuf is always a problem for user threads and exceptions.> On Unix systems the jmpbuf and other important low-level structures> are always defined by the system headers and independent of compilers> AFAIK, so I'm a bit surprised that it should be different on Windows.> But maybe I'm just wrong and haven't just seen the right counter> examples...> > > 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.> > Yes. Real world applications tend to link other libraries (C, C++,> Fortran, ...) and even often call other applications like sh etc.> > > 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.> > Such optimizations should be done depending on the target.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080120/20a01ef2/attachment-0002.html>