internals of typecasting

[Niklaus]

Hi,
I would like to know more about casts.What exactly happens
when casts are applied to a variable.I know that if an
object of type int is applied an cast of float the result
would be of type float.

1)
What i would like to know is the about the
internals when a cast is applied ? Say we have

int i = 3;
double j;
j = (double) i;

What happens in the above statement ? Can someone
explain me at bit level or a considerable explantion ?


2)
Also i would like to know what happens say

i = (int)j;

Again an explanation at the bit level would be very helpful.
If we have

3)

float f = 4.3;
int i;
i = (int) f;

What happens here ? How does the truncation take place ?
4)
Is it similar to how int got promoted to double in the question 2.
5)
How are side effects defined ? When do
i say typecasting is an side effect ?

6)
Is truncation a side effect of type casting or not ?

Nik
-

 

[Arthur J. O'Dwyer]

Hi,
I would like to know more about casts.What exactly happens
when casts are applied to a variable.I know that if an
object of type int is applied an cast of float the result
would be of type float.

A better phrasing: "If a value of type int is cast to float,
the resulting value is of type float." Type-casting has nothing
to do with /objects/, which in C are the actual locations where
values can be stored. 42 is not an object; yet (float)42 is still
a valid C expression.

1)
What i would like to know is the about the
internals when a cast is applied ? Say we have

int i = 3;
double j;
j = (double) i;

What happens in the above statement ? Can someone
explain me at bit level or a considerable explantion ?

On the average Wintel machine, this will retrieve the bits stored
in i (say, 0x0300), and pass them through a special function designed
specifically to convert "int bits" to "float bits." On the x86 line
of processors, the FPU has a special machine instruction that will do
this conversion. The result will be a bunch of bits that represent
a float value (say, 0x42DE; I don't know the real internals here).
These "float bits" get stored into the object denoted by j.

2)
Also i would like to know what happens say

i = (int)j;

Same thing in reverse. Again, the x86 processors have a special
floating-point-unit opcode devoted to converting between floating-
point values and integer values. On other machines, maybe the C
runtime library would handle this, essentially replacing cast-
expressions with function calls:

extern int __C_RUNTIME_double_to_int(double);
i = __C_RUNTIME_double_to_int(j);

On other machines, maybe this would simply be a bitwise truncation
of the value of j. It all depends on how the implementation wants
to represent floating-point and integer values.

3)
float f = 4.3;
int i;
i = (int) f;

What happens here ? How does the truncation take place ?

This is the same thing you wrote in #2, except with "double"
replaced by "float." Nothing's different in the explanation.

5)
How are side effects defined ? When do
i say typecasting is an side effect ?

Type-casting is no more a "side effect" than addition or
multiplication. A "side effect" of an operation is something that
*happens*, not something that *is produced*. Examples:
In the expression 2+2, the value 4 *is produced*. Nothing *happens*.
Thus, 4 is the value of the expression, and it has no side effects.
In the expression g=2.0, the value 2.0 is produced. What *happens*
is that 2.0 is assigned to g. Thus, 2.0 is the value of the expression,
and its side effect is to assign 2.0 to g.
In the expression (int)g, the value 2 is produced. Nothing happens.
Thus, 2 is the value of the expression (int)g, and it has no side
effects.
In the expression (a=1,++a), the value 2 is produced. What happens
is that first 1 is assigned to a, and then a is incremented; those are
the side effects of the expression.

You see now? Very simple.

6)
Is truncation a side effect of type casting or not ?

No. When you write (int)43.2, the value of that expression is 43.
It has no side effects. Yes, the value 43 is a "truncated version
of" 43.2, but that's not a side effect; it's just the way C defines
casting from floating-point numbers to integers.

If you have more specific questions about how your own computer
handles floating-point numbers, try asking in comp.programming or in
a forum or newsgroup dedicated to your platform. comp.lang.c is
for questions related to the standard C programming language, as
distinct from any particular implementation or compiler.

HTH,
-Arthur

 

[Niklaus]

A better phrasing: "If a value of type int is cast to float,
the resulting value is of type float." Type-casting has nothing
to do with /objects/, which in C are the actual locations where
values can be stored. 42 is not an object; yet (float)42 is still
a valid C expression.


On the average Wintel machine, this will retrieve the bits stored
in i (say, 0x0300), and pass them through a special function designed
specifically to convert "int bits" to "float bits." On the x86 line
of processors, the FPU has a special machine instruction that will do
this conversion. The result will be a bunch of bits that represent
a float value (say, 0x42DE; I don't know the real internals here).
These "float bits" get stored into the object denoted by j.

Thanks for the explanation. I would like to know the real internals.
May be this isn't the appropriate group. In case someone knows please
do post a follow up.

 

[Stephen Sprunk]

"Arthur J. O'Dwyer" <[email protected]> wrote in message

Actually you don't need a cast in that case because C allows implicit
conversion between arithmetic types. Explicit casts are most commonly used
to convert between pointer types, which on most implementations don't do
anything at the bit level but allow bypassing the translator's type safety
rules.

Thanks for the explanation. I would like to know the real internals.
May be this isn't the appropriate group. In case someone knows please
do post a follow up.

The only "real internals" to this (at least for x86) are implemented in the
silicon of various processor chips, something the vendors are unlikely to
explain in detail. For other processors, get and read the code for your C
translator and/or runtime library.

The overall process is the same as converting an int to a double, with the
exception that the implementation needs to be told whether to truncate, take
the floor, or take the ceiling of fractional parts (since implementations
are usually capable of all three). I believe the exact behavior is
specified in IEEE 754, but I don't have a copy to check.

S

 

[Richard Bos]

Thanks for the explanation. I would like to know the real internals.

The problem is that, from an ISO C point of view, there are no _the_
real internals. What happens at the bit level is different for each
architecture you do this on. All the C Standard defines is what the
result should be (j is now equal to 3.0), not how that result should be
achieved (such-and-such a bit is shuffled into so-and-so a position).
This is because the natural way to get the required result depends
highly on how both floats and ints are represented on the computer in
question.
So yes, you do need to ask this in another group; however, only you know
what systems you want to know this about, so only you can tell whether
you want comp.sys.amiga.something or microsoft.public.vc.something-else.

Richard

[ Oh, btw, snipping is not forbidden in comp.lang.c ;-) ]