M0 single deref

Nathan Brown nbrown04 at gmail.com
Wed Apr 25 15:01:46 UTC 2012


Thanks for the comments Jimmy.

I know that the length assumption about the constants is bad, but there's currently no specced way to differentiate, so I decided to stick with the old implementation until we pick a new one.

As for the PC, the spec needs to describe how the PC gets incremented so that tests like the poke_caller tests which manipulate PC explicitly work correctly. Before I started working on m0, the perl implementation incremented by 1 and the c by 4. This means that they both couldn't pass the same poke_caller test. So I changed the c implementation to increment PC by one on each iteration of the run loop. Then I updated the spec to explicitly state that. I think this is the way to go. If not, the spec needs to explicitly say increment by 4 and we need to fix the perl implementation and poke_caller test.

Nate

On Apr 25, 2012, at 8:20 AM, "Jimmy Zhuo" <jimmy.zhuo at gmail.com> wrote:

> Hello Nathan Brown,
>      I’m glad that you’re working on m0. But I’m sure you’re passing the tests with a wrong implementation.
> First, take a look at https://github.com/nbrown/parrot/commit/6a75a09a24d410b01ac68eb6ca0765a30a899e0c . It assumes that the length > 8 is pointers and < 8 is consts, which is a wrong way, unless you have a good reason.
> Second, take a look at https://github.com/nbrown/parrot/commit/fa5c366a7384acafbf59f3a631613af1a23534f0 . It changes the spec, the Spec says, “PC - current instruction within the current bytecode segment”. That is, the PC must point to a instruction head, that’s why goto needs to be ‘*4’. Why must use ‘*4’? Let’s take a look at the instructions flow:
>  
> --------------------------
> |OP|I1|I2|I3|OP|I2|I4|I5|
> --------------------------
>  
> If you are ‘*4’, and PC can always point to OP, but if you not, and you use ‘goto’, that may makes PC to point I3, which makes instruction looks like ‘I3 OP I2 I4’, which is wrong.
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20120425/2064d688/attachment.html>


More information about the parrot-dev mailing list