mantissa, sign, exponent

so C is a portable assembly language.. if I am asked to create a program to extract the sign mantissa and exponent on a 32 bit machine and 64 bit machine.. can I just use the same exact code?? as far as I know the location of the exponent, mantissa, and sign bit is totally different in the 64 bit version so therefore the way we mask it is also different. So, because of this we can't use the same exact code, inside the code we should check whether it is a 32 bit machine or 64 bit machine first and then use the corresponding mask to extract the sign, etc.. Please correct me if I am wrong

Well, no, not exactly.
The floating point uses the IEEE standard for it I think, so all machines that uses this standard handles floating points exactly the same way.
x86 and x86-64 should both use the IEEE standard.
What you need to look out for is whether it's float or double, because they use different amount of bits to store different types of the data.

You can use the exact same code if the new machine stores floats the exact same way.

yes it's just float.. and what do you mean the machine stores float the same way?? on the 64 bit and 32 bit machine they store it differently according to the IEEE

I doubt that, though I haven't looked into the docs about that. So long as the size is the same, I doubt the layout will be any different.
Otherwise you could point out where you found out this is the case.

so even if it's in a 32 bit machine or a 64 bit machine.. it will still work?? because I read on wikipedia about the IEEE and they mentioned the layout for floating point number is different in 64 bits:
the mantissa is at bits 0-51 and the exponent is from 52-63 and the sign bit is 64. I read it here:

http://en.wikipedia.org/wiki/IEEE_fl...point_standard

From that same page:

Quote:

---

IEEE 754 specifies four formats for representing floating-point values: single-precision (32-bit), double-precision (64-bit), [...]. For example, the C programming language, which pre-dated IEEE 754, now allows but does not require IEEE arithmetic (the C float typically is used for IEEE single-precision and double uses IEEE double-precision).

---

In other words, a "float" in C is usually single-precision, or 32-bits; and a "double" is usually double-precision, or 64 bits. You can see this by using sizeof(float) and sizeof(double); those values are usually 4 (8 bits * 4 bytes = 32 bits) and 8 (8 bits * 8 bytes = 64 bits). This should be the same on all platforms. You can check by using sizeof(float)/sizeof(double) on both platforms. If they're the same value, it's likely that the format is the same.

oh I see how this works, so in C a float is always stored in a single precision and it doesn't matter if it's a 32 bit machine or 64 bit machine?? so all these days I was always wrong, I was thinking that all 64 bit machines ALWAYS represents floats in 32 bit machine.. this is wrong right??

Floats are 32-bit, so of course they're 32-bits on 64-bit machines, as well.
So long as the compiler adheres to the IEEE standard, the code will be correct wherever you might compile it. And as long as the underlying architecture adheres to the IEEE standard, the code will execute right wherever you run it.

oh I see.. how stupid am I to think these days that they are different on different machines.. can you name some examples of machines that uses a double precision to store a float.?

so even a 32 bit machine can use a double precision floats??

I have no idea of such a machine and I doubt there would exist one, from my inexperienced knowledge of course.
x86 and x86-64 uses single for float, so 90% of the computers out there will have no trouble whatsoever.

I see..that makes more sense.. I just got this weird question tingling inside of me.. my instructor wants us to use appropriate typedefs for the int_4, int_u8 etc data types.

These will take different types(long vs long long for eg.) depending on whether the
machine is 32 bit/64 bit.

I don't quite get that.. in a 64 bit machine a long is a long long??

These types are just different sizes. The types may be different size depending on what platform and operating system it's running under.
A long is 4 bytes under Windows 64-bit, but 8 bytes under Linux 64-bit IIRC.
(On 32-bit, it's usually just 4 bytes, regardless of OS.)
Long long is a compiler extension that creates a 64-bit value (32-bit on Visual Studio).

You should use appropriate types depending on what system you're targeting. That's why the (u)intxx_t types are so good, because if you use them, you will guarantee to get yourself a type of the right size, wherever your code is compiled and executed.

and so what does this type has to do with extracting the sign mantissa and exponent?? say int_u8, what do I use that for??

It's a type! Just like int, long, float and double.

yes I know it's a type I am just asking for the purpose of extracting mantissa sign and exponent why does the sign has to be the type of int_4 and the mantissa has to be int_u8, like that??

They don't. It's just a matter of choosing an appropriate type big enough to hold it.
The sign can be uint8_t, the exponent can be uint16_t and the mantissa can be uint32_t. These are the smallest possible types to hold all data. That's all.

and does it matter in 64 bit computers there isn't any difference to hold these values because a float is a 32 bit too, but what matters is that the size of int is different in 64 bit right?? like they are 8 byte instead of 4 byte?? am I right??

Quote:

---

Originally Posted by -EquinoX-

...but what matters is that the size of int is different in 64 bit right?? like they are 8 byte instead of 4 byte?? am I right??

---

Yes, in sense that they must be large enough to hold the value.
But int is not guaranteed to be 64-bit on 64-bit machines. Int is merely 4 bytes under 64-bit Windows.

okay so if there is an assignment that would ask you to use a typedef to assign int_4, int_u4, int_8, and int_u8 into a 64 bit machine.. how would you do this?? assuming it's running on windows

If it's just a 64-bit machine and if you can use existing typedefs, then just do
typedef int_4 int32_t
If you can't, then do a proper sizeof of all types to see their actual size, and then typedef them.

no I want int_4 to be the type not int32_t so I guess you have it reversed

Yes, of course, my mistake.
typedef int32_t int_4;
^^"

Ya know, between the various threads -EquinoX- has created on essentially the same problem, and all of the twists and turns and arguments and explanations, I have to say: I am almost thoroughly confused as to the point of it all.

At best I'd like to think it is about capturing the bit image of an IEEE-754 single-precision floating point value and separating those bits into 3 integral values for sign, exponent, and mantissa. Plus some caveat about trying to be portable.

We've mentioned the usual approaches: wandering the bytes, casting, and a union. All have various portability issues.

Is there someone, anyone, who can give me the nickel summary?

I don't really think I understand 100% either. Just about the capturing the sign, exponent and mantissa from the float and that it will (probably) be done on a 64-bit system.

Why not just print if into a string and all your problems are solved.

"print if"? I guess you mean "printf", or more precisely "sprintf", right? :) Printing "if" into a string would get you a string with, well, "if", which is hardly helpful.

With that method, you won't get the exact exponent and mantissa.

Why not just print it...
I think that's closer, especially since "f" is just under "t".

On whose keyboard? :p Maybe esbo has a Dvorak keyboard . . . .

You're probably right, though.