[Vm-dev] VMMaker-oscog issues on RISC OS

tim Rowledge tim at rowledge.org
Fri Apr 12 06:09:00 UTC 2013


Hmm, interesting stuff…

On 10-04-2013, at 6:05 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> The main changes (on the stack vm) are
> - a heartbeat.  preferrably this is a thread in a spin-loop, blocking on a delay, and forcing a poll when it unblocks.  

What I can do reasonably well is have a millisecond (actually, arbitrary, non-regular intervals can be done, up to about 1MHz) tick that keeps a counter, flips a flag or similar. I *can't* run any code in the application since it is not knowable if the application will be mapped into memory at that point and so it might jump to an arbitrary point in some other application. Fun, eh? So, for example, I could have a known memory address that is read (or even branched through) and the tick would have changed it to affect the execution path. Might be some cache issues to sort out but my current mSec timer works ok. So if there is some place that can check a single flag for whether an process check is needed and that gets run at appropriate times, then we're good. 
Essentially I can add an interrupt handler in user space but it can only play in its own sandbox; main application code can then read/set that info as well. I'll dig around users of checkHighPriorityTickees() etc.

> 
> - a 64-bit microsecond clock as the basis of time, see the heartbeat files.

'halfAMo'? Seriously; 'halfAMo'? I knew there was a reason working with you is fun.

> 
> - a thread-safe external semaphore registry, see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Cross/vm/sqExternalSemaphores.c
> 
> - some atomic access primitives used to implement both the 64-bit microsecond clock and the external semaphore registry in a lock-free form.  see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Cross/vm/{sqAtomicOps.h,sqMemoryFence.h}


Yeah, can probably do that.

> 
> There's also some Qwaq/teleplace/Term left-overs in the form of a ticker thread for running multi-media processing in parallel with the VM.  See sqTicker.c, but I wouldn't worry about that.

I won't. 

> 
> There's also some experimental stuff to do with support for a multi-threaded VM along the lines of e.g. the S# or Python VMs where any number of threads can share the VM, but only one is actually running the VM at any one time, and hand-over between threads is carefully mediated.  See various COGMTVM defines in the VM.

Threads? We don't do no threads man, way too establishment.

> 
> Then in your makefile you can do -DUSE_GLOBAL_STRUCT=1 if it floats your boat.  This is a great idea on PPC but doesn't work on x86.  I'd be interested to know which is better on ARM.

John McI did the original global struct stuff around '99 and we adopted it in '02, and I reworked it to allow a single register to be global (Yay for global register variables and for Harry Wossname putting them into NorCroft CC in 1988) and point to the table; you might not believe how many instructions that saved on an ARM. I *think* it made the system something like 30% faster overall. So yeah, it's better.


> 
> Make sense?  If not, uncork a Bowmore and read at leisure…

Coffee works better for me. And toasted cheese scones.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Dopeler effect (n): The tendency of stupid ideas to seem smarter when they come at you rapidly.




More information about the Vm-dev mailing list