Path: utzoo!attcan!uunet!mcsun!hp4nl!utrcu1!mi1!klamer From: klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) Newsgroups: comp.os.minix Subject: Byte order. Was: Compiling Minix ar(1) on a SPARC Keywords: little & big endian Message-ID: Date: 9 Jan 91 12:41:07 GMT References: <1991Jan8.152501@mobius.Viewlogic.COM> <1991Jan8.160208@mobius.Viewlogic.COM> Sender: news@utrcu1.UUCP Lines: 37 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