Closed penzn closed 2 years ago
This is basically a revisit of #6. What I've ran into is that because we have to have different instructions for different input types, even if the operations are technically the same, we end up with a bit of opcode bloat. First tier is already getting close to taking up a whole byte for opcodes. From what I can tell we can't really have the same instruction taking multiple different types.
The options are to use just lane sizes in types, which would only cut out two types, or ditch multiple value types altogether and be more like the SIMD spec.
In the discussion in #36 we decided that having more opcodes is not necessarily a bad thing, I will try to keep the current design. There are parts of it that I am not exactly happy about, but there are benefits to FP vs int distinction.
The gist is just defining types and opcodes. However we have multiple vector types (thanks to both sizes and types of lanes) and this makes every operation consist of multiple operations working on a specific types.
I don't know if we can define a single opcode taking various types (and returning matching), or we can define a hierarchy of types with the more generic operations accepting "higher types".