Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 15, 2005 at 02:38:36PM +0200, Leopold Toetsch wrote:
>: I'm not quite sure, but it seems that some of the MMD functions may
>: better be vtable methods:
>:
>: - bitwise_sh[rl]* shift by anything other then int?
>: - bitwise_lsr is missing generally
>:
>: or even just a plain opcode only:
>:
>: - logical_{or,and,xor} return a PMC depending on the boolean value
>:
>: What are HLLs expecting of these infix operations?
> Perl 6 tends to distinguish these as different operators, though Perl 5
> did overload the bitwise ops on both strings and numbers, which newbies
> found confusing in ambiguous cases, which is why we changed it.
We have distinct functions for bitwise shift int and string. That's no
prblem. But can the right operand be anything different then a plain
integer?
>: OTOH it might be useful that the current get_<type>_keyed operations
>: (postcircumfix:[]) become MMD subroutines:
>:
>: Px = Py[Pz] Pz = String, Int, Key, Slice, ...
> At the moment, the Perl 6 optimizer is explicitly allowed to optimize
> array indices with the assumption that the subscript is a scalar
> (or slice) of integer, or something that converts to integer. I'd be
> interested to know if that policy will actually buy us any performance.
> If it always has to go through MMD anyway, maybe it doesn't. But
> array indexing code tends to be pretty hot, so if we can keep it
> somewhat optimizable and/or jittable, that'd be nice.
Above are only the PMC variants. There are optimized forms for array and
hash lookup by native types:
Px = Py[Iz]
Px = Py[Sz]
But with PMCs we seem to have a bunch of different key-ish PMCs,
including a BigInt PMC for bitarrays.
With MMD we'd have one function per key. Without the usual cascaded if
statements:
if key.type == Int
...
elsif key.type == Slice
...
>From a performance POV, MMD is faster with optimizing run cores that can
rewrite the opcode and about the same speed with a plain MMD function cache.
> Larry
leo
