Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!ukc!mucs!mshute
From: mshute@cs.man.ac.uk (Malcolm Shute)
Newsgroups: comp.arch
Subject: Re: What *should* architectural pointers point at?
Message-ID: <1682@m1.cs.man.ac.uk>
Date: 7 Sep 90 13:30:14 GMT
References: <DAVEG.90Aug29225127@near.cs.caltech.edu> <3318@awdprime.UUCP> <643@array.UUCP>
Sender: news@cs.man.ac.uk
Reply-To: mshute@cs.man.ac.uk (Malcolm Shute)
Organization: Department of Computer Science, University of Manchester UK
Lines: 66

I've come in on the middle of this discussion, so forgive me for any
misconceptions.  Can I first check that I understand some of the background
to this correctly.  Is the following correct:

	1) People want to move on from 32-bit addressing
	   (either for genuine reasons of running out of address space
	   or 'fashion' ones of seeing 32-bit as passe').
	2) A single leap to 64-bit seems rather drastic,
	   but there are good engineering and fashion reasons
	   for not going to an intermediate non-power-of-two.
	3) Bit addressing would be one method of disguising the
	   introduction of a 58-bit machine as a power-of-two one
	   whilst at the same time moving some useful bit-twiddling
	   hardware into the data-fetch logic instead of in the
	   occasional ALU instruction logic.

> In article <3318@awdprime.UUCP> tif@reed.UUCP (Paul Chamberlain/32767) writes:
> > Now there's an interesting thought.  Why not order these 64 bits so that
> > the 3 on the left are the bit offset. [...]

In article <643@array.UUCP> colin@array.UUCP (Colin Plumb) writes:
> [It need not be axiomatic that
> incrementing a character pointer adds 1 to the value of its bit pattern, if
> read as an integer]

Moreover, can I comment on the obvious:
integer data are just special cases of fixed-point.
It is simple enough to think of this 64-bit machine as being
a fixed-point, word-addressed one (with 6 binary places of fraction
to indicate fractions of a word).  Let's use octal to represent
an example of such a quantity:

	12345671234567123456.71		(all digits represent 3-bits,
					except the most sig one).

To 'increment' this number correctly requires some knowledge of what we
think 'increment' means.  Thus we would add 1.00 to it in order to increment
to the same position within the next word, or add 0.10 to it in order to
increment to the same position within the next byte, or add 0.01 to it
to point to the next bit.

It is also necessary to allow for different data types being used throughout
the memory.  A table of string pointers might be 'compacted' to a fixed-point
format with only 3 binary places of fraction.  A jump table, or a block of
integer variables might be compacted to 0-binary-place fixed-point
(i.e. integer); the offset on a branch instruction would make sensible use
of this compaction too.

Lastly, it is necessary to determine how to represent the result of the
increment.  An increment to a 6-bp (binary-place) fixed-point pointer
would presumably need to deliver a 6-bp result to the address hardware.
An increment to a 0-bp number (an integer) would need to deliver a 0-bp
result.  And an increment to a 0 or 3-bp compacted pointer in a table
would need to return a 0, 3 or 6-bp result, depending on context.

So, our 'increment' operation needs to ask three questions:
	1) By how much should I increment?
	2) What is the data-type of the object I am incrementing?
	3) What is the data-type of the result I must deliver?

I don't think that I have said anything in this article which has not
already been stated or implied.  However, I wanted to spell it out on
paper, just to check in my mind that I understand thus far.
--

Malcolm SHUTE.         (The AM Mollusc:   v_@_ )        Disclaimer: all