[comp.os.minix] Byte order. Was: Compiling Minix ar

klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) (01/09/91)

greg@mobius.Viewlogic.COM (Gregory Larkin) writes:

>I'm just guessing, but (I'm not a CS person!!) I think the problem
>I'm having is that (obviously) the SPARCstation uses different byte-
>ordering and/or sizes for ints, longs, etc.
Right!

>Doing a sum(1) on the PC for the file h.a says: 22515 46
>On the SPARC, it says:                          22515 23
Don't think sum(1) is portable :-(.

>> stuff deleted << 

>Therefore, can anyone enlighten me about the byte differences between
>PCs and SPARCstations and more importantly,

It is the little-big endian problem. It will also byte :-) you between
a 68K and a x86.
68k, sparc:	first byte (in short,long) is most significant
x86:		first byte (in short,long) is least significant

Associated problem (not so common): ordening of bits in a byte.
Notorious exception to the (minix/sun) rule here is a vax.

>Is there anyway I can extract .a files on the SPARC????

You have to byte swap all values. Beware when making any binary products
on 'the other kind' for this problem.

I recommend transporting all kinds of stuff back through either shar
(is ascii, should work) or tar (writes all integer values in ascii).

Klamer.
-- 
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
klamer@mi.eltn.utwente.nl	{backbone}!mcsun!utrcu1!utep!utelmi01!klamer