24 Nov
2000
24 Nov
'00
6:13 a.m.
-----Original Message-----
From: Eric Smith <eric(a)brouhaha.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Friday, November 24, 2000 3:27 AM
Subject: Re: 80186 and now AMY chip
"Eric J. Korpela"
<korpela(a)ellie.ssl.berkeley.edu> wrote:
Where in the world did that come from? The base data paths for z80
and 8080 are 8bits. Key words are "data paths" as the alu on 8080
is basically 8bits (with microcoded 16 bit ops as two sequential 8bit
ops).
Usually the size of the data word is the metric. What confuses the
subject often is the instruction word size (4004 is really 8bit then)
or the ability to manipulate smaller than word size (VAX and pdp-11
byte ops).
You missed the important one, and the only one
that counts
when determining the bitness of the processor, the width of
the (integer) ALU.
Clearly, regardless of the width of the registers and the
address bus size, the Z80 is an 8 bit processor, as is the
6502. The 8088 and 8086 are both 16 bitters. The 68000 and
68010 are 16 bitters. The 68020 is a 32 bitter as is the
x386.
Actually, using this metric, the 8080 and Z-80 are 4-bit processors, Try asking programmers what width processors are
instead of hardware
engineers. They'll tell you that the 8080 and Z-80 are 8-bitters,
and that the 68000 and IBM 360 (most models) are 32-bitters.
generally agreed. It when you start playing with math ops and
addressing range that the "size" is noticeable and significant.
However if you look at most cpus there is a basic word size and
alu size that are amoung the defining parameters.
Allison
24 Nov
24 Nov
10:17 a.m.
"Eric J. Korpela" <korpela(a)ellie.ssl.berkeley.edu> wrote:
You missed the important one, and the only one that
counts
when determining the bitness of the processor, the width of
the (integer) ALU.
Clearly, regardless of the width of the registers and the
address bus size, the Z80 is an 8 bit processor, as is the
I wrote:
Actually, using this metric, the 8080 and Z-80 are
4-bit processors,
Allison wrote:
Where in the world did that come from? The base data
paths for z80
and 8080 are 8bits. Key words are "data paths" as the alu on 8080
is basically 8bits (with microcoded 16 bit ops as two sequential 8bit
ops).
Eric said "width of the (integer) ALU", not "data paths". Note that
I
said in my message that I thought that was a useless metric.
According to its designers, the ALU on the 8080 is 4 bits wide, and
takes 2 cycles for an 8-bit add or subtract. Presumably it takes at
least 4 cycles for a 16-bit add or subtract. The 8080 takes so many
cycles for *anything* that it's not obvious what it does internally on
any given cycle.
Eric
25 Nov
25 Nov
3:31 p.m.
According to its designers, the ALU on the 8080 is 4
bits wide, and
takes 2 cycles for an 8-bit add or subtract. Presumably it takes at
least 4 cycles for a 16-bit add or subtract. The 8080 takes so many
cycles for *anything* that it's not obvious what it does internally on
any given cycle.
I for one would be interested in seeing whatever references to 8080 internals
this kind of stuff comes from. The bulk of what I have doesn't give any
internal details. I'd alway assumed that there was some sort of
synchronization of writeback to the accumulator (or other destination register)
or the update of the flags that ate up the extra cycle.
Given a 16 bit add takes 11 T cycles, that would be 2 for fetch and decode,
4 for ALU passes, and 5 for who knows what. Probably moving things too and
from internal registers, that would explain why a 16
bit increment could be
done in 6 T cycles, 2 fetch+4 ALU passes.
Eric
8795
days inactive
8796
days old
2 comments
3 participants
participants (3)
-
ajp166＠bellatlantic.net -
eric＠brouhaha.com -
korpela＠ellie.ssl.berkeley.edu