Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!tektronix!oresoft!rick
From: rick@oresoft.UUCP (Rick Lahrson)
Newsgroups: comp.lang.c,comp.sys.atari.st,comp.sys.amiga
Subject: Re: 32bit = 16bit x 16bit
Message-ID: <82@oresoft.UUCP>
Date: Tue, 13-Oct-87 00:38:56 EDT
Article-I.D.: oresoft.82
Posted: Tue Oct 13 00:38:56 1987
Date-Received: Wed, 14-Oct-87 04:54:46 EDT
References: <141@kesmai.COM>
Reply-To: rick@oresoft.UUCP (Rick Lahrson)
Organization: Oregon Software, Portland OR
Lines: 53
Summary: Looks like a "fielder's choice"
Xref: mnetor comp.lang.c:4857 comp.sys.atari.st:5648 comp.sys.amiga:9325

In article <141@kesmai.COM> dca@kesmai.COM (David C. Albrecht) writes:
>                      ... 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.

I think it's more of an implementation decision.  C tries to fill two
sometimes conflicting niches.  On the one hand, it lets the programmer
get down to the nitty gritty, by making the machine very accessible.
On the other hand, it needs to be as portable as possible.  But porta-
bility for arithmetic requires that you feign ignorance of the actual
capabilities of the machine you're on, and use only capabilities that
all machines/implementations can be expected to have.

For example, if you write:
	a = ((long) (b * c)) / d;
where a, b, c, and d are ints, on a 68K you might expect arithmetically
correct answers for any values of b and c.  But what if an int were 32
bits?  In that case, a long and an int would be the same size, the
multiplication would not be carried to double precision, and some values
of b and c would cause an overflow.  So for portability reasons, the
"common denomimator" among all implementations on all machines seems to
be that the result of a multiplication (1) will contain no fewer bits than
there are in the larger factor (let's hope!); and (2) will contain no
more bits than there are in the larger factor (because many machines/
implementations simply don't provide that capability).

I don't have a C validation suite to look at, and the above definition
of a likely compromise is just my best guess, but I'll bet the compiler
that holds the precision to the size of the operands is the one that
the validation suite will like.

In my copy of K&R, the referenced phrase on p 184 just happens to be ...
The Bottom Line!  8-)

-- 

Rick Lahrson  ...tektronix!oresoft!rick

Disclaimer:  If I ever speak for anyone but me, I'll warn you in advance.