3 ms·

> and why you can run x86 software on M1 Macs Seems like a pretty good case for the counterargument: that backwards compatibility can be entirely provided for

by nl 4y ago

> and why you can run x86 software on M1 Macs Seems like a pretty good case for the counterargument: that backwards compatibility can be entirely provided for in software. (To be clear, the M1 chip doesn't support the x86 instruction set at all, and translation is done entirely in software. I don't think there was ever any 16 bit x86 Mac software though, so not sure if that mode is supported).

toast0 4y ago
The M1 chip does support the x86 memory ordering, which allows the software instruction set emulation to not have to do memory ordering work in software. I don't think Macs ever had 16-bit code? 68000 was 32-bit, as was ppc and intel macs were 32-bit to start, with 64-bit later.
- nl 4y ago
  > I don't think Macs ever had 16-bit code? Yeah pretty sure you are right. > 68000 was 32-bit, Interestingly I discovered today the 68008 which was a 68000 with an 8-bit external data bus.
- JonathonW 4y ago
  The original 68k (used in the original 1984 Mac) was funky: it had a fully 32-bit instruction set and 32-bit registers, but 16-bit internal and external data buses and a 16-bit ALU. And a 24-bit address bus, because reasons? Later variants of the 68k family were fully 32-bit internally, but exactly what was exposed externally varied by processor and Mac model. And 24-bit addressing remained a thing in the Macintosh system software up until System 7-- this capped RAM at 8 MB even if the CPU could handle more. But Apple never really had the same sort of 16-bit/32-bit transition that Microsoft and Intel did. The 68k-to-PPC shift is kind of analogous (and happened at around the same time as Microsoft was going fully 32-bit), but backwards compatibility there was purely based around software emulation-- same basic approach as Apple's PPC-to-x86 and x64-to-ARM transitions, as opposed to Intel's "just make the new processor a superset of the old one" approach.
  - rbanffy 4y ago
    > because reasons? Chip size and pin count. Besides, 24 address lines allowed 16 megabytes of RAM, something outrageous back then.
rbanffy 4y ago
> backwards compatibility can be entirely provided for in software. My point was that it's so vital on some platforms that their vendors go to great lengths to make it available, despite the fact that the architecture is completely different. I don't see the same requirement in open-source stacks.

by nl 4y ago

toast0 4y ago

The M1 chip does support the x86 memory ordering, which allows the software instruction set emulation to not have to do memory ordering work in software. I don't think Macs ever had 16-bit code? 68000 was 32-bit, as was ppc and intel macs were 32-bit to start, with 64-bit later.

nl 4y ago
> I don't think Macs ever had 16-bit code? Yeah pretty sure you are right. > 68000 was 32-bit, Interestingly I discovered today the 68008 which was a 68000 with an 8-bit external data bus.
JonathonW 4y ago
The original 68k (used in the original 1984 Mac) was funky: it had a fully 32-bit instruction set and 32-bit registers, but 16-bit internal and external data buses and a 16-bit ALU. And a 24-bit address bus, because reasons? Later variants of the 68k family were fully 32-bit internally, but exactly what was exposed externally varied by processor and Mac model. And 24-bit addressing remained a thing in the Macintosh system software up until System 7-- this capped RAM at 8 MB even if the CPU could handle more. But Apple never really had the same sort of 16-bit/32-bit transition that Microsoft and Intel did. The 68k-to-PPC shift is kind of analogous (and happened at around the same time as Microsoft was going fully 32-bit), but backwards compatibility there was purely based around software emulation-- same basic approach as Apple's PPC-to-x86 and x64-to-ARM transitions, as opposed to Intel's "just make the new processor a superset of the old one" approach.
- rbanffy 4y ago
  > because reasons? Chip size and pin count. Besides, 24 address lines allowed 16 megabytes of RAM, something outrageous back then.

rbanffy 4y ago

> backwards compatibility can be entirely provided for in software. My point was that it's so vital on some platforms that their vendors go to great lengths to make it available, despite the fact that the architecture is completely different. I don't see the same requirement in open-source stacks.