ok@quintus (07/28/88)
I've had a helpful response about multiply-step instructions from Tim Olson of Advanced Micro Devices. Apparently there are at least two "multiply step" definitions around: the Am29000 uses one, the RT PC uses another. Olson's suggestion was to obtain the full 64-bit product and then check the high word. That's the obvious method, of course, and it has the advantage that one can pick the code up out of the manufacturer's manual without understanding how it works, and just add some stuff at the end. I was hoping for something which could use the fact that I am not interested in the result if it overflows to stop in fewer steps (like the way the algorithm in the SPARC manual checks for small operands). I have had mail from several people who have misunderstood my other question, about doing a 32x32->32 multiplication on the MC88000. My question is about that specific processor. The relevant characteristics of the machine are - there is one integer multiply instruction, which delivers a 32-bit result (the bottom 32 bits of the 64-bit product) - that instruction doesn't set the condition codes, because there aren't any, and it doesn't indicate overflow any other way either - there are no 64-bit shifts (though an addu.co followed by an addu.ci can be used) What I want to do is compute the product of two 32-bit registers when the result will fit in a 32-bit register, and execute my own handler code when it won't. Obviously, I can do this with a sequence of add, ext, and bb instructions. Is there a better way?
ok@quintus (07/29/88)
The best answer I have received to my question came from Marv Rubinstein,
who pointed out that
To determine whether x*y would overflow:
a = abs(x)
b = abs(y)
if (a != 0 && MAXINT/a < b) report overflow
will do the job, and one can then use the multiply instruction provided.
In the best RISC tradition, if one of the operands is a constant, the
division can be done by the compiler, reducing to
if (y < -lower || y > upper) report_overflow.
Since quite a few integer multiplications are by constants (Does anyone have
measurements on this? There should be some for MESA.) this is a reasonable
tradeoff, provided you assume that the common case should be to deliver
incorrect results without warning. At least one Pascal compiler I use
generates code which will report an overflow if you do
var x: 0..127; ... x := 100; x := x*x;
but will not report the overflow in
var x: integer; ... x := 1000000000; x := x*x;
What a botch. {The SunOS 3.2 pascal compiler catches both. Thanks, SMI.}
Richard (A bear of very little brain) O'Keefe.