Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sdcsvax!ucsdhub!jack!man!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.lang.c
Subject: Re: 16x16 = 32
Message-ID: <132@nusdhub.UUCP>
Date: Fri, 16-Oct-87 13:02:27 EDT
Article-I.D.: nusdhub.132
Posted: Fri Oct 16 13:02:27 1987
Date-Received: Sun, 18-Oct-87 00:06:49 EDT
References: <143@kesmai.COM>
Organization: National University, San Diego
Lines: 45
Summary: 8FFFH * (int > 2)

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

This is fairly easy:

	1)  First, we must assume the compiler is designed to work
"general case" solutions, which most are.
	2)  Take the largest possible positive interger, or something
close to it.
	3)  Multiply this interger by something like 4 or 12.  Two
(2) is questionable, as the result would probably still fit in the
interger space.

	If you do not do sign extend durring multiply, i.e. land
the 16x16 value in a 32, the sign and value of the result is
anybodys guess.  Without the extra instructions, the sign is
whatever happened to land in the high order bit. [see ROL]
	The definition of "*" in C where:
int	x, y, z;
...
	z = x * y;

to the best of my knowlege is 16x16 placed in (sign+least-sig-15-bits)
with overflow checking if enabled.  If you used a 16 bit sig primitive
you would either need a chip that supports sign preservation in
all cases, or live with absolutly-no-idea-of-what-really-happend-on-
overflow situation, with no way to recover.
	If you use the "tightened definition" you would need a
totally different aproach dependant on each app subsection.  i.e.
doing a 64bit statistical myltiply in 8 bit segments to preserve
accuracy, while useing a tight 16bit for all small values of x, or
two+ 8bits for larger...etc.

SUMMARY:  You are a victem of best-aproach-for-general-case combined
	with a this-is-the-chip-you-get-so-tough-cookies arcitecture.
	If you *KNOW* the values are going to *ALWAYS* fit in
	15bits+sign then turn off overflow checking, or do it in
	some custom assembly.

Rob.