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