4 ms·

> It's a "16/32"-bit CPU, since it provides 32-bit operations/immediates and 32 bits worth of data- and address registers. Eh, you're getting into some real cr

> It's a "16/32"-bit CPU, since it provides 32-bit operations/immediates and 32 bits worth of data- and address registers. Eh, you're getting into some real crafty wordplay here. If you want to be technical it's a 16-bit processor with compound operations at 32-bit, in the same way a Z80 is an 8-bit processor that does 16-bit compound operations. Yeah, if you redefine the terms, you can make it mean exactly what you want. This is exactly what Atari did to label the Jaguar a "64-bit" machine, after all. It doesn't change what people meant at the time when they used the nomenclature (the native operating size of the ALU).

daneel_w 3y ago
How is it "real crafty wordplay"? 16/32-bit is Motorola's own designation, and that's the width of the registers and the ISA's immediates. When programming the 68k you work directly with 32-bit longwords instead of having to manually herd multiple 16-bit words to achieve the same. Register-combining instructions like those in the Z80 do not exist in the 68000, nor are they necessary. Your comparison is invalid. Perhaps you have no experience programming the m68k family.
- deaddodo 3y ago
  I literally wrote an m68k emulator core, along with multiple z80 variants. I'm intimately familiar with the internals of both, thanks. To reiterate my point, with sourcing (to counter your glib dismissals): > The design implements a 32-bit instruction set, with 32-bit registers and a 16-bit internal data bus.[4] The address bus is 24 bits and does not use memory segmentation, which made it easier to program for. Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[4] and has a 16-bit external data bus.[5] For this reason, Motorola termed it a 16/32-bit processor. Highlighted portion italicized, source: https://en.wikipedia.org/wiki/Motorola_68000 https://en.wikipedia.org/wiki/Motorola_68000 When people refer to bit-width around the generation aforementioned (8-bit to early 32-bit), this is what they are referencing. This is because many CPUs operated on different bus sizes throughout the architecture. What people using the term care about is it's native arithmetic capabilities. Unless you want to run around calling ARM11s "16-bit CPUs" because they support THUMB. As to what Motorola opted to call it, I couldn't care less about marketing speak regarding notoriously fuzzy buzzword CPU-capabilities; I care about technical capabilities and consistency.
  - daneel_w 3y ago
    > "As to what Motorola opted to call it, I couldn't care less about marketing speak regarding notoriously fuzzy buzzword CPU-capabilities; I care about technical capabilities and consistency." Speaking of glib dismissals... I also care for technical capabilities - such as not having to sacrifice multiple registers to operate on 32 bits of data, or having to issue multiple instructions to load and store 32 bits of data. I don't need to treat the 68000 as a completely different platform compared to when I write stuff that run on e.g. the 68020. I mainly need to accept the higher cycle counts.
    - deaddodo 3y ago
      > Speaking of glib dismissals... No, a sourced and quantified dismissal.
  - vidarh 3y ago
    It was not just Motorola. Referring to it as 16/32 was not unusual at the time, because it was nowhere near as clear-cut as you want it to be. The fact we could add/sub/move 32 bit quantities was more important a lot of the time than the specifics of the data bus.
    - deaddodo 3y ago
      And yet, it performed 16-bit operations internally. It's awesome that the interface for the 68k was 32-bit oriented, it made it future-proofed for later iterations. The 68000 still only did fused 16-bit operations and is thus (by the most important metric) a 16-bit processor. For the same reason an ARM operating on THUMB instructions is still a 32-bit processor. Nothing is "clear cut" when you intentionally obfuscate it.
      - vidarh 3y ago
        It was not obfuscated to any of us who used them at the time. Apply whatever purity tests you want, but the reality is that a lot of people used these labels different to how you're using them, and when you insist on ignoring that you're the one engaged in obfuscation.

daneel_w 3y ago

How is it "real crafty wordplay"? 16/32-bit is Motorola's own designation, and that's the width of the registers and the ISA's immediates. When programming the 68k you work directly with 32-bit longwords instead of having to manually herd multiple 16-bit words to achieve the same. Register-combining instructions like those in the Z80 do not exist in the 68000, nor are they necessary. Your comparison is invalid. Perhaps you have no experience programming the m68k family.

deaddodo 3y ago
I literally wrote an m68k emulator core, along with multiple z80 variants. I'm intimately familiar with the internals of both, thanks. To reiterate my point, with sourcing (to counter your glib dismissals): > The design implements a 32-bit instruction set, with 32-bit registers and a 16-bit internal data bus.[4] The address bus is 24 bits and does not use memory segmentation, which made it easier to program for. Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[4] and has a 16-bit external data bus.[5] For this reason, Motorola termed it a 16/32-bit processor. Highlighted portion italicized, source: https://en.wikipedia.org/wiki/Motorola_68000 https://en.wikipedia.org/wiki/Motorola_68000 When people refer to bit-width around the generation aforementioned (8-bit to early 32-bit), this is what they are referencing. This is because many CPUs operated on different bus sizes throughout the architecture. What people using the term care about is it's native arithmetic capabilities. Unless you want to run around calling ARM11s "16-bit CPUs" because they support THUMB. As to what Motorola opted to call it, I couldn't care less about marketing speak regarding notoriously fuzzy buzzword CPU-capabilities; I care about technical capabilities and consistency.
- daneel_w 3y ago
  > "As to what Motorola opted to call it, I couldn't care less about marketing speak regarding notoriously fuzzy buzzword CPU-capabilities; I care about technical capabilities and consistency." Speaking of glib dismissals... I also care for technical capabilities - such as not having to sacrifice multiple registers to operate on 32 bits of data, or having to issue multiple instructions to load and store 32 bits of data. I don't need to treat the 68000 as a completely different platform compared to when I write stuff that run on e.g. the 68020. I mainly need to accept the higher cycle counts.
  - deaddodo 3y ago
    > Speaking of glib dismissals... No, a sourced and quantified dismissal.
- vidarh 3y ago
  It was not just Motorola. Referring to it as 16/32 was not unusual at the time, because it was nowhere near as clear-cut as you want it to be. The fact we could add/sub/move 32 bit quantities was more important a lot of the time than the specifics of the data bus.
  - deaddodo 3y ago
    And yet, it performed 16-bit operations internally. It's awesome that the interface for the 68k was 32-bit oriented, it made it future-proofed for later iterations. The 68000 still only did fused 16-bit operations and is thus (by the most important metric) a 16-bit processor. For the same reason an ARM operating on THUMB instructions is still a 32-bit processor. Nothing is "clear cut" when you intentionally obfuscate it.
    - vidarh 3y ago
      It was not obfuscated to any of us who used them at the time. Apply whatever purity tests you want, but the reality is that a lot of people used these labels different to how you're using them, and when you insist on ignoring that you're the one engaged in obfuscation.