[M3devel] target naming again..DJGPP?

Sun Mar 30 17:38:28 CEST 2008

The environment variable is still "AMD64" on Windows machines with Intel CPUs. It can't change, for compatibility.
The headers mention AMD64 repeatedly.

winnt.h:
#if defined(_M_MRX000) || defined(_M_ALPHA) || defined(_M_PPC) || defined(_M_IA64) || defined(_M_AMD64)#define UNALIGNED __unaligned#if defined(_WIN64)#define UNALIGNED64 __unaligned#else#define UNALIGNED64#endif#else#define UNALIGNED#define UNALIGNED64#endif
#if defined(_AMD64_)#define PROBE_ALIGNMENT( _s ) TYPE_ALIGNMENT( DWORD )#elif defined(_IA64_)#define PROBE_ALIGNMENT( _s ) (TYPE_ALIGNMENT( _s ) > TYPE_ALIGNMENT( DWORD ) ? \...

#ifndef SYSTEM_CACHE_ALIGNMENT_SIZE#if defined(_AMD64_) || defined(_X86_)#define SYSTEM_CACHE_ALIGNMENT_SIZE 64#else#define SYSTEM_CACHE_ALIGNMENT_SIZE 128#endif#endif

excpt.h:

#elif   defined(_M_AMD64)
/* * Declarations to keep AMD64 compiler happy */struct _EXCEPTION_RECORD;struct _CONTEXT;
#endif
This oddity though, winnt.h:
#define PROCESSOR_INTEL_386     386#define PROCESSOR_INTEL_486     486#define PROCESSOR_INTEL_PENTIUM 586#define PROCESSOR_INTEL_IA64    2200#define PROCESSOR_AMD_X8664     8664#define PROCESSOR_MIPS_R4000    4000    // incl R4101 & R3910 for Windows CE
and:
#define PROCESSOR_ARCHITECTURE_INTEL            0#define PROCESSOR_ARCHITECTURE_MIPS             1#define PROCESSOR_ARCHITECTURE_ALPHA            2#define PROCESSOR_ARCHITECTURE_PPC              3#define PROCESSOR_ARCHITECTURE_SHX              4#define PROCESSOR_ARCHITECTURE_ARM              5#define PROCESSOR_ARCHITECTURE_IA64             6#define PROCESSOR_ARCHITECTURE_ALPHA64          7#define PROCESSOR_ARCHITECTURE_MSIL             8#define PROCESSOR_ARCHITECTURE_AMD64            9

 - Jay

CC: dragisha at m3w.org; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] target naming again..DJGPP?Date: Sun, 30 Mar 2008 10:49:17 -0400

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:setlocalset host=%1set target=%2if not defined target set host=NT386if not defined target set target=NT386call %~dp0\..\pkg\cm3\%host%\%target%\cm3 %*  But then NT386MINGNU might actually ship a cm3 with different defaults. cm3:#!/bin/shhost=${1:-PPC_DARWIN}target=${2:-PPC_DARWIN}# how to get your own path?exec $0/../pkg/cm3/$host/$target/cm3 $@ m3cc:#!/bin/shhost=${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/91a97ece/attachment-0002.html>