80186 and now AMY chip

From: Hans Franke <Hans.Franke_at_mch20.sbs.de>
Date: Tue Nov 21 15:05:25 2000

I assume we aggree that the definition shoul be based on
an important part of the design - isn't it ?


> > There are different measurements around, like data path size,
> > register size or _marketing_ size.

> > Now let us look at the 68K family
> > 68000:
> > Data path: 16
> > Register: 32
> > ISA: 32
> > Marketing: 16

> You missed the important one, and the only one that counts
> when determining the bitness of the processor, the width of
> the (integer) ALU.

Well, I'd say you cuted this part of. As described, the size
of the ALU is neither important nor (always) visible.

> 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.

:)

Before I go onto the 68K, have a look at your 8080
(and AFAIR Z80) timeing - these babies have a 4 bit
wide ALU - they need two ALU cycles to add an 8 bit
number.

Hmm well, There is a 2 cycle penalty when adding
32 Bit instead of a 16 Bit (all following numbers
are always taken from my weak memories - please
correct me). Just, a move Dx,Dy instruction got
no additional cycles, no matter if 8, 16 or 32 Bit.
And even more, several bit operations - like TST (?)
show no difference when done for B/W/L, indicating
that at least some logical instructions are done
by a 32 bit ALU - so when guessing about the internal
structure (remember, even the existence of an ALU is
a hidden information) I might say the 68000/08/10
is a 32 bit CPU since it utilizes a 32 bit ALU

Also, when looking at some instruction timeing it
seams like the 68000 has at least another 32 bit
(or 24 bit) ALU for address calculations.

Oh, and speaking of penalty - the 68008 has a handicap
of 16 additional cycles for a 32 Bit add - quite more
than the 2 cycles for the ALU - so isn't the external
data bus size more important to classify a CPU ?

> > Well, this part is marketing, you still may argue that a
> > external data bus is a valid scheme for naming - nice, but
> > then every x86 chip since the original Pentium is a true
> > 64 Bit CPU. Sounds wrong, huh ? But it's true! (according
> > to said scheme)

> No, every x86 chip since the original 386 is a 32 bit CPU since
> the width of the integer ALU is 32 bits.

So what about the different ALUs ? As shown, even the 68000
has more than one, and on an actual x86 CPU got several
sixpacks :) Not to mention the 64 bit ALUs for MMX operations
(ok, ok, I said we have to ignore this if we talk about ISA
specifications, but if you're talking bit level hardware they
have to be in the game :)

> > /360&up-ish CPUs where available with ALUs from 8 to 32 bits,
> > internal data pathes from 8 to 256 bits, external data pathers
> > from 8 to 1024 bits (128 bytes per memory cycle), but nobody
> > will doubt that they are all 32 Bit CPUs.

> I will. Anything with an 8 bit ALU is an 8 bit processor, regardless
> of compatibility and wishful thinking. :)

Well, then you're a bit singled out.

Try to understand that the ALU as a measurement (and I
noted it already in my earlyer post) is as useless as
data bus and data path size. This measurement was valid
in a time when a CPU had only one ALU at all, and every
operation (including address calculation) had to pass
In the mainframe area this was only a _very_ short time,
and even the micros have catched up since 20 years.

As a little brain teaser for the end: imagine an architekture
with several ALUs of 16 and 32 bits - incomming instructions
are scheduled among the ALUs to enhance performance - nothing
unusual you'd say - and what if the scheduler assigns, if all
32 bit ALUs are allocated the next 32 bit operation to one of
the 16 bit ALUs which will perform it as two 16 bit operations.

How's you classify this processor ?

16 Bit ?

32 Bit ?

Gruss
H.

--
VCF Europa 2.0 am 28./29. April 2001 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
Received on Tue Nov 21 2000 - 15:05:25 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:13 BST