Parser only supports exttable opcodes now (from reference types proposal) which are table.grow 0xFC 0F table.size 0xFC 10 table.fill 0xFC 11 Non-trapping float-to-int conversations opcodes and bulk memory operations opcodes also start with 0xFC i32.trunc_sat_f32_s 0xfc 0x00 i32.trunc_sat_f32_u 0xfc 0x01 i32.trunc_sat_f64_s 0xfc 0x02 i32.trunc_sat_f64_u 0xfc 0x03 i64.trunc_sat_f32_s 0xfc 0x04 i64.trunc_sat_f32_u 0xfc 0x05 i64.trunc_sat_f64_s 0xfc 0x06 i64.trunc_sat_f64_u 0xfc 0x07 memory.init 0xfc 0x08 data.drop 0xfc 0x09 memory.copy 0xfc 0x0a memory.fill 0xfc 0x0b table.init 0xfc 0x0c elem.drop 0xfc 0x0d table.copy 0xfc 0x0e Adding any of these new 0xFC opcodes to Source/JavaScriptCore/wasm/wasm.json throws an error. Handling all two-byte opcodes correctly requires changes in generateWasmOpsHeader.py
<rdar://problem/71747813>
Bulk memory operations are implemented (as exttable operations). Non-trapping float-to-int conversations still need to have category "conversation" like all other conversation operations or their own category.
Yeah, I think, for Non-trapping float-to-int conversations opcodes, we can implement it as an extopcodes as bulk memory operation opcodes are implemented. This one can clean up implementation later.