5 ms·
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, w
by 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 agoIt 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 agoAnd 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 agoIt 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.
- deaddodo 3y ago> used these labels different to how you're using them, and when you insist on ignoring that you're the one engaged in obfuscation. Obfuscation is using a clear and consistent metric instead of the one that is most convenient for marketing a product? So not only do we disagree on the meaning of "32-bit", we also disagree on the meaning of a well defined Engish term. But sure, feel free to call humans quadrupeds because sometimes they crawl.
- vidarh 3y agoIt is very clearly obfuscation to insist on using a term in ways inconsistent with a widely used way in which it was used, yes. Language.is for communication - when you insist on purity over clarity to those you're communicating woth, you're obfuscating.