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

David T. Lewis lewis at mail.msen.com
Wed May 29 00:03:34 UTC 2013


On Tue, May 28, 2013 at 11:49:17AM -0700, tim Rowledge wrote:
> 
> 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. 
> 

Good question. We do not really have a convention for things that work
on multiple operating system platforms but that are not general enough
to be considered "Cross". As a result, we have tended to accumulate copies
of things in the platform directories that might better be shared across
several platforms. For example, Ian's unix/vm/aio.c appears also as
iOS/vm/Common/aio.c, and there are various plugins that simply make
copies of code borrowed from other platform trees.

It might be a good idea to invent some directory structure to accommodate
this, but I don't know if it's really necessary. In the case of the
ARM specific code, I think the way to find out if it matters is simply
to plug the code into the platforms/Cross directories of both oscog and
trunk branches (on your own local machine), and see if it breaks the existing
build procedures.

If you can do this with the trunk sources, and find that Ian's CMake
build still happily produces a Unix VM, and if you can also do it on the
branch/oscog sources and find the Eliot's build still works, then it's
a good bet that you can safely add the code to Cross and work out the
build system annoyances later on.

On the other hand, if either Ian's or Eliot's exiting build procedures
crash and burn after you add the new Cross/ARM code, then we should
probably give the matter a bit more thought.

If you want me to try it with trunk/platforms/Cross for a Unix build,
send a copy of the code and I'll let you know if it works.

> 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.
> 

Yes please. I really, really, really appreciate if you can keep the trunk
files in sync with the oscog files :)

r.e. autoconf, I can offer sympathy but not much in the way of help. I'm
not a huge fan of CMake either, but it seems to be less horrible than
autoconf was. The only thing I know of that is worse that autoconf or
CMake is the obvious - maintaining both of them at the same time ;-)

Dave

> 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.
> 


More information about the Vm-dev mailing list