Re: endian issues

[nisse@lysator.liu.se (Niels Möller)]

Glenn McGrath <bug1@optushome.com.au> writes:

> If hurd was on different endian type machines would it all be taken care
> of by the microkernel anyway ?

No, to have the kernel change the byte order as seen by user processes
would be a waste of cpu time, if possible at all. (Some cpu:s can use
either byteorder, but not x86).

> I guess i should just find a way to ignore endian related code when
> compiling under the Hurd.
> 
> Anyone have any pointers to good docs on endian issues?

Basically most endian dependent code are performance hacks (and most
I've seen are not very important optimizations either). Let's say
that you're reading some data structure from the network or from raw
disk (I'm guessing you are reading the partition table...).

You get the data from the hardware as a sequence of bytes (a string),
and the spec for the format says how to parse it. For instance, the
spec may say that there's a 32 bit unsigned integer integer, stored as
four bytes, most significant byte first (i.e. big endian). Assuming
only that char is eight bits and long is 32 bits, you could write

  /* Get pointer to storage, e.g. a pointer into a raw copy of the
   * partition table. */
  unsigned char *buf = get_storage_pointer(...);
  
  unsigned long value  = (buf[0] << 24) + (buf[1] << 16)
  	                 + (buf[2] << 8) + buf[3];

The code above is endian-clean. It obviously depends on the byteorder
used in the partition table, but it does *not* depend on the byteorder
of the machine executing the code. An endian-dependent optimization
might replace the second statement with

  unsigned long value = *(unsigned long *) buf;

This will work sometimes: if the code is executed on a machine that
uses big-endian byteorder, and if the data pointed to by buf is
properly aligned for a 32-bit read accesses.

And the endian-ness used on the disk should be fixed and independent
of the endian used by the cpu, or else you cet into trouble when
you physically move the disk from the pc to a machine with some other
endianness and you try to read it.

Early linux versions of the linux-m68k port used a different
endianness for the datastructures in the ext2 filesystem, but today I
believe you can swap disks with ext2 filesystems on them between all
of linux-x86, linux-m68k, linux-sparc, ...

I hope this makes the issues clearer.

Regards,
/Niels