FL_FIXED_POINT_NARROW_DIVIDE

#define FL_FIXED_POINT_NARROW_DIVIDE   0

1 when the target divides 32 bits in hardware but not 64.

Both halves matter. Without a hardware divider at all – Cortex-M0/M0+, AVR – the routine below would make two libgcc calls where the wide path makes one, so those targets keep the wide path. With a 64-bit divider, as on every host this builds on, the wide path is one instruction and nothing here could improve it.

__ARM_FEATURE_IDIV is GCC and clang's own answer to "does this core have SDIV/UDIV", so this asks the compiler rather than enumerating cores: Cortex-M3/M4/M7/M33 define it, Cortex-M0+ does not.

Paired with __arm__, which is AArch32 only. AArch64 defines __ARM_FEATURE_IDIV too – it has SDIV and UDIV – but its divider is 64 bits wide, so the wide path is already one instruction there and this would replace it with fifty. Every 64-bit ARM host and any Raspberry Pi running a 64-bit kernel is in that set, so the omission was not theoretical.

C++14 is required as well, because operator/ is constexpr and the routine below cannot be under C++11's rule against local variables in a constexpr function – the repo builds at C++11 to match AVR. A C++11 build for a core with a divider therefore keeps the wide path: correct, just not accelerated. The Arduino-Pico core passes -std=gnu++17, so the RP2350 this was measured on is not that build.

Definition at line 57 of file wide_divide.h.