Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!necntc!custom!boykin
From: boykin@custom.UUCP
Newsgroups: comp.lang.c,comp.misc
Subject: Re: 32bit = 16bit x 16bit (Really: Compiler deficiencies)
Message-ID: <776@custom.UUCP>
Date: Wed, 28-Oct-87 14:52:25 EST
Article-I.D.: custom.776
Posted: Wed Oct 28 14:52:25 1987
Date-Received: Sat, 31-Oct-87 08:40:26 EST
References: <141@kesmai.COM> 7349@alice.UUCP <146MAXHAM@RICE> <593@l.cc.purdue.edu>
Organization: Custom Software Systems; Natick, MA
Lines: 29
Xref: utgpu comp.lang.c:4940 comp.misc:1371

> In article <146MAXHAM@RICE>, MAXHAM@RICE.BITNET (Mark Maxham) writes:
> > But the 68000 MULS and MULU commands multiply two sixteen bit words
> > into a 32 bit longword.  Thus they are defined.  Is the question
> > how C translates from multiplicitive expressions into actual machine
> > instructions?
> 
> A general problem with HLL's is that they do not have the necessary
> flexibility to handle situations like this.  I do not know of any language
> which has in its operation list an operation to multiply two 16 bit object
> and get a 32 bit object.

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

Joe Boykin
...necntc!custom!boykin