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

Eliot Miranda eliot.miranda at gmail.com
Fri Feb 22 04:42:58 UTC 2013


On Thu, Feb 21, 2013 at 4:23 PM, tim Rowledge <tim at rowledge.org> wrote:
>
>
> On 21-02-2013, at 12:09 PM, 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...
>>
>
> Humour-transmission-by-email-error; I really ought to add something to the RFC. You'd think with 40-some years of cranky geeks writing emails we'd have invented a decent way to handle it. Then again, look how much effort it takes to get us to use decent tools for anything.

:) :) :) :) now I understand.  Forgive my humour impairment.  I blame ascii.


>
>>
>> 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.
>
> Excellent idea. It would work for time logging too, surely, which would be helpful to me right now. It sounds not unlike the nice trick Craig did to catch used methods for making Spoon, at a guess.
> But - and you just knew there'd be a but - why not just use one (or more?) of the currently unused ones explicitly for this purpose?  I'm thinking that having instructions that record the coverage without the potential expense of trapping might be easier to live with.  Sort of a known-unknown bytecode, to paraphrase that master of English language (and indeed, real) torture. If you had (and I'm betting you do) a way to swap bytecode table easily, then in one table the instruction would be a nop and in the other, the known-unknown. Once you're done with the tools, a recompile could get rid of them entirely, if that were desired. I guess with your translator it isn't all that important to get rid of a few nops in the bytecode stream.
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful Latin Phrases:- Furnulum pani nolo = I don't want a toaster.
>
>



-- 
best,
Eliot


More information about the Vm-dev mailing list