Re: The design of WebAssembly

On Fri, Aug 25, 2017 at 2:43 PM, David Neto <dneto@google.com> wrote:

> Thanks for these references.  I've read through the Semantics.md and the
> Rationale.md and have just started the PLDI paper.
>
> WebAssembly looks well thought-out.  A couple of initial thoughts:
> - You're trying to support more capable programs than traditionally run on
> GPU.   That's fair given that it's supposed to support "main thread" kinds
> of apps.
>

Right, WebAssembly as-is may not be what you want, but some of the design
experience and approach is clearly applicable.

- The docs talk about how nondeterminism will creep in once threads are
> supported.  It's good to acknowledge.  This is a big issue: concurrency is
> pervasive in GPU shaders.  :-)
>

Indeed. We're tackling this by also designing a formalized memory model and
associated test suite to go with the specification:

https://github.com/tc39/ecmascript_sharedmem/issues/88
https://github.com/tc39/ecmascript_sharedmem/issues/133

It's shared with JavaScript.


> - WebAssembly supports recursion, so it uses a general purpose stack to
> support it.  That motivates a lot of the design, and parts of the soundness
> proofs.
>   Shader languages typically ban recursion, so no general stack is
> required. That simplifies a lot.
>

Indeed, and if we make it a hard-requirement of WebGPU that there's no
recursion and that there are no indirect calls (or alternatively restricted
indirect calls) then we can design many interesting things in the language.


> - WebAssembly supports indirect calls (e.g. function pointers).
>   Shader languages I know of ban function pointers.  Again, this
> simplifies a lot.
> - For safety, WebAssembly segregates various things like local variables,
> code, tables, and general purpose memory (memories).   A reference to one
> thing can't accidentally alias to a reference to another.   I'll have to
> write down the argument for it, but SPIR-V with Logical Addressing is
> intended to provide veriy similar separate-by-construction guarantees.
>
>
> While I'm at it:    *Fil: Please post those URLs to the work you cited.*
>
>
> Thanks
> david
>
>
> On Thu, Aug 24, 2017 at 12:31 AM JF Bastien <w3c@jfbastien.com> wrote:
>
>> In the call today Ken asked about what other projects had tackled
>> problems similar to what WebGPU is trying to do, and asked folks to provide
>> references.
>>
>> Here's a paper a few of us wrote about WebAssembly:
>>
>> https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf
>>
>>
>> Of course it's not all relevant to WebGPU, but it's a good starting point
>> to try to break down how we approached the design space, and what
>> considerations were taken. I'm happy to answer any questions this raises.
>>
>> There's also a non-comprehensive rationale document:
>>
>> https://github.com/WebAssembly/design/blob/master/Rationale.md
>>
>> It would be cool if WebGPU did a better job that WebAssembly and kept
>> better documentation.
>>
>> Fil said he'd provide references for other projects too, I'll let him do
>> that :)
>>
>