[fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

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