Re: Big and little endian issue

["Philip Ronzone" <Philip.Ronzone@eng.efi.com>]

  > Date: Sun, 26 Apr 1998 15:57:45 -0700
  > From: Jochen Roth <jochen@znyx.com>
  > Subject: Re: Big and little endian issues
  > 
  > At 07:08 PM 4/22/98 -0700, Philip.Ronzone@eng.efi.com decreed:
  > 
  > >I assert that NO intermediate devices (bridges, buses, etc.) should ever
  > >do BE/LE byte swapping.
  > >
  > >That byte swapping is left to lowest level of software that understands
  > >the CONTEXT (this is a binary 16-bit word, this is text ...) of the data.
  > >
  > >Reasons for any disagreements?
  > 
  > (Getting up from my seat) Yes, Your Honour.
  > 
  > Your statements lack precision. What if the lowest level of software is
  > in control of the intermediate device, bridge, or bus? All of a sudden,
  > that lowest level of software may just want to tell the intermediate
  > device to swap bytes -- even if your master plan didn't allow for it.
  > 
  > While it seems completely hideous and repulsive to some, other people
  > may really want their hardware to implement certain features as an option.
  > Noone is forced to enable them, after all.
  > 
  > Jochen

1. Precision lack? No,  I don't think so. I said "CONTEXT", NOT
   "control of the [device]".

   An IDE or SCSI controller has no knowledge of, and doesn't care,
   and COULDN'T care even if it wanted to, whether the data to/from
   the disk is BE, LE, mixed, or all ASCII text.

   Since it doesn't know, how in the heck can it justify changing
   byte ordering?

   So, without the context, without any knowledge, just HOW can
   "that lowest level of software may just want to tell the intermediate
   device to swap bytes" be reasonable?

2. The confusion generated by hardware that does BS (byte swapping)
   without context is enormous.

   For example, reading a defined data structure from a disk (ATAPI
   ID for example) feeds back a 512 byte structure. The binary fields
   in the structure are little endian, of both 16 and 32 bits in
   size.

   What I want is for the interrvening hardware to LEAVE the byte order
   alone.

   Because, when it doesn't, again as an example, I have to have 3 (THREE!)
   different pieces of code to handle things.

   piece 1 - the byte order is unmolested, so all I have to do is
	     swap 16 OR 32 bits values when on a BE machine.

   piece 2 - the data is brought across as 16-byte swapped values.
	     i now have to "unswap" the 16-bit values in memory
	     before I can use it.

   piece 3 - the data is brought across as 32-byte swapped values.
	     again, i have to unswap.

   Thinking of saving time, and spend the CPU cycles to un-swap a
   a data structure that I was only using a few words from,
   I originally decided to just swap/correct the few values I
   needed.

   Ha!

   Consider a 16-bit length value for a following ASCII field:

           00 10 48 65 6C 6C 6F 21 ......

   After a 32-bit swap, we get:

	   65 48 10 00 21 6F 6C 6C

   Nice and scrambled!!!

   And better yet, it will be scrambled yet another way if
   accessed by a 16-bit path (assuming 16-bit BS).


So again, IF the intermediate device in question does not KNOW
what the context of the data is, and, I have never seen such
a device ever, then it shouldn't byte swap.

And, even if some omnipotent intermediate device WAS created,
it still SHOULDN'T byte swap.

For example, a big-endian machine writing out disk blocks for
a FAT-16/32 filesystem *knows* the data has toi be in little
endian format -- the LAST thing it wants is some smart device
"helping" a big-endian machine by "correcting" the LE
data to BE.



Of course, there probably are some data acquisition machines
that might enjoyed having their high speed binary data
streams swapped, but, as I understand it, most such devices
allow swap/noswap to be specified, and, such devices are
very RARE compared to the vast number of PCI devices, so
why should a bridge have a swap feature for such a rare
case?




-------------------------------------------------------------------------------
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