internals of typecasting

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
-

re: internals of typecasting

On Mon, 3 May 2004, Niklaus wrote:[color=blue]
>
> 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.[/color]

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.
[color=blue]
> 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 ?[/color]

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.
[color=blue]
> 2)
> Also i would like to know what happens say
>
> i = (int)j;[/color]

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.
[color=blue]
> 3)
> float f = 4.3;
> int i;
> i = (int) f;
>
> What happens here ? How does the truncation take place ?[/color]

This is the same thing you wrote in #2, except with "double"
replaced by "float." Nothing's different in the explanation.
[color=blue]
> 5)
> How are side effects defined ? When do
> i say typecasting is an side effect ?[/color]

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.

[color=blue]
> 6)
> Is truncation a side effect of type casting or not ?[/color]

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

re: internals of typecasting

"Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote in message news:<Pine.LNX.4.58-035.0405031827470.14604@unix47.andrew.cmu.edu>...[color=blue]
> On Mon, 3 May 2004, Niklaus wrote:[color=green]
> >
> > 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.[/color]
>
> 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.
>[color=green]
> > 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 ?[/color]
>
> 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.
>[/color]
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.[color=blue][color=green]
> > 2)
> > Also i would like to know what happens say
> >
> > i = (int)j;[/color]
>
> 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.
>[color=green]
> > 3)
> > float f = 4.3;
> > int i;
> > i = (int) f;
> >
> > What happens here ? How does the truncation take place ?[/color]
>
> This is the same thing you wrote in #2, except with "double"
> replaced by "float." Nothing's different in the explanation.
>[color=green]
> > 5)
> > How are side effects defined ? When do
> > i say typecasting is an side effect ?[/color]
>
> 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.
>
>[color=green]
> > 6)
> > Is truncation a side effect of type casting or not ?[/color]
>
> 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[/color]

re: internals of typecasting

"Niklaus" <niklaus@gamebox.net> wrote in message
news:d06ac2eb.0405032203.7cc97008@posting.google.c om...[color=blue]
> "Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote in message[/color]
news:<Pine.LNX.4.58-035.0405031827470.14604@unix47.andrew.cmu.edu>...[color=blue][color=green]
> > On Mon, 3 May 2004, Niklaus wrote:[color=darkred]
> > > 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;[/color][/color][/color]

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.
[color=blue][color=green][color=darkred]
> > > What happens in the above statement ? Can someone
> > > explain me at bit level or a considerable explantion ?[/color]
> >
> > 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.
> >[/color]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
> > > 3)
> > > float f = 4.3;
> > > int i;
> > > i = (int) f;
> > >
> > > What happens here ? How does the truncation take place ?[/color][/color][/color]

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

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

re: internals of typecasting

niklaus@gamebox.net (Niklaus) wrote:
[color=blue]
> "Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote in message news:<Pine.LNX.4.58-035.0405031827470.14604@unix47.andrew.cmu.edu>...[color=green]
> > On Mon, 3 May 2004, Niklaus wrote:[color=darkred]
> > >
> > > 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 ?[/color]
> >
> > 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.
> >[/color]
> Thanks for the explanation. I would like to know the real internals.[/color]

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 ;-) ]