<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Right, I plan to do that too.<BR>
Please let's also chose names for the following two targets:<BR>
<BR>
NTAMD64, <FONT face="">AMD64_NT, AMD64_MSWIN, AMD64_WIN, etc.</FONT><BR>
NTAMD64MINGNU, AMD64_NT_GNU, <FONT face="">AMD64_MSWIN_GNU, <FONT face="">AMD64_WIN_GCC, AMD64_NT_MINGWIN, MING64, MINGWIN64, etc.</FONT></FONT><BR>
<BR>
You can work NTAMD64GNU/AMD64_NT_CYGWIN into the scheme, but it is less likely to happen.<BR>
Also Services for Unix, <FONT face="">AMD64_NT_INTERIX</FONT>, <FONT face="">AMD64_INTERIX</FONT>, AMD64_MSU, etc.<BR>
<BR>
Also consider the following likely targets:<BR>
X86_SOLARIS, I386_SOLARIS, X86_SOLARIS <BR>
X86_SOLARIS_SUN <BR>
<FONT face="">X86_SOLARIS_GNU </FONT><BR>
AMD64_SOLARIS<BR>
AMD64_SOLARIS_SUN (Sun tools. Do they exist?) <BR>
AMD64_SOLARIS_GNU <BR>
AMD64_DARWIN <BR>
<FONT face="">AMD64_FREEBSD</FONT>, AMD64_FBSD, FREEBSDAMD64, FBSDAMD64 <BR>
AMD64_OPENBSD <BR>
AMD64_NETBSD <BR>
<BR>
<BR>
and let me know which are actually "likely".<BR>
I think there are a surprisingly large number of likely new targets -- at LEAST AMD64 for Windows and MacOSX, probably also some AMD64 BSD and maybe AMD64/x86 Solaris.<BR>
<BR>
It's easy to work on getting these to compile actually, they all share the same likely small set of problems, in a cross compile.<BR>
I'll have enough hardware soon enough, though my current primary home machine is only 32 bit.<BR>
<BR>
We should also possibly think more about how cross compilation looks and works, since I think cross compilation is getting more common.<BR>
Could be that it mostly already is worked out though.<BR>
The main thing maybe is to have \cm3\bin\cm3.cmd, \cm3\bin\cm3, \cm3\bin\cm3cg that are actually cmd and sh that delegate off to \cm3\pkg\cm3\host\cm3 and \cm3\pkg\m3cc\host\target\cm3cg, usually via some very unambiguous parameter for the scripts' use or a very fast sniff for interactive use, possibly the scripts are actually host dependenent in their default, rather than ever sniffing, you know, they are like about two lines each, and actually host specific.<BR>
<BR>
cm3.cmd:<BR>
setlocal<BR>
set host=%1<BR>
set target=%2<BR>
if not defined target set host=NT386<BR>
if not defined target set target=NT386<BR>
call %~dp0\..\pkg\cm3\%host%\%target%\cm3 %* <BR>
<BR>
But then NT386MINGNU might actually ship a cm3 with different defaults.<BR>
<BR>
cm3:<BR>
#!/bin/sh<BR>
host=${1:-PPC_DARWIN}<BR>
target=${2:-PPC_DARWIN}<BR>
# how to get your own path?<BR>
exec $0/../pkg/cm3/$host/$target/cm3 $@<BR>
<BR>
m3cc:<BR>
#!/bin/sh<BR>
host=${1:-PPC_DARWIN}<BR>
target=${2:-PPC_DARWIN}<BR>
# how to get your own path?<BR>
exec $0/../pkg/m3cc/$host/$target/cm3 $@<BR>
<BR>
they don't necessarily delegate to the package store.<BR>
It migth actually be<BR>
\bin\cm3 <BR>
\bin\host\target\cm3 <BR>
\bin\cm3cg <BR>
\bin\host\target\cm3cg <BR>
<BR>
or maybe just<BR>
<BR>
\bin\cm3 <BR>
\bin\cm3cg <BR>
\bin\target\cm3cg <BR>
<BR>
host might be implied by "\bin" or what is above it (nothing here, but could be something).<BR>
<BR>
Not delegating out to the package store has a possible advantage to being more "relocatable" into other file system contexts.<BR>
<BR>
I'm a fair amount interested in working out a solid well adhered to convention here.<BR>
In particular, scripts should be able to depend on it so they can skip the wrapper.<BR>
It should, perhaps, if I'm not crazy, be possible and obvious how to create a "very full" tree/distribution for use "anywhere".<BR>
You know, in a file system shared by multiple host systems, or in a distribution that is super piggy on the download and maybe prunes itself down upon install.<BR>
Or maybe one of those stub installers that downloads just what the user requests.<BR>
<BR>
It might also be by file name, cm3, vs. cm3-nt386.exe.<BR>
<BR>
On the other hand, this maybe isn't all that important.<BR>
<BR>
Furthermore..it'd be nice to work gcc and ld and headers/libs into this structure if possible. I like fewer larger pieces of functionality so I don't have to go and setup so many varying inconsistent things, and then it becomes possible to build any Modula-3 target on any host. I guess I should just get into doing my own builds and cross builds of gcc/ld/glibc and setup config files appropriately, though I don't think everything is licensed "appropriately" and/or it'd still be some "aggregation", since it isn't always GNU ld (for example on Darwin) or glibc (many examples -- Cygwin, Darwin, Solaris).<BR>
<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Subject: Re: [M3devel] target naming again..DJGPP?<BR>> From: dragisha@m3w.org<BR>> To: jayk123@hotmail.com<BR>> CC: m3devel@elegosoft.com<BR>> Date: Sun, 30 Mar 2008 12:53:10 +0200<BR>> <BR>> djgpp being piece of archaeology, it surely is interesting. Would be<BR>> much better to invest time in 64bit ports these days, though :).<BR>> <BR>> dd<BR>> <BR>> On Sat, 2008-03-29 at 21:59 +0000, Jay wrote:<BR>> > Does anyone else find the idea of a DJGPP port "interesting"?<BR>> > <BR>> > <BR>> > I think I'll go ahead and do it. I know its useless but I find it<BR>> > "interesting".<BR>> > A few things will come before it.<BR>> > <BR>> > <BR>> > The DJGPP runtime appears to have the adequate support for<BR>> > alarm/setitimer,<BR>> > so it /should/ be fairly easy.<BR>> > I've already demonstrated to myself cooperating threading, and<BR>> > alarm/setitimer<BR>> > can be used for preemption, with the user posix threads.<BR>> > The easy work I did pruning down NT386GNU's *.i3 file to a minimum<BR>> > will be useful.<BR>> > <BR>> > <BR>> > What to call it?<BR>> > <BR>> > <BR>> > Some combination of<BR>> > <BR>> > <BR>> > (x86 or 386 or i386) and (DOS or MSDOS) and (DJGPP and/or GNU)?<BR>> > <BR>> > <BR>> > DJGPP <BR>> > MSDOS <BR>> > X86_MSDOS <BR>> > X86_DJGPP <BR>> > X86_MSDOS_DJGPP <BR>> > X86_MSDOS_DJGPP_GNU <BR>> > X86_MSDOS_GNU <BR>> > <BR>> > <BR>> > It really is reasonable to have a quadruple sometimes.<BR>> > architecture-operatingsystem-C runtime-toolset <BR>> > though C runtime doesn't very often.<BR>> > <BR>> > <BR>> > ?I don't want to open the whole can of worms, just need a name for<BR>> > DJGPP.<BR>> > <BR>> > <BR>> > DJGPP and MSDOS are fairly unambiguous here..but...<BR>> > Open Watcom is also a viable runtime/toolset.<BR>> > Maybe fit into the naming.<BR>> > X86_MSDOS_WATCOM <BR>> > X86_MSDOS_GNU <BR>> > X86_MSDOS_DJGPP <BR>> > <BR>> > <BR>> > Open Watcom really puts a monkey wrench into it.<BR>> > X86_OPENWATCOM is among the most ambiguous hypothetical names, because<BR>> > OpenWatcom targets<BR>> > a bajillion x86 variants (and even made progress toward Alpha and<BR>> > PowerPC).<BR>> > Open Watcom is actively developed and targets at least:<BR>> > 16 bit real mode MS-DOS<BR>> > 32 bit protected mode MS-DOS <BR>> > 16 bit Windows 3.1 (enhanced mode?) <BR>> > 32 bit code in 16 bit Windows <BR>> > 32 bit protected mode Windows (NT) <BR>> > 32 bit protected mode OS/2 <BR>> > other OS/2 variants? 16 bit? Or only 16 bit? <BR>> > Novell Netware I believe! <BR>> > x86 Linux<BR>> > <BR>> > or just<BR>> > DJGPP<BR>> > MSDOS_OPENWATCOM <BR>> > or<BR>> > <BR>> > MSDOS_DJGPP<BR>> > MSDOS_OPENWATCOM <BR>> > <BR>> > MSDOS implies 32 bit x86. ?<BR>> > <BR>> > <BR>> > PERHAPS some more names should be settled for some actual practical<BR>> > targets that might come up soon, to guide the discussion? <BR>> > <BR>> > X86_SOLARIS ? <BR>> > AMD64_SOLARIS ? <BR>> > SPARC64_SOLARIS ?<BR>> > Solaris always has two toolsets though, ? Sun and GNU?<BR>> > AMD64_DARWIN ? <BR>> > PPC64_DARWIN ? (obsolete before it ever caught on?) <BR>> > PPC64_AIX ? (this exists as an OS, right?) <BR>> > AMD64_NT -- ambiguous ? <BR>> > AMD64_NT_GNU ? <BR>> > AMD64_NT_MINGNU ? -- this toolset is already out there <BR>> > AMD64_NT_CYGWIN ? -- This isn't likely, Cygwin is very x86-specific <BR>> > AMD64_LINUX ? <BR>> > IA64_VMS ?<BR>> > IA64_LINUX ?<BR>> > two or more toolsets, right? GCC, Intel, SGI?<BR>> > IA64_LINUX_GNU ?<BR>> > IA64_LINUX_INTEL ?<BR>> > IA64_LINUX_SGI ?<BR>> > <BR>> > <BR>> > I'm skeptical there will be any IA64 ports, but I expect there will be<BR>> > AMD64.<BR>> > (I have seen IA64 for around $500 on eBay, tempting, for a port..)<BR>> > <BR>> > <BR>> > And consider LLVM in the naming exercise? As a toolset, right?<BR>> > AMD64_LINUX_GNU <BR>> > AMD64_LINUX_LLVM ? <BR>> > <BR>> > <BR>> > Are people wedded to "I386" instead of "x86"?<BR>> > To indicate clearly it isn't 286 and the ilk?<BR>> > <BR>> > <BR>> > I am somewhat wedded to "AMD64", though other names include "X64" and<BR>> > X86-64.<BR>> > X86-64 is too long, and the dash would probably go away, X8664,<BR>> > getting to be a long run of gibberish numbers.<BR>> > X64...is that less than X86? :)<BR>> > AMD64 is the value of %PROCESSOR_ARCHITECTURE% on NT and the install<BR>> > directory name on the pre-Vista CDs (along with i386), and it is<BR>> > available as an #ifdef (_AMD64_, _M_AMD64).<BR>> > <BR>> > <BR>> > Intel was calling it EM64T, but that gone away in favor of Intel64, to<BR>> > not be confused with IA64, which is Itanium, stands for Intel<BR>> > Architecture 64 hm...<BR>> > Intel64 != Intel Architecture 64.<BR>> > Admittedly they were kind of stuck.<BR>> > <BR>> > <BR>> > - Jay<BR>> > <BR>> -- <BR>> Dragiša Durić <dragisha@m3w.org><BR>> <BR><BR></body>
</html>