On 30 October 2013 18:47, Vyacheslav Egorov <me at mrale.ph> wrote:
> 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
> allocation.
>
> - 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")

Instead of returning a pair, you could also do it C-style:

var ret = {}
add(al, ah, bl, bh, ret)
add(ret.lo, ret.hi, cl, ch, ret)
var dl = ret.lo, dh = ret.hi

This way, it's up to the caller to allocate a suitable return buffer
and reuse it. (For asm.js, that would probably require extending the
spec to allow a module to pre-allocate one such buffer.)

Cleaner than the other hacks, IMO, but still too ugly for an official API.

/Andreas

Instead of returning a pair, you could also do it C-style:

```js
var ret = {}
add(al, ah, bl, bh, ret)
add(ret.lo, ret.hi, cl, ch, ret)
var dl = ret.lo, dh = ret.hi
```

This way, it's up to the caller to allocate a suitable return buffer
and reuse it. (For asm.js, that would probably require extending the
spec to allow a module to pre-allocate one such buffer.)

Cleaner than the other hacks, IMO, but still too ugly for an official API.