Xref: utzoo comp.lang.c:11798 comp.arch:6015 Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.c,comp.arch Subject: Re: Multiplying two shorts... Summary: This is why there is slow software and hardware Message-ID: <864@l.cc.purdue.edu> Date: 11 Aug 88 13:35:07 GMT References: <948@srs.UUCP> <8101@alice.UUCP> Organization: Purdue University Statistics Department Lines: 80 In article <8101@alice.UUCP>, ark@alice.UUCP writes: > In article <948@srs.UUCP>, dan@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@l.cc.purdue.edu (Internet, bitnet, UUCP)