1 ?RCS: $Id: byteorder.U,v 3.0.1.2 1997/02/28 15:24:55 ram Exp $
3 ?RCS: Copyright (c) 1991-1993, Raphael Manfredi
5 ?RCS: You may redistribute only under the terms of the Artistic Licence,
6 ?RCS: as specified in the README file that comes with the distribution.
7 ?RCS: You may reuse parts of this distribution only within the terms of
8 ?RCS: that same Artistic Licence; a copy of which may be found at the root
9 ?RCS: of the source tree for dist 3.0.
11 ?RCS: $Log: byteorder.U,v $
12 ?RCS: Revision 3.0.1.2 1997/02/28 15:24:55 ram
13 ?RCS: patch61: no longer ask the user if the test runs ok
15 ?RCS: Revision 3.0.1.1 1994/10/29 16:02:58 ram
16 ?RCS: patch36: added ?F: line for metalint file checking
18 ?RCS: Revision 3.0 1993/08/18 12:05:28 ram
19 ?RCS: Baseline for dist 3.0 netwide release.
21 ?MAKE:byteorder: cat Myread Oldconfig Loc Compile rm \
22 longsize crosscompile multiarch
23 ?MAKE: -pick add $@ %<
25 ?S: This variable holds the byte order. In the following, larger digits
26 ?S: indicate more significance. The variable byteorder is either 4321
27 ?S: on a big-endian machine, or 1234 on a little-endian, or 87654321
28 ?S: on a Cray ... or 3412 with weird order !
31 ?C: This symbol holds the hexadecimal constant defined in byteorder,
32 ?C: i.e. 0x1234 or 0x4321, etc...
33 ?C: If the compiler supports cross-compiling or multiple-architecture
34 ?C: binaries (eg. on NeXT systems), use compiler-defined macros to
35 ?C: determine the byte order.
36 ?C: On NeXT 3.2 (and greater), you can build "Fat" Multiple Architecture
37 ?C: Binaries (MAB) on either big endian or little endian machines.
38 ?C: The endian-ness is available at compile-time. This only matters
39 ?C: for perl, where the config.h can be generated and installed on
40 ?C: one system, and used by a different architecture to build an
41 ?C: extension. Older versions of NeXT that might not have
42 ?C: defined either *_ENDIAN__ were all on Motorola 680x0 series,
43 ?C: so the default case (for NeXT) is big endian to catch them.
44 ?C: This might matter for NeXT 3.0.
46 ?H:?%<:#if defined(CROSSCOMPILE) || defined(MULTIARCH)
47 ?H:?%<:# ifdef __LITTLE_ENDIAN__
48 ?H:?%<:# if LONGSIZE == 4
49 ?H:?%<:# define BYTEORDER 0x1234
51 ?H:?%<:# if LONGSIZE == 8
52 ?H:?%<:# define BYTEORDER 0x12345678
56 ?H:?%<:# ifdef __BIG_ENDIAN__
57 ?H:?%<:# if LONGSIZE == 4
58 ?H:?%<:# define BYTEORDER 0x4321
60 ?H:?%<:# if LONGSIZE == 8
61 ?H:?%<:# define BYTEORDER 0x87654321
66 ?H:?%<:# if !defined(BYTEORDER) && (defined(NeXT) || defined(__NeXT__))
67 ?H:?%<:# define BYTEORDER 0x4321
70 ?H:?%<:#define BYTEORDER 0x$byteorder /* large digits for MSB */
71 ?H:?%<:#endif /* NeXT */
76 : check for ordering of bytes in a long
78 case "$crosscompile$multiarch" in
81 You seem to be either cross-compiling or doing a multiarchitecture build,
82 skipping the byteorder check.
91 In the following, larger digits indicate more significance. A big-endian
92 machine like a Pyramid or a Motorola 680?0 chip will come out to 4321. A
93 little-endian machine like a Vax or an Intel 80?86 chip would be 1234. Other
94 machines may have weird orders like 3412. A Cray will report 87654321,
95 an Alpha will report 12345678. If the test program works the default is
97 I'm now running the test program...
106 char c[sizeof(long)];
109 if (sizeof(long) > 4)
110 u.l = (0x08070605L << 32) | 0x04030201L;
113 for (i = 0; i < sizeof(long); i++)
114 printf("%c", u.c[i]+'0');
121 if eval $compile && ./try > /dev/null; then
124 [1-4][1-4][1-4][1-4]|12345678|87654321)
125 echo "(The test program ran ok.)"
126 echo "byteorder=$dflt"
129 ????|????????) echo "(The test program ran ok.)" ;;
130 *) echo "(The test program didn't run right for some reason.)" ;;
135 (I can't seem to compile the test program. Guessing big-endian...)
138 case "$xxx_prompt" in
140 rp="What is the order of bytes in a long?"