Article View: comp.sys.next.hardware
Article #171Byte Swapping (Was: New RISC workstations)
From: Steven T. Abell
Date: Mon, 02 Nov 1992 19:55
Date: Mon, 02 Nov 1992 19:55
62 lines
3609 bytes
3609 bytes
eboltz@jhunix.hcf.jhu.edu (Eric Scott Boltz) writes:
> As far as Intel CPUs go, aren't they the ones that expect multiple-byte
> data to have bytes swaped? - Yuck.
As far as I'm aware, nobody has *ever* made a machine that got byte-ordering
right in combination with several other crucial factors. This has had an
unpleasant effect on sofware quality.
Consistency is very important. The best starting point when designing a CPU
is this picture:
+-------------------------------------------------+
| byte 1 | byte 0 |
+-------------------------------------------------+
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
where the numbers below denote the numerical value of the bits. Thus, the bit
ordering and the byte ordering are consistent with each other and with
standard mathematics. In this regard, the Intel was *right*, however goofy
they were about everything else. With this method, you can draw consistent
machine-data diagrams and never have to worry about which set of rules you
need to be using. One of the crimes of the upper end of the 68000 family is
its flipping of bit ordering in the more advanced bit operations.
Now, extending the previous picture to strings,
abcdefg... ...mnopqrstuvwxyz
more significant <-- --> less significant
higher address <-- --> lower address
which is *consistent*. Once again, no more worries about which set of rules
you are using now. In this way, Intel got it wrong, since they want you to
have the first byte of a string at the lowest address, but then, so does
Motorola, except their picture is flipped. This is *wrong*. It also wastes
some processor capability: string operations usually proceed from left to
right, but with either the Intel or Motorola picture, you can't use the
index of a decrement-branch instruction as an index into the string itself.
The design I suggest is very different from what we're used to, but it works
just as well in the machine, and better in our heads when we're writing
programs. That translates into fewer bugs.
0) All memory diagrams are written sideways,
with the most-significant bit, byte, word, whatever, on the left.
1) The base address of a string, struct, array is its *end*, not its beginning.
These are written in memory diagrams from left-to-right, as in (0).
String indexing is consistent with the value of decrement-branch indices.
2) Post-decrement and pre-increment addressing modes are implemented,
instead of post-increment and pre-decrement.
Post-decrement is just as fast as post-increment, if you were worried.
3) Processor stacks grow from low memory addresses to high,
to allow for easier string concatenations opposite the stack.
Yes, I know, it's weird, but only because *everybody* got it wrong,
and that's what we've become accustomed to. Yuck.
Steve abell@netcom.com
Technical Details
Message-ID:
<1992Nov2.195519.612@netcom.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!ogicse!decwrl!decwrl!netcomsv!netcom.com!abellReferences:
<1992Oct31.234604.21078@tamsun.tamu.edu> <1992Nov2.154050.23454@jhunix.hcf.jhu.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!ogicse!decwrl!decwrl!netcomsv!netcom.com!abell From: abell@netcom.com (Steven T. Abell) Newsgroups: comp.sys.next.hardware Subject: Byte Swapping (Was: New RISC workstations) Summary: Nobody does it right Keywords: byte-swapping Message-ID: <1992Nov2.195519.612@netcom.com> Date: 2 Nov 92 19:55:19 GMT Article-I.D.: netcom.1992Nov2.195519.612 References: <1992Oct31.234604.21078@tamsun.tamu.edu> <1992Nov2.154050.23454@jhunix.hcf.jhu.edu> Sender: abell@netcom.com (Steven T. Abell) Organization: Netcom - Online Communication Services (408 241-9760 guest) Lines: 62