Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site calgary.UUCP
Path: utzoo!utcsri!ubc-vision!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: net.micro.amiga
Subject: Re: What's BCPL? (shifted pointers)
Message-ID: <112@calgary.UUCP>
Date: Tue, 4-Feb-86 18:38:14 EST
Article-I.D.: calgary.112
Posted: Tue Feb  4 18:38:14 1986
Date-Received: Wed, 5-Feb-86 09:22:08 EST
References: <410@wlbr.UUCP> <148600045@uiucuxc>
Organization: University of Calgary, Calgary, Alberta
Lines: 20

> re: BCPL
> 
> now, can somebody explain to me the utility of these #$%^@ shifted pointers?

I take it you're refering to the likely habit of a PDP11, VAX, 68000, etc.
BCPL compiler to shift all pointers left one (maybe two) bits before use?

This is purely a vestige of non-byte-addressable machines. A BCPL program
will assume that if 'p' point to an integer array element, then 'p+1' will
point to the next array element. This is part of the model of the machine
assumed by the language. Since the compiler doesn't know that 'p' is a
pointer to an integer (or even a pointer at all, if I recall correctly), it
must really add just 1, not 2 or 4 like a C compiler would. The only way to
get this to work is to shift the pointer on dereference. The problem doesn't
arise on old machines with only one size of addressable storage unit.

This problem is, of course, the reason for C having typed pointers and
doing stride adjustment as part of pointer arithmetic.

      Radford Neal