[net.micro.68k] Chip Speed / Re: 68020 vs. 32032, ...

phipps@fortune.UUCP (06/15/84)

[Beware the jabberwock ...]

    Traditionally the cpu operations have always been faster 
    than memory operations, since the same technology 
    applied to either operation favors the simpler.  
    
This goes against all I've picked up about hardware
(I acknowledge that I'm primarily a software person).
My understanding is that for the same chip technology, 
memory is always easier to design than CPUs, because memory designs 
are *simpler* and exhibit so much more regularity than CPU designs.  
Isn't it traditionally the case for any given chip family 
that chipmongers introduce memory chips first, then follow that up 
about a year later with a corresponding CPU chip ?

Will someone please point out my error, or explain how both the excerpt above
and my statements can be correct ?

-- Clay Phipps

-- 
   {cbosgd decvax!decwrl!amd70 harpo hplabs!hpda ihnp4 sri-unix ucbvax!amd70}
   !fortune!phipps

kds@intelca.UUCP (06/18/84)

>    Traditionally the cpu operations have always been faster 
>    than memory operations, since the same technology 
>    applied to either operation favors the simpler.  
>    
>This goes against all I've picked up about hardware
>(I acknowledge that I'm primarily a software person).
>My understanding is that for the same chip technology, 
>memory is always easier to design than CPUs, because memory designs 
>are *simpler* and exhibit so much more regularity than CPU designs.  

Well, actually, memory chips do tend to be more regular then
CPU designs, but the problem is complicated by the sheer number
of circuits, buffers, etc., in the memory subsystem as a whole
as opposed to the chips themselves.  That large memory systems
tend to be slower then CPUs points out one reason people use
cache memories.  System performance can be quite different
then chip performance.

In addition, different
kinds of trade-offs are usually made in the design of memories
as opposed to the design of logic circuits, simply because a
different kind of problem is trying to be solved.
-- 
Ken Shoemaker, Intel, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!kds
---the above views are personal.  They may not represent those of Intel.