The first thing to realize is that the binary representation of 0.15625 is not 0.00101. Yes, that is what you would write if you were writing out the number by hand. The actual representation of the number within the computer using IEE 754 for single precision 32 bit. This is specified as part of the Java Language Specification 4.2:
The floating-point types are float, whose values include the 32-bit IEEE 754 floating-point numbers, and double, whose values include the 64-bit IEEE 754 floating-point numbers.
The IEEE 754 binary representation of 0.15625 is: 0x3E200000 which can be broken down into:
- a sign bit:
0 meaning it is positive.
- the exponent for bits:
01111100 which is 124. This value is subtracted from 127 to get the actual exponent that will be used (-3)
- the significand:
.0100000 00000000 00000000. The . I put there is for reading so that it is bytes, not part of the value (the significant uses the lower 23 bits of the number... so the 24th bit I represent with a . so the alignment is easier to read) This value is added to 1 giving us the binary value of 1.010.... or in base 10, 1.25000...
Combining these all together, we get:
(-1)0 * 1.012 * 2-3 which comes out to be, when written, 0.00101. But remember, that we're really dealing with 0x3E200000.
Lets take a quick Java source file:
package com.michaelt.so.floating;
public class Demo {
float foo = 0.15625f;
}
The byte code for this, when decompiled is:
// class version 50.0 (50)
// access flags 0x21
public class com/michaelt/so/floating/Demo {
// compiled from: Demo.java
// access flags 0x0
F foo
// access flags 0x1
public <init>()V
L0
LINENUMBER 3 L0
ALOAD 0
INVOKESPECIAL java/lang/Object.<init> ()V
L1
LINENUMBER 4 L1
ALOAD 0
LDC 0.15625
PUTFIELD com/michaelt/so/floating/Demo.foo : F
RETURN
L2
LOCALVARIABLE this Lcom/michaelt/so/floating/Demo; L0 L2 0
MAXSTACK = 2
MAXLOCALS = 1
}
Which really isn't too interesting. You can see the LDC 0.15625 in there which is a load constant opcode. It takes one argument from a constant pool and pushes it on the stack.
So, lets look at Demo.class with a hex dump viewer.
$ hexdump -C Demo.class
00000000 ca fe ba be 00 00 00 32 00 15 0a 00 05 00 11 04 |.......2........|
00000010 3e 20 00 00 09 00 04 00 12 07 00 13 07 00 14 01 |> ..............|
00000020 00 03 66 6f 6f 01 00 01 46 01 00 06 3c 69 6e 69 |..foo...F...<ini|
00000030 74 3e 01 00 03 28 29 56 01 00 04 43 6f 64 65 01 |t>...()V...Code.|
00000040 00 0f 4c 69 6e 65 4e 75 6d 62 65 72 54 61 62 6c |..LineNumberTabl|
00000050 65 01 00 12 4c 6f 63 61 6c 56 61 72 69 61 62 6c |e...LocalVariabl|
00000060 65 54 61 62 6c 65 01 00 04 74 68 69 73 01 00 1f |eTable...this...|
00000070 4c 63 6f 6d 2f 6d 69 63 68 61 65 6c 74 2f 73 6f |Lcom/michaelt/so|
00000080 2f 66 6c 6f 61 74 69 6e 67 2f 44 65 6d 6f 3b 01 |/floating/Demo;.|
00000090 00 0a 53 6f 75 72 63 65 46 69 6c 65 01 00 09 44 |..SourceFile...D|
000000a0 65 6d 6f 2e 6a 61 76 61 0c 00 08 00 09 0c 00 06 |emo.java........|
000000b0 00 07 01 00 1d 63 6f 6d 2f 6d 69 63 68 61 65 6c |.....com/michael|
000000c0 74 2f 73 6f 2f 66 6c 6f 61 74 69 6e 67 2f 44 65 |t/so/floating/De|
000000d0 6d 6f 01 00 10 6a 61 76 61 2f 6c 61 6e 67 2f 4f |mo...java/lang/O|
000000e0 62 6a 65 63 74 00 21 00 04 00 05 00 00 00 01 00 |bject.!.........|
000000f0 00 00 06 00 07 00 00 00 01 00 01 00 08 00 09 00 |................|
00000100 01 00 0a 00 00 00 39 00 02 00 01 00 00 00 0b 2a |......9........*|
00000110 b7 00 01 2a 12 02 b5 00 03 b1 00 00 00 02 00 0b |...*............|
00000120 00 00 00 0a 00 02 00 00 00 03 00 04 00 04 00 0c |................|
00000130 00 00 00 0c 00 01 00 00 00 0b 00 0d 00 0e 00 00 |................|
00000140 00 01 00 0f 00 00 00 02 00 10 |..........|
0000014a
Look, right there at the start of the second line...
00000010 3e 20 00 00
There's the number.
Someone is going to ask 'but why is the number way up there? There's not even a 12 near it (the hex value for LDC).' And they are right to ask this. Remember that the LDC tool a value from the constant pool. The byte code that I had earlier was converted back into something a person could read.
The structure of a class file can be found in the Java Virtual Machine Specification section 4.1:
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_info methods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
We've got the magic number at the top (ca fe ba be), and the minor version (00 00), and major version (00 32 = 5010) and then the constant pool count (00 15) which then has the constant pool itself.
The constant pool is specified in section 4.4 which has the format:
cp_info {
u1 tag;
u1 info[];
}
The tag value of 04 says that 'what is next is a float`. You can see it at the end of the preceding line.
00000000 ca fe ba be 00 00 00 32 00 15 0a 00 05 00 11 04 |.......2........|
00000010 3e 20 00 00 09 00 04 00 12 07 00 13 07 00 14 01 |> ..............|
The other stuff that is around the number is information about locations for methods (it still has a default constructor), the name of the field, the name of the class, etc... there are a bunch of constants in there.
The key thing there though, you can see the floating point number stored in the class file as an IEEE 754 value that indicates this is something that the compiler does.
