Alternative bytecode sets demo request
Locked
 
|
I'm shooting in the dark here since its a bit hard to grasp... a. The implications of support alternative bytecode sets * Do the alternative bytecode sets run in parallel to normal Pharo bytecodes? * Can the bytecode sets be loaded adhoc/dynamically into an Image? or only compiled into the VM? b. How to implement/work with alternative bytecodes For (a.) I guess an exciting opportunity is facilitating an Ethereum virtual machine running as a Process inside a Pharo image, managed by tools written in Pharo. Other languages are already getting in a party which would be good for Pharo to join. In such a revolutionary domain I expect people are more willing to experiment with alternative systems like Pharo, and I bet Pharo could excel in that domain. To help (b.), would it be feasible to blog a mini-demo showing how to install/use alternative bytecodes? maybe for something like this simple RPN calculator substitute for "arith.c"... (a calculator demo could be an interesting adjunct to Sven's calculator tutorial...) cheers -ben |
Re: Alternative bytecode sets demo request
|
|
Hi Ben,
On Sun, Dec 3, 2017 at 6:08 PM, Ben Coman <[hidden email]> wrote:
Yes. There's a single bit in the header of a compiled method that selects between two bytecode sets. In current Squeak and Pharoi VMs, if the bit is unset then the normal bytecode set is used, and if the nit is set, the Sista bytecode set is used.
Only compiled into the VM.
In Squeak there are class-side accessors in CompiledCode. See CompiledCode class>>installSecondaryBytecodeSet:. Note that the support isn't quite finished yet. I hope to have the Sista vytecde set ready for the next release of Squeak. Clément is providing it in Pharo. In Squeak the BytecodeEncoder hierarchy implements the necessary support for multiple bytecode sets. Via CompiledCode class>>installSecondaryBytecodeSet: the system is informed as to which bytecode set to use. This must match the bytecode set(s) that are in the VM. Classes beneath BytecodeEncoder, in particular EncoderForV3PlusClosures and EncoderForSistaV1 (in package BytecodeSets at http://source.squeak.org/VMMaker) encode the current and the Sista sets respectively.
That's not how this will work. Essentially it is transparent. Once the bytecode set support is installed in the compiler one simply compiles Smalltalk (or anything else that produces parse trees that can be output to compiled methods via the BytecodeEncoder hierarchy) and the method will be output in the currently selected bytecode set. So it's not something one plays around with, unless that is, one is developing the bytecode set in the Vm sim,letter.
_,,,^..^,,,_ best, Eliot |
Re: Alternative bytecode sets demo request
|
|
To use the alternate bytecode set in Pharo 7 use:
Currently in Pharo SqueakV3PlusClosure and SistaV1 are installed in CompiledCode. You need to install another set if you want to use it using #installSecondaryBytecodeSet: or similar methods. CompiledMethod installSecondaryBytecodeSet: EncoderForMyBytecodeSet. Then you can just use the first code snippet to use it: CompilationContext bytecodeBackend: EncoderForMyBytecodeSet. OpalCompiler recompileAll. On Mon, Dec 4, 2017 at 3:48 AM, Eliot Miranda <[hidden email]> wrote:
Clément Béra Pharo consortium engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq |
|
|
In reply to this post by Eliot Miranda-2
On 4 December 2017 at 10:48, Eliot Miranda <[hidden email]> wrote:
> Hi Ben, > > On Sun, Dec 3, 2017 at 6:08 PM, Ben Coman <[hidden email]> wrote: >> >> I'm shooting in the dark here since its a bit hard to grasp... >> a. The implications of support alternative bytecode sets >> * Do the alternative bytecode sets run in parallel to normal Pharo >> bytecodes? > > > Yes. There's a single bit in the header of a compiled method that selects > between two bytecode sets. In current Squeak and Pharoi VMs, if the bit is > unset then the normal bytecode set is used, and if the nit is set, the Sista > bytecode set is used. That clarifies things a lot. So I guess the main advantage of this bit is making it easier to: a. incrementally develop and test new bytecodes? b. transition the Image between bytecode sets? >> * Can the bytecode sets be loaded adhoc/dynamically into an Image? >> or only compiled into the VM? > > > Only compiled into the VM. > >> >> b. How to implement/work with alternative bytecodes > > > In Squeak there are class-side accessors in CompiledCode. See CompiledCode > class>>installSecondaryBytecodeSet:. Note that the support isn't quite > finished yet. I hope to have the Sista vytecde set ready for the next > release of Squeak. Clément is providing it in Pharo. > > In Squeak the BytecodeEncoder hierarchy implements the necessary support for > multiple bytecode sets. Via CompiledCode > class>>installSecondaryBytecodeSet: the system is informed as to which > bytecode set to use. This must match the bytecode set(s) that are in the > VM. Classes beneath BytecodeEncoder, in particular EncoderForV3PlusClosures > and EncoderForSistaV1 (in package BytecodeSets at > http://source.squeak.org/VMMaker) encode the current and the Sista sets > respectively. Can more than two bytecode sets be compiled into the one VM? i.e. Is a bytecode-set hard coded into position, or is it more like a variable slot that can select between several bytecode sets compiled into the VM. For example, if someone wanted to experiment with implementing Ethereum bytecodes, would they first need to rip out either EncoderForV3PlusClosures or EncoderForSistaV1? Now I made the mistake once of thinking it was Sista introducing this bytecode-bit, (btw, how do you normally refer to it?) but IIUC Sista is just making use of the feature. So I'm curious historically when the bytecode-bit was introduced? cheers -ben > >> To help (b.), would it be feasible to blog a mini-demo showing how to >> install/use alternative bytecodes? maybe for something like this simple RPN >> calculator substitute for "arith.c"... >> * https://github.com/philipaconrad/mini-vm/tree/master/examples/arith >> * >> https://github.com/philipaconrad/mini-vm/blob/master/examples/arith/arith.c > > > That's not how this will work. Essentially it is transparent. Once the > bytecode set support is installed in the compiler one simply compiles > Smalltalk (or anything else that produces parse trees that can be output to > compiled methods via the BytecodeEncoder hierarchy) and the method will be > output in the currently selected bytecode set. So it's not something one > plays around with, unless that is, one is developing the bytecode set in the > Vm simulator. |
Re: Alternative bytecode sets demo request
|
|
Hi Ben,
> On Dec 4, 2017, at 4:17 AM, Ben Coman <[hidden email]> wrote: > >> On 4 December 2017 at 10:48, Eliot Miranda <[hidden email]> wrote: >> Hi Ben, >> >>> On Sun, Dec 3, 2017 at 6:08 PM, Ben Coman <[hidden email]> wrote: >>> >>> I'm shooting in the dark here since its a bit hard to grasp... >>> a. The implications of support alternative bytecode sets >>> * Do the alternative bytecode sets run in parallel to normal Pharo >>> bytecodes? >> >> >> Yes. There's a single bit in the header of a compiled method that selects >> between two bytecode sets. In current Squeak and Pharoi VMs, if the bit is >> unset then the normal bytecode set is used, and if the nit is set, the Sista >> bytecode set is used. > > That clarifies things a lot. So I guess the main advantage of this bit > is making it easier to: > a. incrementally develop and test new bytecodes? > b. transition the Image between bytecode sets? Exactly. >>> * Can the bytecode sets be loaded adhoc/dynamically into an Image? >>> or only compiled into the VM? >> >> >> Only compiled into the VM. >> >>> >>> b. How to implement/work with alternative bytecodes >> >> >> In Squeak there are class-side accessors in CompiledCode. See CompiledCode >> class>>installSecondaryBytecodeSet:. Note that the support isn't quite >> finished yet. I hope to have the Sista vytecde set ready for the next >> release of Squeak. Clément is providing it in Pharo. >> >> In Squeak the BytecodeEncoder hierarchy implements the necessary support for >> multiple bytecode sets. Via CompiledCode >> class>>installSecondaryBytecodeSet: the system is informed as to which >> bytecode set to use. This must match the bytecode set(s) that are in the >> VM. Classes beneath BytecodeEncoder, in particular EncoderForV3PlusClosures >> and EncoderForSistaV1 (in package BytecodeSets at >> http://source.squeak.org/VMMaker) encode the current and the Sista sets >> respectively. > > Can more than two bytecode sets be compiled into the one VM? > i.e. Is a bytecode-set hard coded into position, > or is it more like a variable slot that can select between several > bytecode sets compiled into the VM. For example, if someone wanted > to experiment with implementing Ethereum bytecodes, would they first need > to rip out either EncoderForV3PlusClosures or EncoderForSistaV1? It's hard coded. There could be more sets. This is Claus Gittinger's idea and in his VM there are two bits, allowing 4 sets. The implementation is simple. A variable holds the bytecode index times 256, and this is added to the bytecode on each dispatch in either the interpreter or the JIT. So in Claus' VM the bytecodes range from 0 to 1023. The variable must be set on every send and return. Obviously in jitted code it is effectively free. We were short of header bits and only needed one extra set so we support only two. > > > Now I made the mistake once of thinking it was Sista introducing this > bytecode-bit, > (btw, how do you normally refer to it?) but IIUC Sista is just making use > of the feature. So I'm curious historically when the bytecode-bit was > introduced? I added it with Claus when we were working on a project together in 2012. It was first used for Newspeak in 2013 or 2014 when I defined a set that supported the full range of Newspeak sends and lifted the number of literals and branch displacement limits. > > cheers -ben > >> >>> To help (b.), would it be feasible to blog a mini-demo showing how to >>> install/use alternative bytecodes? maybe for something like this simple RPN >>> calculator substitute for "arith.c"... >>> * https://github.com/philipaconrad/mini-vm/tree/master/examples/arith >>> * >>> https://github.com/philipaconrad/mini-vm/blob/master/examples/arith/arith.c >> >> >> That's not how this will work. Essentially it is transparent. Once the >> bytecode set support is installed in the compiler one simply compiles >> Smalltalk (or anything else that produces parse trees that can be output to >> compiled methods via the BytecodeEncoder hierarchy) and the method will be >> output in the currently selected bytecode set. So it's not something one >> plays around with, unless that is, one is developing the bytecode set in the >> Vm simulator. > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |