[M3devel] target naming? AMD64_NT, UWIN?

[Jay]

the old target name game
Lately I'm playing around at home with AMD64 Linux and Windows.Been using AMD64 Windows a while otherwise.I've also been playing around with UWin, which is something like Cygwin.Really nothing substantial yet.Anyone else with similar inclination, go ahead.
UWin has an optional runtime, and not really a toolset.It has cc, ld, ar, but cc and ld are just wrappers forVisual C++ cl/link or other alternatives like Digital Mars,Borland, etc.ar is either a link -lib wrapper or doesn't do all that much in any case.
They also have ncc -- native compiler, to produce Win32 executables.pcc for Posix executables, not sure of the point.
Their runtime supports fork/vfork/exec/spawn, Posix file names, pthreads.They have sh that is ksh, vi.So far gcc does not build in this environment. I tried a bit.They are a much smaller system than Cygwin.Far fewer packages.
They DO have X Windows.
They say they will have 64 bit soon -- presumably AMD64. (IA64?)
Cygwin is fairly x86 specific at this point.I haven't seen any movement on an AMD64 port, though it probably isn't that difficult.
MinGWin is out there too already of course, and has a 64 bit port (shouldn't behard to just rebuild gcc, esp. with Tony's update).
Therefore there are bunch more viable targets or configurations.It is hard to even describe them, other than via the earlier proposedand essentially implemented calculus:
 processor + runtime + C compiler + linker + modula-3 backend  
 processor = x86, AMD64  runtime = msvc, uwin  C compiler = msvc, gcc (borland, watcom, metrowerks, etc.)   (now I see a reason to eliminate C -- so it doesn't figure into the target calculus! :) )  modula-3 backend = integrated, gcc 
 NT386.Common implements something like this, though not always correctly, just  enough for the three existing instantiations to work.
UWin does not provide setjmp/longjmp, good.They have sigsetjmp/siglongjmp that only adds a /small/ amount, like 2 integers or 2 pointers.I have no qualm inflating always an AMD64 jmpbuf to accomodate, if needed.Inflating the NT386 one is still tempting to reduce variety.
On one hand there is a quandary of too many target combinations to consider.But on the other hand is the solution that I implemented under the covers, the above calculus.Therefore, the compiler need only know about AMD64_NT, and the rest can be just "configurations".
Besides, this same answer can be applied to any 32 bit UWin target.
 ??? 
Given the "configuration" idea, I would be ok with NTAMD64, or AMD64_NT, or AMD64_MSWIN, etc.I assume most folks will chose AMD64_NT.
Some other names should probably be chosen, for the Quake files. AMD64_NT_WIN_UWIN -- "native runtime" AMD64_NT_POSIX_UWIN -- posix, X Windows AMD64_NT_MINGWIN  -- native runtime  AMD64_NT - reserved for future port of integrated backend? 
But in the compiler these could all be the same.
or, shorter:
  AMD64_UWINN - UWin native  AMD64_UWINP - UWin posix   AMD64_UWINX - UWin posix ?
"UWIN" implies "Windows" implies "NT", so good enough?
or, processor, ostype, variant, and again UWin implies NT, ostype=win implies NT?:
 AMD64_POSIX_UWIN  AMD64_WIN_UWIN (not very interesting, really)   AMD64_WIN_GCC (MinGWin)  AMD64_POSIX_CYG (future)    same as AMD64_CYGWIN or NTAMD64GNU??  AMD64_WIN_NATIVE -- integrated backend, msvc cl/link (future) 
Usually "ostype" is not interesting in targets, since nearly everything is Posix.And "variant" is just a random escape hatch to try to come up with something.
???
I know I talk more about making new targets than actually doing it, sorry.
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080414/a43880e4/attachment-0002.html>