A89: Re: What the heck is wrong with this?!

[Prev][Next][Index][Thread]

A89: Re: What the heck is wrong with this?!


 > l've tried those, and it gives errors about parse errors after int, etc.  How 
 > can l get an int value after multiplying an int var by a float?  or even a 
 > float var by a float, which doesn't work either.

You *can't* do it. You can not multiply floats or doubles with
anything. The 68k w/o the coprocessor does not have a float multiply 
instruction. Therefore, if your program needs a float multiply (or any 
other operation), the compiler invokes a library function (i.e. it
compiles a call to that function into your code).
This library is called the 'C support library' and should contain
functions that realize the operations needed by the C language
primitives but not supported by the processor's instruction set.

For example, if you do a long * long = long operation, gcc must invoke 
a library function for that because the vanilla 68k can not multiply
32-bit numbers, only 16-bit ones. 

Now the problem with the float stuff is, that there's only one such
library around. It does not support doubles (well, treats them as
floats), it is written in C (thus it is far less efficient than a
hand-optimised assembly could be). However, if you are desperate to
use floats, that might be useful. It comes w/ the gcc sources.

On the other hand, if you have to multiply an integer with a float
*constant*, then there are alternatives:

int x, y;

   x = 3.8 * y;
   
That would require a float operation, while doing this

   x = ( 38 * y ) / 10;
   
would not. Note that you must use the parens, for 38 * ( y / 10 ) is
not what you want: if y is 1, then y / 10 is 0 (integer division) thus 
your result is 0. Since the compiler without parens could evaluate
the subexpressions any way it pleases, you must force the order
explicitly by the usage of them.

If you are a speed freak and a little loss of precision would not
be a problem, then you would do something like this:

   x = ( 3891 * y ) >> 10;
   
which, of course, is equivalent to 3.8035191 * y, and error of 0.09 %
and you save the fairly expensive integer division.

In general, if you can get away with fixed-point arithmetics instead
of floats, you are almost always better off. The only drawback is,
that since C does not support fixed point as built-in data type, you
yourself have to synthetise all primitives and take care of all the
normalisation etc.

Best Regards,

Zoltan
References: