NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/mac/hardware/24947

Internet Message Format | 1992-12-27 | 3.2 KB

Path: sparky!uunet!utcsri!torn!spool.mu.edu!hri.com!enterpoop.mit.edu!linus!alliant!merk!spdcc!jfwhome!jfw
From: [e-mail] (John F. Woods)
Newsgroups: comp.sys.mac.hardware
Subject: Re: P5 v. PowerPC (WAS: Where the mac really wins)
Message-ID: <[e-mail]>
Date: 27 Dec 92 14:22:14 GMT
References: <[e-mail]> <[e-mail]>
Organization: Misanthropes-R-Us
Lines: 45

In <[e-mail]> [e-mail] (Parag Patel) writes:
>[e-mail] (Michael Peirce) writes:
>>My friends at DEC tell me there was one overriding reason that Alpha
>>wasn't picked over PowerPC: Politics.  The technological considerations
>>were a distant second.
>Don't underestimate the effects of hardware endian problems (ie which
>byte is most significant in a word).  Macs (mc68ks) are big-endian, and
>a lot of software (system and otherwise) makes implicit assumptions
>about it.  The Alpha is little-endian, making both porting Mac system
>software and Mac emulation a lot more difficult.
> ...
>I believe that the PowerPC is like the MIPS, in that it can handle
>either endian-ness, but if it can't, I'll bet it's big-endian.
>Unfortunately, while most modern chips can go either way, the software
>which runs upon it usually doesn't.  Sad, but system software generally
>has to make such assumptions to run fast (networking code, drivers, etc.)

Don't overestimate the effects of byte-order, either.  Extremely few programs
*should* care one way or the other, and very few programs *do* care one way
or the other (having ported enough software to learn the difference in the
size of those two sets :-).  It is not hard to write software (in high-level
languages, anyway) which is independant of byte order -- to use one of your
examples, get a copy of the Berkeley networking code (before USL has it
declared Top Secret :-( ), and look around for uses of the macros ntohs(),
ntohl(), htonl(), htons(); essentially, you convert network-order values to
host order once, then stare at them hundreds of times in native format.  The
"wrong-endian" processor for a given network is at a slight disadvantage
(since it does, indeed, need to swap those bytes), but it only needs to swap
them once.  Drivers are somewhat harder (though with the prevalence of byte-
wide chip registers, this is less of a problem than you might thing), but it
is nowhere near insurmountable.

It occurs to me that another technical glitch the Alpha presents may have
been more significant -- the Alpha is a 64 bit chip (I assume PowerPC is
32 bits), and there's a lot more code that stumbles over data-*size* problems
than byte-order; the Berkeley networking code will again show lots of examples
where (for example) pointers are laid over no-longer-used structure elements
to avoid having to allocate a pointer structure and copy some data around.
That kind of thing, too, is not insurmountable (having surmounted several
examples myself), but that may have been a more significant factor in
the decision (I hope the Pink system interface is specified at a high-enough
level that it will be able to migrate to 64-bit processors easily).

Or maybe the folks at Apple misheard the name and declared "We do *fruits*,
not *grains*."    :-)