[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