
Partial WebAssembly backend for the GNU toolchain - ingve
https://sourceware.org/ml/binutils/2017-03/msg00044.html
======
gant
And thus the era of METAL[1] begins...

[1]: [https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
spraak
This is super enjoyable thank you ^_^

~~~
andrewflnr
_And_ compelling. Can you really make that work securely in the kernel?

~~~
amelius
It's a nice idea, but it goes against layered security [1]. Perhaps computer-
assisted proofs can make that a non-issue.

In any case, I would very much like to see an implementation of this.

[1]
[https://en.wikipedia.org/wiki/Layered_security](https://en.wikipedia.org/wiki/Layered_security)

------
JoshTriplett
I sincerely hope this gets a good reception, and doesn't suffer the fate of
previous attempts to add similar backends to the GNU toolchain.

In the past, backends for anything usable as an intermediate language received
pushback as possible "escape hatches" by which one could glue proprietary code
(whether frontends, backends, or optimization passes) into the GNU toolchain.
That pushback mostly went away when the GCC Runtime Library Exception came
out, which makes such proprietary combinations much less viable.

So, hopefully this will get merged, or at least get on the path to merging
after further development.

~~~
hamandcheese
I don't really follow. Do you mean, for example, BigCorp making a backend that
compiles to proprietary BigCorpLang? Why would that be such a bad thing?

~~~
foota
I think they mean it compiles to BigBorp ir which is then used with BigCorps
secret sauce optimizing compiler.

~~~
bonzini
That's already happening with the nVidia PTX backend, so I guess that's
accepted too nowadays.

------
joaomacp
Maybe it's a foolish thought, but it occurred to me that maybe in 10/20 years
AAA game titles will have a 'web' version, as well as the PC and game console
ones. Or maybe they let you play a demo for free on the browser, with real
gameplay mechanics and graphics made with wasm or similar tech.

~~~
owaislone
If you have a fast enough internet, you can right now stream games to your PS4
just like Youtube. In 10-20 years time, we'll be able to stream games running
directly on publisher's server farm somewhere.

~~~
larsiusprime
Latency will always be a consideration though; the fidelity might get there in
terms of audiovisuals, but you can't engineer around the speed of light.

~~~
tomatsu
> _Latency will always be a consideration though_

And it will always be _way_ too high for VR.

~~~
Jyaif
They could stream a spherical texture (with depth map). Locally you would only
have to render the sphere from the view point of the eyes.

------
felipellrocha
How is this different than using the emsdk to build?

~~~
bobajeff
Emscripten is a cross-compiler tool chain. This is a back end for a compiler.

Currently Emscripten uses a fork of Clang/LLVM called fastcomp with a ASM.js
backend.

This is a fork of GCC/Binutils with a WebAssembly and ASM.js backend.

~~~
azakai
To add to that, in principle Emscripten could use gcc and this backend instead
of clang and an LLVM backend. Emscripten itself abstracts over the backend
details (it's supported 3 different backends in its history, and currently
supports 2). Most of the code in Emscripten is in the libraries, like
OpenGL=>WebGL, etc., and JS integration code, which shouldn't depend on the
backend.

It would be interesting to get that working and do some code comparisons on
the output.

------
quickben
So what does the future hold? Will this replace JavaScript?

~~~
tannhaeuser
The more imminent concern is that publishers are beginning to bundle browser
runtimes completely replacing native browser functionality along with its
established privacy and fair use expectations. Say hello to unskippable
interstitials, unblockable analytics and targeted advertising, content that
can't be linked, saved/archived, mirrored, cached, shared, translated or made
otherwise accessible.

Developers mostly discuss JavaScript shortcomings and new possibilities
offered by WebAss, but seem otherwise happy to completely throw the
fundamental architecture of the web under the bus.

Technically, what WebAss can do has since long been possible with native
applications; the only thing added here are new software licensing models, eg.
pay-per-use, but mostly tracking/ad-financed.

~~~
skissane
I have the same worry. Page downloads content as some encrypted binary blob,
displays it using <canvas>, impossible to block advertising or copy text.

However, at the end of the day, content providers have to make their content
available in plain HTML format in order for search engines to index it. If
they did the above without offering a plain HTML alternative, they'd lose
traffic from search engines. But, if they are offering that format to search
engines, they have to offer it to us too.

(Okay, they could lock it down so the plain HTML is only available if User-
Agent = Googlebot/Bingbot/etc and source IP is coming from Google/Bing/etc
network. But, will the search engines let them get away with that? I would
hope Google would refuse to index it on the grounds that their crawler is
getting something very different from what the real user sees, but I guess
that's their decision.)

~~~
dasfasf
You can already do all this. In practice, I've never seen a site render its
text and ads to a canvas to make things difficult for me.

IMO, the bigger obstacle to "content that can't be linked, saved/archived,
mirrored, cached, shared, translated or made otherwise accessible" is the
"fundamental architecture of the web": HTTP. You can't link it (who knows if
the person who clicks the link will get the same page?), you can't cache it
(who knows when to invalidate it?), you can't mirror it (who can enumerate the
dependencies?), and so on. Something like IPFS would fix these things (and
should fix these things). But in practice, a fairly cacheable, linkable,
mirrorable, sharable web has been built on HTTP and I expect nothing much will
change when wasm is thrown into the big vat of web technologies too.

------
bitL
This is precisely what I was waiting for! Finally a set of reasonable
languages for web! Many thanks!!!

~~~
7373737373
Is the closer C family of languages really reasonable for the web?

~~~
bitL
In many ways yes, as C can be much more straightforward than JavaScript, which
enforces spaghetti-programming by design (via callback hell). So anyone used
to develop desktop apps, facepalming on trivial problems in JS like loading
resources, can rejoice. And I expect other languages will be ported soon, like
Java, C#, Scala, Python, Go, Rust etc. Imagine getting the whole Java stack of
libraries, .NET or ML stack for Python running on top of WebAssembly with
almost zero differences and at native speeds. Why not?

~~~
josephg
> In many ways yes, as C can be much more straightforward than JavaScript,
> which enforces spaghetti-programming by design (via callback hell).

I don't think this is a fair criticism of javascript. In javascript if you
want to you can define all your callbacks as top level functions and just pass
a function pointer through, the same way you would in classic C or C++. But
nobody does that because its an awful way to write your code. If you want to
do async programming you need callbacks of some form, and putting the callback
inline is better. (Hence lambda functions being added to C++ and java).
Arguably await/defer is better still, and unlike C, javascript now supports
await if you want to write code that way.

The only other decent way to write high performance code is to use lightweight
threads and message passing (go or erlang). But again, (as far as I know) C
and C++ make this sort of code really hard to write correctly because of the
memory model. I'm looking forward to seeing that battle played out in rust,
where both models can work side-by-side.

As for resource loading in JS, promises aren't perfect but they make deferring
code execution on resources loading work great. Just bundle your resource
loading into a promise and then require('./resources').then(whatever =>
{...}).

