Darren New <dne### [at] sanrrcom> wrote:
> I'm pretty sure that's not correct.  Granted, it's been decades since I 
> did Z80 assembler. It had a 16-bit ALU for the addressing, for the most 
> part, but the registers were definitely 8-bit registers. Some of the 
> opcodes would pair them up into an address or some such, but you'd be 
> taking two registers to do it. Not unlike the "AX = AH:AL" sort of thing 
> the x86 series does.

  It's exactly what the x86 does, and that's why the x86 series is a
16-bit processor (up to the 386).

  With the z80 you can have 16-bit literals, perform 16-bit ALU operations
(such as additions, substractions, shifts, etc), you can address the entire
memory with one single 16-bit register, etc. I don't understand what's *not*
16-bit about the z80.

  Just because the 16-bit operations are performed on pairs of 8-bit
registers that doesn't make it any less of a 16-bit operation. The
crucial thing is that you can perform a 16-bit operation with *one*
single opcode. You can also load a 16-bit value into such a pair with
one single opcode. This means the opcode is a 16-bit one.

  If the z80 is not a 16-bit processor, then neither is the 80286.

> Almost everyone calls the processor the number of bits on the data bus, 
> fwiw, when talking about this stuff.

  How is that even useful? It might tell something about the speed at which
the processor can handle data, but it doesn't tell anything about the
processor itself.

  I understand "8-bit" to mean "has 8-bit registers, and you can only
perform an 8-bit operation with a single opcode, because registers can
only hold 8 bits of data". Likewise for any other bitsize.

  Btw, didn't the 386 usually have a 16-bit data bus? The 386 is still
a 32-bit processor, though.

-- 
                                                          - Warp

Post a reply to this message