Some people find "global" state that this proposal introduces bad. I
see two ways addressing this:

- Returning {lo, hi} object.

Pros: no global state, in combination with destructuring allows to
write concise code, overhead can still be optimized away.
Cons: performance of polyfill is abysmal on bad and moderately good
VMs, requires allocation sinking pass to optimize away object

- Make H property of the respective operation (e.g. u64mul updates its
own property H)

Pros: easy to implement, good perf on bad VMs
Cons: still kinda global state

- Math.<s>64<op> can become Math.createOperator(<s>64, <op>) that
returns function with H property:

var add = Math.createOperator("u64", "add");
var dl = add(add(al, ah, bl, bh), add.H, cl, ch);
var dh = add.H;

Pros: no global state, relatively good performance on the non advanced
VMs, can be actually extended(!) e.g. SIMD operations can be exposed
as Math.createOperator("simd128", "add")

Vyacheslav Egorov

On Wed, Oct 30, 2013 at 5:46 PM, Olov Lassus <> wrote:
> 2013/10/30 Vyacheslav Egorov <>
>> > Rationale being faster polyfilled execution
>> The main reason for H being one shot is to allow optimizing compiler
>> *elide* updating it in most cases to eliminate memory traffic.
> Aaah. Thanks for pointing this out - I thought only of the polyfill
> performance so I neglected this key aspect of your proposal.
>> After thinking about it a bit I propose the following alternative step 5:
>> Math.H is from the very beggining a non-configurable non-writable
>> accessor property with a getter that returns hidden inner value and
>> always zeros inner value.
> +1 (for now) :)
> /Olov
es-discuss mailing list

Reply via email to