M0 design problem

[Nathan Brown]

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

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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev