M0 constants segment, deref, and value vs pointer registers

Nathan Brown nbrown04 at gmail.com
Thu Apr 12 11:31:20 UTC 2012


On Wed, Apr 11, 2012 at 8:44 AM, Jimmy Zhuo <jimmy.zhuo at gmail.com> wrote:
>> 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.

Offering deref_i, deref_n, deref_s, etc won't help with this issue. The issue stems from how the constants are loaded from the m0b file and stored in the interpreter memory. Assuming the deref op has a single meaning whatever it's operation on, there are two ways to handle this: 1) with a new op that does the appropriate thing depending on the constant type or 2) change the way that the constants section is loaded out of the m0b file and into the interpreter memory. Either way would require type metadata associated with each constant so that the interpreter or op would know how to do the right thing.



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

The authors of the spec did explicitly say that any type of data could be stored in any register and the type associated with each register is merely a convention. See the third paragraph of: https://github.com/parrot/parrot/blob/m0/docs/pdds/draft/pdd32_m0.pod#___top

I kinda like being able to use a register to store any type. It allows things like:

set_imm S0, 0 0
deref      S0, CONSTS, S0

To get the string constant stored in the first constant slot. This allows for a smaller call frame since the number of registers allocated is supposed to be selectable by the M0 code generator (see paragraph 2 of the link above) but I don't see a way to specify it yet. This concept would be nice on embedded systems or for simpler HLLs.

-Nate



More information about the parrot-dev mailing list