3 ms·

Not sure if this has been mentioned, but this exact technique (storing extra data in addresses) was used in the early days of the MacOS, with 24 bits for the ad

Not sure if this has been mentioned, but this exact technique (storing extra data in addresses) was used in the early days of the MacOS, with 24 bits for the address, and 8 bits for extra info (not sure if I can remember exactly what they were for). The 68000 only had 24 address lines after all. This allowed a maximum of 16Mb of RAM which was of course far more than would ever be in a computer... By the time the Mac II came out (68020 with 32 bit address bus), it was apparent that this was going to be an issue, and there was an effort to remove this logic. Those early machines were a combination of ROM and loaded OSes, so there was an effort to clean the code for both the distributed OS and the stuff included in the ROMs of the machines. I think if memory serves the Mac IIcx from around '89 or so was the first machine with 32 bit clean roms, and with the right OS version you were good for >16mb of RAM. I've also got a hazy memory of some architecture (i'm going to guess DEC Alpha) which only read from 32 bit boundaries, and where the bottom 2 bits of the address were masked out, so you could store data there too... Anyhow, the real take home from all that was that misusing addresses to store additional information, which might seem like a clever trick is likely to bite you at some point in the future.

rjsw 6y ago
The Mac IIci was the first 32 bit clean machine. Plenty of dynamically typed languages have used the bottom bits in an address to store tags. You have two available on a 32 bit machine, three on 64 bit. The SPARCv7 has instructions that will do arithmetic on tagged values.
- jacobush 6y ago
  AmigaBASIC
crocktucker 6y ago
" ... if memory serves ... ", well done.
Someone 6y ago
The extra bits stored flags that indicated whether handles were movable, could be purged at will, or came from a resource (on disk) IIRC Excel went a bit further by using the leftover bits and even bit(s) starting at bit 24. That worked until hardware stopped wrapping around memory. Apple created a launch error “program had special memory requirements” which actually meant “this is Excel version so-and-so”. And yes, that can bite you in the future, but the gains today can (appear to) outweigh that. It also is perfectly valid when you control both the side that determines the constraints and the side that runs extremely close to them. For example, Cocoa’s tagged pointers (https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-build-tagged-pointers.html https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-bui...) are fine, given that Apple both controlled the memory allocator and the library assuming it aligned allocations (they also are safer in that they won’t try to read from addresses that don’t point to valid memory. That’s essential for their use)
Stierlitz 6y ago
> .. The 68000 only had 24 address lines after all. This allowed a maximum of 16Mb of RAM .. And now we need 16GB to do exactly the same thing! Long ago I made my own DOS/Netscape image that ran from a 1MB 3 1/4 inch floppy that did the exact same thing! It booted and loaded a compressed ramdisk into memory and ran from there.
kjs3 6y ago
While conceptually similar (and made me think of the same thing), this doesn't really look like the same thing. In the Mac case, it was (ab)using technically unused addressed bits in unintended ways. In the ARM case, it is an explicit architectural feature. More like pointer tags in Lisp machines.
Dylan16807 6y ago
The biggest problem there was programs hiding away state and then not masking it out when using the addresses. This meant they couldn't just use the lower part of memory on new chips, they were completely incompatible. The lesson has been learned from that, and CPUs don't ignore reserved bits. But also this is a hardware feature so the code will continue to be compatible anyway. Even if this acts like a permanent truncation of the address space by 4 bits, so what? If you think you can keep Moore's law going strongly enough to hit that cap, you're probably going to hit the 64 bit wall soon enough after; might as well focus on that shift to 128 bit addresses

rjsw 6y ago

The Mac IIci was the first 32 bit clean machine. Plenty of dynamically typed languages have used the bottom bits in an address to store tags. You have two available on a 32 bit machine, three on 64 bit. The SPARCv7 has instructions that will do arithmetic on tagged values.

jacobush 6y ago
AmigaBASIC

crocktucker 6y ago

" ... if memory serves ... ", well done.

Someone 6y ago

The extra bits stored flags that indicated whether handles were movable, could be purged at will, or came from a resource (on disk) IIRC Excel went a bit further by using the leftover bits and even bit(s) starting at bit 24. That worked until hardware stopped wrapping around memory. Apple created a launch error “program had special memory requirements” which actually meant “this is Excel version so-and-so”. And yes, that can bite you in the future, but the gains today can (appear to) outweigh that. It also is perfectly valid when you control both the side that determines the constraints and the side that runs extremely close to them. For example, Cocoa’s tagged pointers (https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-build-tagged-pointers.html https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-bui...) are fine, given that Apple both controlled the memory allocator and the library assuming it aligned allocations (they also are safer in that they won’t try to read from addresses that don’t point to valid memory. That’s essential for their use)

Stierlitz 6y ago

> .. The 68000 only had 24 address lines after all. This allowed a maximum of 16Mb of RAM .. And now we need 16GB to do exactly the same thing! Long ago I made my own DOS/Netscape image that ran from a 1MB 3 1/4 inch floppy that did the exact same thing! It booted and loaded a compressed ramdisk into memory and ran from there.

kjs3 6y ago

While conceptually similar (and made me think of the same thing), this doesn't really look like the same thing. In the Mac case, it was (ab)using technically unused addressed bits in unintended ways. In the ARM case, it is an explicit architectural feature. More like pointer tags in Lisp machines.

Dylan16807 6y ago

The biggest problem there was programs hiding away state and then not masking it out when using the addresses. This meant they couldn't just use the lower part of memory on new chips, they were completely incompatible. The lesson has been learned from that, and CPUs don't ignore reserved bits. But also this is a hardware feature so the code will continue to be compatible anyway. Even if this acts like a permanent truncation of the address space by 4 bits, so what? If you think you can keep Moore's law going strongly enough to hit that cap, you're probably going to hit the 64 bit wall soon enough after; might as well focus on that shift to 128 bit addresses