Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Endian wars
Message-ID: <8480@aw.sei.cmu.edu>
Date: 8 Feb 89 15:36:16 GMT
References: <6133@columbia.edu> <3300050@m.cs.uiuc.edu>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 32

In article <3300050@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes:

>Second, I was once told that the following C code compiles into 1
>instruction (or something amazingly short) on the PDP-11, C's mother
>machine:
>
>while (*p++ = *q++);

It compiles into two instructions.  If p and q are in registers R1 and
R2 respectively, the code is

    1$: MOVB (R2)+,(R1)+
	BNE 1$

The "=" maps onto the MOVB, the "++" maps onto the autoincrement
address mode, the move sets the condition codes for the branch
to test, and the move of the trailing NUL makes the test fail.

This is a neat and beautiful idiom in PDP-11 Assembler.  There is,
however, one problem with the equivalent C code: it is incorrect.
After termination of the loop, the variables p and q, though declared
of type 'pointer-to-char', will hold values that do not point to
declared or allocated objects of type 'char'.  Should you ever have
the misfortune to port this code to a machine with hardware segmentation,
and automatic segment bounds checking as part of the address arithmetic,
(or be a consultant involved in such a port), you will face this
problem.

Could someone inform me whether the current C standard has fixed this?
The simplest answer I guess is to rule that the address of array[upb+1]
must always be legal; in practice this means the implementation has to
leave dead space at the end of each memory segment.