[comp.arch] RISCy question

jjb@crg8.sqnt.com (Jeff Berkowitz) (04/10/90)

In article <20880@eerie.acsu.Buffalo.EDU> axaris@acsu.Buffalo.EDU (vassilios e axaris) writes:
>Hello everyone,
>
>Suppose we have a pipelined, delayed branch, RISC processor, and the
>instruction stream contains a series of compare-and-branch instructions...
>However, something tells me that another possibility is to evaluate the
>condition of the next branch instruction instead of the NOP which will
>lead to the following cases: the first branch is taken so no big deal
>the condition evaluation is discarded, or the first branch is not taken
>and the address computation in the second branch proceeds normally. Is
>this feasible...?

A now-dead minisupercomputer company implemented a design similar to this.
The machine had two delay slots, referred to as "trailers".   If a branch
was taken, and either of the two trailers was also a branch, the "trailing"
branch was executed as a noop by the hardware.  This allowed you to write
code sequences like

			bgt foo
			blt bar
			br  looptop

With the expected consequences.  (Does this look like something a compiler
would generate to you?  It doesn't look that way to me either :-).  Speaking
from experience, I don't believe this branch logic was a very good idea.
First, you have to handle calls.  You want to be able to write

			jsr foo
			bcs err

and execute the branch WHEN YOU RETURN (else, why bother with the whole mess?)
but you also want to use the delay slots in the RISCy way when possible:

			jsr foo
			push arg2	# push args in the delay slots
			push arg1
	returnhere:

This means the the hardware has to determine and save the "appropriate"
return address: the first trailer (if it's a branch), else the second trailer,
(if *it's* a branch), else the third instruction following the jsr.  On the
now-dead machine, the hardware "figured this out" at some high cost, all
just to save a couple of noops in the first example.

There are other problems.  Breakpoint debugging, for example.  You now need
breakpoint instructions that "look like" branches, and others that don't, in
order to preserve the semantics of the program when breakpoints are set in
trailers.

The now-dead computer was built by Culler Scientific.
--
Jeff Berkowitz N6QOM			uunet!sequent!jjb
Sequent Computer Systems		Custom Systems Group