Floating +point support

ARM provide a hardware floating point coprocessor that provides floating +point computation that is fully compliant with IEEE Std 754-1985. This is +an implementation of the ARM Vector Floating Point Architecture (VFPv2). We +refer to the coprocessor as the VFP unit.

Symbian platform supports the use of VFPv2 on platforms where the required +hardware is present in both RunFast mode and in IEEE-without-exceptions mode. +See ARM's Vector Floating-point Coprocessor Technical reference Manual for +more details on the coprocessor, its architecture, and its execution modes.

Note that Symbian platform does not support floating point exceptions in +any mode.

Using the Vector Floating Point Architecture (VFP) in an application
Run time check for hardware floating point
Execution modes

Using the Vector +Floating Point Architecture (VFP) in an application

An application +can use VFP in two ways:

indirectly through the +use of floating point support functions.
directly in its code, +either generated by the compiler, or hand-written in assembler.

Indirect use

By default, all applications are built +to use the floating point support functions.

On a device without a +VFP unit, floating point support functions are implemented in software and +operate slowly. On a device with a VFP unit, the floating point support functions +are handled by the VFP unit, and operate faster than when implemented in software.

Note +that applications do not need to make any changes to take advantage of VFP-enabled +floating point support functions, if they are provided in the device's ROM. +Such functions are used automatically at run time.

Direct use

To +generate VFP specific code at compile time, you need to add +the armfpu statement +with the vfpv2 keyword into your .mmp file:

armfpu vfpv2

On +a device with a VFP unit, this option results in code that runs faster than +the floating point support functions generated by armfpu + softvfp. Note, however, that binaries generated with VFP specific +code do not work on devices without a VFP unit - any call to VFP specific +code results in a KERN-EXEC 3 panic.

On those devices that have a +VFP unit, the functions supplied in the Math class, that +perform trigonometric and transcendental operations may also be implemented +using VFP specific code. This is transparent to application code.

Run time check +for hardware floating point

An application can find out at run +time whether a device supports hardware floating point by calling HAL::Get(), +using the EHardwareFloatingPoint attribute. The following +code fragment shows how you would do this:

... +TInt supportedFp; + +TInt HalVfp = HAL::Get(HALData::EHardwareFloatingPoint, supportedFp); +if (HalVfp == KErrNone && (supportedFp & EFpTypeVFPv2)) + { + // HAL says that we have a VFP unit + ... + } +else + { + // HAL says that we do NOT have a VFP unit + ... + } +... +

Note that, strictly speaking, the return value from HAL::Get() indicates +whether or not the attribute is supported. To deduce whether hardware floating +point is supported by the device, the following logic applies:

If the Hardware Abstraction +Layer (HAL) does not support the EHardwareFloatingPoint attribute, +then HAL::Get() returns KErrNotSupported. +This can be interpreted as meaning that the device does not support hardware +floating point.
If the HAL does support +the EHardwareFloatingPoint attribute, then HAL::Get() returns KErrNone. +In this case the TInt variable supportedTypes in +the above example code fragment will contain an enum value of type TFloatingPointType describing +the type of hardware floating point supported. If hardware floating point +is supported, then currently, this can only be ARM Vector Floating Point Architecture +(VFPv2) as indicated by the EFpTypeVFPv2 enum value.

Execution modes

Symbian +platform can support the two execution modes: RunFast and IEEE-without-exceptions.

+ + + +

RunFast

In this mode, denormalised numbers, i.e. those outside the range +of normal floating point values, are treated as zero, and a default NaN (Not +a Number) value is used for all NaN situations regardless +of the inputs.

+ + +

IEEE-without-exceptions

In this mode, denormalised numbers are treated as their actual values, +and the IEEE754-mandated values for NaN s are used.

The +floating point model mandated by the Java specification is identical to this +mode, and means that this mode is sufficient to implement a VFP-accelerated +JVM.

+ + + +

An application can set (and check) the execution mode at run time +by calling User::SetFloatingPointMode(), and passing one +of the TFloatingPointMode enum values, which represent +the possible modes.

The function can still be used even if hardware +floating point is not supported. In this case it returns KErrNotSupported.

Applications +that do not require NaN values to be as specified by IEEE754 +and are not concerned with accuracy when dealing with very small (denormalised) +quantities, can select RunFast mode for a possible performance +increase. Games or 3D engines are likely to fall into this category. Applications +that require accurate IEEE754 interpretations, such as the JVM, can explicitly +select IEEE-without-exceptions mode, and if this fails as +being unsupported, refuse to run.