[fpc-pascal] WebAssembly Target
benjamin at rosseaux.com
Thu Mar 16 14:23:13 CET 2017
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) <
charlie at scenergy.dfmk.hu> wrote:
> 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
> have full control on the code which runs there.
> Also, WebAssembly is a descendant of asm.js, which was basically striped
> 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.)
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-pascal