By: anon.1 (abc.delete@this.def.com), November 6, 2019 12:19 pm
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on November 5, 2019 11:39 am wrote:
> anon.1 (abc.delete@this.def.com) on November 5, 2019 6:17 am wrote:
> >
> > Somewhat orthogonal: I don't understand the opposition to
> > 2 reg source loads though. It still satisfies 2R1W.
>
> I think people get worried about the whole "loads and stores would be different".
>
> So then you'd have the base/index addressing only for loads, and stores would
> have base-only, because it needs the other read port for store data.
>
> Of course, stores don't need the 1W, so if you're willing to bend the rules a bit that's not a problem:
> you accept that you will always split stores into "generate address" and "generate data" ops.
>
> But if your primary design goal is a minimally simple pipeline, that doesn't work.
>
> Personally, I think that "not willing to ever bend rules" shows you don't care about
> reality. And again, personally, I think that "hey, loads and stores are very different,
> so maybe it's perfectly fine if addressing is very different too".
>
> But if you're the kind of person who finds traditional RISC to be "fundamentally beautiful", you're
> not the kind of person who accepts either of those choices. One is bending the rules, and the other
> is not symmetrical and thus unacceptable. It's like having specialized registers, for chrissake! Where
> do you end up? It's shades of x86 with one register dedicated for shift counts? Quelle horreur!
>
> End result: base-index addressing is evil and against everything RISC-V stood for.
>
> Linus
Ah, thanks. I hadn't thought of that. It's a bit ridiculous though, given that loads are typically more common than stores. So, even if 2-source-only instructions had merit, instead of using an extra LEA-like op only for stores, you now need it for both, just to meet this 'ideal encoding'. Seems like the RISC-V folks recommend op-fusion, which is another thing I find ridiculous. The whole point of RISC was to make decode simple. Now they want to add complexity in decode because, well, the ISA is oversimplified. Take that idea further and a uopcache is the next logical step because you can't sustain dispatch bandwidth or add extra pipe stages for fusion (it's not magic pixie dust, transistor gates have to be spent). Madness.
> anon.1 (abc.delete@this.def.com) on November 5, 2019 6:17 am wrote:
> >
> > Somewhat orthogonal: I don't understand the opposition to
> > 2 reg source loads though. It still satisfies 2R1W.
>
> I think people get worried about the whole "loads and stores would be different".
>
> So then you'd have the base/index addressing only for loads, and stores would
> have base-only, because it needs the other read port for store data.
>
> Of course, stores don't need the 1W, so if you're willing to bend the rules a bit that's not a problem:
> you accept that you will always split stores into "generate address" and "generate data" ops.
>
> But if your primary design goal is a minimally simple pipeline, that doesn't work.
>
> Personally, I think that "not willing to ever bend rules" shows you don't care about
> reality. And again, personally, I think that "hey, loads and stores are very different,
> so maybe it's perfectly fine if addressing is very different too".
>
> But if you're the kind of person who finds traditional RISC to be "fundamentally beautiful", you're
> not the kind of person who accepts either of those choices. One is bending the rules, and the other
> is not symmetrical and thus unacceptable. It's like having specialized registers, for chrissake! Where
> do you end up? It's shades of x86 with one register dedicated for shift counts? Quelle horreur!
>
> End result: base-index addressing is evil and against everything RISC-V stood for.
>
> Linus
Ah, thanks. I hadn't thought of that. It's a bit ridiculous though, given that loads are typically more common than stores. So, even if 2-source-only instructions had merit, instead of using an extra LEA-like op only for stores, you now need it for both, just to meet this 'ideal encoding'. Seems like the RISC-V folks recommend op-fusion, which is another thing I find ridiculous. The whole point of RISC was to make decode simple. Now they want to add complexity in decode because, well, the ISA is oversimplified. Take that idea further and a uopcache is the next logical step because you can't sustain dispatch bandwidth or add extra pipe stages for fusion (it's not magic pixie dust, transistor gates have to be spent). Madness.