Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!decvax!decwrl!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.lang.c Subject: Re: Writing readable code Message-ID: <24246@sun.uucp> Date: Mon, 27-Jul-87 15:06:36 EDT Article-I.D.: sun.24246 Posted: Mon Jul 27 15:06:36 1987 Date-Received: Tue, 28-Jul-87 07:31:10 EDT References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <1126@nu3b2.UUCP> Sender: news@sun.uucp Lines: 73 > Oddly enough, by definition what you have used above is a valid > construct on just about every machine I have ever seen. "valid", yes, in the sense that the C compiler won't reject it; it may give you a warning, but it won't reject it. However, that construct won't do what you want it to do on a big-endian machine; therefore, since the 3B2 is a big-endian machine, if the "3b2" in the name of the machine you're posting from indicates what type of machine it is, you mustn't have "seen" that machine. I took the code: main() { int c = 'a'; write(1, &c, 1); } and compiled it on a 3B2, ran it, and piped the output through "od -c" to see exactly what the output was. "od -c" printed: 0000000 \0 \0 0000001 (the second '\0' is an artifact of "od" working in 2-byte words). Note that it did NOT write an 'a', but wrote a '\0'. This is what was in the high-order byte of the (4-byte) quantity "c". > Since the low order byte of a word, and the low order word of a double-word > are stored "above" the high-order portion you get: > > +--------+--------+ > | low | high | > +--------+--------+ > ^ > | > This is the point indicated by the address-of operator Wrong. On big-endian machines, the *high*-order byte of a 2-byte or 4-byte quantity is the one whose address has the same bit-pattern as the address of the quantity itself. > On any machines which do not use this inter-position, the use > of pointers is massaged in the memory model to produce the same net > effect. Wrong. This is not done on any big-endian machine that I've worked with. > If this arangement, or some adaptive work-around were not > built into the language, the casting between types [i.e. assigning > the value of a sufficiently small int to a char] would produce more > logical shifting and adaptive work than the actual math/assignment. > int x; char y; x = 13 ; y = x; would be unreasonably large. Wrong. The code sequence for "x = 13; y = x" generated for a 68020 (another big-endian machine) by our compiler is: moveq #13,d1 /* 13 */ movl d1,a6@(-4) /* x = 13; "x" is at a6@(-4) */ movb a6@(-1),a6@(-5) /* y = x */ The "movb" merely picks up the appropriate byte of "x" and stuffs it into "y". Please note that the address of "x" is-4, but the address of the appropriate byte of "x" is -1, or +3. No shifting or "adaptive work" (whatever THAT means) is required. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com