🚀 go-pugleaf

In article <21936@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes:
[...]
>I'm planning to buy a 80386 PC for use with UNIX, MSDOS, OS/2,
>and WINDOWS/386. After studying the trade papers and marketing
>literature, I've made the following conclusions: 

[...]
>3. Is it impractical (cost and/or size) to put 40 256KB
>25ns SRAMs (no refresh overhead and cycle 
>time=access time) up for main memory? In other 
>words, is it cheaper to implement paged (PMRAM, 
>SCRAM) or interleaved schemes to reduce wait 
>states rather than use 40 SRAMs? It seems like
>alot of trouble to go to...but how much do SRAMs cost?

A lot.  I haven't got any prices for 25ns SRAMs handy, but at 100ns
256K of SRAM cost the same as 1MB of DRAM ($24.95 retail).  For 256K
the SRAM part is about 3 times as expensive as the DRAM one ($24.95 vs.
$7.25).  Note that both have the same speed.  Fast memories are VERY
expensive.

[...]
>5. I assume the ONLY thing that makes the 33MHz PCs 
>faster is the 25 ns cache. Otherwise, with 70 ns 
>DRAM the BEST you could do would be run as fast as 
>a 16MHz 80386 PC (62 ns) but with lots of wait 
>states. In other words, memory cycle time limits 
>non-cache CPU performance to that of a 16MHz 80386.

This is not true.  Typicaly an instruction has to be fetched, fetch
some operands, do some processing and write some results back.  The
time taken for the processing decreases as the clock frequency
increases.  Instruction prefetchig also contributes to a speed-up.
Viewing the microcode as a program and the memory accesses as I/O your
question can be rephrased as:  ``Is the 80386 microcode execution I/O
(i.e. memory) or CPU (i.e. microCPU) bound ?'' Your assertion would be
correct only if the 386 microcode execution was memory bound.  I think
this is not the case for typical instruction sequences.

[...]
>6. If you whipped out your trusty soldering gun and 
>anti-static gear and changed all your memory chips 
>to 25 ns SRAMS(on a 33MHz machine w/no cache) would 
>the wait states go away? OR is the timing part of the 
>hardware architecture? (Pardon me for this seemingly
>naive question, but I've been doing software for 8
>years.)

The timing is part of the machine design.  Replacing the components
with faster ones will most of the time not contribute to the speed of
your machine*.  In the memory components used in the PCs there is no
signal from the memory chip which is asserted when data is available.
This a problem of the synchronous designs.  (Conceptual solutions
exist, but require a total rethink of the way hardware is designed.
Read the 1989 ACM Turing award paper by Ivan Sutherland on
micropipelines for more details.)  I would expect for the timing to be
hard coded in the form of some jumpers from a PISO shift register, a
PAL  or a PROM.  You could always modify these, but it would not be
trivial.

* An exception is when a processing element is replaced with a more 
efficient one e.g. when an Intel 8088 is replaced with a NEC V-20.

[...]
>7. The PC manufacturers never talk about parity error 
>checked memory, ECC memory, Harvard A.(separate 
>data/instruction cache), data write-thru cache, 
>write buffers (CPU can go on after issuing write 
>instruction only), and multi-word memory 
>transfers. Are PC mfgs behind the times? Or is this
>because of all the canned stuff from the east.

Parity error checked memory is available by some manufacturers.  (IBM
was one of them.) I don't think that the target market for PCs could
bear the cost of ECC memory.  For Harvard architecture you need support
from the processor, the 386 does not directly support it.

Diomidis
-- 
Diomidis Spinellis          European Computer-Industry Research Centre (ECRC)
Arabellastrasse 17, D-8000 Muenchen 81, West Germany        +49 (89) 92699199
USA: diomidis%ecrcvax.uucp@pyramid.pyramid.com   ...!pyramid!ecrcvax!diomidis
Europe: diomidis@ecrcvax.uucp                      ...!unido!ecrcvax!diomidis