Multiplying two shorts...

[Herman Rubin]

In article <8101 at alice.UUCP>, ark at alice.UUCP writes:
> In article <948 at srs.UUCP>, dan at srs.UUCP writes:
> 
> > Sun's compilers seem to let you multiply two short integers and get all 
> > 32 product bits, if you code like this:
> >     register short x, y;
> >     register long z;
> 
> >     z = x * y;
> 
> > If the compiler is nice, it emits the correct (16x16=32) multiply instruction.
> > If it isn't nice, it emits the slower (32x32=64) instruction and throws
> > away the top 32 bits.
> 
> > Do most modern compilers perform this optimization?
> > It would be nice to be able to depend on it.
> 
> The effect of the statment above is undefined.
> 
> To get the right answer, you should write
> 
> 	z = (long) x * (long) y;
> 
> Actually, it is enough to cast only one of x and y, so you
> can say
> 
> 	z = (long) x * y;
> 
> but that may be a little confusing.  If your compiler is clever,
> it will realize that it can use the multiply instruction that
> takes short operands into a long result.  If it's not clever,
> you'll still get the right answer.
> 
> Wouldn't you rather risk having your program get the right answer
> slowly rather than risk getting the wrong answer outright?

It is a rare compiler which can recognize that it can ignore type
casting and use a different instruction to get a result.  It is hard
enough to get a compiler to do the obvious.  I find the attitude of
"ark" execrable; this is what has produced our current bad software
and also bad hardware.  Unfortunately, hardware manufacturers do not
realize that people like dan and me know how to use machine instructions
which the language gurus have not seen fit to put into the language,
and to recognize that hardware constructs beyond the scope of the
language can be useful.

We need the type of operator overloading which dan is using.  If the
hardware supports 16 x 16 -> 32 multiplication, it should be done with
that instruction.  On the VAX or PYRAMID or CRAY or CYBER, it can only
be done the way "ark" suggests.  I suggest that the compiler implementer
be required to enable dan to put in his improvement even if the implementer
had not thought of it.

Another example of the neglect is the problem of the power operator.  This
has been discussed in this group, and I will not elaborate.  However, the
minimalists (do it using the current C tools) do not even meet "ark"s
requirement of getting the correct answer slowly.

How about the use of long long?  I needed to compute a function which
required unpacking a double into an exponent field and a mantissa (long long),
doing integer and boolean arithmetic starting with the mantissa, etc.,
and putting things together to get a double result.  Needless to say, I
had to do this in assembler.  BTW, my biggest difficulty was the fact that
hex was not the default.

How about multiplying two longs to get a long long, both signed and unsigned?
Few machines have the unsigned version, cheap in hardware but expensive in
software.  And how about division?  One much needed instruction, cheap in
hardware and expensive in software, is dividing a float (of any length) by
a float and getting an integer quotient and a floating remainder.  And there
was the long discussion in this group about how integer/integer should be
treated if they are not positive.

We need software which allows those who understand their machine to exploit
the capabilities.  We need hardware which provides the capabilities.  We do
not need to be told that "this is not portable; you must not do it."
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)