M0 constants segment, deref, and value vs pointer registers

[Nathan Brown]

Hey Jimmy,

Thanks for taking a look. My comments are inline below.

On Tue, Apr 10, 2012 at 11:51 AM, Jimmy Zhuo <jimmy.zhuo at gmail.com> wrote:
>> Hey,
>
>
>
>> I just wanted to pass along a note that my m0 branch:
>
>> https://github.com/nbrown/parrot/tree/m0-c-double-deref is currently
>
>> passing all m0 tests in the repository using my double deref approach
>
>> discussed below.
>
>>
>
>> I'm going to continue working on cleaning up the code and getting
>
>> closer to the spec, but I thought other people might like to see it.
>
>
>
>> -Nate
>
>
>
> I’m not a expert, so I may be wrong. Here is my thought:
>
> 1. If double deref must be used here, then we should modify M0 spec to avoid
> it.

To avoid the double deref, I'd suggest that we introduce a new op
(load_const) that knows how to handle different constant types so that
we don't have to create special cases for deref that handle constants
differently than registers.

Also, the spec about the constants section states "Data can be either
an integer, a floating point number, a quote-delimited utf-8 string,
arbitrary data in hex notation or the name of a chunk." Right now, the
perl and c implementations differentiate between the constant data
types by the size of the constant and if it's string-like by the
string encoding. This isn't going to work with the arbitrary hex
notation since it could be any size. We probably need to add type
metadata to all constants.

Personally, I kinda like the simplicity of the double deref and
wouldn't change it unless it has performance issues that we need to
avoid. I keep going back to the M0 design goals: "M0's simplicity
should be extreme; the moment M0 gets ops for the sake of developer
efficiency or ease of use, it has failed its design goals." and I feel
that the double deref approach meets this goal.

>
> 2. I don’t like type conversion(casting) everywhere either, I think we can
> avoid it through the other way too.
>

If we're going to store all data types in the uint64_t registers, then
the casting will be required for most operations. There's simply no
way to avoid it. There's probably some ways to optimize the amount of
casting in my code, but I took the straightforward approach to make
everything work.

Right now, I'm taking a swing at cleaning up the spec (there's some
inconsistencies) and adding some details about how things work. But I
still have some questions about how things like the interpreter in
memory layout works. Basically, the spec seems to suggest some things
in the interpreter and associated config data contain arrays without
array sizes and I don't understand how that could work.

>
>
> And we really need more eyes and more love on M0 spec and M0 implementation.
>

I agree and I thought I could help stimulate conversation by providing
a working implementation that is close to the spec.

>
>
> Regards,
>
> Jimmy Zhuo
>
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

Thank you very much,
Nate