[Vm-dev] primFailCode currently dormant?

Eliot Miranda eliot.miranda at gmail.com
Mon May 3 00:43:56 UTC 2010


On Sun, May 2, 2010 at 11:47 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 2 May 2010 21:23, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Fri, Apr 30, 2010 at 10:56 PM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >>
> >> Hello,
> >>
> >> Alien adds a new primitive pragma:
> >>
> >> <primitive: 'foo' error: tempName module: 'bar' >
> >>
> >> where tempName is auto-declared during parsing as a special temp which
> >> will be used to retrieve primitive error code. i.e.
> >>
> >> myMethod
> >>  <primitive: 'foo' error: code module: 'bar' >
> >> "prim failed , check the error code"
> >>  code = 5 ifTrue: [ self error: 'you wrong' ]
> >>  code = 666 ifTrue: [ self error: 'you are wrong as hell' ]
> >>
> >>
> >> The problem is, that i found that while its integrated in parser
> >> (through Alien package overrides),
> >> it leads to nowhere in current Interpreter. :(
> >
> > But it's fully supported in the Newspeak VM and in the Cog VMs.  Please
> don't delete this.
>
> i won't. I like being told by prim, _why_ its failed.
> I just don't like that this is currently dormant.
>
> >>
> >> The sole reference to primFailCode is only in #primitiveFailFor: ,
> >> which actually should be used by prims to set the failure code:
> >>
> >> Interpreter>>primitiveFailFor: reasonCode
> >>        "Set specific primitive failure."
> >>        primFailCode := reasonCode.
> >>        self primitiveFail.
> >>
> >>
> >> I'd like to propose an alternative implementation:
> >>
> >> - at VM side , add only a single primitive:
> >> primitiveLastFailureCode
> >>        self export: true.
> >>        self pop: 1 thenPush: (self integerObjectOf: primFailCode).
> >>        "reset the code"
> >>        primFailCode := 0.
> >>
> >> At language side, we can support both, old and new format:
> >>
> >> Add the method , which will retrieve the code:
> >>
> >> Object>>lastFailureCode
> >>  "Primitive: answer the last primitive failure code. Resets the failure
> code.
> >>  Note: it can fail only if we're running on older VMs, which has no
> >> support of this primitive, if so, answer the generic failure code"
> >>  <primitive: 'primitiveLastFailureCode' module: ''>
> >>  ^ 0
> >>
> >>
> >>
> >> And then, to handle things manually, one could use:
> >>
> >> Myclass>> foo
> >>   <primitive: 'myprimitive' module: 'mymodule>
> >>   "we're failed"
> >>   | code |
> >>   code := self lastFailureCode.
> >>   ... handle the error code...
> >>
> >> And to support the Alien's new pragma pattern (primitive:error:module:)
> >> it can simply instruct the encoder to generate an implicit bytecode
> >> sequence (at method's beginning), which equals to:
> >>   temp := self lastFailureCode.
> >> (where temp, is one, which used in pragma)
> >>
> >> What you think?
> >
> > This is bad for a number of reasons, primarily thread-safety.  There's
> nothing to guarantee that the prim fail code is accessed before a process
> switch which could cause the error code to get overwritten.  Instead if you
> wanted to do something in this area you could get the Newspeak VM and start
> integrating the code there-from.
>
> Yes. This might be an issue.
> I thought, there is no chance interrupting it between
> - current prim fail - enter a method - do a #lastFailureCode send
>
> or it is?
> If i remember, an interrupt check performed only on a normal return
> from method.
>

Going by the old Teleplace interpreter interrupts are checked on activating
a method, which includes a failing method.  See senders
of internalQuickCheckForInterrupts & quickCheckForInterrupts. i.e whenever a
frame is built for a send. This is indeed between the primitive invocation
and the send of lastFailureCode.



> And a normal return can't happen anywhere between the above stages.
>
>
> I remember your description of setting a temp value with failure code.
> Its cool from language side perspective, but ugly & complex at VM side
> (i can imagine how ugly and complex that code may look like where have
> to crunch a lot of bits and do many various checks before attempting
> to store code into temp).
>

Its not at all complicated.  Find the code in the Newspeak VM.  The code to
load the temp is likely also in the Closure compiler already.  Here's the
code in internalActivateNewMethod as described on my blog:


        “Pass primitive error code to last temp if method receives it
(indicated
         by an initial long store temp bytecode). Protect against obsolete
values
         in primFailCode by checking that newMethod actually has a
primitive.”
        primFailCode ~= 0 ifTrue:
                 [((self methodHeaderHasPrimitive: methodHeader)
                  and: [(self byteAtPointer: localIP + 1) = 129 "long store
temp"]) ifTrue:
                          [errorCode *:=* self
getErrorObjectFromPrimFailCode.
                           self longAt: localSP put: errorCode "nil if
primFailCode == 1, or primFailCode"].
                 primFailCode *:=* 0].


> > But I'm now in a position to put some effort into open sourcing Cog,
> having completed my current Teleplace assignment, and so perhaps being
> patient and waiting a little longer is the best approach.  In the mean time
> please don't change any of the primitive fail code stuff.  Its fully
> functional in the code we're using at Teleplace and in Newspeak and it would
> be good to avoid incompatibilities.
>
> well, my proposal actually don't requires altering existing code.
> It just adds a prim, which exposing the failure code value to language
> side.
>

Alas in a way that can't provide reliable access given the VM's current
interrupt response.  I don't mean to frustrate you, but I do hope to get my
code out soon.

best
Eliot



>
> > best
> > Eliot
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko AKA sig.
> >>
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100502/ca2bf1d2/attachment-0001.htm


More information about the Vm-dev mailing list