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
