🚀 go-pugleaf

>     Q3: All of the discussion so far has been about delayed LOADS. What about
> 	delayed STORES, where you can't touch the data to be stored for a
> 	few instructions after the store instruction? Does anybody try to
> 	save a latch?

	This isn't a good idea.  While you can easily determine when
	two registers are identical, it is hard to determine at
	compile-time, that two address expressions are potentially
	conflicting. Thus it is hard to effectively reorganize code
	to avoid conflicts over delayed stores.

> I wonder if the idea of an architectural family is dead? If not, how do you
> reconcile it with delayed loads/branches? Start off with the longest possible
> delay factor, and reduce it as machines get faster?

	In general, you'd take one or two delay slots, which is all
	you can usually fill in software and make them architectural.
	If the machine you are building has more than the architecturally
	defined number of delay slots, it better interlock.
	This tradeoff permits building a fast, simple, machine now,
	and a faster, more complicated machine later.
	However, even the more complicated machine has fewer, less
	stressful interlock cases than a machine without delay slots.

> Do machines that have no interlocks on their delayed loads have strict
> or relaxed semantics? Ie. in the code sequence
> 
> 	ADD r1 += r0
> 	LOAD r0 := [memaddr]
> 	-- delay slot
> 
> do MIPS et cie. permit the rearrangement
> 
> 	LOAD r0 := [memaddr]
> 	ADD r1 := r0
> 
> where the value put in r1 is not [memaddr], but whatever was there before?


	This is explicitly not permitted in MIPS or in any other RISC
	machine I am aware of. The reason is that the occurance of
	an interrupt between the two instructions will cause it to fail.

> There is a difference between saying "the result is not available for N
> cycles" and saying "the destination value is not changed for M cycles".

-- 

Craig Hansen			|	 "Evahthun' tastes
MIPS Computer Systems		|	 bettah when it
...decwrl!mips!hansen		|	 sits on a RISC"