M0 constants segment, deref, and value vs pointer registers

[Jimmy Zhuo]

> 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.

No, I think double deref is tricky and hacky. And I want to add type
metadata to all constants at first, but I think it's not necessary after I
added deref_i, deref_n, deref_s.

> 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.

So I just push a new JimmyZ/m0 branch, I think different type values should
be stored in different registers, so I borrow Regs from parrot. And
introduced new ops, such as deref_i , deref _n, deref_s. I'm fine to add
some new ops which is like add_i and add_n. It avoids type conversion
everywhere and double deref. I hope m0 is strong type, since its users(such
as Perl 6) will be strong type too. But, I'm not sure I'm right, maybe the
M0 designer had considered it and had a better way but he did not describe
it in the spec. And I'm expecting it. :)

Regards,
Jimmy Zhuo