[M3devel] nt386gnu is posix or win32?

[Jay]

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?)

>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.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080109/dafbc0f4/attachment-0002.html>