On Fri, Mar 28, 2008 at 1:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Fri, Mar 28, 2008 at 10:51:16AM +0100, Klaas-Jan Stol wrote: > > Attached is a patch implementing: > > > > * ++ and -- postfix operators, implemented as n_sub and n_add (taking > > "1" as the 3rd operand), this is because each instruction must have an > > output register as far as I can tell (so "inc"/"dec" won't work). > > It really needs to be inc/dec. And not only that, but the output > value of postfix ++ and -- needs to be the value _before_ the > inc/dec operation. So the PIR code for postfix:++ should be > something like: > > %r = clone %0 > inc %0 >
Yes, that's right. I was too quick. > Also, they need to have the "is lvalue(1)" trait so that PAST > knows that the operand is to be treated as an lvalue. > is this really necessary? It seems to work without. This is also a problem when writing "1++"; not sure if this is allowed, but the grammar allows it. PAST::Val doesn't have an lvalue method. > > > I wasn't sure how to implement +=; how to spell that? (as there's only > > a ":=" operator right now). I figured that ++ and -- are probably more > > used anyway, and if you want to += 2, then you can always use the > > normal assignment syntax. > > Ideally += should be implemented as the two-argument 'add' opcode > in PIR... something like > > add %0, %1 > > But the PAST compiler doesn't yet have a great way for distinguishing > a 2-argument add from a 3-argument add. We can get close with > > add_p_p %0, %1 > > but of course that means that an expression like += 2 would end up > creating a PMC for the 2 constant. And PAST needs a way to know > that the result is in the %0 argument as opposed to a new > unique register (this is planned but not yet implemented). maybe the PCT can include optimizations to remove the creation of PMCs for constants? > > > * <, <=, > and >= operators > > The relational ops in the patch appear to be using iseq and > isne; I think it would make more sense for them to use islt, > isle, isgt, isge. is there any reason that == and != have to use cmp_num, and not use iseq and isne directly on the operands? reasons I used iseq and isne, is that cmp_num returns -1, 0 or 1, so I checked for these return values. I think, if the new rel.ops can use islt and friends, then == and != can use iseq and isne directly too without cmp_num, right? > > Also, we should have tests for all of the above. > > Thanks! > > Pm > kjs
