M0 design problem

[Christoph Otto]

On Tue, Apr 3, 2012, at 19:45, Nathan Brown wrote:
> On Mon, Apr 2, 2012 at 6:12 PM, Christoph Otto <christoph at mksig.org>
> 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