undefined | Better HN

0 pointsuserbinator5y ago0 comments

Right now, x86 needs one set of instructions for each SIMD data size.

If you look at the encodings, many of them are actually the same opcodes as the original MMX, but with prefixes.

In the proposed RISCV design, you wouldn’t have to. It would just work on all sizes.

That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ? Unless they added some really un-RISC instructions to do automatic vectored operations (like if x86 had a REP ADDSB), I don't see how you wouldn't need to change software for changing SIMD widths.

0 comments

3 comments · 1 top-level

monocasa5y ago· 2 in thread

> That doesn't make sense --- how would the code know how much to increment pointers by, how many times to loop, alignment, etc. ?

You ask the hardware. The current vector width is a register that can be set and queried.

https://gms.tf/riscv-vector.html

userbinatorOP5y ago

That is interesting... and actually feels a bit CISCy, but this

Configuring a grouping of 8 registers for a vector of 16 elements might look like overkill because 128 bit vector registers are sufficient and should be widely available. On the other hand, there might be a CPU with "V" support that just implements - say - 64 bit vector registers where we would need to group 2 registers. Since a grouping thus may be needed it really doesn't hurt to configure the maximum here.

...seems to imply that the generated code may still need to assume certain widths.

brucehoult5y ago

No, it doesn't imply that.

It's just that if your code doesn't need 32 different vector variables then you can step down to, say, 4 variables with 8x longer registers for more efficiency. You need to know how many live variables your code has (which the compiler knows), not how long the registers are.

j / k navigate · click thread line to collapse