On Thu, Apr 12, 2012 at 7:31 AM, Nathan Brown <[email protected]> wrote: > > On Wed, Apr 11, 2012 at 8:44 AM, Jimmy Zhuo <[email protected]> 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
Oops, that link doesn't help much, I meant to say the Register Types and Call Frame Structure section of https://github.com/parrot/parrot/blob/m0/docs/pdds/draft/pdd32_m0.pod I don't know how to link to a specific pod section on github. > > 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 > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
