<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>The environment variable is still "AMD64" on Windows machines with Intel CPUs. It can't change, for compatibility.<BR>
The headers mention AMD64 repeatedly.<BR>
<BR>
winnt.h:<BR>
#if defined(_M_MRX000) || defined(_M_ALPHA) || defined(_M_PPC) || defined(_M_IA64) || defined(_M_AMD64)<BR>#define UNALIGNED __unaligned<BR>#if defined(_WIN64)<BR>#define UNALIGNED64 __unaligned<BR>#else<BR>#define UNALIGNED64<BR>#endif<BR>#else<BR>#define UNALIGNED<BR>#define UNALIGNED64<BR>#endif<BR><BR>
#if defined(_AMD64_)<BR>#define PROBE_ALIGNMENT( _s ) TYPE_ALIGNMENT( DWORD )<BR>#elif defined(_IA64_)<BR>#define PROBE_ALIGNMENT( _s ) (TYPE_ALIGNMENT( _s ) > TYPE_ALIGNMENT( DWORD ) ? \<BR>...<BR>
<BR>
#ifndef SYSTEM_CACHE_ALIGNMENT_SIZE<BR>#if defined(_AMD64_) || defined(_X86_)<BR>#define SYSTEM_CACHE_ALIGNMENT_SIZE 64<BR>#else<BR>#define SYSTEM_CACHE_ALIGNMENT_SIZE 128<BR>#endif<BR>#endif<BR><BR>
<BR>
excpt.h:<BR>
<BR>
#elif defined(_M_AMD64)<BR>
/*<BR> * Declarations to keep AMD64 compiler happy<BR> */<BR>struct _EXCEPTION_RECORD;<BR>struct _CONTEXT;<BR>
#endif<BR><BR>
This oddity though, winnt.h:<BR>
#define PROCESSOR_INTEL_386 386<BR>#define PROCESSOR_INTEL_486 486<BR>#define PROCESSOR_INTEL_PENTIUM 586<BR>#define PROCESSOR_INTEL_IA64 2200<BR>#define PROCESSOR_AMD_X8664 8664<BR>#define PROCESSOR_MIPS_R4000 4000 // incl R4101 & R3910 for Windows CE<BR><BR>
and:<BR>
#define PROCESSOR_ARCHITECTURE_INTEL 0<BR>#define PROCESSOR_ARCHITECTURE_MIPS 1<BR>#define PROCESSOR_ARCHITECTURE_ALPHA 2<BR>#define PROCESSOR_ARCHITECTURE_PPC 3<BR>#define PROCESSOR_ARCHITECTURE_SHX 4<BR>#define PROCESSOR_ARCHITECTURE_ARM 5<BR>#define PROCESSOR_ARCHITECTURE_IA64 6<BR>#define PROCESSOR_ARCHITECTURE_ALPHA64 7<BR>#define PROCESSOR_ARCHITECTURE_MSIL 8<BR>#define PROCESSOR_ARCHITECTURE_AMD64 9<BR><BR>
<BR>
- Jay<BR><BR><BR>
<BR>
<HR id=EC_stopSpelling>
<BR>
CC: dragisha@m3w.org; m3devel@elegosoft.com<BR>From: hosking@cs.purdue.edu<BR>To: jayk123@hotmail.com<BR>Subject: Re: [M3devel] target naming again..DJGPP?<BR>Date: Sun, 30 Mar 2008 10:49:17 -0400<BR><BR><BR>
<BLOCKQUOTE>
<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">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. </SPAN></DIV></SPAN></DIV><BR>
<DIV>On Mar 30, 2008, at 10:15 AM, Jay wrote:<BR class=EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Right, I plan to do that too.<BR>Please let's also chose names for the following two targets:<BR> <BR> NTAMD64,<SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">AMD64_NT, AMD64_MSWIN, AMD64_WIN, etc.</FONT><BR> NTAMD64MINGNU, AMD64_NT_GNU,<SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">AMD64_MSWIN_GNU,<SPAN class=EC_Apple-converted-space> </SPAN><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,<SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">AMD64_NT_INTERIX</FONT>,<SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">AMD64_INTERIX</FONT>, AMD64_MSU, etc.<BR> <BR>Also consider the following likely targets:<BR> X86_SOLARIS, I386_SOLARIS, X86_SOLARIS<SPAN class=EC_Apple-converted-space> </SPAN><BR> X86_SOLARIS_SUN<SPAN class=EC_Apple-converted-space> </SPAN><BR> <SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">X86_SOLARIS_GNU </FONT><BR> AMD64_SOLARIS<BR> AMD64_SOLARIS_SUN (Sun tools. Do they exist?)<SPAN class=EC_Apple-converted-space> </SPAN><BR> AMD64_SOLARIS_GNU<SPAN class=EC_Apple-converted-space> </SPAN><BR> AMD64_DARWIN<SPAN class=EC_Apple-converted-space> </SPAN><BR> <SPAN class=EC_Apple-converted-space> </SPAN><FONT face="">AMD64_FREEBSD</FONT>, AMD64_FBSD, FREEBSDAMD64, FBSDAMD64 <BR> AMD64_OPENBSD<SPAN class=EC_Apple-converted-space> </SPAN><BR> AMD64_NETBSD <BR> <SPAN class=EC_Apple-converted-space> </SPAN><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 %*<SPAN class=EC_Apple-converted-space> </SPAN><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<SPAN class=EC_Apple-converted-space> </SPAN><BR> \bin\host\target\cm3<SPAN class=EC_Apple-converted-space> </SPAN><BR> \bin\cm3cg<SPAN class=EC_Apple-converted-space> </SPAN><BR> \bin\host\target\cm3cg<SPAN class=EC_Apple-converted-space> </SPAN><BR> <BR>or maybe just<BR> <BR> \bin\cm3<SPAN class=EC_Apple-converted-space> </SPAN><BR> \bin\cm3cg<SPAN class=EC_Apple-converted-space> </SPAN><BR> \bin\target\cm3cg<SPAN class=EC_Apple-converted-space> </SPAN><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=EC_stopSpelling>
<BR>> Subject: Re: [M3devel] target naming again..DJGPP?<BR>> From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:dragisha@m3w.org">dragisha@m3w.org</A><BR>> To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</A><BR>> CC:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>> Date: Sun, 30 Mar 2008 12:53:10 +0200<BR>><SPAN class=EC_Apple-converted-space> </SPAN><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>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> dd<BR>><SPAN class=EC_Apple-converted-space> </SPAN><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>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><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>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><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>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > What to call it?<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > Some combination of<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > (x86 or 386 or i386) and (DOS or MSDOS) and (DJGPP and/or GNU)?<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > DJGPP<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > MSDOS<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > X86_MSDOS<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > X86_DJGPP<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > X86_MSDOS_DJGPP<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > X86_MSDOS_DJGPP_GNU<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > X86_MSDOS_GNU<SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > It really is reasonable to have a quadruple sometimes.<BR>> > architecture-operatingsystem-C runtime-toolset<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > though C runtime doesn't very often.<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > ?I don't want to open the whole can of worms, just need a name for<BR>> > DJGPP.<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><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<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > X86_MSDOS_GNU<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > X86_MSDOS_DJGPP<SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><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<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > 16 bit Windows 3.1 (enhanced mode?)<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > 32 bit code in 16 bit Windows<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > 32 bit protected mode Windows (NT)<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > 32 bit protected mode OS/2<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > other OS/2 variants? 16 bit? Or only 16 bit?<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > Novell Netware I believe!<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > x86 Linux<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > or just<BR>> > DJGPP<BR>> > MSDOS_OPENWATCOM<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > or<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > MSDOS_DJGPP<BR>> > MSDOS_OPENWATCOM<SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > MSDOS implies 32 bit x86. ?<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > PERHAPS some more names should be settled for some actual practical<BR>> > targets that might come up soon, to guide the discussion?<SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > X86_SOLARIS ?<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > AMD64_SOLARIS ?<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > SPARC64_SOLARIS ?<BR>> > Solaris always has two toolsets though, ? Sun and GNU?<BR>> > AMD64_DARWIN ?<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > PPC64_DARWIN ? (obsolete before it ever caught on?)<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > PPC64_AIX ? (this exists as an OS, right?)<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > AMD64_NT -- ambiguous ?<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > AMD64_NT_GNU ?<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > AMD64_NT_MINGNU ? -- this toolset is already out there<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > AMD64_NT_CYGWIN ? -- This isn't likely, Cygwin is very x86-specific<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > AMD64_LINUX ?<SPAN class=EC_Apple-converted-space> </SPAN><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>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><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>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > And consider LLVM in the naming exercise? As a toolset, right?<BR>> > AMD64_LINUX_GNU<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > AMD64_LINUX_LLVM ?<SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > Are people wedded to "I386" instead of "x86"?<BR>> > To indicate clearly it isn't 286 and the ilk?<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><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>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><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>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> > - Jay<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><BR>> --<SPAN class=EC_Apple-converted-space> </SPAN><BR>> Dragiša Durić <<A href="mailto:dragisha@m3w.org">dragisha@m3w.org</A>><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></body>
</html>