Small Address Hacks

The same mistake was made in most machine designs from the 50's thru the 80's. Engineers underestimated the need for larger addresses. Generally they looked at the cost of memory and chose an address size to balance the production costs of memory and other system components. Perhaps it was not until the unexpected success of the IBM 7090 that engineers began to viscerally understand the cost of producing code for a new machine and that the new highly compatible 7090 could run all the old 704 and 709 code immediately. The 15 bit addresses of the 704 and 709 had been extravagantly big for those machines but was an embarrassing limitation for the 7090.

Most other architectures made the same mistake. Gene Amdahl told me that there were dissenting voices who claimed that 24 bits was too big an address for the IBM 360 series.

Various ugly “small address hacks” came about to accommodate more memory. I could write about several but it would be painful; they are best forgotten.

I think that 64 bits is big enough. Some who remember the havok of the earlier hacks fear 64 may be eventually too small.

The advent of virtual memory split the dilemma into two parts: real address size and virtual address size. It is not clear to me which should be larger. The size of the virtual address effects more code; the real address size effects only the kernel. I almost think that 32 bits of virtual memory is enough but there are just a few applications on even my Macintosh that exploit bigger addresses to good ends to hold data arrays. More often I suspect that 32 bits should suffice to locate instructions but that would limit some language technologies that may effectively tame larger code collections.

Large Virtual Addresses

Since large virtual addresses do not generally require large physical addresses there may be benefits to exploiting patterns that use addresses extravagantly. An array larger than a few pages might always begin the array on a page boundary. I assumed that hardware memory map design with page tables was specifically to support this. Some kernels indeed exploit this to support sharing parts of distinct address spaces.

Perhaps using bits from a data base key in the high end of a data address might be strategic, but several things might go wrong with that plan. First the kernel might not respond efficiently to such an unforeseen pattern.