You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In fact, the instructions are always supporting both types.
And new proposals have to consider and support them.
in fact, signed integers have always existed and are supported, in all numerical instructions. However, they are not in the number types: s8, s16, s32, s64
The instructions:
i64.load8_s means s8.load and s64.extend_s8
i32.extend8_s means s32.extend_s8
i8x16.splat means v128.splat_i8x16
We know that the number of 1-byte-opcode is limited. It is not necessary to allocate instructions like this i16.add. Assigning a prefix byte to them is worth considering.
They exist in the instruction but are not named, very strange.
The text was updated successfully, but these errors were encountered:
previous discussion: #1049 #85 #804
related proposal: sign-extension-ops simd
I will not repeat the comments of previous here.
In fact, the instructions are always supporting both types.
And new proposals have to consider and support them.
in fact, signed integers have always existed and are supported, in all numerical instructions. However, they are not in the number types: s8, s16, s32, s64
The instructions:
i64.load8_s
meanss8.load
ands64.extend_s8
i32.extend8_s
meanss32.extend_s8
i8x16.splat
meansv128.splat_i8x16
We know that the number of 1-byte-opcode is limited. It is not necessary to allocate instructions like this
i16.add
. Assigning a prefix byte to them is worth considering.They exist in the instruction but are not named, very strange.
The text was updated successfully, but these errors were encountered: