[OT][Q][VM][ENH][RFH][COMP] Request For Help : CompilerPlugin

Hans-Martin Mosner hmm at heeg.de
Fri Apr 5 19:45:26 UTC 2002


Tim Rowledge wrote:

> > a bytecode translator and native method cache which fit into the L2 cache of the
> > machine
> <minor rant>Without in any way intending to bash on hmm, this mercilessly cut phrase, taken out of the context of the original intent, reminds me ofa little peeve of mine. I often seem to see people espousing the idea that we can 'make the vm fit into the cache' or 'if we get the method lookup table to fint the cache' as if it is possible to get a specific chunk of memory into a typical cache and lock it there. T'ain't so, at least not typically. Caches do their own thing according to some hardware decisions (which occasionally include allowing some software input) made years ago when your cpu was being designed. Often caches use virtual addresses, or load groups of memory addresses, or get messed up by those pesky interrupt handlers.. all sorts of thing happen to make pretty sure you don't get your application or even a recognisable portion of it into any cache at any particular time. Now a writable control store is a horse of a different kettle altogether. Don't see many o!
> f them about these days.
> </minor rant>

Tim, you're the hardware guy, you know more about caches than I ever would aspire to know, and I retract everything I wrote obviously under the influence of some very weird substance :-) And please don't hesitate to bash on me when necessary!
For some very special situations and on really few processors, caches can be tamed so much as to be adequately useful. IIRC, there are ways to control the cache on some MIPS processors so that a number of cache lines is never flushed out, which can be used for example to keep performance-critical task switch code for a microkernel always in cache. Of course, you can only do that if the code in question is only a couple dozen instructions.
Regarding writable control stores: Has anybody been able to peek under the hoods of the mythical Crusoe processor family? Just emulating x86 family machines seems so boring, but they seem to be able to do it with reasonable performance. Wouldn't it be much nicer to emulate a ST-80-stype bytecode virtual machine on that hardware?

> > We (Georg Heeg, Michael Rueger, yours truly and some people whose names escape me
> > at the moment) ported PS to the PCS Cadmus UNIX workstation and to the Atari Mega
> > ST, which was a fun project in itself, and really usable for quite some stuff :-)
> Oh, yeh, great graphics performance for the day. IIRC it was the only machine able to beat my self-compiling bitblt on the early Acorn machines. Fun days.

Do you mean the Atari, or the PCS machines? On the PCS, we had a second processor for the BitBlt stuff and a queue for BitBlt commands, which made the interactive performance really snappy. It felt like a real Dorado :-) The later HPS ports to MIPS-based PCS machines were even better...
In our current MacOS X VisualWorks port, we implement a queue for graphics operations again (out of necessity: the event handling thread is unsuitable to run the VM, some MacOS X graphics operations just don't work correctly when done from the second thread, so we need to pass graphics back from the VM thread to the primary thread). I'd really like to know how that VM would perform on a dual processor machine where these threads are really concurrent.

Cheers,
Hans-Martin






More information about the Squeak-dev mailing list