).
Lowered version
cl = Math.div64l(al, ah, bl, bh);
ch = Math.div64h(al, ah, bl, bh);
should perform well (no allocations, potentially only some boxing if
engine requires that) and can be assembled into a single instruction
by the optimizer... but this just looks slightly bizarre.
// Vyacheslav
.
If you really want such an API, it is not worth proposing a lowered
version because division is slow anyway
This is also a fair point. But having inconsistent APIs is very weird if
you ask me.
// Vyacheslav Egorov
On Wed, Jul 9, 2014 at 12:07 PM, Fabrice Bellard fabr...@bellard.org
wrote
);
- simple to implement and optimize on any platform (including 32bit ones);
--
Vyacheslav Egorov
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-configurable non-writable
accessor property with a getter that returns hidden inner value and
always zeros inner value.
--
Vyacheslav Egorov
On Wed, Oct 30, 2013 at 5:28 PM, Olov Lassus olov.las...@gmail.com wrote:
2013/10/30 Vyacheslav Egorov m...@mrale.ph
5. A one shot property Math.H is created
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
into something Math.bigop. But this is pretty ugly
and probably also results in abysmal polyfill performance.
--
Vyacheslav Egorov
On Wed, Oct 30, 2013 at 9:56 PM, Luke Wagner l...@mozilla.com wrote:
Just to be sure, do you agree that both the {lo, hi}-returning API and the
magic-property API
6 matches
Mail list logo
