Define "portable"

[jfbastien]

We currently don't really define what "portable" means. A few ideas:

• Works within recent browsers, based on web standards.
• Works on multiple mainstream OSs. Should we specify which (Windows (which?), OSX, Linux, ChromeOS)?
• Works on multiple ISAs. Should we specify which? (x86-32, x86-64, ARMv7 ARM, ARMv8 A32/A64, MIPS).
• Expects little endian.
• Expects 32-bit address space (for now).

Should we discuss portable performance expectations? It's pretty handwavy, but if it's not pretty fast isn't not really working!

If that sounds good I'll send a PR.

[lukewagner]

Most of those sound great. Perhaps it makes sense to define our "tier 1" platforms (browsers, OSes, ISAs) which we should avoid hobbling by any design decision. Nailing down little endian seems good. For 32-bit address space, I wonder if we should be more explicit and say: v.1 assumes a 32-bit pointer and heap, 64-bit would be a new option in future versions (with links).

[jfbastien]

@lukewagner your clarifications sgtm.

I forgot: do we want to mandate a minimum arch version? A few examples:

• Mandate SSE2 support on x86.
• Mandate NEON on ARM.
• Mandate support for non-faulting unaligned access (with more details! This is partly controlled by the OS, on ARM with SCTLT.A).

Do we want to support bare-metal execution? I can see ways to leave the door open for this in the future.

[sunfishcode]

I think we also want to leave the door open to other architectures and OSs when it doesn't hurt our "tier 1" platforms to do so. For example, the unaligned access instruction looks like it will greatly help armv6 et al at relatively low effort for platforms that don't need it, and I think that's worthwhile.

Also, to clarify, 64-bit hosts are just fine for running WebAssembly, and are among our "tier 1" platforms. It's just that WebAssembly itself doesn't yet have >4GiB heaps.

[lukewagner]

It does make sense to include SSE2/NEON/non-faulting-unaligned as part of "tier 1". Agreed with Dan we should be clear about what "tier 1" means (in the text describing tier 1): we design for it, we are sure not to hobble it, but we would make small concessions for non-tier-1 where it doesn't cost us to do so.

[jfbastien]

sgtm.

I'll send a PR in a few days, when we run out of additions and I'm not in Kansas.

[sunfishcode]

Is SIMD going to be optional or non-optional? I don't have an opinion about this yet. If SIMD is an optional feature, machines which lack SSE2/NEON could run WebAssembly without implementing SIMD (provided they don't have x87 problems). I think mandating SSE2/NEON for SIMD support is reasonable though.

Also, I don't see the benefit in mandating non-faulting unaligned access right now. We have already agreed on a solution which supports machines with faulting unaligned accesses which ought to cover the vast majority of use cases adequately.

[sunfishcode]

I'll also suggest that "bare metal execution" is not presently a "tier 1" platform, but is among the many platforms desirable to accomodate when it can be done without hurting our "tier 1" platforms.

[titzer]

I don't think we want to mention specific ISAs, nor state some kind of
"platform requirements". Any execution engine that can implement the
semantics of the individual operations is enough, even an interpreter.

On Wed, May 6, 2015 at 5:59 PM, JF Bastien [email protected] wrote:

@lukewagner https://github.com/lukewagner your clarifications sgtm.

I forgot: do we want to mandate a minimum arch version? A few examples:

• Mandate SSE2 support on x86.
• Mandate NEON on ARM.
• Mandate support for non-faulting unaligned access (with more
  details! This is partly controlled by the OS, on ARM with SCTLT.A).

Do we want to support bare-metal execution? I can see ways to leave the
door open for this in the future.

—
Reply to this email directly or view it on GitHub
WebAssembly/spec#38 (comment).

[lukewagner]

I've been assuming that this "tier 1" list was more for the benefit of goals and focusing (like the other items in the high-level goal list) and not defining any hard requirements. The benefit would be (esp. as the standardization discussion broadens) that discussions don't get side-tracked by "what about obscure architecture X?".

[jfbastien]

Yes, I think this is a list of architectures we care about, and of what's out of scope e.g. it's a non-goal to support lock-free atomics on Alpha.

It's not binding or anything, we can always revisit, but it's useful to make sure we're all agreeing! It's also important to let outside contributors understand how we came to conclusions, or why we're conservative on certain things. It also allows them to come in with a new architecture they think we should focus on: maybe someone will want us to put effort towards little-endian POWER8.

[jfbastien]

Fixed by #123.