On Fri, 15 Aug 15, 2003 Dan Sugalski wrote:
> On Fri, 15 Aug 2003, TOGoS wrote:
>
> > There may be something I'm missing, but I don't
> > understand why we need a keyed version of just
> > about every opcode.
>
> It avoids having to create a lot of temporary PMCs with weird
> magic on them, avoids having to create temporary PMCs in general,
> and allows the container to hold the value overloading code.
>
> At some point I'll put together a more comprehensive formal
> reasoning for it, but for now accept that you have to do it this
> way and cope.
How many instructions are really just microcode--bloat for the parrot
core? What's next after
{set,assign}{keyed_,}_{add,mul,sub,div,mod,cat,...}_{i,p,n}_{i,p,n}_{i,p
,n}? How many of these combinatoric instructions offer actual
performance advantages after code has been JITted? What's the cost of
having dozens of extra instructions to do things which could be done
through the straightforward combination of those you absolutely need in
order to obtain a solution with full generality? What's the relative
likelyhood of bugs with the increased opcode count? Why should a
container PMC author be concerned (ever) about implementing arithmetic
operators? Does the need for "magick PMCs" in a minimalized container
ISA speak to a larger problem? How many of the combinatoric instructions
are legitimately useful to a caller who needs full generality? Why
should ($a[$i] += $b;) or ($a[$i] = $b + $c;) get special optimizations,
but ($a[$i] = $b + $c + $d;) be penalized? How many languages are going
to bother with the AST magick to recognize that "="("[]"(a, x),
any("+","-","/",...)(m, n)) can be translated to a single opcode? How
will a PIR peephole optimizer be able to approach these operators when
the PMCs have been endowed with the ability to respond differently to
these extra operators? How would the optimizer handle it if the keyed
version winds up being slower than the non-keyed operation? How would
the optimizer handle it if keyed is faster for certain PMCs, but
non-keyed is faster for others? Is the RISC design philosophy not useful
when applied to a JITted virtual machine?
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
