6 ms·

For some history—the early Macs in 1984 used 24-bit addressing. The 68000 itself had a 24-bit address bus, but the address registers were 32 bits. So you could

For some history—the early Macs in 1984 used 24-bit addressing. The 68000 itself had a 24-bit address bus, but the address registers were 32 bits. So you could use the top 8 bits for some extra data, and programs actually did this (including ROMs/system software for early Macs). This meant that your memory would max out at 8 MiB, with the other half of the address space used for something else (ROM?). When System 7 came out, 32-bit addressing became available but not all software was “32-bit clean”. So you could enable or disable 32-bit addressing in the memory control panel. This is similar to the A20 gate on IBM PCs. By 1993 or so the hardware was no longer built to support 24-bit addressing. PowerMacs followed soon after.

saagarjha 7y ago
I wonder if we’ll ever have to make today’s software “64-bit clean”.
- jjtheblunt 7y ago
  Is that what Apple developers were given a several-year advanced notice of, and Catalina now requires such? I recall many people running non 64-bit clean apps complaining about Catalina, which I found curious.
  - wtallis 7y ago
    Apple dropped support for 32-bit applications. That's different from requiring 64-bit applications to stop abusing unused address bits—something that hasn't ever been commonplace for x86-64.
    - zozbot234 7y ago
      x86-64 actually requires that every memory access occur with a "canonical" address, specifically to ensure that everything will be "64-bit clean". That is, even though virtual address space in some cases may be limited to 48 or 56 bits the actual address has to be sign-extended to 64 bits, so everything is "clean". "Abusing" unused address bits is then just a matter of ensuring that any virtual addresses you use are restricted to the appropriate range. "x32" binaries do this in order to ensure that any pointers will fit within 32 bits even on x86-64, for example.
      - wtallis 7y ago
        It's also possible to use a few low address bits for non-address information if you're willing to accept coarser alignment on all pointers. It's not as easy since you have to mask off those lower bits before dereferencing, as opposed to simply relying on the MMU to ignore high bits you're using for tags or whatever.
- wvenable 7y ago
  The address space of AMD64 was designed so that both the upper and lower spaces of the address are used when using less than 64 bus lines specifically to address this problem.
  - saagarjha 7y ago
    Right, but a lot of high-performance code will tag the high bits of pointers anyways and apply a mask before using it for memory accesses.
    - that_jojo 7y ago
      > and apply a mask before using it for memory accesses So it never goes onto the address bus. So it never causes an addressing issue. The 24-bit issue of the 68000 is fundamentally different. Those tagged 32-bit pointers were used directly, but truncated by the width of the actual physical interface so they never touched the outside world. ...until Motorola released CPUs with full 32-bit address pins on the package. Oops.
      - saagarjha 7y ago
        It's still going to break software, though. But if you're looking for a platform that lets you do this, look no further than ARMv8's TBI.
  - jdsully 7y ago
    That only ensures the programmer fixes the pointer before dereference. Tagged pointers that don’t make it to the bus are still a compatibility problem. It means malloc() can’t return an address overlapping the tagged bits.
    - saagarjha 7y ago
      malloc usually gets more aligned with time, not less. The tagging we're talking about goes in the high bits of a pointer.
zackmorris 7y ago
Ya I miss the 68000. It was the first assembly language that I learned. It was much closer to RISC than x86 is, so there were plenty of registers and the instructions were fairly generic so it was straightforward to map C code almost directly to assembly. The "32 bit clean" stuff caused a lot of bugs for years after 32 bit memory arrived though. What really killed it though was perceived slowness. Apple insisted on shipping generations of Macs with crippled busses running at half the bit width of the CPU and/or at reduced frequencies. I remember the very fastest Macs in the early 90s not being able to even run a scrolling 2D game at 640x480 in 8 bit color because it just wasn't a priority. Meanwhile a 486 could run DOOM in 320x240. We had to wait until the 60 MHz PPC 601 arrived, and even it struggled with 640x480 graphics (the lowest resolution available). On top of that, most software was still emulated 68000, so the perceived slowness of Macs continued until Steve Jobs returned and introduced the colored iMacs. I eventually came to love x86 assembly for the brief time I used it though. It has so many easter egg instructions for moving bytes around wider registers and getting free side effects with memory access that it felt like there was always another way to gain a bit more performance out of hand-rolled loops. Of course that's all gone today, because instruction sets are so.. byzantine that a good compiler will usually beat hand-rolled assembly. That's because the real processing happens as RISC beneath microcode so a human can't really know the optimal way to string instructions together to keep the pipeline full or avoid cache misses. Also the SIMD stuff expanded the solution space to such a degree that it's almost pointless to do anything directly. Better to use a vector language like MATLAB and compile to SIMD accelerated C or go to GPU processing instead IMHO. Otherwise you're perpetually struggling with premature optimization and can't work at a productive level of abstraction.

