3 comments

Discussion is closed. Login to edit/delete existing comments.

• 

  MGetz August 11, 2022 1

  Collapse this comment Copy link

  Not sure how to say this, but I find it hilarious when the RISC diehards come out of the woodwork to trash CISC architectures without actually understanding the dynamics of ISA design, pipelining, caches, and multi-core consistency. The fact of the matter is that all ISAs are generally heading towards FISC at this point (Fast Instruction set computing) where the goal is to do things the fastest with the least power. AArch64 is a really...

  Read more

  Not sure how to say this, but I find it hilarious when the RISC diehards come out of the woodwork to trash CISC architectures without actually understanding the dynamics of ISA design, pipelining, caches, and multi-core consistency. The fact of the matter is that all ISAs are generally heading towards FISC at this point (Fast Instruction set computing) where the goal is to do things the fastest with the least power. AArch64 is a really good example of an ISA that was designed FISC from the start instead of being retrofitted to be FISC later like x86-64.

  The split reservation based atomics are great on paper, and if I was writing assembly maybe then too. But actually expressing that in code is actually quite painful using anything but intrinsic ops. Whereas the combined instructions actually fit how most atomics code is written in my experience, it’s either a load or store done in an acquire or a release. That also fits with how the standards for C++ and C is written, imagine that.

  I’m guessing if the designers of AArch64 could do it over clean they’d leave out quite a bit they brought over as ARMisms and just go with what’s showing up in 8.1 and later.

  Also for anyone hoping RISC-V will swoop in to be the savior from the AArch64 de-facto monopoly… unless the ISA gets significantly reworked it’s going to be mostly focused on embedded for the foreseeable future because it’s just not designed from the ground up to be highly parallel like AArch64 is.

  Read less
  • 

    Simon Farnsworth August 15, 2022 1

    Collapse this comment Copy link

    It's all circling back round to the beginning - the original RISC versus CISC war was whether the fastest possible processor would have a small number of simple instructions (RISC) and execute them very fast, or whether it would have hugely complex instructions but execute fewer instructions per second (CISC).

    The real development, though, was that early RISC advocates did ISA design differently to the then-established practice. Established practice was to design a set of instructions...

    Read more

    It’s all circling back round to the beginning – the original RISC versus CISC war was whether the fastest possible processor would have a small number of simple instructions (RISC) and execute them very fast, or whether it would have hugely complex instructions but execute fewer instructions per second (CISC).

    The real development, though, was that early RISC advocates did ISA design differently to the then-established practice. Established practice was to design a set of instructions that would make programming in assembly easy, and to them implement that; RISC advocates instead suggested that you should start with the smallest set of instructions to make it possible to program the system, and then only add new instructions if you could demonstrate an improvement to performance by doing so.

    Read less
    • 

      MGetz August 16, 2022 1

      Collapse this comment Copy link

      I think that's why I'm so amused by the whole thing. When RISC was first described pipelines were largely in order, superscalar was just starting to be a thing, and nobody had really hit a hard limit on clock speed due to leakage in silicon yet. So to me most RISC fans have lost the plot of what RISC was intended to do as you mentioned. The Pentium 4 and the various PowerPC and POWER...

      Read more

      I think that’s why I’m so amused by the whole thing. When RISC was first described pipelines were largely in order, superscalar was just starting to be a thing, and nobody had really hit a hard limit on clock speed due to leakage in silicon yet. So to me most RISC fans have lost the plot of what RISC was intended to do as you mentioned. The Pentium 4 and the various PowerPC and POWER ISA CPUs put an end to the ‘clock speeds will save us’ however due to leakage and the fact that there is a limit to how fast you can drive the gate of a transistor. Traditional RISC trades complexity of instructions for complexity of dependency chains however and that adds complexity to silicon… the very thing RISC was designed to avoid in the original description. Itainium tried to solve this using VLIW which just spread the pain to the compiler, Arm32 did much the same in some ways with making every instruction largely conditional. Both features were largely ‘failures’. Arm32 because nobody and no compiler ever really used it and the superscalar was largely faster anyway. Itainium because well… lots of reasons that are documented everywhere.

      This is why I think RISC-V is a dead end, it sticks to traditional RISC and thus traps itself in questionable dependency chains. Whereas AArch64 was designed from the ground up largely to break those chains as quickly as possible to allow the CPU to use its superscalar capabilities to the max.

      From my perspective the restrictive x86 memory model is holding back x86-64 more than the variable length instructions. This is because it constrains the ability of the CPU to retire instructions until the previous reads and writes are visible to the CPU. If x86-64 were to introduce an opt in ‘loose mode’ where that constraint is no longer enforced it would allow the already robust super scalar infrastructure to bottle neck on execution port availability in most cases.

      Read less