Re: endian issues
Niels Mvller wrote:
>
> 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.
>
Yes, it all makes sense now, thanks for the good description.
Glenn
Reply to: