[M0] request for feature

[kjstol]

(Sorry, did a reply only not reply-all; below my reply, and cotto
replied to that)

I think a more simple isgt/islt I0, I1, I2 would be more fundamental,
and useful throughout I think. Probably easier to analyse as well, to
keep control flow with simple control structures that exist. The
proposed 2/3 way op _always_ jumps, but you don't always need that.

cheers
kjs

(cotto's reply:)

There could be a place for an isgt/isge or islt/isle pair in M0.  Having
both isgt and islt is redundant because one is easy to implement in
terms of the other when you've got a compiler to swap arguments as
appropriate. If there's a reason to include both that I'm missing, I'm
open to it.  If not, we can add a pair to the spec if nobody comes up
with something better soonish.

jmpif is nice because code will often be jumping around based on the
result of a comparison.  If you don't want to jump, it's easy to avoid
that with labels.  Adding a special register to store the result of
comparisons would allow jmpif to be fully general at the cost of a bit
of magic and an extra instruction.  This is just a random idea before I
drift off to sleep and will probably seem like a bad one tomorrow.



On Mon, May 28, 2012 at 2:28 AM, Christoph Otto <christoph at mksig.org> wrote:
> M0 only has three-argument ops, but this could be emulated with an op
> that didn't jump in one case:
>
>    jmpif I0, label_gt, label_lt
> label_eq:
>    # I0 == 0
> label_gt:
>    # I0 > 0
> label_lt:
>    # I0 < 0
>
> On Mon, May 28, 2012, at 11:07, Vasily Chekalkin wrote:
>> Hello.
>>
>> Three way jmpif is something like:
>>
>> jmpif $I0, label_le, label_eq, label_gt.
>>
>> Compare $I0 to zero and jump to corresponding label.
>>
>> So, example usage will be
>>
>>   $I99 = $I1 - $I0
>>   jmpif $I99 le_zero, eq_zero, gt_zero
>>
>> le_zero:
>>   ...
>>
>> eq_zero:
>>   ...
>>
>> gt_zero:
>>   ...
>>
>>
>> --
>> Bacek
>>
>> --
>> Vasily
>>
>> On Fri, May 25, 2012 at 9:27 PM, kjstol <parrotcode at gmail.com> wrote:
>> > hi,
>> >
>> > the problem is, there needs to be a *directional* comparison. just
>> > checking whether somethign is equal or not doesn't help to implement
>> > the > operator for instance. You can do tricks with subtracting
>> > numbers from itself, but you need to check which side you are of 0...
>> >
>> > Same for neg: x = -x.
>> > There's no way to do this without at least a gt or lt op, unless
>> > there's a neg op.
>> >
>> > (try it out :-)
>> >
>> > Not sure what tristate means btw...
>> >
>> > I had a quick look around in other vms and jit engines and it seems
>> > that lt and gt are always present as basic ops. I don't see a problem
>> > adding one of them (or > and < both) as they're very straightforward
>> > and will likely JIT-compile to a single CPU instruction.
>> >
>> > cheers
>> > kjs
>> >
>> > On Fri, May 25, 2012 at 12:19 PM, Vasily Chekalkin <bacek at bacek.com> wrote:
>> >> Hello.
>> >>
>> >> What about tristate cmp and trilabel jmpif? :)
>> >>
>> >> (Half jocking there)
>> >>
>> >> Bacek
>> >>
>> >> On May 25, 2012 8:55 PM, "kjstol" <parrotcode at gmail.com> wrote:
>> >>>
>> >>> hi there,
>> >>>
>> >>> I'm making nice progress on M1, the C-like language that compiles to M0.
>> >>> However, I'm missing an essential op in M0, which is a comparison op
>> >>> like < or >. At least one of them is necessary in order to implement
>> >>> the <, >, <=, >= operators. the unary minus (-x) also could use it,
>> >>> but adding a "neg" opcode would be sufficient for that of course.
>> >>>
>> >>> So, the request is to add at least 1 op to M0, namely either ">" or
>> >>> "<". (gt, lt). Both is preferable, but if it's essential to keep the
>> >>> number of ops to a minimum, then 1 is fine. (One could argue that we
>> >>> could get rid of "mul_i" as that can be implemented by repeatedly
>> >>> adding... :-)
>> >>>
>> >>> best regards,
>> >>> kjs
>> >>> _______________________________________________
>> >>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev