Integers: Programs get a lot of mileage out of 32 and 64 bit integers. If 64 bits is a limitation, the fix for that is to have software-implemented bignum integers. High level languages can implement integer types such that the operations smoothly shift between "fixnums" and "bignums". Of course you take a performance hit with bignums, but you have to consider that in the big picture: how many of the operations in a program are bignum operations. 256 or 512 bit numbers do not eliminate the need for bignums, they only increase the headroom before we have to switch to bignums. If you want to manipulate 2048 bit public keys, 512 bit integers will not do (but a bignum with 512 bit digits could be fast).
Pointers: Wider pointers mean only one thingallow two things: greaterwider address spaces, and additional meta-data stored in a pointer. Address spaces are virtual these days and so they can grow even if memories do not grow. It has been proposed that if you have 128 bit pointers, the address space is so vast that you can put all the user-space processes of an operating system, and the kernel, at random places in a single unprotected space, and they are unlikely to collide. So, from there it doesn't seem to make sense to go to 256 bit pointers, never mind 512. Fat pointers haveRather than simply creating a disadvantage: they bloat all data structures which contain pointers. And, generallylarger address space, you want pointers to be the same size. Different classes of pointers of different sizes are a disaster. It's been tried and hopefully won't be resurrected. One advantage of fat(tter)fatter pointers is that they can be used to carry bits which are not address bits, such as information about the referent object (type, size and other info) or security-related information. There is probably some "optimal fatness" for this kind of thing, and if I were to guess, I would still cap it at 128 bits. It doesn't seem to make sense to go to 256 bit pointers, never mind 512. Fatter pointers have a disadvantage: they bloat all data structures which contain pointers. And, generally, you want pointers to be the same size, otherwise you need complications in the instruction set architecture (like memory segments) whereby you then have full pointers (segment descriptor and offset) or just local pointers (offset within some understood segment).
Floating-point types: More bits in floating point numbers means more precision. I would say that the floating-point types benefit the most from a wider representation. A 256 or 512 bit floating type will improve the stability of numeric code and the quality of scientific calculations that require many iterations, and accumulate errors along the way. Precision in floating-point is not the same as precision in integers: we cannot separate the floating point type into ranges like fixnums versus bignums. More precision in floating point affects the quality of all inexact numbers, whether they are close to zero or have a large magnitude. More bits in floating point exponents can also vastly extend the range of floating point numbers, and much faster than adding bits to a bignum integer.
|2||Restructure text on pointers for clarity and to eliminate obvious contradiction.|
Firstly, the bit size of a processor is usually determined by the abstract architecture that is visible to the machine language programmer, not by implementation details like the size of the data bus.
For example, the Motorola 68000 is a 32 bit processor. It has 32-bit data registers and 32-bit address registers. Now, the first version of that architectural family only expose 24 bits of address lines. Furthermore, variants exist which have only an 8 bit data bus (so 32 bit memory operations are performed by the processor as multiple access cycles).
Now about the question, why not go to 256 and 512. Processors "natively" manipulate several kinds of data types, so it is helpful to look at what 256 or 512 bits means for each of these data types individually. We have integers, pointers and floating-point types.
For these reasons, I suspect that the predominant future trend will be increases in the width of hardware floating-point numbers, not necessarily followed by increases in the widths of pointers and integers.
Remember that floating-point numbers have already been ahead of the other types in the past. For instance, for a while we had a predominance of 32 bit processors supporting 64 bit IEEE double floats. This is because while you can do a lot with 32 bit pointers and integers, 32 bit floats are very limited for any serious numeric work.
One very, very useful feature that would be nice to see emerge in floating-point representations would be a few spare bits for a type tag. Implementing floating-point types in dynamic, high-level languages (in which objects have type, but storage locations hold values of any type) is a struggle because whereas spare bits can be found in pointers and integer-like objects to put parts of an identifying type tag, this is difficult to do with floating-point numbers. So what often ends up happening is that floating-point numbers get heap-allocated. Some schemes steal bits from the mantissa, so then floating-point types in that language lose precision compared to floats in other languages on the same machine.