random person (random.delete@this.person.com) on December 21, 2018 2:04 am wrote:
> Doug S (foo.delete@this.bar.bar) on December 20, 2018 11:10 pm wrote:
> > Adrian (a.delete@this.acm.org) on December 20, 2018 8:51 pm wrote:
> > > The RISC-V fans argue that the extra instructions do not matter, because a fast implementation will fuse
> > > the address computation instructions with the data handling instructions, achieving the same throughput.
> > >
> > >
> > > I do not agree, because I believe that it is stupid to code
> > > the address computation with an extra instruction
> > > word, when the same thing can be encoded with a couple of
> > > bits in an addressing mode field and the instruction
> > > decoder is also certainly simpler than the one that must fuse those instruction pairs.
> >
> >
> > Aren't these differences due to the fact ARMv8 has evolved from previous ARM ISAs over a
> > few decades of real world use that showed where the weak points were, whereas RISC-V is
> > mostly from an academic ivory tower purist background with very little real world usage?
> > Sometimes you find you must compromise your purist principles to produce a better result,
> > which is why ARMv8 adopted some features that aren't considered traditionally RISC.
>
> I think this is oversimplifying things - you don't have to have built an ARMv7 chip to have learned from some
> of ARMv7's mistakes. Or x86's. You seem to be oddly dismissive of academics, but they articulate why they
> made the choices that they did. Clearly, one of their primary goals was to create an ISA that is as simple
> as possible to decode, with some obvious sacrifices to code density. Having such a small and easy to decode
> ISA allows them to push to even smaller design points than might be possible for some other ISAs.
>
> > The arguments made by the RISC-V fans sound a lot like arguments made by Itanium fans
> > where the compiler would pick up the slack for the shortcomings, and the raw speed would
> > enable it to beat all comers. But RISC-V fans aren't even claiming this will result in
> > superior performance, only that it will be the same. If so, what's the point?
> >
> > They are trading complexity in instruction decode for dynamic execution complexity. I think the
> > performance that x86 is able to attain has shown us that instruction decode complexity matters
> > little if at all given modern transistor budgets. Getting wider to issue and execute those index
> > calculations as separate instructions in parallel, on the other hand, requires very careful design
> > to insure all paths have enough resources without escalating power draw too much.
>
> Let's not get carried away here - x86 processors are attaining performance by fighting against/working
> around ugliness of the ISA here. Those uop caches take a lot of transistors, and will have to continue
> to grow over time and then they still have to put down a lot of logic for the regular decode path,
> so they sure are spending a lot on this for it to supposedly 'matter little if at all'. Wide issue
> helps little if you can only sustain a couple of uops per cycle from the front end.
>
> The loss of some code density does hurt though, so there is definitely room for a more middle-ground
> approach. RISC-V C extension presents either 2B or 4B instructions, which is certainly a lot better
> to deal with than the 'anywhere between 1 and 15 bytes' of x86. However, there's something to be
> said for the simplicity of pure fixed-length ISAs, as it simplifies quite a bit in the fetch, decode,
> branch prediction. Notice that even Samsung's ARMv8 core can hit 48B fetch per cycle, where Skylake
> can get to at most 16B. Is x86 able to achieve 3x the code density to make up for it?
>
>

As dmcq mentioned, ARMv8 is slightly more dense than x86-64.

RV64 is about 8% less dense than x86-64 (on SPECint2006). But RV64C is about 30% more dense than x86-64.