Re: [Squeak-VMdev] Fw: Q: Lowest level VM changes

[Dan I. <Da...@Sq...>]

[forgot to cc the list on my reply...]

Hi, Ian (and all) -

Ian wrote...
>Dispatch bytecodes through a pointer to the bytecode table (identical to what gnuification generates for the inner loop at present anyway) and on creation of a float result push it onto the float stack and switch the dispatch pointer to the "floating bytecode set".  Arithmetic selectors continue to manipulate the float set until something non-arithmetic comes along, triggering a pop and box of the float stack onto the regular stack and a switch back to the regular dispatch pointer before continuing with whatever bytecode we're up to.

Yes, this is a very nice way to handle it.

>No compiler changes needed.
>
>Anton Ertl did something related (but different) in his vmgen, where parallel bytecode sets are used to represent the state of caching the topmost stack value in a register.

Yes, and so did my Apple Smalltalk back in 1985.

But your suggestion generalizes to a very nice way to integrate "volatile contexts".

Best of all (at least at this point), I don't think we need to add anything to the V4 project to get into this.

>With a little work this could maybe even be made to look fairly pretty in the source (with the parallel implementations generated automagically of the same source methods with compile-time conditionalised sections) and extended to work for SIs too (or even matrices if they were every to become a primitive type known to the arithmetic selectors directly).
>
>(Of course, the right solution is to generate and execute in native code and do minimal dataflow analysis and method splitting to keep everything unboxed and in registers as much as possible.  But I digress...)

No, no... please go on!...  ;-)

	- Dan