[Vm-dev] Adding CPU specific code for fast bitblt on ARM

[tim Rowledge]

In order to make the Raspberry Pi Squeak faster we've built a fairly large chunk of ARM specific code to implement a good fraction of the bitlbt plugin. It *ought* to speed up some common blits by around 5-10X once all functioning fully.

My current problem is integrating it nicely so it doesn't get in the way of 'normal' code. I have fudged the BitBltSimulation code a little to make the relevant connections with, I hope, minimal intrusion and maintained the compile-time configuration that should support Jenkins builds etc. A single -DARM_FAST_BLT in CFLAGS triggers #including a header and taking a branch in copyBits to the specialised code. It's not the most elegant code in the world but the best I could come up with without rewriting everything.

That all works to generate suitable code for the Pi and seems not to mangle anything for other platforms. I'll make sure it works for RISC OS sometime soon, too.

The other issue is where to store the rest of the hand-written code. Right now it's mostly in platforms/Cross/plugins/BitBltPlugin which doesn't really seem right. It's cross platform in the sense of RISC OS & any ARM linux but hardly universally cross-platform. Would it annoy anyone if it stays there? Would naming it BitBltPluginARM make it nicer? There are a couple of other files that *are* platform specific and implement cpu discovery to configure the tricks used in the rest of the code. One is currently in unix/src/vm/intplugins/BitBltPlugin, which certainly isn't suitable. There's also a config.cmake fragment currently in unix/plugins/BitBltPlugin which clearly would need some work to handle non-ARM builds. 

Oh, the other, other issue is integrating it into the make world for both plain interp and stack/cog. Right now I have the ST code integrated into the cog vmmaker but not the plain vmmaker, but the makefile stuff is for the CMake used in the plain interp branch. Sigh. I'll move the code across to the plain vmmaker today and that ought to result in something that would build clean on an ARM unix but likely not non-ARM. Changing the cog makefiles to incorporate the new code…. yuck. autoconf. Help.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Put a lens in each ear and you've got a telescope.