🚀 go-pugleaf

JS> 1) The VAX memory access speed relies on write back cache - the bus cycles
JS> are 400 ns.  With a 10 Mhz 32032 *or* 32016 one can get real memory
JS> response times of 200ns.  This saves time.  
 
me> Say what????  200 ns bus cycle times on a 10 MHz 32K?  At 10 Mhz, each
me> clock is 100 ns.  Except for slave processor register accesses, the
me> shortest possible bus cycle on a 32xxx is 4 clocks.  That's 400 ns.
me> If you have an MMU, it's 5 clocks, or 500 ns.
 
JS> Though the basic processor cycling takes 4 T states, and each of these
JS> takes 100ns on a 10Mhz chip, the turnaround time is measured from address
JS> valid to data valid, which is 200ns.

True, but this is of no importance to the CPU.  It is of importance to
a) the designer, who has to build a 200 ns memory to support a CPU which
has a 400 or 500 ns bus cycle; and b) multi-ported memories where the
shorter memory cycle reduces contention as seen from the other ports.

It is hard to see how "this saves time".

me> My experience is that a 10 MHz 32016 w/MMU and FPU is in the same
me> ballpark as (or slightly faster than) a VAX 11/750.  But -- the C
me> compiler supplied with Genix is terribly slow, taking twice as long
me> as the VAX/UNIX C compiler.
 
JS> Several people have commented that the
JS> development machine National has is terribly slow in practice

Not really too surprising -- the DB16000 is run at 6 MHz with 2 wait
states.

JS> If it is the
JS> case, might this not in part account for your speed differences?

No, simply because the benchmarks were not run on the DB16000.

I see that I've goofed.  I didn't state that where the Genix C compiler
falls down is *compile time*, and folks naturally assumed that I meant
that the object code was poor.  Sorry about misleading y'all.

The object code is not a problem.  But it takes so dratted long to
compile even the smallest programs that one hates to turn on the
optimization feature.
-- 
Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug