[M0] request for feature

Vasily Chekalkin bacek at bacek.com
Mon May 28 01:07:52 UTC 2012


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


More information about the parrot-dev mailing list