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