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).
On Thu, Mar 16, 2017 at 2:07 PM, Karoly Balogh (Charlie/SGR) < char...@scenergy.dfmk.hu> wrote: > Hi, > > On Thu, 16 Mar 2017, Graeme Geldenhuys wrote: > > > I love how they say multiple times in the video: > > > > "... and completely secure." > > > > Umm, didn't they say the exact same thing about Java Applets, Flash, > > Silverlight etc. :) I guess time will tell, but if history is anything > > to go buy, security issues *will* pop up. > > Yes, but it is important to know there's a difference with Java Applets, > Flash and Silverlight - WebAssembly is not a plugin. It runs in the same > VM which runs everything Javascript in the browser. So the browser vendors > have full control on the code which runs there. > > Also, WebAssembly is a descendant of asm.js, which was basically striped > down Javascript with some integer/pointer type tagging. As far as I know, > the main problem with JS from a computing point of view, that it handles > all numbers as floats for "simplicity", but with some code in other > languages, this can have real side effects (for example some integers > cannot be exactly expressed as floats, which means slight differences in > computation results accumulate over time, etc), and it's much slower on > most CPUs. This is why I'm a bit relucant to accept High Level language > translators to JS - there could be too many sideeffects hidden in any > algorithm, just because of this one thing. > > This is the main problem asm.js, and now WebAssembly is addressing. It can > work with the same integer and float types the hardware underneath is > using, and can avoid all the float handling and various range/index etc > checks. This is what provides the performance part. And obvously a lot of > other "shortcuts" to work around JS language requirements, which another > language might not need. > > And it fits in the process, how they gradually opened up the underlying > hardware to the browser. Another great example is WebGL, which is also a > very thin layer on top of the hardware, to skip through the billion "who > cares about that" CSS and JS canvas layers, and go directly to the GPU, to > get some decent performance... > > So all in all, despite its problems, it's still the best effort to provide > some sane bytecode standard for the web. (If a web bytecode can be > anywhere near sane, that is.) > > Charlie > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
