Xref: utzoo comp.lang.c:11911 comp.arch:6106 Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!oddjob!gargoyle!att!alberta!calgary!radford From: radford@calgary.UUCP (Radford Neal) Newsgroups: comp.lang.c,comp.arch Subject: Re: Multiplying two shorts... Summary: C is not an assembly language Message-ID: <1810@vaxb.calgary.UUCP> Date: 13 Aug 88 20:50:57 GMT References: <948@srs.UUCP> <8101@alice.UUCP> <864@l.cc.purdue.edu> Organization: U. of Calgary, Calgary, Ab. Lines: 60 In article <948@srs.UUCP>, dan@srs.UUCP writes: > Sun's compilers seem to let you multiply two short integers and get all > 32 product bits, if you code like this: > register short x, y; > register long z; > > z = x * y; In article <8101@alice.UUCP>, ark@alice.UUCP writes: > The effect of the statment above is undefined. > > To get the right answer, you should write > > z = (long) x * (long) y; > ... > Wouldn't you rather risk having your program get the right answer > slowly rather than risk getting the wrong answer outright? In article <864@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: > It is a rare compiler which can recognize that it can ignore type > casting and use a different instruction to get a result. It is hard > enough to get a compiler to do the obvious. I find the attitude of > "ark" execrable... Very puzzling. Why is informing people that their programs may break when moved to another compiler such a crime? If you want to argue that the C language _ought_ to be defined so that the product of two shorts is computed to long precision, that's another issue, though some might object to the code this would imply for: int a, b, c, d; a = (a*b*c*d) % 10; By your logic, the intermediate result (a*b*c*d) should be computed to 128-bit precision, assuming int's are 32 bits. > We need software which allows those who understand their machine to exploit > the capabilities. We already have such software. It's called an assembler. > We need hardware which provides the capabilities... If you're willing to pay enough, I'm sure someone will oblige. Actually, your best bet in this case would seem to be RISC machines with software multiplication and division, then you can do whatever you want. > We do not need to be told that "this is not portable; you must not do it." Any professional programmer ought to realize when a programming technique is not portable. Whether they choose to do it anyway is another matter. In fact, "ark" was arguing that including casts got you both - a portable program, and a fast one if the compiler is smart. Contorting your program to get fast code out of dumb compilers is a technique of limited usefullness. Radford Neal