Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!bbn!uwmcsd1!ig!agate!ucbvax!hplabs!decwrl!spar!freeman
From: freeman@spar.SPAR.SLB.COM (Jay Freeman)
Newsgroups: comp.arch
Subject: Re: More than 32 bits needed where?
Message-ID: <747@spar.SPAR.SLB.COM>
Date: 14 Feb 88 23:53:53 GMT
References: <4340@ames.arpa> <28200094@ccvaxa> <22931@ucbvax.BERKELEY.EDU> <328@gen1.UUCP>
Reply-To: freeman@spar.UUCP (Jay Freeman)
Organization: SPAR - Schlumberger Palo Alto Research
Lines: 56

In article <328@gen1.UUCP> peter@gen1.UUCP (Peter CAMILLERI) writes:

>Perhaps the optimum soloution would be to have a machine in which the size
>of an address where unkown. For example the inmos transputer contsructs
>its address out of instruction components that can be concatenated to
>form an arbritarily large value. Address then would essentially be passed 
>betwwen machines in a string like format. Internally the address would be
>evaluated to 64 or whatever bits. The advantages of this scheme are that
>small program would not be penalized, and hardware can be upgraded with-
>out trashing all of the softwrare.

Speaking off the cuff, I think there is merit to that suggestion:  Suppose
addresses were encoded with a variable-length coding scheme.  A processor
with a non-variable-width (!)  bus would do a bus-wide fetch, then start
decoding; it would only go and do another fetch if it turned out it needed
to.  With sane design of the coding scheme, a substantial address space
could be described in the set of encoded addresses that could be fetched in
one bus transaction.  (I am guessing, but I suspect it might be as high as
2**(N-1) encoded locations for an N-bit bus width.)  That would mean that
most of the time (one hopes) the processor could run at one fetch per
address location, but that longer addresses would be available when needed,
at no more expense than additional fetches to get them.  Possibly there
would be useful circumstances in which odd-length addresses could be packed
so that they did not all start at word boundaries.

One problem here is that you do not know the length of any specific pointer
until run-time; that perhaps creates a problem for storing pointers in
memory.  You can't just store a "forwarding pointer" instead, cause there's
no guarantee that it will fit, either.  However, it is possible to imagine a
reasonable work-around; one could require that a programmer declare a
maximum length-of-pointer at compile-time, and make the compiler allocate
that much storage for each pointer.  Having a pointer come out too long
would then be a run-time error, which could be fixed merely by changing the
compile-time declaration and recompiling.  That's a little painful, but not
nearly so much as having to wait for the hardware people to implement a
longer word.

There is also perhaps a problem for how the CPU addresses memory; one can
imagine the poor CPU saying "let me see, the user wants to provide a
1000-bit address, do I have enough address registers to store all those
bits, and even if I do, how shall I put them out on the address bus ..."
But there probably is an answer involving cycling through an address in
fetch-wide chunks, with the aid of an MMU that knows how to bank-switch (or
whatever) on all but the last "fetch" number of bits.

Another win for such a scheme would be if frequently-accessed data were
stored at places for which the address was short.  One could map registers
into address space, and have them get the shortest addresses, or use
relative addressing off the stack top or off a base register, or ...



					-- Jay Freeman


(canonical disclaimer -- these statements are my opinions and nothing else)