[M3devel] nt386gnu is posix or win32?

[Tony Hosking]

On Jan 9, 2008, at 6:08 PM, Jay wrote:

> I'm going to be rude and just throw this out there at a time when I  
> probably can't discuss it or yet have enough data/diffs to matter.
>
> However, in building NT386GNU -- I can build libm3 and m3core --  
> the question arises as to if this target is "win32" or "posix'.
> Currently in the tree it is setup to be "posix", with a fair amount  
> of work already done in that direction -- in particular, the Unix  
> interfaces.
>
> However, I think this target is potentially an odd beast.  
> Potentially it is two targets.
> I guess this mimics cygwin vs. mingwin. Exactly.
>
> The "host" is gcc. In order to build this system, one needs  
> "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/ 
> linker cannot build m3cg, but very maybe..).
>
> In order to build anything with this system, one needs "as", and  
> most likely ld.
>   (I quote "as" because it is an English word and confusing to read  
> otherwise.)
> Changing it to output assembly for masm or even Visual C++'s inline  
> __asm is probably actually viable, but not a tiny short term task.
> (Or maybe writing an as clone that outputs .objs? Maybe using nasm/ 
> yasm??? Not sure the point, maybe "as" is perfectly ok.)
>
> And then the question arises as to what it takes to run the output.
> As I've said in other topics, the C runtime dependency of Modula-3  
> is light -- startup code mainly, but, yeah, also important setjmp/ 
> longjmp, and multiplication/division helpers sometimes. This could  
> perhaps all be statically linked. Certainly for Visual C++ it can be.
> (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A  
> THOUGHT is to grow them to the same, for object code compatibility,  
> but probably not useful, and very wasteful, Cygwin's is much  
> larger, the data in the existing code I verified is correct, like  
> 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof 
> (jmp_buf)).)
>
> To get m3core to build, I switched NT386GNU to use Win32 threads.
> For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in  
> order to get the Win32 *.i3 files.
> Overkill perhaps, but it does build.
>
> I fully suspect that old style Posix threads can work easily, and  
> that pthreads can work easily, increasing the dependency on  
> cygwin1.dll.

User-level (ThreadPosix) threads might work (using setjmp/longjmp for  
thread switching -- I guess that is what PM3 used to do).  Or did it  
use ThreadWin32?   I doubt ThreadPThread will work since I don't  
think there is a pthreads binding for Win32 threads on NT, or is there?

> While this is the "other" direction, given the dependency on as,  
> and gcc to build m3cg, probably the horse is out of the barn.
> This is arguably a simpler answer, less hybrid.

My strong preference is to tread NT386GNU (i.e., Cygwin based) as a  
POSIX target, which might happen to use ThreadWin32.  That way, the  
usual POSIX/Cygwin flavor of things is preserved.

>
>
> I think the analogy to cygwin/mingwin holds, possibly perfectly.
>
> Maybe this is two targets.
>   NT386CYGWIN  ?
>   NT386MINGWIN ?
>
> (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS 
> +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is  
> toolchain and C runtime in the mix..)
>
> Obviously SOMETHING is better than NOTHING and I have no useful  
> binary distribution yet to show, so these questions are all very  
> premature.
>
> I'm also unsure as to the "seriousness" of using the GNU tools.
> a) There don't seem to be many users of Modula-3 on Win32.
> b) Will such users accept/trust a non Microsoft toolchain?
> (Just what to do folks do with cygwin/mingwin? Build/ship real  
> software?)
>
> From my point of view, the attractive thing about m3cg is I get the  
> int64 stuff arguably out of the way easier. :)
>
> Licensing wise..probably a dependency on cygwin1.dll is not desirable.
>
> When I'm further along, er, actually, with my existing libm3.dll/ 
> m3core.dll, I can see what the dependencies are.
> If it's just setjmp/lonjmp/memset, maybe try static linking (what  
> is the licensing of that?) or link to msvcr*.dll.
>
> Maybe see if I can configure to use mingwin to compile/link except  
> for m3cc. That sounds excellent.
> You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a  
> MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for  
> building m3cc, and either could be used for building anything  
> else. ?? That seems good, though I just thought of it, need more  
> time to think and investigate.
>
> Later..
>  - Jay
>
>
> Share life as it happens with the new Windows Live. Start sharing!