[net.micro.68k] 68020 vs 16k

agr@vaxine.UUCP (Arnold Reinhold) (01/13/84)

Some thoughts on the 68k vs 16k debate:

Had Motorola waited until it had enough microcode space to do the 68000 right,
a lot of us would be using 8086's now.  I would be more interested in hearing
the merits of the 68020 debated relative to the 16k series.  The 16k
still has a more elegant instruction set, but some of the worst blunders in
the 68k -- no long pc relative displacements, no 32 x 32  multply -- are
to be fixed. Floating point is still a ways off. However, some people are
apparently using the National fp chip with the 68k.  Motorola is planning a
demand paged mmu but it is a year behind the 68020. My best info suggests
initial 68020 samples this summer or fall.

I would be interested in other comments and rumors about how well Motorola has
patched the 68000's flaws in the 68020 and about using the National fpu with
the 68k series.

Arnold Reinhold
Automatix Inc.
Billerica, MA 01821
617 667 7900

rcm@tropix.UUCP (Robert C. Moore) (01/28/84)

Some further thoughts on the 68020 vs 16k:

	The 68020 will contain a cache for text refrerences, with
		only 2 clock cycles per instruction running from the
		cache.  The 16k doesnt have a cache.

	The 68020 provides indexed addressing modes (as does the vax
		and the 16k) and memory resident pointer addressing modes.

	The 68020 fpu, due out 3 months after the 020, provides full
		80 bit precision and a host of transcendentals.  The
		16k uses 32 and 64 bit presision, and no transcendentals.
		The fp instructions work into 8 80bit registers, making
		floating point register variables quite practical.  The
		16k provides 8 32bit (paired as 4 64bit) fp registers.
		Whetstones should look pretty good on the 020.

	The 68020 will be provided with clocks from 12 to 25 Mhz.  The
		design center is around 20 Mhz.  The 16k is hard to get
		above 6 Mhz.  They are hopeing for 10 Mhz eventually.

	The 68020 paged mmu will allow variable page size and number of
		levels.  This is fixed in the 16k's mmu.

	
	These and other considerations make the 68020 worth waiting for.

						bob moore
						inhp4|tropix|rcm

norm@rocksvax.UUCP (Norm Zeck) (02/09/84)

About the cache, rumors indicate that the size will be about 256 bytes, ie it
will not be a 68010.  Sounds like Motorola really put that one word instruction
hold in the 68010 to improve their benchmarks against CPU's that have string
instructions (Intel 80x86 for example).

About part speeds, I think Rob's comments about memory speeds is well
said.  We have been running with 12.5 Mhz 68000's for about a year now.
The processor board design is versabus based with a 4k byte cache, 32 bit
wide data r/w to memory, and segmented mmu (Charles River Data systems).
>From a memory speed point of view, the 12.5 Mhz 68k likes to see memory
respond in ~80 ns (DTACK') + 50 ns to data valid (give or take some time for
margin) without adding wait states.  To do this on a bus that is not local
to the processor such as multibus or versabus is difficult to say the least.
Hence the cache is VERY important in SYSTEM performance.  For example, we
also have a 8 Mhz 68k CPU board from Motorola that we have run some 
benchmarks on, and on the 12.5 Mhz system these same benchmarks run
about 2.5x faster using the same memory.  Obviously 12.5/8 != 2.5.
The cache + 32 bit r/w to keep the cache full make a significant
performance difference above and beyond the CPU clock speeds.  This will
Memory bandwidth will become more important in future CPU's as clock
speeds increase (I believe the 386 may have some type of cache ???).

Nothing against the 16k, nice chip, nice design.  Will definitely give
Motorola a run for their money.  But, increased CPU clock speeds
without consideration for memory speed requirements can be misleading
in terms of REAL acheivable system performance.  The cache can help here.
Beware of the benchmarks that sound real impressive, but require you
to use VERY fast memory to acheive as I have heard about some of the
faster versions of the 286 (not a put down on Intel, but their sales
lit which seems to always compare benchmarks is on CPU's often has
looked real good on paper, but has not turned out the same in a system).

					Norm Zeck

phil@amd70.UUCP (Phil Ngai) (02/09/84)

I can't let this one go by. Intel, feel free to respond also.

> Beware of the benchmarks that sound real impressive, but require you
> to use VERY fast memory to acheive as I have heard about some of the
> faster versions of the 286 (not a put down on Intel, but their sales
> lit which seems to always compare benchmarks is on CPU's often has
> looked real good on paper, but has not turned out the same in a system).
> 					Norm Zeck

The 286 does not require VERY fast memory, at least, for a given
memory bandwidth, the 286 will run with slower access memories than
the 68000 will. The 286 has a separate address and data bus, just
like the 68000. However, they do something useful with it. They overlap
the data operation of the current cycle with the address of the next
cycle. For example, with an 8 MHz 286, a word is required every 250 nS.
However, the required memory access time is a leisurely 242 nS.

To run a 68000 with an 8 megabyte per second memory bandwidth would
require a 16 MHz 68000. The required memory access time in that case
would be about 156 nS (address strobe in state 2, data required
end of state 6, 5 states * 31.25 nS per state = 156.25 nS).

Of course, if you have 156 nS, you probably need 100 nS DRAMs.
This is expensive.

Perhaps intelca!kds could comment on my analysis.
-- 
Phil Ngai (408) 988-7777 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!phil