casey@COGNET.UCLA.EDU (11/01/88)
I need to put some byte order ifdef's in my code based on CPU architecture type. The Apollo SR10 cpp doesn't define the architecture type being compiled on. I.e., I can't do things like ``#ifdef mc68000''. Note that I can't replace this with ``#ifdef apollo'' since Apollo now has a non mc68000 architecture. For all I know, the new RISC architecture is Big Endian just as the mc68000 is, but unless Apollo is willing to guarantee that all future products will have exactly the same byte ordering, ifdef'ing on apollo seems somewhat silly ...
lnz@LUCID.COM (Leonard N. Zubkoff) (11/02/88)
If you look in /usr/include/apollo_$std.h, you'll find that the symbol m68000 is defined. If you look at the file /sys/ins/error.ins.pas in SR10, you'll also see that Apollo uses the symbols isp_$m68k and isp_$a88k to differentitate between the two architectures. The PRISM architecture is indeed big-endian; since Apollo is firmly committed to binary compaitibility of data files, it would be very hard to change this in future architectures without losing that binary compatibility. Leonard Zubkoff
oj@apollo.COM (Ellis Oliver Jones) (11/02/88)
In article <17414@shemp.CS.UCLA.EDU> casey@COGNET.UCLA.EDU (Casey Leedom) writes: >I need to put some byte order ifdef's in my code based on CPU >architecture type. >The Apollo SR10 cpp doesn't define the architecture >type being compiled on. Yes it does! There are two symbols: _ISP__M68K (underscore I S P underscore underscore M 6 8 K ) _ISP__A88K (underscore I S P underscore underscore A 8 8 K ) In an Apollo SR10 C compiler, both are defined, and one has a nonzero value. _ISP__M68K means Motorola 68K cpus. _ISP__A88K means Apollo PRISM cpus (DN10000) For compatibility with SR9.7, I use cpp stuff like the following: #ifdef _ISP__A88K /* do whatever for SR10 (regardless of CPU type) */ #if _ISP__A88K /* do whatever for PRISM CPUS */ #endif #if _ISP__M68K /* do whatever for Motorola 68K CPUS */ #endif #else /* do whatever for pre-SR10 */ #endif The following symbols are also defined: #define apollo 1 #define aegis 1 #define unix 1 #define m68000 1 #define timezone _bky_timezone The PRISM is in fact big-endian, and data-compatible with the Motorola cpus. To stop idle speculation about the meaning of A88K, the "A" means Apollo, the "88" refers to the year of the first release of a cpu of the type, and I have no idea what the "K" means. /Ollie Jones (speaking for myself, not necessarily for Apollo Computer, Inc.)
Jinfu@cup.portal.com (Jinfu Jinfu Chen) (11/03/88)
oj@apollo.COM (Ellis Oliver Jones) writes: > In an Apollo SR10 C compiler, both are defined, and one has a > nonzero value. > _ISP__M68K means Motorola 68K cpus. > _ISP__A88K means Apollo PRISM cpus (DN10000) ^^^ This reminds me a rumor floating around for sometime. It was said that originally Apollo wanted to use Motorola's 88000 (88k) chip set for its new line of workstation. However, they couldn't wait Moto too long (Sun's heat?) so that they went off to design the PRISM archecture. The rumor even said the PRISM archecture is designed that the Moto 88k chip set can be used easily in the DN10k. Any comments? Jinfu Chen
casey@admin.cognet.ucla.edu (Casey Leedom) (11/10/88)
Sorry for taking so long to get back to this subject. I've been totally
snowed under with a number of things, including my continuing efforts to
get X.V11R3 compiled under SR10, but more on that in a later letter ...
Thanks to Larry Allen <lwa@apollo.com>, Leonard Zubkoff
<lnz@LUCID.COM>, and Ellis Jones <oj@apollo.COM> for information about
the Apollo compiler predefined defines m68000 (apparently for back
compatibility with previous releases of Apollo's development system), and
_ISP__M68K and _ISP__A88K under Apollo's new release, SR10.
These defines do indeed allow me to determine the architecture of the
machine I'm compiling on so I can do the ``right thing'' for byte
ordering dependencies in structures for things like network independent
data, etc. And, as was pointed out by Leonard Zubkoff,
``The PRISM architecture is indeed big-endian; since Apollo is
firmly committed to binary compatibility of data files, it would
be very hard to change this in future architectures without
losing that binary compatibility.''
it turns out not to matter too much. Or rather, ``#ifdef apollo'' can
probably be taken as the same as ``#ifdef BIG_ENDIAN'' for the rest of
time (but I still prefer to ifdef on particular architectures to be
safe).
But a question pops into my mind at this point: are these predefined
defines defined anywhere? That is, does ANSI C define them? Obviously
it couldn't define all of them because new architectures will be brought
to market, etc. A set of standard ANSI C predefined architecture defines
would in fact almost seem to be the perfect thing to add to a new section
of the Assigned Numbers RFC that the NIC maintains. Does anyone have any
information on this?
Casey
P.S. I'm prompted to this question because 1. I've seen most compilers
use "mc68000", not "m68000", and 2. the _ISP... defines look very
ANSI Cish ...gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/11/88)
In article <17746@shemp.CS.UCLA.EDU> casey@cs.ucla.edu (Casey Leedom) writes: > But a question pops into my mind at this point: are these predefined >defines defined anywhere? That is, does ANSI C define them? Obviously >it couldn't define all of them because new architectures will be brought >to market, etc. A set of standard ANSI C predefined architecture defines >would in fact almost seem to be the perfect thing to add to a new section >of the Assigned Numbers RFC that the NIC maintains. Does anyone have any >information on this? To provide a guarantee of purity of application-usable name spaces, ANSI C forbids the implementation to predefine any macro names that do not begin with a leading underscore followed by an upper-case letter or a second underscore. Thus a conforming implementation cannot predefine symbols such as unix vax mc68000 u3b apollo However, _ISP__MC68K is permitted. There is no known central registry for such implementation-supplied names. (It is certainly outside the scope of X3J11.)