(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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >> Hello. >> >> >> >> What about tristate cmp and trilabel jmpif? :) >> >> >> >> (Half jocking there) >> >> >> >> Bacek >> >> >> >> On May 25, 2012 8:55 PM, "kjstol" <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
