Re: typecast internals
From: glen herrmannsfeldt (gah_at_ugcs.caltech.edu)
Date: 05/07/04
- Next message: janylj_at_citiz.net: "test URL"
- Previous message: E. Robert Tisdale: "Re: Style question: (5 == x) or (x == 5)"
- In reply to: Chris Torek: "Re: typecast internals"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 07 May 2004 21:15:52 GMT
Chris Torek wrote:
(snip)
> Since this *is* (or was) comp.arch, let us take a look at a high(ish)
> level of how the hardware does the trick. (I am going to cross-post
> this back to comp.lang.c, because I will touch on requirements
> imposed by Standard C too.)
(snip of description of floating point formats)
> The C cast construct here acts as as request to convert from an
> int (represented in ordinary binary) to a double-precision floating
> point number (represented as above). At the CPU instruction level,
> the expression "(double)i" might (or might not) do something like:
> store reg_holding_i => memory
> load_fpu_with_integer memory => fpu_register_pair
Or consider S/360 and S/370, which didn't have any instructions
to do the conversion. It was done by storing the fixed point
value in memory, applying the appropriate high order word with
the right exponent, loading it into a floating point register,
and then correcting for possible negative numbers.
(snip)
> How the bits are actually laid-out by the hardware -- in FPU
> registers or in memory (which may well different internal layouts)
> -- is architecture-dependent. (Indeed, IEEE float is already
> architechture-dependent; IBM S/370 systems still use "hex-float"
> and older systems used other methods.)
Note that there is also the different endianness even for the
same format, and especially the VAX not big or little endian
formats.
(snip of more details of fix/float conversions)
>>Casts like (int*) or (float*) tell the compiler to assume
>>(if it can) that the value is of the appropriate pointer type,
>>but not actually change the value of the pointer, or the
>>value that the pointer points to.
> This is not really true. Pointer casts are, conceptually, just as
> much of a conversion operation as arithmetic-type casts. It is
> just that the machines on which this conversion requires
> machine-instructions are now rare. An example machine that *does*
> require instructions is the Data General Eclipse, where one uses
> a shift instruction to convert between byte and word pointers.
Reading it again, after the fact, I said it doesn't change the
value not that it doesn't change the bits. The value (that it
points somewhere in memory) still doesn't change, even though
the bits change. I do agree that it is a strange distinction
to make, though.
> As I recall, the old Burroughs A-series machines used floating-point
> formats to store integers, so on the Burroughs, a cast from int to
> double would use no instructions. It would still be a conversion,
> though.
This is true. Consider, though, that it would have been possible
for the C language to define the (int) and (float) casts as
converting data types without converting bits, such as the Java
functions (oops, methods) floatToIntBits() and doubleToLongBits().
These exist in Java/JVM as native methods because the tricks used
in other languages don't work in Java.
It is generally more common, (and more portable,) to convert the value,
so for example I can do something like printf("%f",sqrt((double)i));
Somewhat like the Fortran DFLOAT() function. One could imagine a C
where casts didn't convert the data but functions like DFLOAT() did.
One could also imagine a pointer cast that would create a pointer
pointing to converted data. Consider what PL/I does with a
fixed point array used as an argument to the FLOAT function?
It should create a whole new array containing the converted data.
It seems to me, then, that it isn't completely obvious that the C
way is the only possible way, but the one that fit most closely
with the C language when it was being developed.
It did take me a little while to get used to casts, after using
languages, such as Fortran and PL/I, with conversion functions.
To continue on, PL/I pointers are typeless, somewhat like the (void*)
pointer in C. They are only given a type when they are dereferenced,
similar to structure pointers in C. Especially interesting is that the
operator -> is used to dereference PL/I pointers. (Is that where
the C operator came from?)
-- glen
- Next message: janylj_at_citiz.net: "test URL"
- Previous message: E. Robert Tisdale: "Re: Style question: (5 == x) or (x == 5)"
- In reply to: Chris Torek: "Re: typecast internals"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
