Split SIMD.js spec into two (or more) phases

[littledan]

The current draft SIMD.js spec is rather large. To help us get things standardized quickly, let's split it into multiple phases. It's clear that the universal SIMD API is not yet ready and should be in a later phase, but I'd propose that we actually move a few more things to Phase 2. I wrote up a doc explaining the motivation and a categorization of items in Phase 1 and Phase 2 (and undecided) at https://docs.google.com/document/d/1ofTew1SJIOK9e2PYsorfabbtictffJoTOe3opp-IGEM/edit?usp=sharing . Please let me know what you think. I'd like to discuss this at the next phone call if there's time.

@PeterJensen @sunfishcode @johnmccutchan @BrendanEich @ljharb @juj

[ljharb]

I think that's a great idea - it will make each phase more bite-size, and easier to understand (and polyfill) for those of us not well versed in SIMD :-)

It also provides more time for as-needed discussion of things that are beyond solely performance concerns, like API consistency.

[littledan]

Strawman for splitting the SIMD.js spec into two phases:

• http://littledan.github.io/simd-phase-1.html
• http://littledan.github.io/simd-phase-2.html

This is the rather extreme version, pushing the Int8x16 and Int16x8 types to Phase 2. I don't know whether those should be in Phase 1 or Phase 2. My understanding is that Float32x4 and Int32x4 are the most important types, but that those two other types also come up in a number of circumstances. An intermediate option is to include the types but not all operations on them.

[littledan]

OK, we decided to keep small integer types in, but take some other things out from phase 1. There's also a solution to calculating the sum of absolute differences on ARM tentatively in phase 1. Spec v0.7 1ba0295815 reflects these changes and constitutes the phase 1 proposal.