<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>> the infrastructure. So I'd rather vote that only new targets get<BR>> more systematic names.<BR><BR>
Of course, though the existing names suggest new names, and<BR>
not clear the value of the existing NT386GNU. Ie. is there a benefit<BR>
to keep it in use with some meaning or not?<BR>
<BR>
Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin.<BR>
I think it holds sigaction state besides register state.<BR>
<BR>
"NT" and "Win" seem redundant.<BR>
I386_MINGWIN? <BR>
I386_CYGWIN? <BR>
NT386_GNU? <BR>
NT386_MINGNU? <BR>
<BR>
Ok, I admit that<BR>
NT386_CYGWIN<BR>
NT386_MINGWIN<BR>
<BR>
despite the redundancy, clearly point to existing projects that probably have name recognition.<BR>
And building from NT386 is reasonable -- as was I saying about existing names influencing new names.<BR>
<BR>
A C generating backend gets you perhaps easier retargeting as well.<BR>
I do see there is "MINGWIN64" out there, for AMD64.<BR>
Not sure what the state of IA64 is though...<BR>
(See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.)<BR>
<BR>
I also would agree that creating one target instead of two is probably a good idea -- seems easier.<BR>
<BR>
I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use?<BR>
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.)<BR>
<BR>
And thus the precedent for no underscore.<BR>
NT386MINGWIN ?<BR>
NT386MINGNU ?<BR>
<BR>
I don't know if "MSYS" needs a place in this name.<BR>
It is needed for building m3cc.<BR>
<BR>
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.<BR>
<BR>
Hint for anyone trying out Cygwin and getting an odd mix of paths:<BR>
mkdir \cygdrive<BR>
get junction.exe from the former <A href="http://www.sysinternals.com">www.sysinternals.com</A><BR>
junction \cygdrive\c c:\<BR>
now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed.<BR>
If you have multiple drives, I guess just fully populate each one<BR>
c:\cygdrive\c => c:\<BR>
c:\cygdrive\d => d:\<BR>
d:\cygdrive\c => c:\<BR>
d:\cygdrive\d => d:\<BR>
<BR>
etc. but I haven't tried that.<BR>
Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Sun, 20 Jan 2008 15:56:49 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> <BR>> > Good, a happy customer. :)<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'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 <BR>> > much larger jmpbuf than the others.<BR>> > I think same TARGET implies code can be linked together, and I think <BR>> > varying jmpbuf implies otherwise.<BR>> > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.<BR>> <BR>> I think a new target is called for if I have understood everything right.<BR>> We need one pure native target (NT386), one pure-Cygwin-based target<BR>> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin<BR>> (NT386_MINGWIN?).<BR>> <BR>> As NT386GNU already exists, we must decide if we want to use it as<BR>> we traditionally did (all Cygwin) or the mixed implementation<BR>> (Mingwin and much Windows RT).<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 <BR>> > isn't necessarily one "path" of<BR>> > stuff which to name platforms, though the GNU folks have settled on <BR>> > a way or two.<BR>> > They have triples or quadruples -- processor-hardware-os or such, <BR>> > however this doesn't<BR>> > clearly suffice.<BR>> <BR>> Well, yes, something more systematic would have been better, but<BR>> to break with the history will cause much trouble for all users and<BR>> the infrastructure. So I'd rather vote that only new targets get<BR>> more systematic names.<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>> I'm not sure that a C generating backend would really help matters.<BR>> This was done in the first implementation of DEC, and they soon<BR>> abandoned it as C had proven to be a bad choice as intermediate language.<BR>> I agree it would be great for cross-compilation etc.<BR>> <BR>> As far as C and RT dependencies of native Windows compilers go, I don't<BR>> see why this couldn't be just a question of another cm3.cfg setup.<BR>> <BR>> > To a large extent, these can be few platforms, subject to <BR>> > configuration, like if all<BR>> > the linkers consume a common file format (not clear), and if all the <BR>> > jmpbufs are the same<BR>> > size (known to be partly true, partly false).<BR>> <BR>> Yes, jmpbuf is always a problem for user threads and exceptions.<BR>> On Unix systems the jmpbuf and other important low-level structures<BR>> are always defined by the system headers and independent of compilers<BR>> AFAIK, so I'm a bit surprised that it should be different on Windows.<BR>> But maybe I'm just wrong and haven't just seen the right counter<BR>> examples...<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 <BR>> > substantial amount of<BR>> > C or C++, in which case, it isn't necessarily cuttable.<BR>> <BR>> Yes. Real world applications tend to link other libraries (C, C++,<BR>> Fortran, ...) and even often call other applications like sh etc.<BR>> <BR>> > As well, if I can figure out a good way to do it, switching NT386 <BR>> > from awful slow<BR>> > frequent TlsGetValue/TlsSetValue to manipulating the linked list in <BR>> > fs:0, that would be nice,<BR>> > and might incur a C runtime dependency, but well worth it. The way <BR>> > Modula-3 works here<BR>> > is terrible. Another compromise option is probably <BR>> > __declspec(thread), though there is trickiness there<BR>> > in terms of being in a .dll that isn't used by the .exe.<BR>> <BR>> Such optimizations should be done depending on the target.<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><br /><hr />Climb to the top of the charts! Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>
</html>