[M3devel] target naming again..DJGPP?

[Tony Hosking]

I would prefer to use x86_64 instead of AMD64 to describe these  
platforms as there is now a degree of commonality between AMD and  
Intel's implementations.  I have had it in the the back of my queue to  
do/complete (someone started it at some point) a Linux x86_64 port  
sometime.

On Mar 30, 2008, at 10:15 AM, Jay wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080330/8c677083/attachment-0002.html>