On Tue, Apr 3, 2012, at 19:45, Nathan Brown wrote: > On Mon, Apr 2, 2012 at 6:12 PM, Christoph Otto <[email protected]> > wrote: > > On Sun, Apr 1, 2012, at 23:51, Brian Gernhardt wrote: > >> > >> On Apr 1, 2012, at 11:17 PM, Jimmy Zhuo wrote: > >> > >> > I just realized that M0 is stack based. M0 is dedicated to use the > >> > least op to do the work, it's extreme makes it being stack based, > >> > not register based. If the latter is more advanced, then it's a > >> > retrogression. Here is some compares: > >> > > >> > M0: > >> > set_imm I0, 0, 123 > >> > set_imm I1, 0, 356 > >> > add_i I2, I1, I0 > >> > >> > CPU-ish: > >> > mov %eax, 123 > >> > add %eax, 356 > >> > or > >> > add %eax, %ebx > >> > or > >> > add %eax, [0] # [0] is memory unit. > >> > or > >> > add [0], %eax # [0] is memory unit. > >> > > >> > In M0, we can't do this: > >> > add_i I2, 123, 356 > >> > >> I have thought it would be nice if M0 had some concept of addressing > >> modes. Indirect, indexed, and immediate are things that jump to mind > >> quickly. They could be handled by the core runloop before dispatching > >> off to the ops for simplicity. > >> > >> ~~ Benabik > > > > The big goal of M0 is stupid simplicity, but I also don't want > > meaningfully efficient execution to require an optimizing assembler. > > Adding addressing modes isn't out of the question. > > > > I'm busier than I should be at the moment, but I'd love to see an > > experiment with addressing modes. If either of you have the time, > > please feel free to fork the m0 branch and hack out something on > > the Perl interpreter. This kind of experimentation is exactly > > what it's for. > > > > Christoph > > > I think that the changes Jimmy is proposing are interesting, but I'd > like to continue to pursue the ideas described in the spec if there's > any value in it. The commits made to the m0 branch over the last week > by Jimmy are clearly pursuing the new direction so I was wondering, > where should changes that are sticking closer to the existing spec go? > > -Nate >
I've been too busy to review his commits to the m0 branch (though I'll endeavor to do so as soon as I have a free hour), but the m0 branch should very much stay with the current spec. If Jimmy's moving in a different direction, he should start a new branch. Experimentation in branches is highly encouraged and I'm glad to see it, but the "m0" branch should be the integration point for M0-related work, not the place where new directions get tested. Christoph _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
