Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site sjuvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!sjuvax!jss
From: jss@sjuvax.UUCP (J. Shapiro)
Newsgroups: net.micro.16k
Subject: Re: 32xxx bus cycles & CPU speed
Message-ID: <971@sjuvax.UUCP>
Date: Wed, 20-Mar-85 01:52:36 EST
Article-I.D.: sjuvax.971
Posted: Wed Mar 20 01:52:36 1985
Date-Received: Thu, 21-Mar-85 01:58:14 EST
References: <928@sjuvax.UUCP> <446@terak.UUCP>
Organization: Saint Josephs Univ. Phila., Pa.
Lines: 75

Me:
> > 1) The VAX memory access speed relies on write back cache - the bus cycles
> > are 400 ns.  With a 10 Mhz 32032 *or* 32016 one can get real memory
> > response times of 200ns.  This saves time.  

Doug Pardee:
> Say what????  200 ns bus cycle times on a 10 MHz 32K?  At 10 Mhz, each
> clock is 100 ns.  Except for slave processor register accesses, the
> shortest possible bus cycle on a 32xxx is 4 clocks.  That's 400 ns.
> If you have an MMU, it's 5 clocks, or 500 ns.

Pulling out the data book, it appears to me that you are incorrect.
Though the basic processor cycling takes 4 T states, and each of these
takes 100ns on a 10Mhz chip, the turnaround time is measured from address
valid to data valid, which is 200ns.  ~ADS goes low midway through T-state
1 and data is read midway through T-state 3.  On the VAX this is not the
case, though I don't have the hardware manual handy to spell it out.
I seem to recall the full VAX cycle takes longer. If I am wrong, would
someone yank out their hardware manual and outline it for me?

Typically, one does not just access memory, one does something with it, and
the access itself is only a fraction of the time (though a significant
one). Cut memory access time by 1/4 or 1/2 and lots of things get speeded
up, precisely because the most significant fraction of the time of an
operation is often memory (where applicable, of course).

> One of the "unique" aspects of the 32xxx is that there's no point in
> putting a memory cache on it, 'cause the bus cycle will take forever
> anyway.

At present, I can get 150ns rams (256Kx1) at $10 a piece in qty 10 or so.
100 ns rams are not that much more expensive, and how many processors out
there (really out there, not just in internal engineering samples, so no
talk about the 68020) run significantly faster than 100ns cycles? Of these,
how many expect to do a memory fetch in one cycle.  The fastest thing
around in general use that I know of is the NCR/32 series, which expects to
get a 32 bit read from memory with a turnaround of 80ns (though it will
wait as necessary).

The point I am making is, I can't thing of *any* current microprocessor
which in general use hardware can possibly benefit from a memory cache.
Memory is no longer the bottleneck in memory cycles, and hasn't been for a
few years.

> > 2) it is not clear that the 32016 doesn't compare to a VAX.  With the right 
> > kind of paging algorithms and hardware, one might very well outperform an 
> > 11/750 WITH FPA. I haven't tried it, but it looks possible.
> 
> My experience is that a 10 MHz 32016 w/MMU and FPU is in the same
> ballpark as (or slightly faster than) a VAX 11/750.  But -- the C
> compiler supplied with Genix is terribly slow, taking twice as long
> as the VAX/UNIX C compiler.

With respect, the quality of UNIX compilers (including the C compiler) is
low, in part because many of them are pcc derivatives. pcc was written to
be portable, not necessarily to take full advantage of the virtual machine
on which it is used. This doesn't change my comment. Not having used the
Genix compiler, I can't say.  Several people have commented that the
development machine National has is terribly slow in practice, again I
haven't yet had a chance to use one, so this is hearsay.  If it is the
case, might this not in part account for your speed differences?

To support further the point about C compilers, pick your favorite C
compiler benchmarks and run them under 4.1 (which is faster than 4.2) and
VMS 4.0.  Though of course there will be exceptional benchmarks, the DEC
compiler wins hands down, even where the program is fairly straightforward
computation.  This doesn't make UNIX better or worse than VMS. It means the
VMS compiler is in most places better written *for the VAX.* It is needles
to say not terribly portable.


It seems I have waxed longer than I intended. Time to pack away the soapbox
until next week.

Jon Shapiro