From: adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: Sat, 26 Sep 1992 17:41:01 GMT
	<ADAMS.92Sep25172127@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
	<1992Sep25.192643.15126@odin.corp.sgi.com>
Organization: TH-Darmstadt


In article <1992Sep25.192643.15126@odin.corp.sgi.com> mash@mash.wpd.sgi.com (John R. Mashey) writes:

>   Joe User should indeed not care ... although, of course, this is the wrong
>   newsgroup to read, given that it often discusses the reasons why designers
>   make
>   the choices that they do, and sometimes why something that is a good idea
>   at
>   one time is not necessarily so good a few years later.  I quote from
>   COMPUTER ENGINEERING: A DEC View of Hardware Systems Engineering, Bell,
>   Mudge, and McNamara, Digital Press, 1978, a fine book that I hope is still
>   in print.  p495:
>	   "Since the ACs [Accumulators] wre in the address space, ordinary
>	   memory could be used in lieu of fast registers to reduce the minimal
>	   machine price.  In reality, almost all users bought fast registers."
>  I.e., when PDP10s appeared in the late 60s, the cost of (16) registers was
>   enough to make people worry about it; the speed comparisons betweeen
>   memory
>   and logic were such that you'd be willing to sometimes consider using
>   memory
>   for your registers (although obviously, customers decided not to,
>   usually);
>   the speed difference was probably something like 2-4 (?).

1) I was not referring to one of the earliest or cheapest PDP-10s, but
to one of the faster CPUs, KL10.

2) DECsystem-10,DECsystem-20,Processor Reference Manual, AA-H391A-TK,
AD-H391AT1, June 1982, tells me :
page 1-2:
" .. At present there are four types of PDP-10 central processors, 
the KL10, the KS10 and the KA10. The first, which exists in two versions,
with and without extended addressing, is the fastest and most powerful .... "

page 1-8:
"The KL10 Processor:
Figure 1.3 shows the internal configuration of the KL-10 processor. Of the 
registers shown, only PC [!!!], the program counter, is directly relevant to a 
typical user ...."

Figure 1.3 on page 1-7 shows, that cache (2k*36) is directly connected 
to micro controller.

page 3-12:
" ... One may view the cache as 2048 general purpose registers, ..."

page 1-9:
"
 ... These first sixteen locations are not actually in the storage
modules -- they are in fast memory [!] contained in the processor. ....
Moreover there are acutally eight of these fast memory blocks ..., but
generally only one is available to a progrm at any given time. Blocks
6 and 7 are reserved specifically for the mcirocde; the Monitor
usually assigns block to 1 to user programs and reserves the other for
itself... "

>   Now, there is no way in the world you'd consider using main memory for
>   what are supposed to be the fastest registers in the machine, since CPUs
>   are
>   *much* faster than memory.  Consider that a 100MHz (internal) R4000 can
>    fetch 2 registers and write one every 10ns, and doing this with main
>   memory
>   would easily take 10-20 times longer....

I did not claim this. I claimed that PDP10-KL10 mapped [user] registers to
location 0-15 in user address space, on context switch their context was
spilled to cache, and from cache spilled to memory only on demand...
Restore vice versa. I claimed that this allowed simple and fast context
switches.

>   In addition, as designs get more parallel, it si really helpful to be able
>   to
>   access regsiters with no complications or surprises.  
You might use scoreboarding ...

>	and it is especially
>   unnice that *any* store instruction might modify any register (on any
>   machine
>   that puts the registers aspart of the address space).  This can inhibit
>   pipelining and more parallel implementations.  

Invalid - valid copies of an item ... lost updates.  This is a problem
of all parallel architectures.  You may loose an update of ma variable,
independent of its location in register or memory. 

More likely you loose an update, if variable is kept in a register
than in memory. Bus snooping would not work for registers outside 
address space ....

>   Of course, the PDP10 not only has indirect addressing, but multi-level
>   indirect addressing, so basically, it's even worse than what I showed:
>   the adds not only have to wait until the ALU has computed the address for
>   the store, but if the indirect-bit is set, must wait until memory is
>   accessed,

Did you mean "[memory] indirect " like : MOVNS @2570, but multilevel
like 68020??? Later is unkown to me, and I guess even unknown to the
reference manual.

You might know, that you may interleaf address generation with 
ALU-operations, if dedicated address generators are available. 
Have a look at all these signal processors and graphic processors.....

But, how many cycles do you need to implement memory indirect addressing,
altogether with necessary register spill ? Translate MOVNS @2570 into 
MIPS assembler....

PDP-10 solves a larger part of a problem in one cycle, though external
clock is running much slower than  at Rxxxx.

best adams

(Dislaimer: How about boosting MFlops instead of MIPS, reminding the 
old AMD 29C235 /  AMD29C237 cycle time 100-140 ns, one floating point 
multiply per cycle ... ;-> )