On Thu, Mar 08, 2001 at 11:31:06AM -0800, Hong Zhang wrote:
> > Looks like they do operations with 16-bit integers. I'd as soon go with
> > 32-bit ones--wastes a little space, but should be faster. (Except where we
> > should shift to 64-bit words)
>
> Using 32/31-bit requires general support of 64-bit arithmetics, for shift
> and multiply. Without it, we have to use some extremely complicated
> code to deal with multiply/division/shift, and we will lose the speed.
unsigned 64 multiply of two unsigned 32 bit quantities is not hard if you
have a 32 bit multiply instruction. (you use 4, to evaluate the partial
products of splitting the operands into low and high 16 bits)
I don't know how to do shift or divide. I don't see shift as hard.
> Detecting overflow for 2's complement signed integer addtion/substract will
> be easy:
> c = a + b;
> if (((c ^ a) & (c ^ b)) < 0) {
> /* overflow */
> }
> The code is super-scalar and need only one branch. It is also fast to
> generate boolean flag without using branch:
> int overflow = ((unsigned) ((c ^ a) & (c ^ b))) >> 31;
Does the above work on 64 bit Irix?
The overflow in c = a + b is undefined behaviour in C. Irix gave the
bit value that was expected, but didn't execute subsequence > conditions
in the way that would be expected by an assembly programmer.
[However, I like the elegant sign bit testing logic you give.]
Nicholas Clark
