DIRECTORY PrincOps USING [zEXCH]; Endian: CEDAR DEFINITIONS = { BYTE: TYPE = [0..100H); HWORD: TYPE = WORD; FWORD: TYPE = RECORD [high, low: WORD]; bytesPerHWord: NAT = 2; bytesPerFWord: NAT = 4; FFromCard: PROC [LONG CARDINAL] RETURNS [FWORD] = TRUSTED MACHINE CODE { PrincOps.zEXCH; }; FFromInt: PROC [INT] RETURNS [FWORD] = TRUSTED MACHINE CODE { PrincOps.zEXCH; }; CardFromF: PROC [FWORD] RETURNS [LONG CARDINAL] = TRUSTED MACHINE CODE { PrincOps.zEXCH; }; IntFromF: PROC [FWORD] RETURNS [INT] = TRUSTED MACHINE CODE { PrincOps.zEXCH; }; HFromCard: PROC [CARDINAL] RETURNS [HWORD] = TRUSTED MACHINE CODE { }; HFromInt: PROC [INTEGER] RETURNS [HWORD] = TRUSTED MACHINE CODE { }; CardFromH: PROC [HWORD] RETURNS [CARDINAL] = TRUSTED MACHINE CODE { }; IntFromH: PROC [HWORD] RETURNS [INTEGER] = TRUSTED MACHINE CODE { }; }. zEndian.mesa Copyright c 1986 by Xerox Corporation. All rights reserved. Hal Murray, January 24, 1986 2:31:45 pm PST Some machines are big endian, some are little endian... See [Indigo]IEN-137.txt Dorados, DLions, IBM 360s, and Motorola 68000s are big endian. PDP-11s, VAXes and Intel are little endian. Don't use CARDINAL, INT, INTEGER, LONG CARDINAL, WORD, or subranges bigger than a BYTE in the definition of any record going to the wire. (Of course, you are crazy if you send pointers. RELATIVE pointers might be interesting. ?) NB: Enumerated types bigger than a BYTE won't work either. (eg ErrorCodes) This will change to a pair of BYTEs if we get serious about running on little endian machines. That will require another handful of INLINEs, but the Compiler should tell us where to put them. Cedar LONGs are word swapped from a clean big endian viewpoint. Since the old Alto BCPL world did 32 bit numbers right, many of the Pup protocols already do it right. Beware: Many Cedar programs, in particular RPC, send raw (word swapped) LONGs on the wire. Dragon's will do it right, so now is the right time to find the problems. Κ£˜codešœ ™ Kšœ Οmœ1™