[M3devel] nt386gnu is posix or win32?

[Tony Hosking]

This echoes my desire that NT386GNU/Cygwin rely mostly on the POSIX  
personality of Cygwin, though threading might use win32.dll.


On Jan 9, 2008, at 8:02 PM, hendrik at topoi.pooq.com wrote:

> On Wed, Jan 09, 2008 at 11:08:57PM +0000, 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.
>> 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.
>>
>> 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?)
>
> One of my reasons for using m3 long ago was that I could write  
> programs
> that would run on both Linux and Windows *without* using the Microsoft
> tools, which I did not possess.
>
> -- hendrik