<div dir="ltr">The ECMAScript standard uses 64-bit double-precision floating point numbers, and a double-precision floating point value can represent absolute integer values up to of less than or equal to 2^53, without any loss of accuracy, since an IEEE 754 64 bit double-precision floating point number has a mantissa with a size of 52 bits (plus 1 bit implied).<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 2:07 PM, Karoly Balogh (Charlie/SGR) <span dir="ltr"><<a href="mailto:charlie@scenergy.dfmk.hu" target="_blank">charlie@scenergy.dfmk.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span><br>
On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:<br>
<br>
> I love how they say multiple times in the video:<br>
><br>
>    "... and completely secure."<br>
><br>
> Umm, didn't they say the exact same thing about Java Applets, Flash,<br>
> Silverlight etc. :)  I guess time will tell, but if history is anything<br>
> to go buy, security issues *will* pop up.<br>
<br>
</span>Yes, but it is important to know there's a difference with Java Applets,<br>
Flash and Silverlight - WebAssembly is not a plugin. It runs in the same<br>
VM which runs everything Javascript in the browser. So the browser vendors<br>
have full control on the code which runs there.<br>
<br>
Also, WebAssembly is a descendant of asm.js, which was basically striped<br>
down Javascript with some integer/pointer type tagging. As far as I know,<br>
the main problem with JS from a computing point of view, that it handles<br>
all numbers as floats for "simplicity", but with some code in other<br>
languages, this can have real side effects (for example some integers<br>
cannot be exactly expressed as floats, which means slight differences in<br>
computation results accumulate over time, etc), and it's much slower on<br>
most CPUs. This is why I'm a bit relucant to accept High Level language<br>
translators to JS - there could be too many sideeffects hidden in any<br>
algorithm, just because of this one thing.<br>
<br>
This is the main problem asm.js, and now WebAssembly is addressing. It can<br>
work with the same integer and float types the hardware underneath is<br>
using, and can avoid all the float handling and various range/index etc<br>
checks. This is what provides the performance part. And obvously a lot of<br>
other "shortcuts" to work around JS language requirements, which another<br>
language might not need.<br>
<br>
And it fits in the process, how they gradually opened up the underlying<br>
hardware to the browser. Another great example is WebGL, which is also a<br>
very thin layer on top of the hardware, to skip through the billion "who<br>
cares about that" CSS and JS canvas layers, and go directly to the GPU, to<br>
get some decent performance...<br>
<br>
So all in all, despite its problems, it's still the best effort to provide<br>
some sane bytecode standard for the web. (If a web bytecode can be<br>
anywhere near sane, that is.)<br>
<span class="gmail-m_-2181989921055565193HOEnZb"><font color="#888888"><br>
Charlie<br>
</font></span><div class="gmail-m_-2181989921055565193HOEnZb"><div class="gmail-m_-2181989921055565193h5">______________________________<wbr>_________________<br>
fpc-pascal maillist  -  <a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.or<wbr>g</a><br>
<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal" rel="noreferrer" target="_blank">http://lists.freepascal.org/cg<wbr>i-bin/mailman/listinfo/fpc-pas<wbr>cal</a></div></div></blockquote></div><br></div></div>