I completely agree that you would have multiple *of the same* opcode for the different types. I guess the question I was (too delicately) asking, is why you have opcodes that are usually in standard libraries, and even some that aren't. For example; fact, exsec...,
I answered this in some detail, but the short answer is "There's no reason not to"
why have both concat and add...?
Erm... because they do completely different things?
> -----Original Message-----JITFrom: Leopold Toetsch [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 2:07 AM To: Matt Greenwood Cc: [EMAIL PROTECTED] Subject: Re: newbie question....
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 thecode are may tenths faster then their PMC counterparts.
> ... What are the criteria for > adding/deleting them?
On demand :)
> Thanks, > Matt
leo
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
