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") -- Vyacheslav Egorov On Wed, Oct 30, 2013 at 5:46 PM, Olov Lassus <olov.las...@gmail.com> wrote: > 2013/10/30 Vyacheslav Egorov <m...@mrale.ph> >> >> > 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss