Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!psuvax1!vu-vlsi!cbmvax!higgin
From: higgin@cbmvax.UUCP (Paul Higginbottom SALES)
Newsgroups: comp.lang.c,comp.sys.atari.st,comp.sys.amiga
Subject: Re: 32bit = 16bit x 16bit
Message-ID: <2496@cbmvax.UUCP>
Date: Wed, 14-Oct-87 14:17:08 EDT
Article-I.D.: cbmvax.2496
Posted: Wed Oct 14 14:17:08 1987
Date-Received: Fri, 16-Oct-87 05:39:32 EDT
References: <141@kesmai.COM>
Organization: Commodore Technology, West Chester, PA
Lines: 44
Xref: mnetor comp.lang.c:4912 comp.sys.atari.st:5680 comp.sys.amiga:9415

in article <141@kesmai.COM>, dca@kesmai.COM (David C. Albrecht) says:
> Xref: cbmvax comp.lang.c:4799 comp.sys.atari.st:5522 comp.sys.amiga:9125
> 
> I would be interested in some other people's input on this.
> ...I noticed a good many multiplys were 16x16=32 (which is
> supported in hardware on the 68000) while it was currently using
> 32x32=32 (which is not).  In attempting to get the MULS operation
> I made the variables 16bit in size and coded the expression thusly:
> 
> ((long) (x * y))
> 
> It is a bit greasy but it was the only way I could think of to get
> the proper result.  On the Amiga using Lattice 3.10 it worked ducky.
> Recently we moved the code back to the MAC which is using Counsulair (sp?)
> and that also seems to work.  On the ST using Mark Williams we were not
> so lucky.  They actually explicitly sign extend the result throwing away
> the upper 16bits.  We assumed that they did so because their compiler
> was not smart enough to recognize that it already had a long result which
> it could just use.  After some communication with them they claimed that > the phrase on pg184 in K&R which says that an expression with two ints
> should produce an int (their ints are 16 bits) REQUIRE that they sign
> extend or they will fail some of their commercial customers acceptance
> suites.  Personally I think they are full of it.

Personally (and knowing the guys at MWC), I bet they're right.

Second, your expression '((long) (x * y))' should not do as you say because
the cast is performed AFTER the expression is evaluated, so '(x * y)'
is 16bits x 16bits, which is not supposed to be guaranteed to generate 
32 bits, but instead will generate another int (16 bits), the overflow
having probably been lost, or is at least undefined, and THEN the result
is cast to a long, and to make the sign extension work properly, bit 15
will be extended through bits 16-31.
> 
> Does anyone know of a commercial test suite that checks to make sure that
> y = x * x where x is a 16 bit int and y is long (32 bits)  produces garbage
> instead of the proper result?
		 ^^^^^^

This word is important.  I think the result of an OVERFLOWED 16 bit
quantity is undefined.

> David Albrecht

	Paul Higginbottom