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