Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

Max Hailperin wrote:
> An even bigger problem, in my experience is that C/C++ are built on
> the strange notion that when you operate on two n-bit numbers, you get
> an n-bit result, even when multiplying. This doesn't make a whole lot
> of mathematical sense, and moreover the processor architects have in
> my experience always gotten it right -- they have instructions for
> multplying two 16-bit numbers and getting a 32-bit product, or two
> 32-bit numbers and getting a 64-bit product, or whatever. The C
> compiler "hides" these from you, which can cause a major slowdown. In
> multiple-precision multiplication, which is generally implemented
> roughly as the normal grammar-school multiplication algorithm but with
> each "digit" being n bits wide (i.e., radix 2^n), you typically wind
> up with having to use half as large a value of n, hence twice as many
> "digits" in each of the multiplier and multiplicand, hence a four-fold
> slowdown (2 squared).


This is not necessarily the case if you have an optimizing
compiler. If you want to perform an int by int multiplication to a
long result you may write:


la = (long)ia * ib;


If you don't write the (long) cast the compiler is forced to do an int
evaluation of the right part, so you will certainly lose your high
part. In a straightforward approach the compiler will create internal
casts to long on the integer operands, calculate the result in long
precision and assign it. An optimizing compiler however will recognize
the special case of long = int * int, forget about the casts and
produce the result just like you want it to. I will not go into the
issue of standardisation here, but you can see that it not always
creates an inevitable burden in the end result.


Ciao,


Robert Jan Ridder.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.