[Vm-dev] Re: VMMaker-tfel.358 in Inbox: Fixes for BitBlt simulation

timfelgentreff timfelgentreff at gmail.com
Thu Mar 12 13:32:46 UTC 2015


Hi Eliot,

The bugs in 358 were:

for loadColorMap:, that the assertion was simply failing. Since in C, no
assertion is generated, Tobias and I figured it may simply be not needed,
and everything seemed to work without.

and halftoneAt: was simply missing, BitBltSimulator overrides dstLongAt: and
srcLongAt:, but didn't include an override for halftoneAt:, and we ran into
a debugger when trying to simulate. Adding this method fixes that.

Regarding how initaliseModule was called so often - we're using the code in
the plugins a little unconventionally. We have a VM without the BitBlt
plugin and when the named primitive comes up, we instead dispatch to
BitBlt>>copyBitsSimulated, and then simulate _only_ the BitBlt part, not the
entire image. But that entails creating a new InterpreterProxy and
initalising it from current context, and and thus also creating a new
instance of the BitBltSimulator. That's how initialiseModule ends up being
called often. 359 doesn't remove those calls, it just caches those constant
tables on the class side.

I've just pushed VMMaker-tfel.360 to the inbox, which adds methods so we can
do the same with Balloon (BalloonEngine gains a
#simulateBalloonPrimitive:args:). The idea is that we can run the VM without
BitBlt and Balloon plugins and just run the Slang code (on RSqueakVM with
the changes from 359, we get about 50% of the BitBlt performance running the
Simulation compared to the C plugin)



--
View this message in context: http://forum.world.st/VMMaker-tfel-358-in-Inbox-Fixes-for-BitBlt-simulation-tp4805362p4811438.html
Sent from the Squeak VM mailing list archive at Nabble.com.


More information about the Vm-dev mailing list