4 ms·

I'm not qualified to comment whether this is a significant issue or not. What puzzles me though is that as RISC-V is an open source ISA there should presumably

I'm not qualified to comment whether this is a significant issue or not. What puzzles me though is that as RISC-V is an open source ISA there should presumably be discussion of pros and cons and documentation of the decision to use this approach rather than that used in AVX and SVE. I would expect that this would help to settle the point. And yet several hours after Casey has raised this issue I can see no references either here or on Github. Edit: There is a thoughtful and extensive response now on GitHub (but without links to the original discussions) - which includes: > Having separate mask registers as some, but by no means all, other ISAs do was explicitly considered by the working group, and rejected. Some members were for it, but not sufficient to do it. The implications of the decision were, I believe, well understood. > There are many places in the design of RISC-V intended to make simple implementations simple, and high performance implementations possible, as possibly a little extra complexity in the already-complex implementations that can best afford it. which seems clear.

dogleash 4y ago
https://github.com/riscv/riscv-v-spec/issues/811 https://github.com/riscv/riscv-v-spec/issues/811 linked in the article.
- klelatti 4y ago
  That's Casey raising this issue not any preceding discussion or documentation of the decision.
dkjaudyeqooe 4y ago
There likely has been a discussion, but maybe not documentation of the trade offs and logic behind the decisions, which are hard to capture and usually verbose and meandering. The assumption here is that this fellow has discovered a flaw. Maybe that's the case or maybe it's not, but at this point my money is on the standards group and not one guy and his six day old blog.
- KerrAvon 4y ago
  In general — not necessarily this specific issue — I’d take the lone person pointing out a flaw. Things designed by committee are always compromises at best. Sometimes that’s good, and even necessary! But it doesn’t tend to lead to clean, elegant design. This could be both the right thing for RISC-V and a wart on the design for high-performance implementations.

dogleash 4y ago

https://github.com/riscv/riscv-v-spec/issues/811 https://github.com/riscv/riscv-v-spec/issues/811 linked in the article.

klelatti 4y ago
That's Casey raising this issue not any preceding discussion or documentation of the decision.

dkjaudyeqooe 4y ago

There likely has been a discussion, but maybe not documentation of the trade offs and logic behind the decisions, which are hard to capture and usually verbose and meandering. The assumption here is that this fellow has discovered a flaw. Maybe that's the case or maybe it's not, but at this point my money is on the standards group and not one guy and his six day old blog.

KerrAvon 4y ago
In general — not necessarily this specific issue — I’d take the lone person pointing out a flaw. Things designed by committee are always compromises at best. Sometimes that’s good, and even necessary! But it doesn’t tend to lead to clean, elegant design. This could be both the right thing for RISC-V and a wart on the design for high-performance implementations.