Clarify some behaviors that were listed as needing further clarification.

Integer division by zero and signed integer division overflow both trap:

 - If either of these happens, it's reasonable to call it a bug in the application.
 - Integer division by non-constant values is already expensive and
   somewhat rare. A few range checks here on hardware which doesn't trap
   is a reasonable expense for portability and sanity.

Shift counts are unsigned and unmasked:

 - Of the plausible alternatives, this is the most intuitive behavior, given
   that shifts already have silent overflow/truncation.
 - This will have a significant cost on certain applications on "tier 1"
   platforms. However, hardware behavior here varies even within "tier 1",
   so the main alternative is to return implementation-specific values,
   which harms portability. We specifically want to discourage "x86-only" or
   "ARM-only" applications from becoming common.
 - On x86, there's even inconsistency between scalar and SIMD, so something
   somewhere has to bend to accomodate it in a reasonable way.
 - SIMD.js is currently proposed to have unsigned and unmasked shifts too.

Failure in converting floating-point to integer traps:

 - Applications may wish this to saturate to INT32_MIN/INT32_MAX, or to
   return a designated value. Or it may be a bug. We could theoretically spec
   multiple opcodes to let applications pick the behavior they want, but it's
   not currently clear how important that is.
 - Among "tier 1" platforms there are different behaviors for such conversions,
   so anything other than implementation-specific values is already going to
   require extra code on some platforms.
 - SIMD.js is currently proposed to trap in this case too.

0 files changed, 0 insertions, 0 deletions