-
Notifications
You must be signed in to change notification settings - Fork 691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
i8/i16 values with limited operators #1049
Comments
I think this is worth discussing as part of the threads discussion in the upcoming performance meeting. @binji could you add it to the threads proposal and make sure it's one of the items discussed? |
Sounds good. |
We discussed this in the CG meeting and decided not to implement i8/i16 value types at this time. On a related point, we decided to pursue new sign-extending operators along with the threading proposal:
|
On 22 June 2017 at 01:49, Ben Smith ***@***.***> wrote:
We discussed this in the CG meeting and decided not to implement i8/i16
value types at this time.
On a related point, we decided to pursue new sign-extending operators
along with the threading proposal:
- i32.extend_s/i8
- i32.extend_s/i16
- i64.extend_s/i8
- i64.extend_s/i16
See https://github.com/WebAssembly/threads/blob/master/proposals/threads/
Overview.md#new-sign-extending-operators.
Oh, I hadn't noticed these. I think the naming scheme is a bit off, since
the parts after the "/" are always proper value types denoting the operand
type elsewhere. It would be preferable to mirror the naming scheme used for
loads:
* i32.extend8_s
* i32.extend16_s
* i64.extend8_s
* i64.extend16_s
That would also allow you to include i64.extend32_s, which is currently
missing and not expressible in the above scheme (since it is ambiguous with
the existing operator).
|
Good point; opened WebAssembly/threads#34 to discuss. |
previous discussion: #85
Looking at the atomics proposal, there are a lot of operators that are only necessary because WASM doesn't have
i8
andi16
value types. e.g. here are the operators for atomic adds:i32.atomic.rmw8_s.add
i32.atomic.rmw8_u.add
i32.atomic.rmw16_s.add
i32.atomic.rmw16_u.add
i32.atomic.rmw.add
i64.atomic.rmw8_s.add
i64.atomic.rmw8_u.add
i64.atomic.rmw16_s.add
i64.atomic.rmw16_u.add
i64.atomic.rmw32_s.add
i64.atomic.rmw32_u.add
i64.atomic.rmw.add
If there were
i8
andi16
value types, those could be simplified to:i8.atomic.rmw.add
i16.atomic.rmw.add
i32.atomic.rmw.add
i64.atomic.rmw.add
The same applies to the atomic
xchg
,cmpxchg
,load
,sub
,and
,or
, andxor
operators.Would folks consider adding
i8
andi16
types that have a limited set of conversion operators meant for composition with the memory loads/stores? e.g. fori8
:i8.wrap/i32
/i8.wrap/i64
i32.extend_s/i8
/i64.extend_s/i8
i32.extend_u/i8
/i64.extend_u/i8
The text was updated successfully, but these errors were encountered: