And ...
I should mention that the origin of the bytecode interpreters was the hardware of the Burroughs B5000, first described in print in 1961. I used this as a model for the Flex machine in the late sixties, including the idea of overlapping contexts (it's a direct consequence of one way to have the compiler map the stack). The B5000 also had HW flag bits to distinguish its typed pointers from data, the ability to call procedures on the left side of an assignment statement (so many kinds of data could be simulated), automatic HW process switching, addressless bytecodes, segmented swappable memory structures, etc. It was designed by one of the great geniuses of our field (and unfortunately not remembered today), Bob Barton.
Cheers,
Alan
--------
At 7:34 PM -0800 3/29/00, Dan Ingalls wrote:
I wrote...
I'm sure this is true. Ian wrote a context cache for an earlier Squeak and
it sped th
ings up by about 50% as I recall. What we have now is nicely simple, and
we've been h
olding off on any serious tweaks until we can play around with J3 (How's it going, Ian?). J3 does even better things with the stack, which
allows the b
asic interpreter to remain simple, yet offers a true high speed solution as
well.
Tim Rowledge tim@sumeru.stanford.edu replied...
It's a relatively standard trick, with the first description that I know of being the Deutsch/Schiffman 'Efficient Implementation of the Smalltalk-80 System' paper in 84 POPL proceedings.
If we are talking about putting contexts in the hardware stack, I did this half a decade earlier. Smalltalk-78 ran on a 4MHz 8086(*). The VM was 6K of code. And it put its contexts right in the hardware stack. I also used the trick of overlapping adjacent contexts so there was no need to transfer arguments (Ian and I have been discussing doing this for Squeak -- it requires pushing the receiver last instead of first).
You can read this and other tales of early Smalltalk VMs in my chapter of the "Green" book edited by Glenn Krasner.
- Dan
squeak-dev@lists.squeakfoundation.org