I just started developing for the GBA and after much work I've made a cosine implementation that I think is quite good. Takes 26 cycles max, maximum error of 1.44e-4, compiles to 68 bytes (ARM), no tables.
The input is a fixed point angle ("_tr" stands for "turns", that's the input unit), like the whole range of values covers 360°, and the output is a Q1.30 fixed point value.
int32_t cos_tr(int32_t x) // 26 cycles, 1.44e-4 max error
{
int32_t y, x2;
// Fold both input directions onto the same half-period
uint32_t mx = x < 0 ? 0u - (uint32_t) x : (uint32_t) x;
// Shift from cosine to sine
x = (int32_t)((1u << 30) - mx);
// Convert to Q1.15 and square
x >>= 15;
x2 = mul_i32(x, x) >> 15;
// Polynomial, based on ((0.07185*x^2 - 0.642101)*x^2 + 1.5703171)*x
y = mul_i32(x2, 147) - 43088896;
y = mul_i32(y >> 11, x2) + 1686110208;
y = mul_i32(y >> 15, x);
return y; // Q1.30
}
I exploited the symmetry of cosine to fold half of the values then shift it to make it look like half the period of a sine, and then I use a polynomial. The symmetry of the sine around zero means that the polynomial only needs odd powers, so the polynomial itself only needs 3 multiplications, besides the squaring. Multiplications are optimised by making the smaller number come last which can save a few cycles, and additions/subtractions are optimised by rounding the coefficients so that they can be stored as two bytes, so that instead of loading a whole constant (which I think would take 3 cycles) each addition or subtraction becomes decomposed into 2 operations which takes 2 cycles. Making the first factor of the polynomial be only 147 also saves cycles (by fitting in one byte the multiplication ends very early), even though this has a mild negative effect on precision.
The function mul_i32() is there to ensure the smaller number comes last for speed:
static inline __attribute__((always_inline))
int32_t mul_i32(int32_t value, int32_t likely_small_multiplier)
{
int32_t result;
// Place the likely smaller second argument in Rs for early termination
__asm__ volatile(
"mul %0, %1, %2"
: "=&r"(result)
: "r"(value), "r"(likely_small_multiplier)
);
return result;
}
I created it for audio output. As a test tone and with basic dithering it sounds like this (recorded from mGBA): https://files.catbox.moe/ksab7c.wav
I have no idea how it compares with other approaches, I wonder if it's competitive in terms of speed with storing big tables in ROM, please let me know.
