thanks for the clarifications; attached an updated patch including some tests.
I left out += and friends for now. kjs On Fri, Mar 28, 2008 at 4:18 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Fri, Mar 28, 2008 at 02:41:28PM +0100, Klaas-Jan Stol wrote: > > On Fri, Mar 28, 2008 at 1:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> > wrote: > > > > 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 know it's often necessary in the general case, it might not > be necessary for NQP. Consider: > > our $a; > $a++; > > The "our $a" defines $a as having package scope, but doesn't bind > the variable to a value. The "$a++" will then automatically create > an Undef value for $a (since it's not vivified yet), but unless > something says it's to be an lvalue it won't bind that auto-generated > Undef back to the $a symbol in the namespace. > > But now that you've mentioned it, ISTR that Parrot Undef objects > throw an exception on inc/dec anyway, so perhaps we don't need > to worry about this case in NQP. > > > > [...] 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. > > > > > maybe the PCT can include optimizations to remove the creation of PMCs > > for constants? > > Actually, PCT tends to work the other way -- it uses constants whenever > it can and PMCs when told otherwise (or can't figure it out). In the > above case, 'add_p_p' explicitly indicates that the second operand is > a PMC, so PCT would feel obligated to create one. > > In the general case we can't do a global "remove creation of PMCs > for constants" because not all opcodes work with all operand types. > So, before we choose to optimize or not optimize, we have to know > how the operand is going to be used. The PAST compiler handles this > through its %piropsig table, which indicates what kinds of operands > are allowed for each opcode. > > > > > > * <, <=, > 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? > > Yes, because iseq, isne, islt, isgt, etc. aren't guaranteed to > do numeric comparisons. They do comparisons based on the underlying > PMC type (which might not be numeric). > > > > 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? > > I think my previous message was unclear... I wasn't aiming to > eliminate the cmp_num, but rather to use islt and friends on > the result of cmp_num (instead of iseq and isne). For example: > > ## infix:< > $I0 = cmp_num %0, %1 > $I0 = islt $I0, 0 > > ## infix:<= > $I0 = cmp_num %0, %1 > $I0 = isle $I0, 0 > > ## etc. > > Pm >
nqp_proposals.patch
Description: Binary data
