WebAssembly
Support for 16 bit Integer
16-bit types are supported by extending them to i32. See for example: https://godbolt.org/z/Rbvxzq
Also of note, this is how x86 handles this as well: https://godbolt.org/z/_5yWcH
It's useful to think of wasm i32s as being the register size of the machine. x86 has 32bit registers, not 16bit registers, but all 16bit values will fit in 32bit registers.
Also https://godbolt.org/z/yZjUZY
Note that i32.const 65535; i32.and only takes place when returning the value from the function, because the high bits aren't relevant for 16bit math, but may be examined later outside the function scope. In particular, if you had an external (JS) function that wanted to assert(wasm.exports.add(50000, 25000) < 65536), that wouldn't work without and-ing off the high bits at that time.
When 8 and 16 bits operations are not available into the wasm, that will force the addition of very serious amount of instructions in each program that uses that. The 8 and 16 bits math is supported by many processors. How is the memory accessed, in blocks of 32 or 64 is not really the issue here. The issue is, that when such operations are not available, they will still be used (by a slow emulation) with all costs to bear. That some compilers are doing this, does not really addresses the issue, there is and other tools, and will be other tools. The question is, why should external tools do this, when the wasm could support it (with an extension to its format for good).
It is not clear to this person that using 32 bit instructions for 16 and 8 bit arithmetic is much of a hardship. On the other hand, for doing BCD arithmetic and multi-precision arithmetic, having variants of the instructions that detect and respond to carry and overflow seems worthwhile. To support BCD arithmetic, in some sense you would also want 4 bit arithmetic!
On Wed, Nov 13, 2019 at 5:29 AM verbessern [email protected] wrote:
When 8 and 16 bits operations are not available into the wasm, that will force the addition of very serious amount of instructions in each program that uses that. The 8 and 16 bits math is supported by many processors. How is the memory accessed, in blocks of 32 or 64 is not really the issue here. The issue is, that when such operations are not available, they will still be used with all costs to bear.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WebAssembly/design/issues/1292?email_source=notifications&email_token=AAQAXUAIOD7NSXMFSCG3JULQTP6L3A5CNFSM4IIDSODKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED6EQII#issuecomment-553404449, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQAXUDYKCXZ5BVRDHJZ6NDQTP6L3ANCNFSM4IIDSODA .
-- Francis McCabe SWE
I completely agree with @fgmccabe and @verbessern. On processors which have native support for 8-bit or 16-bit arithmetic, having to emulate the flags adds a lot of overhead.
Same goes for storing and reading 8-bit or 16-bit integers. Especially if we think about applications such as ML, I think that not having an i8 or i16 is going to impact performance by design on processors that natively support such.
