[M3devel] platform/build_dir is a big tuple?

[Jay]

 >      If anyone wanted user vtlaram or fiber, this could be extended.
 > It probably always should have been fibers instead of setjmp/longjmp where fibers are available...
 
Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm threads.
 
If anyone does want to take over their own scheduling and have an N:M model, fibers are perhaps the way to go, unless you need Win9x. Fibers take care of creating a stack and swapping register context, whereas setjmp/longjmp only swap register context and I suspect Modula-3 uses them in a non-conformant but generally-compatible way. I haven't looked into this yet. For exceptions, ok. For thread switching, probably not.
But I'd have to look at how it's implemented..
 
user mode threads, fibers..are problematic. For example Win32 critical sections can be taken recursively, on the same thread. Fibers can move around between threads and therefore cannot take them recursively.
 
All in all, as said below, I'm inclined to omit support for user mode threads on Windows.
I ASSUME the Cygwin pthreads are a thin wrapper over Windows, except...except there is the condition variables...not sure they can be layered over thinly... As I said, this is one bit I am uncertan of. Maybe just always use native Win32 threads.
It would be a perhaps interesting curiosity to see if cygwin binaries tend to only depend on cygwin .dlls and not win32 .dlls, as a "proof" of the "completeness" of the layer/wrapping. (though as to the quality, see below.) Of course, cygwin code can still use win32..your m3makefile might actually check target==nt386 to know "the truth". But I doubt anyone would use this flexibility.
 
 - Jay


From: jayk123 at hotmail.comTo: lemming at henning-thielemann.de; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] platform/build_dir is a big tuple?Date: Wed, 23 Jan 2008 07:37:28 +0000


Let me cut to the chase, again:  Everyone will probably be satisfied.  For a very small "everyone". :)  The underlying implementation shall be "heavily" parameterized.There shall be three visible pre packaged configurations.Power users, and clever and crazy people can experiment beyond those three.The EXACT three configurations is SLIGHTLY up in the air, but is likely to be: NT386  same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 kernel threads, native backslashy paths (and perhaps increased compat with forward slashes, some of that is already in, m3core, but not yet cm3), Visual C++ compiler and linker. NT386MINGNU  same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working    external backend, gcc compiler and linker, but otherwise same as NT386  One small wrinkle here is there is no m3gdb, but you can use the m3gdb from the next one, or Cygwin's gdb. NT386GNU  As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C library, stupid looking paths that start /cygdrive, wierdo symlinks that don't interoperate well with the rest of the system (attempting to run cc.exe crashes ntvdm.exe, for example), "link" makes file system links (or at least strange files) instead of linking programs, a slow and perhaps fragile copy-immediately implementation of fork, problems running one type of program from another because you don't know which command line parameters and which environment variables represent paths or lists of paths and therefore how to translate them, etc. The underlying parameters, which are largely independent and which you can change individually, but which you will actually just ignore usually, shall be:   modula-3 backend     integrated 0     cm3cg 1   This might be replaced by the existing 0-3 variable.   C compiler      Visual C++ cl 0    gcc 1    In future this could be redefined as decimal digit or a character to accomodate other choices.   linker     Visual C++ link 0     gcc 1    In future this could be redefined as decimal digit or a character to accomodate other choices.    Threading library     Native Win32 kernel threads 0     Cygwin pthreads which are probably layered on native Win32 kernel threads 1     This is the one area where people have suggested using native Win32 functionality instead of Cygwin     vtalaram user threads probably not available     fiber user threads probably not available          This would have been better than vtalaram, but not Win9x compatible     If anyone wanted user vtlaram or fiber, this could be extended. It probably always should have been fibers instead of setjmp/longjmp where fibers are available...    Window library      Native Win32 gui 0 (hopefully with bugs to be worked out)       X Windows via CygwinX 1 (hopefully the binaries are X server agnostic, and even work against a remote Unix machine?)     C library      native msvcr* through Visual C++ or MinGWin 0      Cygwin and its path oddities 1  The current notion of "OSTYPE" becomes much less useful here, as it previously embodied multiple factors. It wasn't all that useful anyway, imho, but as a way to reduce the matrix of targets down to two, the same two in multiple places. Now, in a few places, you check a more specific variable. Theoretically, I don't have to change cm3 here, just the config file and some m3makefiles. Because, tricky tricky, the main thing cm3 cares about is the backend "mode", and that does match up above with the 0/1. There are actually 4 modes and I should maybe hoist that up to be the variable, very maybe. A few m3makefiles will have to change, in small ways.   Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe threading, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet, is that individual m3makefiles should be able to ask for one compiler or the other. The base system won't do that, but user systems could, if they have some code that depends on one compiler or the other and they are going to link it together. For this purpose, for exposing these features to users, possibly values other than "0" and "1" are needed. If the configuration is one of these three combinations, build_dir is translated as shown.Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. This is essentially already commited. NT386 works this way. NT386MINGNU works this, but is for now called NT386GNU, and doesn't have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, but easily should be. There are three config files, NT386, NT386MINGNU, NT386GNU, they are all just a few lines and then include NT386.common. Oh, one more thing I haven't worked out is how the user asks for one target or another.It is probably via the environment variable CM3_TARGET, though in reality, "TARGET" for all of these shall be NT386. Any questions?Don't ask me when Cygwin NT386GNU will be active or when the names will flip. I will try it soon. This is essentiallyalready in the tree, with a little bit of "temporary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, I think I've stopped thinking through the indecisiveness, I just keep hearing the two extreme sides, the Windows users who want Windows (do you even care about the gcc backend? It's slow. It generates inefficient code. It supports Longint) and a few Unix users who might reluctantly use Windows a little more if their backend slowed down and their libraries changed... Personally my main goal here is to not feel guilty about not finishing the LONGINT support yet in the integrated backend.I'd still like to finish that, but it was taking embarassingly long. I'd also like an uber-cross build environment, where I can build anything from anything. Getting cm3cg working was part of that. I'm not sure I have the patience to build gcc and ld/binutils that many times though.    - Jay

> Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22 Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I am happy to stay with the underlying OS, the> > native windows threading, the integrated backend, and use the free> > Microsoft Visual Studio tools. I don't really want to have to> > install/use cygwin or any of the other variants. When I see target => > NT386, this list is what I am expecting. For the cm3 newbie coming from> > a Microsoft Windows environment, I think this list would be the most> > appealing and pose the least barrier to getting starting. Yes, I still> > will work on the installer program once I'm satisfied that I have a good> > working cm3 on Windows.> > One year ago I was in the situation to port one of my Modula-3 programs> from Linux to Windows in order to hand it over to a Windows user. As I> never use Windows, I have only a plain Windows installation on my machine> with almost no tools other than cm3. I was glad to be able to run cm3> immediately and to find all libraries that I needed in binary form without> Cygwin dependencies - otherwise not only I had to install that on my> machine but I also would have to persuade the other Windows guy to install> it as well. Summarized I strongly vote for NT386 being Windows with least> dependencies on other packages.

Connect and share in new ways with Windows Live. Get it now! 
_________________________________________________________________
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/20080123/5c9fa264/attachment-0002.html>