saagarjha 7y ago

I wonder if we’ll ever have to make today’s software “64-bit clean”.

jjtheblunt 7y ago
Is that what Apple developers were given a several-year advanced notice of, and Catalina now requires such? I recall many people running non 64-bit clean apps complaining about Catalina, which I found curious.
- wtallis 7y ago
  Apple dropped support for 32-bit applications. That's different from requiring 64-bit applications to stop abusing unused address bits—something that hasn't ever been commonplace for x86-64.
  - zozbot234 7y ago
    x86-64 actually requires that every memory access occur with a "canonical" address, specifically to ensure that everything will be "64-bit clean". That is, even though virtual address space in some cases may be limited to 48 or 56 bits the actual address has to be sign-extended to 64 bits, so everything is "clean". "Abusing" unused address bits is then just a matter of ensuring that any virtual addresses you use are restricted to the appropriate range. "x32" binaries do this in order to ensure that any pointers will fit within 32 bits even on x86-64, for example.
    - wtallis 7y ago
      It's also possible to use a few low address bits for non-address information if you're willing to accept coarser alignment on all pointers. It's not as easy since you have to mask off those lower bits before dereferencing, as opposed to simply relying on the MMU to ignore high bits you're using for tags or whatever.
wvenable 7y ago
The address space of AMD64 was designed so that both the upper and lower spaces of the address are used when using less than 64 bus lines specifically to address this problem.
- saagarjha 7y ago
  Right, but a lot of high-performance code will tag the high bits of pointers anyways and apply a mask before using it for memory accesses.
  - that_jojo 7y ago
    > and apply a mask before using it for memory accesses So it never goes onto the address bus. So it never causes an addressing issue. The 24-bit issue of the 68000 is fundamentally different. Those tagged 32-bit pointers were used directly, but truncated by the width of the actual physical interface so they never touched the outside world. ...until Motorola released CPUs with full 32-bit address pins on the package. Oops.
    - saagarjha 7y ago
      It's still going to break software, though. But if you're looking for a platform that lets you do this, look no further than ARMv8's TBI.
- jdsully 7y ago
  That only ensures the programmer fixes the pointer before dereference. Tagged pointers that don’t make it to the bus are still a compatibility problem. It means malloc() can’t return an address overlapping the tagged bits.
  - saagarjha 7y ago
    malloc usually gets more aligned with time, not less. The tagging we're talking about goes in the high bits of a pointer.

zackmorris 7y ago

Ya I miss the 68000. It was the first assembly language that I learned. It was much closer to RISC than x86 is, so there were plenty of registers and the instructions were fairly generic so it was straightforward to map C code almost directly to assembly. The "32 bit clean" stuff caused a lot of bugs for years after 32 bit memory arrived though. What really killed it though was perceived slowness. Apple insisted on shipping generations of Macs with crippled busses running at half the bit width of the CPU and/or at reduced frequencies. I remember the very fastest Macs in the early 90s not being able to even run a scrolling 2D game at 640x480 in 8 bit color because it just wasn't a priority. Meanwhile a 486 could run DOOM in 320x240. We had to wait until the 60 MHz PPC 601 arrived, and even it struggled with 640x480 graphics (the lowest resolution available). On top of that, most software was still emulated 68000, so the perceived slowness of Macs continued until Steve Jobs returned and introduced the colored iMacs. I eventually came to love x86 assembly for the brief time I used it though. It has so many easter egg instructions for moving bytes around wider registers and getting free side effects with memory access that it felt like there was always another way to gain a bit more performance out of hand-rolled loops. Of course that's all gone today, because instruction sets are so.. byzantine that a good compiler will usually beat hand-rolled assembly. That's because the real processing happens as RISC beneath microcode so a human can't really know the optimal way to string instructions together to keep the pipeline full or avoid cache misses. Also the SIMD stuff expanded the solution space to such a degree that it's almost pointless to do anything directly. Better to use a vector language like MATLAB and compile to SIMD accelerated C or go to GPU processing instead IMHO. Otherwise you're perpetually struggling with premature optimization and can't work at a productive level of abstraction.