[M3devel] [M3commit] CVS Update: cm3

[Daniel Alejandro Benavides D.]

Hi:
I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment.
The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment.
Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same.
So Jay, m3cc could be built on a cygwin enviroment and m3gdb?
If so, we can think in those two separeted platforms? although  cooperative for m3 developers.
I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform.

Thanks


Jay <jayk123 at hotmail.com> wrote:    .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma }  > 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. Play now!

       
---------------------------------

Web Revelación Yahoo! 2007:
 Premio Favorita del Público - ¡Vota tu preferida!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080120/2e479f8f/attachment-0002.html>