"Oddball string instructions", as an assembler coder bitd, they were a welcome feature as opposed to running out of registers and/or crashing the stack with a Z-80.
Despite what the article says, the 68000 was microcoded too. Another difference is that the 68K was a 32b architecture, not 16b, and that required investing more transistors for the register file and datapath.
The 68000 actually had both microcode and nanocode, so it was even further from hardwired control logic than the 8086. In terms of performance the 68000 was slightly faster than the 286 and way faster than the 8088 (I never used an 8086 machine).
The 286 looks like it ought to be usefully quicker in general? Motorola did a good job on the programming model, but you can tell that the 68000 is from the 1970s. Nearly all the 68000 instructions take like 8+ cycles, and addressing modes can cost extra. On the 286, on the other hand, pretty much everything is like 2-4 cycles, or maybe 5-7 if there's a memory operand. (The manual seems to imply that every addressing mode has the same cost, which feels a bit surprising to me, but maybe it's true.) 286 ordinary call/ret round trip time is also shorter, as are conditional branches and stack push/pop.
My reading is that there aren't really a lot of addressing modes on 286, as there are on 68000 and friends, rather every address is generated by summing an optional immediate 8 or 16 bit value and from zero to two registers. There aren't modes where you do one memory fetch, then use that as the base address for a second fetch, which is arguably a vaguely RISC flavored choice. There is a one cycle penalty for summing 3 elements ("based indexed mode").
Not for the data path; the 68000 operates on 32 bit values 16 bits at a time, both through its external 16 bit bus and internal 16 bit ALU. Most 32 bit operations take more cycles. But yes, it has a 32 bit programming model.
Actually, the 68000 had one full (all operations) 16 bit ALU and two more simple (add/subtract, so AU might be a better name) 16 bit ALUs so in the best case it could crunch 48 bits per clock cycle. The 8086 had one full 16 bit ALU and one simple 16 bit ALU (the ancestor of todays AGUs - address generator units).
Not only was it microcoded, but it was sufficiently divorced from the assumptions of the 68000 instruction set that IBM were able to have Motorola make custom "68000-based" chips that ran S/370 code directly.
Want a different architecture? Sure, just draw it with a different ROM. Simple (if you've got IBM money to throw around).
"Oddball string instructions", as an assembler coder bitd, they were a welcome feature as opposed to running out of registers and/or crashing the stack with a Z-80.
Despite what the article says, the 68000 was microcoded too. Another difference is that the 68K was a 32b architecture, not 16b, and that required investing more transistors for the register file and datapath.
The 68000 actually had both microcode and nanocode, so it was even further from hardwired control logic than the 8086. In terms of performance the 68000 was slightly faster than the 286 and way faster than the 8088 (I never used an 8086 machine).
The 286 looks like it ought to be usefully quicker in general? Motorola did a good job on the programming model, but you can tell that the 68000 is from the 1970s. Nearly all the 68000 instructions take like 8+ cycles, and addressing modes can cost extra. On the 286, on the other hand, pretty much everything is like 2-4 cycles, or maybe 5-7 if there's a memory operand. (The manual seems to imply that every addressing mode has the same cost, which feels a bit surprising to me, but maybe it's true.) 286 ordinary call/ret round trip time is also shorter, as are conditional branches and stack push/pop.
My reading is that there aren't really a lot of addressing modes on 286, as there are on 68000 and friends, rather every address is generated by summing an optional immediate 8 or 16 bit value and from zero to two registers. There aren't modes where you do one memory fetch, then use that as the base address for a second fetch, which is arguably a vaguely RISC flavored choice. There is a one cycle penalty for summing 3 elements ("based indexed mode").
Not for the data path; the 68000 operates on 32 bit values 16 bits at a time, both through its external 16 bit bus and internal 16 bit ALU. Most 32 bit operations take more cycles. But yes, it has a 32 bit programming model.
Actually, the 68000 had one full (all operations) 16 bit ALU and two more simple (add/subtract, so AU might be a better name) 16 bit ALUs so in the best case it could crunch 48 bits per clock cycle. The 8086 had one full 16 bit ALU and one simple 16 bit ALU (the ancestor of todays AGUs - address generator units).
Not only was it microcoded, but it was sufficiently divorced from the assumptions of the 68000 instruction set that IBM were able to have Motorola make custom "68000-based" chips that ran S/370 code directly.
Want a different architecture? Sure, just draw it with a different ROM. Simple (if you've got IBM money to throw around).
Did anyone else read the headline and think....Zilog? WTF?