[M3devel] target naming again..DJGPP?

Dragiša Durić dragisha at m3w.org
Sun Mar 30 17:16:36 CEST 2008


Is that non-finished port available somehwere?

dd

On Sun, 2008-03-30 at 10:49 -0400, Tony Hosking wrote:
> 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>
> > > 
> > 
> > 
> 
-- 
Dragiša Durić <dragisha at m3w.org>




More information about the M3devel mailing list