By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), November 4, 2019 3:08 pm
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on November 4, 2019 12:22 pm wrote:
>
> 128-bit is the easiest case. The first addition produces carry, but never consumes
> carry. The second addition consumes carry, but never produces it.
> Try 192-bit or more. That's where replacement for middle
> ADCs will start to take a lot of RISC-V instructions.
A lot more? Two more instructions.
Yes, the extra carry-in will mean that you need a second 'sltu' instructions to generate subsequent carry bits (one for the regular add, the second for the previous carry add rippling all the way through). And then an instruction to add/or the two carries together. With a conditional move (which RISC-V doesn't have) I think the second sltu and the add/or to mix it in can be done as single cmov instead, saving one instruction (but probably making the dependency chain longer).
But it doesn't get worse from there. So a 192-bit add will need that extra sltu/add (on top of the other sltu/add) to generate the carry out of 128 bits. But that pattern won't get any worse for longer additions.
So is it annoying? Yes. But arbitrary extended-precision math isn't that common (and the two-word case that is simpler is probably the most common case of it), and it's not a complete deal-breaker when it happens, so it's probably the least of the RISC-V worries.
I'd take a base/index addressing mode (preferably with scaling) long before I'd worry about something like add-with-carry. ARM64 got this right (although I'm not sure about the indexed addressing modes, I get the feeling that they are because or ARM legacy rather than being all that useful. but I guess it's one of those "you have to run the numbers" things, and I would expect ARM did).
That said, I think in the end, almost none of this matters. The real argument for RISC-V isn't really all that technical. It's an economic thing for people who want their own core, and don't want the licensing worries.
Linus
>
> 128-bit is the easiest case. The first addition produces carry, but never consumes
> carry. The second addition consumes carry, but never produces it.
> Try 192-bit or more. That's where replacement for middle
> ADCs will start to take a lot of RISC-V instructions.
A lot more? Two more instructions.
Yes, the extra carry-in will mean that you need a second 'sltu' instructions to generate subsequent carry bits (one for the regular add, the second for the previous carry add rippling all the way through). And then an instruction to add/or the two carries together. With a conditional move (which RISC-V doesn't have) I think the second sltu and the add/or to mix it in can be done as single cmov instead, saving one instruction (but probably making the dependency chain longer).
But it doesn't get worse from there. So a 192-bit add will need that extra sltu/add (on top of the other sltu/add) to generate the carry out of 128 bits. But that pattern won't get any worse for longer additions.
So is it annoying? Yes. But arbitrary extended-precision math isn't that common (and the two-word case that is simpler is probably the most common case of it), and it's not a complete deal-breaker when it happens, so it's probably the least of the RISC-V worries.
I'd take a base/index addressing mode (preferably with scaling) long before I'd worry about something like add-with-carry. ARM64 got this right (although I'm not sure about the indexed addressing modes, I get the feeling that they are because or ARM legacy rather than being all that useful. but I guess it's one of those "you have to run the numbers" things, and I would expect ARM did).
That said, I think in the end, almost none of this matters. The real argument for RISC-V isn't really all that technical. It's an economic thing for people who want their own core, and don't want the licensing worries.
Linus
