Matt Greenwood <[EMAIL PROTECTED]> wrote: > Hi all, > I have a newbie question. If the answer exists in a doc, just > point the way (I browsed the docs directory). What is the design > rationale for so many opcodes in parrot?
We have four different register types. They have to be covered by opcode, which leads to a lot of opcode permutations: $ grep -w add docs/ops/math.pod =item B<add>(inout INT, in INT) =item B<add>(inout NUM, in INT) =item B<add>(inout NUM, in NUM) =item B<add>(in PMC, in INT) =item B<add>(in PMC, in NUM) =item B<add>(in PMC, in PMC) =item B<add>(out INT, in INT, in INT) =item B<add>(out NUM, in NUM, in INT) =item B<add>(out NUM, in NUM, in NUM) =item B<add>(in PMC, in PMC, in INT) =item B<add>(in PMC, in PMC, in NUM) =item B<add>(in PMC, in PMC, in PMC) We could of course only provide the very last one but that would prohibit any optimizations. Opcodes with native types running in the JIT code are may tenths faster then their PMC counterparts. > ... What are the criteria for > adding/deleting them? On demand :) > Thanks, > Matt leo
