ARM Cortex-M4 and Helium Fixed-Point Multiplication: Precision and Shift Behavior
Fixed-point arithmetic is a cornerstone of digital signal processing (DSP) and embedded systems, particularly when working with microcontrollers like the ARM Cortex-M4 and vector processing extensions like Helium. The core issue revolves around the intrinsic fixed-point multiplication instructions, such as SMULL for the Cortex-M4 and VMULH.S16 for Helium, which inherently perform shifts by 16 and 32 bits respectively. These shifts are integral to the fixed-point representation, but they introduce a critical precision loss due to the handling of the sign bit in signed fixed-point formats like Q15 and Q31.
In fixed-point arithmetic, numbers are represented as integers but interpreted as fractions. For example, in Q15 format, a 16-bit integer is interpreted as having 15 fractional bits and 1 sign bit. Similarly, Q31 uses 31 fractional bits and 1 sign bit. When multiplying two Q15 numbers, the result is a Q30 number, which must be renormalized back to Q15 by shifting right by 15 bits. However, the ARM instructions SMULL and VMULH.S16 perform shifts by 16 and 32 bits, effectively discarding one additional bit of precision. This behavior is counterintuitive and problematic for developers expecting full precision in their fixed-point calculations.
The issue is exacerbated by the fact that these instructions are designed to return the high half of the multiplication result, which aligns with the shift-by-16 or shift-by-32 behavior. For example, multiplying two Q15 numbers (32767 x 32767) yields a result that, when shifted by 16 bits, loses one bit of precision compared to the expected shift-by-15. This precision loss is particularly problematic in DSP applications where maintaining accuracy is critical.
Memory Alignment and Instruction Set Limitations in Fixed-Point Operations
The root cause of this issue lies in the design of the ARM instruction set and its handling of fixed-point arithmetic. The SMULL instruction, for instance, performs a 32-bit multiplication and stores the result in two 32-bit registers (RdLo and RdHi). The high half of the result (RdHi) is effectively the result of a shift-by-32 operation. Similarly, the Helium VMULH.S16 instruction performs a vectorized multiplication and returns the high half of the result, equivalent to a shift-by-16.
This design choice is likely rooted in historical and architectural considerations. ARM processors are optimized for general-purpose integer arithmetic, and the fixed-point instructions were added as extensions to support DSP workloads. However, these instructions were not designed with the flexibility to handle arbitrary fixed-point formats. Instead, they assume a specific interpretation of the fixed-point format, which aligns with shifts by 16 and 32 bits.
The lack of flexibility in the shift amount is a significant limitation. In many DSP applications, developers need to work with custom fixed-point formats, such as Q7.24 or Q15.16, where the required shift amount differs from the default 16 or 32. Without the ability to specify the shift amount dynamically, developers are forced to manually adjust the results using additional instructions, which increases code complexity and reduces performance.
Implementing Custom Shifts and Precision Recovery in ARM Fixed-Point Arithmetic
To address the precision loss and inflexibility of the ARM fixed-point instructions, developers can implement custom shift operations and precision recovery techniques. For example, after using the SMULL instruction, developers can manually shift the result by 15 bits instead of 16 to recover the lost precision. This can be achieved using a combination of logical shifts and bitwise operations, as shown in the following example:
SMULL RdLo, RdHi, Rn, Rm ; Perform 32-bit multiplication
LSRS RdLo, RdLo, #15 ; Shift lower half by 15 bits
ORR RdLo, RdLo, RdHi, LSL #17 ; Combine with upper half
This approach ensures that the result is correctly aligned with the Q15 format, preserving the full precision of the fixed-point representation. However, it comes at the cost of additional instructions and increased cycle count, which may be unacceptable in performance-critical applications.
For Helium, similar techniques can be applied, but the vectorized nature of the operations complicates the implementation. Developers may need to use additional vector instructions to manually adjust the results, further increasing the complexity of the code.
A more elegant solution would be for ARM to introduce new instructions or intrinsics that support dynamic shift amounts, allowing developers to specify the desired shift as part of the operation. This would enable the use of arbitrary fixed-point formats without the need for manual adjustments. For example, an instruction like SMULLS could be introduced, which takes an additional operand specifying the shift amount:
SMULLS RdLo, RdHi, Rn, Rm, #15 ; Perform multiplication and shift by 15 bits
Such an instruction would greatly simplify fixed-point arithmetic on ARM processors, making it more flexible and efficient for DSP applications. Until such instructions are available, developers must rely on manual techniques to achieve the desired precision and flexibility.
In conclusion, the shift-by-16 and shift-by-32 behavior of ARM fixed-point instructions is a significant limitation for DSP applications, particularly when working with custom fixed-point formats. By understanding the underlying causes and implementing custom shift operations, developers can mitigate the precision loss and achieve the desired results. However, the introduction of new instructions supporting dynamic shift amounts would greatly enhance the usability and performance of fixed-point arithmetic on ARM processors.
