[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
BE & LE hardware help
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: BE & LE hardware help
- From: "Philip Ronzone" <Philip.Ronzone@eng.efi.com>
- Date: Fri, 1 May 1998 14:51:49 -0700
- Resent-Date: Fri, 1 May 1998 16:38:34 -0700
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-ID: <"eFd_t3.0.Mj.JFaIr"@electra.znyx.com>
- Resent-Sender: pci-sig-request@znyx.com
> ... If that
> includes a LE/BE bridge between some 68k architecture I/O chips and
> an x86 architecture system interconnect, so be it.
> ...
> Jochen
The above is a good example. If the "LE/BE bridge" does do byte swapping
on the assumption it is helpful and/or needed between the 68K and
the X86-style devices (say, an IDE controller or NIC) it will NOT
be helpful and will make things WORSE.
I've seen just that done, which is why I say STOP it.
For example, in the real life case, the IDE controller is shoving
16-bit words out from the disk, which turned into 32-bit words
which were then "allegedly" helped by being 32-bit endian swapped.
Talk about garbage!
First, I had to unswap all the 32-bit words back. To undo the effects
of the now-un-helpful LE/BE bridge swap".
Using the case of the ATAPI Identify Device Packet, I now a series of
fields on many 16-bit fields in LE order, which I would swap into
the 68K BE order as I used them. Other fields, such as the ASCII text
fields, would also be byte swapped. The 32-bit fields (sectors, capacity)
fields would be 32-bit swapped as needed.
So, this one, common, industry standard 512-byte record had
16-bit LE-to-BE swaps, 16-bit ASCII text swaps, and a few 32-bit
LE-to-BE swaps (note, the 32-bit fields are NOT on 4 byte boundaries).
1. 32-bit swapping this record just mucks it up.
2. 16-bit swapping this record doesn't work either. Some fields
are not corrupted.
3. By leaving the record alone, it is at LEAST understandable, as the
byte order matches that of the specification.
Therefore, maybe hopefully for that last time:
If you DON'T know the context of the data, DON'T try to be
helpful by doing BE<->LE swapping. You'll only make
matters worse.
-------------------------------------------------------------------------------
Philip K. Ronzone (RON-zone), extension 8300 ..................................
-------------------------------------------------------------------------------
DIR:(415) 286-8300 (work email) Electronics for Imaging, Inc.
OPER:(415) 286-8600 Philip.Ronzone@eng.efi.com 2855 Campus Drive
FAX:(415) 286-8663 San Mateo, CA