[M3devel] platform/build_dir is a big tuple?

[Tony Hosking]

On Jan 23, 2008, at 2:49 AM, Jay wrote:

>  >      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.

ThreadPosix uses user/vtalarm threads.  Swicthing is done using  
setjmp/longjmp or setcontext/getcontext depending on platform.  ON  
modern POSIX platforms it should always use the latter.

>
>
> 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.com
> To: lemming at henning-thielemann.de; rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> Subject: 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. Play now!