From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Curtin University of Technology
Date: Wed, 30 Sep 1992 16:56:40 GMT

In article <1992Sep26.204430.29763@odin.corp.sgi.com>, mash@mash.wpd.sgi.com (John R. Mashey) writes:
> In article
> <ADAMS.92Sep26174101@PDV2.pdv3.fmr.maschinenbau.th-darmstadt.de>,
> adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
> 
> |> 1) I was not referring to one of the earliest or cheapest PDP-10s, but
> |> to one of the faster CPUs, KL10.
> Ah, yes; thanx for posting more detail.
> ....
> |> >   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 ...
> That (or at least not the way most people think of it) doesn't do it;
> scoreboards usually let an operation delay until its operands are ready,
> as outputs of earlier loads or ALU operations; the peculiarity of
> this scheme is that you have to delay register reads until you're
> sure that a preceding store doesn't modify them, which is what the
> following was trying to say:
> 
> |> >	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 ....
> I don't understand this ... if you have an architectural definition
> that says:
> 	store	X,Y
> 	add	R1,Z
> and Y happens to evaluate to the address of R1, and the programmer
> should expect that the add dlivers the result of X+Z,
> THEN: you cannot expect to implement a new family member of that
> architecture and lose updates .... that's just unacceptable, and
> that kind of restriction has plagued many CPU designers as
> designs evolved from simple sequential ones towards more
> parallel ones.  The sympton usually manifests itself as requiring
> a bunch of additional checking logic to watch out for events that
> are actually infrequent in order to provide binary compatibility.
>  
> |> >   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.
> 68020s aren't multilevel, at least not in the way that PDP10s & (I think)
> UNIVAC 1108s, etc.  I quote from "Introduction to DECsystem-10 Assembler
> Language Programming", Michael Singer, Wiley, 1978, p47:
> 	"Effective Address Calculation
> 	Prefixing the memory reference with the symbol @ causes the
> 	assembler to set bit 13 to 1 in the code word representing an
> 	instruction.  Bit 13 is called the *indirect bit*.
> 	...The given memory reference is modified by indexing, if any,
> 	to get a new address.  If bit 13 is set to 0, this completes
> 	the effective address calculation.
> 	If, however, bit 13 has a 1, then the address so far is not the
> 	effective address.  Instead, the processor takes the contents of
> 	that address, and performs the whole effective address calculation
> 	over again on them ... So if the indirect bit in that address
> 	contains a 1, yet another level of address retrieval is demanded,
> 	and so on.  The process continues until a word is retrieved with
> 	a 0 in bit 13.  Then *its* right half, modified by the contents
> 	of the accumulator given by the contents (unless zero) of *its*
> 	bit 14 through 17, forms the effective address for the *original*
> 	instruction.  Remember that the entire effective address calculation
> 	is completed before anything else is done in the performance of
> 	an instruction.  COnsider the perverse program
> 		START:	JUMP	@LAB
> 		LAB:	JRST	@START
> 			EXIT
> 			END	START
> 	which will tie up computer time endlessly without result. You run
> 	this program at your own peril!..."  FOR SURE.

But not in the way most people think... Rule 0 for the 6/10/20... Jump doesn't
jump and Skip doesn't skip.

try		Start:	JumpA	@Lab
		Lab:	JRst	@Start
		;       Exit		not needed!!
			End Start

> 
> |> But, how many cycles do you need to implement memory indirect
> |> addressing,
> |> altogether with necessary register spill ? Translate MOVNS @2570 into 
> |> MIPS assembler....
> This is very difficult to compare directly, although it's a common
> mistake to look at a single instruction and try to figure out the
> equivalent, and then make strong conclusions from the result.

In fact, it is worst than it may at first appear. The above busies ALL registers
and memory, as 1) we don't know where the indirect chain ends, 2) and even if
we allow full knowlege of memory, the chain can include registers as well
as any other memory location ( so we can't overlap stores ) and we can also
read regs as an index register on each cycle ( effective address, that is, not
clock ) plus of course, a register can be the final store destination. Worse,
(PC) can end up being the destination, so we can't even prefetch.

Mind you, for multi dim array referencing, it was hard to beat..

>  
> |> PDP-10 solves a larger part of a problem in one cycle, though external
> |> clock is running much slower than  at Rxxxx.
> You can do anything in one cycle ... if the cycle is long enough :-)
> 
Yep, getting a KL to run at a sustained 4 ins per sec takes LOTS of work!!
THe clock in a KL is 66Mz BTW.

~Paul

Newsgroups: comp.arch