>
>
> On Mon, Mar 21, 2011 at 12:13 PM, Mariano Martinez Peck
> <[hidden email]> wrote:
>>
>>
>> On Mon, Mar 21, 2011 at 7:23 PM, Stéphane Ducasse
>> <[hidden email]> wrote:
>>>
>>> This would be a nice little topic... this bytecode verifier.
>>
>> Probably on top of Opal
>
> The bytecode verifier must be in the VM.  If it is up in the image it can be
> side-stepped.  The VM is the ultimate executor of code and so it must apply
> verification.  It could be written in Smalltalk and verified in Smalltalk
> and then translated.  But it must be part of the VM and used by the VM
> before running any previously unverified method.

> best,
> Eliot
>>
>>
>>>
>>> Stef
>>>
>>> On Mar 21, 2011, at 2:57 PM, Toon Verwaest wrote:
>>>
>>> > Yes you are right! Bytecode validation would be very important here. If
>>> > you ask me, the VM should only allow verified bytecode to be executed. Here
>>> > it could have a dual model, where bytecodes are "internalized" whenever you
>>> > give them to the VM first. At that point they are validated. Once it's
>>> > internalized, it can't be modified anymore from the outside, since the
>>> > Smalltalk world doesn't have direct access to the internalized version. All
>>> > changes to the bytecode "source", needs to be propagated to the VM by
>>> > re-internalizing it.
>>> >
>>> > This is exactly the model I'm using in Pinocchio... and that allows us
>>> > to not use bytecodes in the first place :) You just need a way to map the
>>> > internal version back onto the highlevel version for debugging. (We don't
>>> > verify the bytecode yet though).
>>> >
>>> > Bytecode verification btw shouldn't be too hard. You just need to make
>>> > sure that all the codes are safe for the instance at hand, and for the
>>> > method contexts you create. Anything else is just a runtime semantical error
>>> > which you can't guarantee, since you don't know what the programmer is
>>> > trying to do. We don't verify it yet since I'm still designing my
>>> > register-based bytecodes; and since I atm have too much work at hand :)
>>> >
>>> > cheers,
>>> > Toon
>>> >
>>> > On 03/21/2011 02:22 PM, Igor Stasenko wrote:
>>> >> On 21 March 2011 13:14, Toon Verwaest<[hidden email]>  wrote:
>>> >>> I couldn't agree more!
>>> >>>
>>> >>> However, here the problem is not that the format isn't a correct
>>> >>> format. The
>>> >>> problem is that a bytecode is activated that is incompatible with the
>>> >>> instance format. So basically on every bytecode accessing an instance
>>> >>> you
>>> >>> would have to check if this is a valid access. And as we all know,
>>> >>> Smalltalk
>>> >>> avoids this; it makes things faster :)
>>> >>>
>>> >> In other words, a responsibility of having correct bytecode lies on
>>> >> image side, not on VM side.
>>> >>
>>> >> Adding a bytecode verifier to VM will be a lot of work.. And of course
>>> >> it could verify it only when you installing a method,
>>> >> not when you activating it.
>>> >>
>>> >>> Toon
>>> >>>
>>> >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote:
>>> >>>> On 21 March 2011 11:29, Tudor Girba<[hidden email]>    wrote:
>>> >>>>> Thanks, Toon!
>>> >>>>>
>>> >>>>> I changed the code to explicitly set the format, and it seems to
>>> >>>>> fix the
>>> >>>>> problem:
>>> >>>>>
>>> >>>>>        cls := Class new superclass: MooseElement;
>>> >>>>>                setFormat: MooseElement format;
>>> >>>>>                yourself.
>>> >>>>>        cls compileSilently: 'mooseName   ^ 1/0'.
>>> >>>>>        element := cls new.
>>> >>>>>
>>> >>>>> Is this correct?
>>> >>>>>
>>> >>>> Yes, you should pay attention to have correct format.
>>> >>>> But of course VM could also be more cautios  and verify if your
>>> >>>> class
>>> >>>> are well formed before creating an instance of it..
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>> Cheers,
>>> >>>>> Doru
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>
>