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..., why have both concat and
add...?
Matt
> -----Original Message-----
> From: 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 the
JIT
> code are may tenths faster then their PMC counterparts.
>
> > ... What are the criteria for
> > adding/deleting them?
>
> On demand :)
>
> > Thanks,
> > Matt
>
> leo
