A Git based version of Magic Lantern, for those unwilling or unable to work using Mercurial. The vast majority of branches have been removed, with those thought to be important brought in individually and merged.
GNU General Public License v2.0
142
stars
50
forks
source link
Can we combine fast hw div on D6 with eabi_idiv module compatibility? #92
Digic6 is ARMv7-R, which has hw division, most other Arm don't. Gcc is aware and emits idiv and sdiv instructions. On other Arm, there's some external symbols that code calls into, including e.g. __aeabi_idiv. Modules expect these and so fail dep checking on -R.
This forces the linker to include code and symbols for the expected exports into the magiclantern binary. Magiclantern itself on D6 will still have idiv and sdiv instructions, so the only inefficiency is a small code size increase there, and the fact that modules when loaded on D6 will use software division even though hardware division is available (no worse than other platforms).
We could do some trickery so that these symbols, on ARMv7-R builds, resolved to the hardware operations. You'd still get the call overhead per division but the code would be small and presumably faster.
We would need to be sure that the module builds couldn't inline the now much smaller code, since this would mean if the first build for a module was from -R, the next non-R platform zip build would include broken code. This may already be true, I don't know.
Digic6 is ARMv7-R, which has hw division, most other Arm don't. Gcc is aware and emits idiv and sdiv instructions. On other Arm, there's some external symbols that code calls into, including e.g. __aeabi_idiv. Modules expect these and so fail dep checking on -R.
This is a provisional fix: https://github.com/reticulatedpines/magiclantern_simplified/commit/e345717fe65ca637f22eabbc62a5a0401c10e50c
This forces the linker to include code and symbols for the expected exports into the magiclantern binary. Magiclantern itself on D6 will still have idiv and sdiv instructions, so the only inefficiency is a small code size increase there, and the fact that modules when loaded on D6 will use software division even though hardware division is available (no worse than other platforms).
We could do some trickery so that these symbols, on ARMv7-R builds, resolved to the hardware operations. You'd still get the call overhead per division but the code would be small and presumably faster.
We would need to be sure that the module builds couldn't inline the now much smaller code, since this would mean if the first build for a module was from -R, the next non-R platform zip build would include broken code. This may already be true, I don't know.