Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!mhuxt!mhuxm!mhuxo!ulysses!allegra!alice!ark
From: ark@alice.UUCP
Newsgroups: comp.lang.c,comp.misc
Subject: Re: 32bit = 16bit x 16bit (Really: Compiler deficiencies)
Message-ID: <7418@alice.UUCP>
Date: Thu, 29-Oct-87 16:07:22 EST
Article-I.D.: alice.7418
Posted: Thu Oct 29 16:07:22 1987
Date-Received: Sun, 1-Nov-87 05:35:09 EST
References: <141@kesmai.COM> 7349@alice.UUCP <146MAXHAM@RICE> <776@custom.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 29
Xref: utgpu comp.lang.c:4971 comp.misc:1381

In article <776@custom.UUCP>, boykin@custom.UUCP writes:
> I don't believe this is a problem with the language, but with
> the compiler.  The compiler should be able to optimize to use
> the instructions available to it.  On most C compilers I've
> seen the following will use instructions like the 68000's MULS
> rather than a subroutine call:
  
> 	long	x;		/* 32-bit value	*/
> 	short	y, z;		/* 16-bit value	*/
  
> 	x = y * z;
  
> While this is implementation dependent, it has worked on most
> C compilers I've seen.  Don't blame the language when the
> compiler (optimizer) is at fault.


On a machine with a 16-bit multiply that gives a 16-bit product,
the compiler is completely justified in using that multiply
and then sign-extending the result to 32 bits.  If you have any
thoughts about portability, you should be writing:

	x = (long)y * (long)z;

And yes, I have seen compilers that will translate that to
a single 16x16=32 multiply.