[Vm-dev] VM Maker: VMMaker.oscog-eem.267.mcz

Eliot Miranda eliot.miranda at gmail.com
Thu Feb 21 21:49:48 UTC 2013


On Thu, Feb 21, 2013 at 12:57 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>
> On 21 February 2013 20:09, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> On Thu, Feb 21, 2013 at 11:24 AM, tim Rowledge <tim at rowledge.org> wrote:
>>>
>>>
>>> On 21-02-2013, at 11:10 AM, commits at source.squeak.org wrote:
>>>> Implement unknownBytecode.
>>>
>>> If you implement all unknown bytecodes then you won't need to...
>>
>> First of all, in the Newspeak VM using the augmented SqueakV3 bytecode
>> set all the bytecodes are implemented.
>>
>> Second of all, in the current newspeak VM we support two bytecode sets
>> and that second set has bytecodes to spare, and were the same approach
>> taken for Squeak there would be lots of bytecodes to spare for
>> experimentation.
>>
>> Third, I can think of a couple of uses for unknownBytecode as
>> implemented above.  My current idea is to use it for a basic-block
>> coverage tool. Pepper a method with single-byte unknown bytecodes at
>> the start of each basic block, storing the original bytecodes in
>> properties. Now let the test suite run, and respond to unknownBytecode
>> by recording the coverage, restoring the old bytecode and continuing.
>> The same scheme can implement breakpoints.  But it depends crucially
>> on having a single bytecode that raises an exception.  For example, at
>> Cadence our current bytecode sequence is a clumsy three-bytecode one,
>> push false, long jump true 0, which gets rewritten into push self,
>> send breakpoint, pop.  Flipping a byte between a one-byte nop and a
>> one-byte unknown bytecode would be nicer.
>
> So this functions kind've like INT3 / CC?

Right, that's the hope :)  But it's not aggressively tested yet.  I
have to try and overwrite any kind of bytecode with it and see if
things are OK.  One simplification is that the JIT refuses to have
anything to do with unknown bytecodes and so methods containing them
are always interpreted.

>
> frank
>
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>> No one is listening until you make a mistake
>>>
>>>
>>
>>
>>
>> --
>> best,
>> Eliot



-- 
best,
Eliot


More information about the Vm-dev mailing list