Slim down selection of mathematics vtables

[whiteknight]

We have far too many mathematics vtables for too many combinations of input arguments. I would like to make the following suggestions:

• Convert all "3-argument" VTABLEs to "2-argument" ones. These are of the form "PMC * foo(PMC *value, PMC *dest)". VTABLEs of this form are extremely inconsistent throughout the codebase for the handling of the third "dest" argument. In many implementations the third argument is completely unused. I suggest they should all be changed to "PMC *foo(PMC *value)", and always return a new PMC that contains the resultant value.
• Remove all "i_*" vtables. These are less frequently used and tend to be implemented internally in terms of the 3-argument vtables.

These changes will signficantly reduce bloat of the VTABLE structure and decrease Parrot's memory footprint and startup times. We'll also be able to have more consistent implementations of the math ops across all core types, and will have a much lower maintenance burden if we need to make changes to these operations.

[pmichaud]

- Remove all "i_*" vtables. These are less frequently used and tend to be implemented internally in terms of the 3-argument vtables.

As noted in #1433, I disagree with the notion that Parrot should completely do away with the optimization possibilities provided by having separate "inplace" versus "create a new value" operations available to PMCs. It's not just the core PMCs at issue here, but also the PMC types that other HLLs may choose to use or implement.

Pm

[bacek]

Hello.

-1 from me. I think it should be other way around. Implement 3-args math ops in terms of i_* ops. E.g. $a := $b + $c is same as $a := $b; $a += $c . Core PMCs can always fallback 3-args ops to 2-args. HLL can choose different implementation.

OTOH, current 3-args ops with $dest _should_ always allocate new PMC for $dest without reusing old PMC. It's closely related to "lvalue semantics" ticket.

-- Bacek.

[pmichaud]

On Thu, Nov 25, 2010 at 01:46:02PM -0000, Parrot wrote:
>  Hello.
> 
>  -1 from me. I think it should be other way around. Implement 3-args math
>  ops in terms of i_* ops. E.g. {{{ $a := $b + $c }}} is same as {{{ $a :=
>  $b; $a += $c }}}. Core PMCs can always fallback 3-args ops to 2-args. HLL
>  can choose different implementation.

Please, no.  An 3-argument inplace add is *not* always the same as
a 2-argument inplace add.  In particular, adding two very large Integers
could result in a BigInt, and I definitely think we should not be morphing
PMCs to achieve that.

Put another way, over time I've come to realize that immutable values 
are a good thing, and inplace operations are the antithesis of that.
Please don't make them the core/default.

Pm

[chromatic]

On Thursday 25 November 2010 at 09:48, Patrick R wrote:

> Put another way, over time I've come to realize that immutable values 
> are a good thing, and inplace operations are the antithesis of that.
> Please don't make them the core/default.

+1.  It's the optimizer's job to cheat by removing temporaries and coalescing 
multiple resources, not the programmer's.

-- c