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

tim Rowledge tim at rowledge.org
Fri May 31 02:34:26 UTC 2013


Oh my, this is turning out to be fun with a capital 'A'.

I'm not at all sure Dave's tests the other day tell us anything much; it turned out that Ben forgot to tell me of the need to call an initialiser function! Without that the code would always use the fallback code and thus ought to work on non-ARM, so simply checking that it didn't blow up doesn't tell us so much. Sigh.

Now I have the initialiser set up there are other problems like the code not actually doing quite what we thought. That's going to be fun to fix.

Integrating into the BitBltPlugin code has been interesting. We need to selectively:-
a) include a header file, 
b) choose a branch to the new code or not
c) hide or expose references to a struct defined in the new header file
d) use or not use the make related fragments 
e) use the appropriate file for getting the OS to tell us about the architecture in use

a) might possibly be best done by simply adding the headerfile, including it always and relying on the fact that the relevant code simply won't be called, and would likely get dropped when the unix libtool does its work. That has the attraction of not needing an ugly hack that lets me add a header file named 
'#ifdef ARM_FAST_BLT
#include "BitBltDispatch.h"
#else
// to handle the unavoidable decl in the spec of copyBitsFallback();
#define operator_t void
#endif'
That 'operator_t 'is the struct mentioned in c). We could wrap much of the header file contents in a suitable #ifdef ARM_FAST_BLT of course.

d) is completely outside my knowledge. If we add a cmake fragment for bitblt and don't need some of it when there is no ARM_FAST_BLT, what do we need to do?

e) ought to be handled by putting the BitBltArmLinux.c file in the unix platform branch as usual and a derivative of BitBltArmOther.c in suitable places. I imagine this code will be of use should someone do a WindowsRT port, too.

Other fun issues-
I've had to make quite separate versions for trunk and Cog trees. Eliot uses cppIf:ifTrue: etc and there is no support for that in the trunk VMMaker code. I don't have time to fix that right now.
Eliot has things set up to generate code as generally as possible (still can't do RISC OS suitable code though!) so that choices of platform and global-struct or not etc can be made at compile time. It doesn't look like the same is true of trunk. 

Current changes from trunk VMMaker - I'm really not sure it is ready to commit yet. I don't want to break everyone else's builds...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VMMaker-fastbitbltARM3.st
Type: application/octet-stream
Size: 14505 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130530/e4cf1e81/VMMaker-fastbitbltARM3-0001.obj
-------------- next part --------------


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Computer possessed? Try DEVICE=C:\EXOR.SYS




More information about the Vm-dev mailing list