Reading the armv8 spec:
The Floating-point move (register) instructions copy a scalar floating-point value from one register to another
register without performing any conversion.
Some of the Floating-point move (register) instructions overlap with the functionality provided by the Advanced
SIMD instructions DUP , INS , and UMOV . However, Arm recommends using the FMOV instructions when operating on
scalar floating-point data to avoid the creation of scalar floating-point code that depends on the availability of the
Advanced SIMD instruction set.
Table C3-64 shows the Floating-point move (register) instructions.
The spec suggests that this instruction is the only way to move from a floating point register to a general purpose register, if the listed SIMD instructions aren't available. So you need java code that converts a float to an int without performing a conversion, and a processor that doesn't have SIMD support.
The defacto way to do this in java seems to be Float.floatToIntBits
.
On my JVM install(hotspot jdk8u forest) this is implemented as a native function. This native function eventually reaches hotspot/src/share/vm/opto/library_call.cpp
, with the following code:
case vmIntrinsics::_floatToRawIntBits:
case vmIntrinsics::_floatToIntBits:
case vmIntrinsics::_intBitsToFloat:
case vmIntrinsics::_doubleToRawLongBits:
case vmIntrinsics::_doubleToLongBits:
case vmIntrinsics::_longBitsToDouble:
return inline_fp_conversions(intrinsic_id());
The definition of inline_fp_conversions
is in the same file and as far as I can tell could output a FMOV
instruction.
Notably MoveF2INode
is emited, though this may end up calling native code instead of actually JIT'ing an FMOV
.
I'm a little conflicted, since it appears this question could be a homework question. But if this is the answer homework-issuer is looking for it seems like a dumb homework question, so I'm fine with this answer existing.