This repository was archived by the owner on Dec 22, 2021. It is now read-only.
This repository was archived by the owner on Dec 22, 2021. It is now read-only.
Names of load instructions #297
Closed
Description
I would like to discuss the names of load instructions (this came up in #237 and #271).
Currently, we have:
v128.load
- load splats,
v8x16.load_splat
,v16x8.load_splat
,v32x4.load_splat
,v64x2.load_splat
- load extends,
i16x8.load8x8_s
,i16x8.load8x8_u
,i32x4.load16x4_s
,i32x4.load16x4_u
,i64x2.load32x2_s
,i64x2.load32x2_u
- (proposed addition),
v128.load32_zero
,v128.load64_zero
Some issues:
- There is some inconsistency in the prefix,
v128
v.s.v8x16
v.s.i8x16
. - The suffix (ignoring the sign extension) is also adhoc: in some cases, it has a shape (
load8x8_s
), in some cases it has the number of bytes loaded (inload32_zero
), and sometimes it's just a word (splat
). - This also makes writing the formal text a bit more involved since these are all separate syntax, even though they are all loads.
A more consistent naming convention will be:
- all instructions use
v128.load
prefix, this is the return type, it makes it clear that all the loads return av128
- followed by number of bits to load, similar to MVP (
i32.load8_s
) - followed by the "kind" of load,
splat
,extend
,zero
With this convention, all the loads now look like:
v128.load
- load splats,
v128.load8_splat
,v128.load16_splat
,v128.load32_splat
,v128.load64_splat
load extends,v128.load64_extend8x8_s
,v128.load64_extend8x8_u
,v128.load64_extend16x4_s
,v128.load64_extend16x4_u
,v128.load64_extend32x2_s
,v128.load64_extend32x2_s
- load extends,
v128.load8x8_s
,v128.load8x8_u
,v128.load16x4_s
,v128.load16x4_u
,v128.load32x2_s
,v128.load32x2_s
- (proposed addition),
v128.load32_zero
,v128.load64_zero
(The load extends are a bit wordy, maybe we can come up with a better name.)
Metadata
Metadata
Assignees
Labels
No labels