:: Hi Frank,
::
:: > ::
:: > :: 1) one type is long double, the other will be casted to long double
:: > :: 2) one type is double, the other will be casted to double
:: > :: 3) one type is float, the other will be casted to float
:: > Fully wrong.
:: > The rest I haven't checked.
:: >
::
:: Does it mean that you've tested the above?
:: If yes - how did you test this to be wrong? what is the compiler,
:: optimization options?
::
First
a) char, signed char, short => int
b) unsigned char, unsigned short => unsigned int
c) float => double
Second
d) still different types?
ldouble double ulong long uint int
ldouble ldouble ldouble ldouble ldouble ldouble ldouble
double ldouble double double double double double
ulong ldouble double ulong ulong ulong ulong
long ldouble double ulong long ulong long
uint ldouble double ulong ulong uint uint
int ldouble double ulong long uint int
float <op> float gives a double.
Note that a lot of compilers modifying rule c) and d) using instead:
c') float, double => long double
d') still different types?
ldouble double ulong long uint int
ldouble ldouble ldouble ldouble ldouble ldouble ldouble
double ldouble ldouble ldouble ldouble ldouble ldouble
ulong ldouble ldouble ulong ulong ulong ulong
long ldouble ldouble ulong long ulong long
uint ldouble ldouble ulong ulong uint uint
int ldouble ldouble ulong long uint int
On machines computing with 80 bit-IEEE floats rounding costs huge amounts of
CPU time. But ANSI C forces this silly rounding on standard.
>From the view of code optimization, C was a great milestone in the 70's, in
the 2000's it is a millstone round the compiler builder's neck.
Problems:
* nearly no infrastructure
* problems with 64 bit (problems with pointer <=> &array[index]
transformation)
* typical C structures are not very good for super scalar machines
* pointer aliases avoid a lot of deep optimization on super scalar
machines
* low level standardization (nearly no demands on the hardware, so
also 13 bit CPUs with 1's complement and really strange arithmetic
(a+b-b!=a on overrun) can be supported).
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721 home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
