[fpc-pascal] WebAssembly Target

[Benjamin Rosseaux]

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:

> 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 at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20170316/929462f1/attachment.html>