breuel@harvard.ARPA (Thomas M. Breuel) (12/17/84)
|[Dave Trissel writes:] |Lets examine now the potential extension to 64 bits. I would suggest that |the criterian will be the same. If there are data types (address or data) |which will not effectively operate in a 32-bit register environment then |there will be a push for a larger than 32-bit architecture. | |Concerning data types, there is only one I can think of that would merit |more than 32-bits: the floating-point number. Most architectures which When you are thinking in terms of 'conventional' programming languages like ALGOL, Pascal, 'C', or Fortran, that is certainly true. Not much is gained by increasing the bus size to more than the the size of an average pointer, integer, and floating point number, which means to more than 32bits. However, for languages like PROLOG, SmallTalk, and LISP it turns out to be incredibly useful to be able to store two pointers, or pointers and type information, in a single word of memory. The reason for this is that for almost any operation in such languages you need to obtain both the type and the value of an object from memory. The granularity of a memory access is therefore, on the average, two times the size of a pointer. As an example take PROLOG. Having two pointers per memory word allows you to implement structure sharing efficiently, a technique in which you basically represent complex data structures by a pointer to a template and a vector consisting of the variable parts of the data structure. Each item in the template (e.g. integer, variable, atom, ...) consists of a reference describing the particular value of the item, and its type. To use an item in the template, both its type and its value have to be known, and therefore, both its type and its value have to be brought into the CPU at one point. It therefore helps a lot to be able to load both of them with one memory access. Thomas. PS: On the DEC-10, on which most work on structure-sharing PROLOG's has been done, the type information can even be encoded in such a way that most operations on PROLOG objects are performed in micro-code, i.e. without memory accesses for the re-loading of new instructions. The reason for this is that part of an instruction can be contained in the data that the instruction operates upon. I know of only the DEC-10 which allows you to do this in sufficient generality. Some IBM machines, for example, have an indirection bit in pointers, but they restrict the number of indirections to 5 (?).
henry@utzoo.UUCP (Henry Spencer) (12/18/84)
Remember that architectural width and memory-access width are not
necessarily the same. The 11/70, for example, has a 16-bit architecture
but a 32-bit memory path. Requirements for greater memory bandwidth
are a fairly weak argument for a change in *architecture*.
I tend to agree with the contention made by the folks who started this
debate: the pressures that pushed us from 16 to 32 bits do not operate
nearly as strongly to push from 32 to 64. 16 just plain isn't enough
for a decent address (it is often, although not always, sufficient for
the data). 32 will last us a fair while, perhaps a long while, before
it becomes seriously constraining.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry