The JVM operates on primitive values (integers and floating-point numbers) and references. The JVM is fundamentally a 32-bit machine. codice_1 and codice_2 types, which are 64-bits, are supported natively, but consume two units of storage in a frame's local variables or operand stack, since each unit is 32 bits. codice_3, codice_4, codice_5, and codice_6 types are all sign-extended (except codice_6 which is zero-extended) and operated on as 32-bit integers, the same as codice_8 types. The smaller types only have a few type-specific instructions for loading, storing, and type conversion. codice_3 is operated on as 8-bit codice_4 values, with 0 representing codice_11 and 1 representing codice_12. (Although codice_3 has been treated as a type since "The Java Virtual Machine Specification, Second Edition" clarified this issue, in compiled and executed code there is little difference between a codice_3 and a codice_4 except for name mangling in method signatures and the type of boolean arrays. codice_3s in method signatures are mangled as codice_17 while codice_4s are mangled as codice_19. Boolean arrays carry the type codice_20 but use 8 bits per element, and the JVM has no built-in capability to pack booleans into a bit array, so except for the type they perform and behave the same as codice_4 arrays. In all other uses, the codice_3 type is effectively unknown to the JVM as all instructions to operate on booleans are also used to operate on codice_4s.)