Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sunybcs!boulder!hao!oddjob!mimsy!umd5!uvaarpa!virginia!kesmai!dca
From: dca@kesmai.COM (David C. Albrecht)
Newsgroups: comp.lang.c
Subject: 16x16 = 32
Message-ID: <143@kesmai.COM>
Date: Wed, 14-Oct-87 14:00:22 EDT
Article-I.D.: kesmai.143
Posted: Wed Oct 14 14:00:22 1987
Date-Received: Sat, 17-Oct-87 10:28:46 EDT
Organization: Kesmai Corporation, Charlottesville, VA
Lines: 73

Okay,
It seems quite apparent that I wasn't clear enough in my original posting
because most of the responses I have gotten via mail or on the net don't
really address the point I trying to get commentary on.

Okay, first off I am quite well aquainted with the C typing rules.
Second, my point was one of OPTIMIZATION not typing.  There is
no question that the fully unoptimized expression (where ints are 16 bits
and longs are 32 bits).

   ((long) (x * y)) where x and y are ints says:

   get int x
   get int y
   multiply using operation appropriate for 16 bit ints
   convert result to long (32 bits).

   This is obvious.

In no way was I trying to say that the code produced by Mark Williams
for this operation is incorrect as it most certainly is.  I was addressing
one of the other ways to skin a cat.

In virtually every machine I know of the multiplies produce a
double width result (PDP-11, VAX, 68000, 8?86, ad nauseum).  Extending
the result of a multiply to long is a NEEDLESS operation.  Eliminating
NEEDLESS operations is what optimization is all about.  The whole point
of my posting was not that the code they generated was incorrect, it most
certainly was correct code.  The point was that they claimed that
eliminating the extend to long was INCORRECT and would cause their compiler
to fail acceptance testing.  That is what I think is BOGUS.  What possible
point could there be to testing for garbage out from a multiply when the
numbers coming in cause a result too large to fit in the same type.
I can't think of any instance when the full 32bit accuracy wouldn't
be preferable.

The only response to this that I thought even came close to addressing the
point was that someone made the comment that some compilers produce code
that traps on results longer than 16 bits from a 16x16 multiply.  If
Mark Williams did this in their code then I would agree that is more
correct result and it would be preferable to just taking the full 32
bit accuracy.
But they don't and it ain't.

You have to realise that my application is a flight simulator and it
uses a large number of multiplies.  It is hardly a negligable affect
as it gives roughly a 30% speedup on the Macintosh to use MULS instead
of the software simulated 32 bit multiply.  Getting the compiler to
generate the MULS is preferable because it makes better use of registers
and doesn't cause the call overhead.  Barring that, there is of course
always assembly code.  Most likely I will use a macro to do the multiplies
that will generate either a procedure call or my ((long) (x*y)) construct.
If the compiler has an intelligent optimizer I will use it, if it doesn't
I can always fall back to the assembler call.

I think it highly unlikely that ((long) x) * y would give me a better
result as then the compiler has to realise that an expression now cast
as long was previously short so that a 16x16 multiply is
perfectly viable.  I would speculate that this is easily as complicated
if not more than realising that the result of a MULS operation doesn't
require an extend to long.  Granted, it expresses the result wanted
better but in reality I think it highly doubtful you could find a compiler
for the Amiga, ST, or Mac that would generate anything but 32x32 operations
from the expression.

Finally.  Again, I'm not debating that the code MW generates is correct. I'm
debating their assertion that code that doesn't throw away the high
bits in the result of a 16x16 multiply when extending to 32 bits
is incorrect and would fail acceptance testing.  I was trying to
see if anyone knew of an acceptance test or a VALID reason why
not sign extending over the high bits is an INVALID result.

David Albrecht