[M3devel] serial/Cygwin

[Jay]

Pretty much agreed.
 
 
The implementation is factored along the lines I describe, but I don't test the cross product.
 
 
I think there might be one other interesting middle ground -- a target that uses the gcc backend but is otherwise Windows-like..oh, and probably GNU/gcc and GNU/ld, else you can't debug.
This is analogous to the "MinGWin" project, which is real and works, it offers gcc, that can I believe build itself, but which generally produces binaries with no extra dependency or "strange" :) behavior.
 
 
There is a config file for this called NT386MINGNU, though I think it should be called I386_MINGWIN.
The system was able to build itself, and getting it to work was a subset of Cygwin -- they shared an important bug. This port can't use Trestle currently due to a minor bug in cm3cg.
 
 
The benefits of this middle ground are that you get 64bit LONGINT already, and you might get highly optimized code instead of only moderately optimized code. Personally, I almost never ask gcc to optimize.
 
 
You'll also probably get "AMD64_MINGW" before "AMD64_NT".
Neither all that soon, but I know MinGWin/AMD64 is very far along or even done.
(Other avenues to avoid updating the backend are C_NT and LLVM_NT, but these are so far just fantasies.)
 
 > The implementation is factored along the lines I describe
 
And that is an exaggeration. It is mostly the config file that is factored such.
 
Within the Modula-3 compiler, the only distinction is the "backend mode".
The jmpbuf size is chosen I think to be the maximum of the two C runtimes.
In the distant distant future, the compiler could also distinguish exception handling codegen strategies.
There are several to chose from, like 3 or 4 for x86, 2 for the rest.
  -  setjmp/longjmp -- as it stands now, or interoperable with gcc's similar 
  - "elf/dwarf/whatever" -- range tables, stack walking, gcc supports this these days  
  - NT/x86 style -- builds a linked list through a special per-thread/fiber location 
    conceptually like setjmp/longjmp, but highly optimized.
  - NT/other  -- basically like "elf", but perhaps the relevant data and runtime is different in the details 
 
 - Jay> Date: Thu, 18 Dec 2008 16:03:06 -0600> From: rodney.bates at wichita.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] serial/Cygwin> > I agree that it is highly desirable to have both native windows and Cygwin> variants of Modula-3. But I also think that it is unrealistic to try to> support a complete or even partial Cartesian product of all the many> separate options Jay enumerates. Without debating whether it might be> desirable, it's just way too much work when there are other, more pressing> things to do with our limited support time.> > Mix and match is just entirely unrealistic. By the same reasoning, I> have given up on the similar ideal of making m3gdb handle a linked-together> mix of code from different Modula-3 compilers: PM3, CM3, standalone> backend, different versions of gcc-derived back end, etc.> > I advocate a Cygwin target that is as Unix-like as possible, in as many> respects as possible, and a native Windows target that is as Windows-like> as possible in as many respects as possible. No more.> > > > Mika Nystrom wrote:> > Yes, I don't think the world is a terrible place because people like> > you exist :-)> > > > I just think that Cygwin users generally have modest requirements.> > They're just trying to get something---anything!---to work on> > Windows, and if they want to do anything that's really Windows-specific> > I think they/we understand they/we may have to make the effort to> > learn a bit about Windows and use the native environment.> > > > What it adds up to, in my opinion, is that one shouldn't screw> > things up in the native Windows port (or in the Unix ports) just> > to satisfy Cygwin users, who really don't care if Windows feature> > XYZ is available.> > > > How many people actually use Modula-3 on Cygwin? I do... and I> > just use it so I can run programs I developed on Unix on random> > Windows machines when the owners of those machines have made the> > bizarre (to me) decision to run Windows...> > > > If anything, I'd like it if the Cygwin Modula-3 were *less* Windows-y> > than it is now. For instance, the version I use has Windows> > file-locking semantics, i.e., default readers-and-writers locking> > on all open files, which can be quite annoying when porting from> > Unix. It also uses a different epoch for Time.T. Not sure if> > the current version has these features...> > > > Mika> > > > "Randy Coleburn" writes:> >> --=__Part6F4761B2.0__=> >> Content-Type: text/plain; charset=US-ASCII> >> Content-Transfer-Encoding: quoted-printable> >>> >> I do use Cygwin on occasion, but I'm not sure how most Cygwin users feel => >> about it and Modula-3.> >> =20> >> Mika has a point that if you want to create an environment on Windows that => >> is devoid of Microsoft tools, the Cygwin Modula-3 may be what you are => >> looking for.> >> =20> >> On the other hand, I am in a camp of folks who don't mind using the => >> Microsoft tools and want Modula-3 to work out of the box on Windows => >> without having to add any other non-Microsoft stuff (like Cygwin).> >> =20> >> I think it is great for CM3 to be able to support both these camps!> >> =20> >> Thus, you will find me always advocating for keeping the "CM3 on Windows => >> variant" where it will work on Windows using just the Microsoft tools. I => >> am happy with the use of Windows threads and the native backend and use of => >> the MS Visual Studio linker.> >> =20> >> Regards,> >> Randy Coleburn> >>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081219/393ec80c/attachment-0002.html>