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 OS 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 OS 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

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.

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.

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.

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.

Symbian OS 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 NaNs 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.