
Web Assembly Working Group Charter Approved - gfredtech
https://lists.w3.org/Archives/Public/public-webassembly/2017Aug/0001.html
======
mostafah
How is it different from “Web Assembly” (aka “wasm”) that has already started
to gain support in major browsers[1]?

Edit: Found the answer myself. This is part of the same effort, as mentioned
in the official website of Web Assembly[2].

[1] [http://caniuse.com/#feat=wasm](http://caniuse.com/#feat=wasm)

[2] [http://webassembly.org/roadmap/](http://webassembly.org/roadmap/)

~~~
akmittal
What are the changes compared to current Implmentation. Is DOM access on
radar?

~~~
mostafah
I haven’t found anything specific about future changes. I just found out that
this is part of the same effort.

~~~
markdog12
Here's a recent meeting about future changes:
[https://news.ycombinator.com/item?id=14873594](https://news.ycombinator.com/item?id=14873594)

------
grondilu
I'm slightly disappointed by the target end date : 31 July 2019. WebAssembly
seems like a huge deal to me and I was hoping things would progress quicker
than that :(

~~~
TomMarius
Let's not mess it up just because we want it quickly, if we (they) do this
correctly, it might be the final big progression, but if we do it too quickly,
it might turn into the next JavaScript (problem-wise).

~~~
alekratz
This. They want to get it right, and iron out any kinks NOW so we aren't
worried about "breaking compatibility" 20 years down the road.

------
CyberDildonics
I hope they at least have unaligned atomics in this version. I feel that is a
major omission from the current plans, since it makes algorithms
difficult/impossible that use 64 bit atomics to change two 32 bit atomic
numbers next to each other in an interlocked fashion.

~~~
wahern
Other than x86, do many processors permit either of those things--1) unaligned
atomic operations, or 2) type-punning where memory ordering is guaranteed for
a 32-bit read of a 64-bit atomic write.

~~~
CyberDildonics
64 bit ARM and POWER both do as far as I know. They definitely all support
aligned 128 bit atomics.

~~~
wahern
An aligned word won't span a cache line. So any aligned 64-bit or 128-bit word
is always wholly within a single cache line.

But two 32-bit words can span a cache line if the first isn't 64-bit aligned.
So what you're doing relies on hardware supporting atomic operations not only
on unaligned words, but on words spanning cache lines. Are you really sure ARM
and POWER support that?

~~~
CyberDildonics
> An aligned word won't span a cache line. So any aligned 64-bit or 128-bit
> word is always wholly within a single cache line.

On x86 a 64 bit atomic can span cache lines.

> Are you really sure ARM and POWER support that?

Do they not?

[http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html)

On older processors, such as ARM9 family based processors, an unaligned load
had to be synthesised in software. Typically by doing a series of small
accesses, and combining the results.

"The ARMv6 architecture introduced the first hardware support for unaligned
accesses. ARM11 and Cortex-A/R processors can deal with unaligned accesses in
hardware, removing the need for software routines."

~~~
wahern
Apparently not. From "ARM Architecture Reference Manual ARMv8 for ARMv8-A
architecture profile",

    
    
      Apart from Load-Exclusive, Store-Exclusive, Load-Acquire,
      and Store-Release, addresses can have any alignment unless
      strict alignment checking is enabled....
    
      -- Section C3.2 Loads and Stores, page C3-160.
    
    
      The Load-Exclusive/Store-Exclusive instructions other than
      Load-Exclusive pair and Store-Exclusive pair require natural
      alignment, and an unaligned address generates an Alignment
      fault. Memory accesses generated by Load-Exclusive pair or
      Store-Exclusive pair instructions must be aligned to the
      size of the pair, otherwise the access generates an
      Alignment fault. 
    
      -- Section C3.2.6 Load-Exclusive/Store-Exclusive
    
    
      The Load-Acquire/Store-Release instructions other than Load
      Acquire pair and Store-Release pair require natural
      alignment, and an unaligned address generates an Alignment
      fault. Memory accesses generated by Load-Acquire pair or
      Store-Release pair instructions must be aligned to the size
      of the pair, otherwise the access generates an Alignment
      fault.
    
      -- Section C3.2.7 Load-Acquire/Store-Release
    
    
      The LoadLOAcquire/StoreLORelease instructions require
      natural alignment, and an unaligned address generates an
      Alignment fault.
    
      -- Source C3.2.8 LoadLOAcquire/StoreLORelease
    
    
      The CAS and CASP instructions require natural alignment, and
      an unaligned address generates an Alignment fault.
    
      -- Section 3.2.12 Compare and Swap, page C3-172
    
    
      The LD<OP> and ST<OP> instructions require natural
      alignment, and an unaligned address generates an Alignment
      fault.
    
      -- Section C3.2.13 Atomic memory operations, page C3-173.
    
    
      The SWP instructions require natural alignment, and an
      unaligned address generates an Alignment fault.
    
      -- Section C3.2.14 Swap, page C3-175
    
    

I've only ever dabbled in assembly programming, but the ability of x86 to do
atomic operations across cache lines is, AFAIU, rather unique. That Intel and
AMD engineers are able to accomplish it relatively performantly is an
incredible achievement. But it's not a handicap anybody else wishes to adopt
and then compensate for.

------
baybal2
Yet another ActiveX-like tech re-spin, we are going back to the dark age.

Having usable and capable _SCRIPTING_ language for web was the biggest
achievement of the whole Web 2.0 push, now the browsermaker is about to
reverse that

~~~
tannhaeuser
I'm siding with baybal2 on this one. No matter how much you're wishing to use
your favourite language on the Web, WASM is at best unnecessary, as the kind
of application it enables (near-native speed) can be had with ordinary native
apps as well. Why does something like that have to run in the browser? The
only reason I can think of is because software/game publishers want to control
your usage even more.

But it doesn't stop there: the worst possible outcome of WASM is that entire
custom browser runtimes are being pushed to you [1]. Say goodbye to content
linking, sharing, saving, translation, accessibility, ad blocking, etc. Not to
mention content will only work on the bundled WebKit version.

WASM is user-hostile and anti-Web. What does it even mean that W3C "approved"
a working group? I thought WASM was a WHATWG thing. W3C shouldn't lend what's
left of its credibility to it.

[1]: [https://trevorlinton.github.io/](https://trevorlinton.github.io/)

~~~
bigato
> But it doesn't stop there: the worst possible outcome of WASM is that entire
> custom browser runtimes are being pushed to you [1]

If we ever come to the point where all you need to develop a web browser is a
wasm vm, don't you find exciting how much simpler a web browser would become?
At the moment it is one of the most complex pieces of software out there. It
is so hard to build a modern web browser from scratch nowadays that doing so
as a hobby would take a lifetime. This takes the power away from individual
developers, since it's not very realistic to build a new browser unless you
are a big corporation with money to spare.

This situation also poses a big problem for the development of new operating
systems. If your shiny, awesome, new research open source OS does not have a
modern web browser, it will never reach wide adoption and thus never atract
enough developers to build critical mass. The alternative is to make your OS
compatible with POSIX and thus reuse the work of others so that you can build
existing web browsers. But then you are most likely bound to become just
another unix/linux alike, thus hindering innovation.

~~~
icebraining
_If we ever come to the point where all you need to develop a web browser is a
wasm vm, don 't you find exciting how much simpler a web browser would
become?._

But you're not removing complexity, just moving it into the wasm-based
runtime, and in the process it removes the power that comes with building the
browser, which is shaping how the user sees and interacts with websites.

If every website is a blob of code that you have to execute as a black box,
what's the point of writing your own browser? It'll just be a slower copy of
every other, since all the potential for making it _different_ has been taken
away.

~~~
baybal2
>If every website is a blob of code that you have to execute as a black box,
what's the point of writing your own browser? It'll just be a slower copy of
every other, since all the potential for making it different has been taken
away.

A very insightful comment

