Let's hope Apple has learned from the past and doesn't use this feature in its ARM machines - 24 bit addressing (the original 68000 only had 24 address lines but 32 bit registers) was abused by software developers who used the 8 MSBs of a pointer to store additional information. When switching to the 68020, which could address 4 GB, this caused a lot of trouble...
Since people know about it, and turn it on only when they want to use it, it's not a problem.
Had the move to the m68020 and m68030 included mandatory memory management, then old tasks could've all been run in the first 16 megs and clean apps run anywhere else. It's a shame Apple didn't do this.
Since this is now a documented feature of the CPU, processes can have up to 65,536 terabytes of usable memory and still use this. If they need more than 65,536 terabytes of memory, they can simply not use this feature :)
Still, with VM enabled (the 68851 PMMU was only available some time after the 68020 came out and an expensive addition, only the 68030 included an on-chip MMU as you probably know - so Apple was unable to use it in the Mac II initially) all 256 possible aliases for software storing arbitrary data in the 8 MSB would have to be mapped in the worst case. This would certainly be possible, but depending on the application might imply quite some overhead due to the limited number of TLB entries available.
Of course, on 68k Macs also the OS parts stored in ROM were not 32 bit "clean". MODE32, a tool developed by Connectix, patched the ROMs (traditional MacOS stores entry points for system functions in RAM which can be modified) to get rid of 24 bit addressing (https://en.wikipedia.org/wiki/MODE32).
What would be nice, of course, is to use the ARMv8-a top byte ignore feature to implement tagged data types for Lisp and Smalltalk implementations... [and I should read the whole article since this is a large part of it... oops]
"65,536 terabytes ought to be enough for anybody." :)
> old tasks could've all been run in the first 16 megs and clean apps run anywhere else. It's a shame Apple didn't do this.
It would not have been feasible; RAM was expensive back then. Most of Apple's 68020 and 68030 machines only shipped with 1MB of RAM; it was not until 1992 that they started shipping machines with 4MB.
You don't need that much memory to make use of memory management. In many cases, using memory management can help to save memory, but that's another discussion.
Obviously you don't need to use MODE32 if you don't use more than 8 megs. Same thing. Memory wouldn't be rearranged to have (stuff in the first 16 megs) and (everything else) until you have more memory than would fit in the first 16 megs.
Apple disables TBI and uses those bits for pointer tagging (edit: only for code, it’s enabled for data, which is likely where you’d want it more). This is pretty much irrelevant at this point anyways, applications today that use pointer tagging are generally written with portability in mind and have a way to adjust based on how many bits are available (if any). I don’t actually think Apple exposes a way of detecting whether it’s enabled so it’s probably not worth using until they commit to it.
The developers responsible for this 'abuse' were first and foremost Apple themselves - key services provided by the OS/ROMs used the high order bits for various things.
See https://apple.fandom.com/wiki/24-bit_addressing for more details.