From: mash@mash.wpd.sgi.com (John R. Mashey)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 26 Sep 92 20:44:30 GMT
Organization: Silicon Graphics, Inc.

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, 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 particular, a lot of what would have been indirect references
on some machines evaporated when going to typical RISCs.
For example, to pick a common example of using a 1-level indirect
scheme (as in VAX, for example), one would compile a call by reference
into passing a pointer on the stack.  To get the value, one would use
indirect reference, i.e.:
	LOAD	R1,@N(SP)	(or something like that)
and later, when you need it again:
	LOAD	R2,@N(SP)	(or something like that)
Now, a smart compiler may decide to grab the variable into memory once,
so that the second LOAD disappears, or it may at least decide that the
pointer to the data is needed, and worth keeping, os that it can once say:
	LOAD	R3,N(SP)	get the pointer off the stack
and then later use
	LOAD	R1,(R3)		which is faster than LOAD R1,@N(SP)

Of course, in most RISC schemes, you have more registers, and the
compilers
try hard to pass arguments in registers, with the typical result that
the pointer to the needed variable was already *in* R3, thus
lessening the usefulness of the indirect addressing.

 
|> 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 :-)

Seriously, though, most of this discussion is a moot point:
1) At one time or another, many computer architectures included
indirect-addressing, hence computer designers are quite familiar with it.

2) With the sole exception of the 68000->68020 transition, I cannot think
of a major computer architecture done in the last 10 years that
included indirect addressing, and none at all that permitted multi-level
indirect addressing (or the PDP-10 sort).  I.e., CPU designers
have voted this feature down....  no matter how nice it may seem.


-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA
94043