Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!dciem!nrcaer!cognos!jimp
From: jimp@cognos.uucp (Jim Patterson)
Newsgroups: comp.lang.c
Subject: Re: 16x16 = 32
Message-ID: <1596@aldebaran.UUCP>
Date: Mon, 19-Oct-87 10:11:54 EDT
Article-I.D.: aldebara.1596
Posted: Mon Oct 19 10:11:54 1987
Date-Received: Wed, 21-Oct-87 01:48:02 EDT
References: <143@kesmai.COM>
Reply-To: jimp@aldebaran.UUCP (Jim Patterson)
Organization: Cognos Inc., Ottawa, Canada
Lines: 51

In article <143@kesmai.COM> dca@kesmai.COM (David C. Albrecht) writes:
>Okay, first off I am quite well acquainted 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).

>  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.

I think your logic is correct, and consistent with the ANSI C draft. A
compiler implementer could treat the 16x16 multiply operation as a
special case, and skip the sign-extend.  This is so because if the
multiply result fits in 16 bits, then the sign extend is unnecessary
(being done by the multiply instruction).  If it doesn't fit within 16
bits, then this constitutes an exception and the behavior is UNDEFINED
according to the ANSI draft (section 3.3 Expressions). The definition
of undefined behavior (section 1.6 definitions) states that
"Permissible undefined behavior ranges from ignoring the situation
... , to behaving ... in a documented manner characteristic of the
environment ... to terminating ..." (my paraphrasing). By this
definition, it is perfectly valid to implement the 16-bit multiply
optimization and document that 16-bit multiply's, extended to long,
will properly represent the 32-bit result. This fits with the note
"behaving in a documented manner".

Neither of these points is to say that compilers must make such
optimizations (I think you agree based on your earlier comments).  It
is only to say that a compiler implementor is allowed to make these
optimizations. For this reason, relying on a compiler to deal with the
16-bit multiply in this fashion is non-portable, as you have found
out. Given that compiler writers first need to be concerned with
implementing the semantics correctly before they can spend much
time on optimizations in the code generator, it isn't surprising that
many 16 bit compilers don't do this optimization. 
-- 
Jim Patterson                              Cognos Incorporated
UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707    
PHONE:(613)738-1440                        3755 Riverside Drive
                                           Ottawa, Ont  K1G 3Z4