[MUD-Dev] Naming and Directories?

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

J C Lawrence wrote:
> 
> On Fri, 19 Mar 1999 01:44:50 +0100
> olag  <Ola> wrote:
> 
> > It's too bad the Intel's use such a hopeless byteorder...

[postmodern defense of nasty little endian snipped]

> 
>         SMxxxxxxx yyyyyyyyL SMzzzzzzL  "J" "O"   "H" "N"
>        |--word0--|--word1--|--word2--|--word3--|--word4--|....
>        |-C0-|-C1-|-C0-|-C1-|-C0-|-C1-|-C0-|-C1-|-C0-|-C1-|.....
>        |B15....B0|B15....B0|B15....B0|B15....B0|B15....B0|......
> 
> The  M68000  always  has on the left (i.e., LOWER byte- or word-address)
> the wide-end of numbers in any of the various sizes which it may use:  4
> (BCD), 8, 16 or 32 bits.

*CHEERS*

YESSS, the M68K is the only processor that did most things right except
for... Uh, survival tactics (ok, and the clr instruction). It isn't too
difficult to argue that this is the most logical way of doing it. Logic:
if memory starts at zero, then it is natural that strings starts near
zero, comparing strings should not be much different from comparing
numbers.  Little-endian was reasonable on smaller (8bit) systems, because
you had to do the adds in loops to get larger integers etc, so when you
got a pointer you could just add,inc,add,inc,add,inc etc...

> Real CPUs, like MIPS, Alpha, etc can operate natively in either
> little endian and big endian mode.  Truly modern CPU designs (MIPS
> is the only one I'm aware of that fits this description), can
> arbitrarily switch endianess at runtime at a per-process level.

I don't think MIPS is a truly modern CPU... They probably just support
little endian so they can  emulate x386 efficiently. Is that what you
would call "sucking up"? :P  I'll settle for "pragmatic". They've even
got mutiply-add instructions, now that is CISCish... ;)

> Thus you could have both big and little endian binaries running on
> the same OS at the same time...

Yeah well, that is what I don't want. I want one standard: big endian
;-). The pentium does have a BSWAP instruction so that is not the
problem. The problem is that C doesn't, and one has to be careful about
everything... Have some empathy for a programmer with a sore back,
please?

All evil little endians must die!!

KILL KILL KILL

--
Ola Fosheim Groestad,Norway      http://www.stud.ifi.uio.no/~olag/
(Yes, I am infected by a nasty little endian, but I have a big endian in
my bedroom to protect me at night. So rest assure, that I dream sweat
dreams (uh "sweet", one of my regular typos))

PS.
It is my opinion that addresses should refer to bits and not bytes as
well. That would be more elegant, and now with 64bit address-spaces it
would be cheap to sacrifice those 3 bits. Implicit shifts would be cool
(and handy in gfx applications). You can tell that to those Intel
types... Is IA64 bigendian friendly? It better be... *loads shotgun*

Oh yeah, have you noticed how those buggers screw up the instruction sets
with all kinds of specialized instructions? Just to make sure that
compiler-optimization and portability of code is going to suffer. And
that explicit parallelism stuff... :-(  Methinks processors are starting
to get retarded. (waiting for massive parallelism)




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev