Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: A simple question on RISC
Message-ID: <7723@aw.sei.cmu.edu>
Date: 16 Nov 88 13:19:35 GMT
References: <6544@xanth.cs.odu.edu> <75577@sun.uucp> <1618@imagine.PAWL.RPI.EDU> <419@augean.OZ> <392@ksr.UUCP>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 44

In article <392@ksr.UUCP> richt@ksr.UUCP (Rich Title) writes:

>When I was at DEC, I remember one of the software guys asking one
>of the hardware guys essentially this question: why, on the VAX 780,
>are the add-compare-branch compound instructions slower than doing
>separate add, compare, and branch instructions? The answer had to
>do with exceptions and restartability. E.g., if the add-compare-branch
>gets a memory fault on the compare step, it has to be restartable,
>which means the result of the add cannot yet have been written. I.e.,
>the add-compare-branch cannot be implemented straightforwardly by 
>doing an add, compare, and branch; but instead it needs to go about
>its operations in an unnatural order and save enough state as it
>goes so it can always back out if it gets an exception.

[ The instruction is

	ACB limit.rx add.rx index.mx displ.bw
]

I don't believe this.  First, the instruction cannot get a memory
fault after the add step, since the address of the index operand is the
last one to be evaluated.

Secondly, the instruction is not restartable.  For example, an overflow
during the add step will still cause the index to be overwritten, a
junk compare to be performed, and a synchronous trap to be taken with
the value of PC unpredictable.  Only a reserved operand fault leaves
the machine in a known state.

As an aside, the instruction doesn't even work.  It implements an add,
compare and branch at the bottom of the loop.  The only language that
defines a FOR loop that is always executed at least once is Fortran,
and it requires the sign of the step to be known at compile time.  For
all other languages, you have to hand code a compare at the top of the
loop anyway, so it's pretty pointless to code it again at the bottom.
(Well, actually you put the compare at the bottom and have an initial
branch to it, but you see what I mean.)  In other words, there is no
programming language construct to which this instruction corresponds.

It also implements in hardware that famous Pascal bug: an iteration
whose termination value is an extremum of the integer range fails.

Lest this post fall into the hands of young persons, I shall not mention
the floating-point form of the instruction.