5 ms·

Thus begins the slide from RISC to (what POWER/PowerPC ended up calling) FISC. It's not about reducing the instruction set, it's about designing a fast instruct

by addaon 5y ago

Thus begins the slide from RISC to (what POWER/PowerPC ended up calling) FISC. It's not about reducing the instruction set, it's about designing a fast instruction set with easy-to-generate, generalizable instructions. Even more than PowerPC (which generally added interesting but less primitive register-to-register ops), this is going straight to richer memory-to-memory ops.

marcodiego 5y ago
> Thus begins the slide from RISC to (what POWER/PowerPC ended up calling) FISC. You mean from RISC to CISC, right?
- jamesfinlayson 5y ago
  Looks like FISC is Fast Instruction Set Computing (maybe - all I could find was a Medium article that says that).
- galdosdi 5y ago
  Fair, haha. But I think the distinction intended lies in that the old CISC ISAs were complex out of a desire to provide the assembly programmer ergonomic creature comforts, backwards compatibility, etc. Today's instruction sets are designed for a world where the vast majority of machine code is generated by an optimizing compiler, not hand crafted through an assembler, and I think that was part of what the RISC revolution was about.
- addaon 5y ago
  No, although one could make that argument. RISC (reduced instruction set) has a few characteristics besides just the number of instructions -- most "working" instructions are register-to-register, with load/store instructions being the main memory-touching instructions; instructions are of a fixed size with a handful of simple encodings; instructions tend to be of low and similar latency. CISC starts at the other side -- memory-to-register and memory-to-register "working" instructions, variable length encodings, instructions of arbitrary latency, etc. FISC ("fast instruction set") was a term used for POWER/PowerPC to describe a philosophy that started very much with the RISC world, but considered the actual number of instructions to /not/ be a priority. Instructions were freely added when one instruction would take the place of several others, allowing higher code density and performance while staying more-or-less in line with the "core" RISC principles. None of the RISC principles are widely held by ARM today -- this thread is an example of non-trivial memory operations, Thumb adds many additional instruction encodings of variable length, load/store multiple already had pretty arbitrary latency (not to mention things like division)... but ARM still feels more RISC-like than CISC-like. In my mind, the fundamental reason for this is that ARM feels like it's intended to be the target of a compiler, not the target of a programmer writing assembly code. And, of the many ways we've described instruction sets, in my mind FISC is the best fit for this philosophy.
  - microtherion 5y ago
    > RISC (reduced instruction set) has a few characteristics besides just the number of instructions Many (or all?) of the RISC pioneers have claimed that RISC was never about keeping the number of instructions low, but about the complexity of those instructions (uniform encoding, register-to-register operations, etc, as you list). "Not a `reduced instruction set' but a `set of reduced instructions'" was the phrase I recall.
    - monocasa 5y ago
      It's both. Most of RISC falls out of the ability to assume the presence of dedicated I caches. Once you have a pseudo Harvard arch and your I fetches don't fight with your D fetches for bandwidth in inner loops, most of the benefit of microcode is gone, and a simpler ISA that looks like vertical microcode makes a lot more sense. Why have a single instruction that can crank away for hundreds of cycles computing a polynomial like VAX did if you can just write it yourself with the same perf?
  - Gaelan 5y ago
    > Thumb adds many additional instruction encodings of variable length, load/store multiple already had pretty arbitrary latency Worth noting that, AFAIK, both of these were removed on aarch64 (and aarch64-only cores do exist, notably Amazon's Graviton2)
baybal2 5y ago
Both x86, and 68xxx started that way. Old silicon actually game had a premium for smarter cores, which can do tricks like µOp fusions to compensate for smaller decoders. RISC was originally about getting reasonably small cores, which can do what they are advertised, and nothing more, and µOp fusing was certainly outside of that scope. Now, silicon is definitely cheaper, and both decoders, and other front-end smarts are completely microscopic in comparison to other parts of a modern SoC.
dehrmann 5y ago
When transistor density is growing and clock speed isn't, specialized instructions make a lot of sense.
brigade 5y ago
Begins? Where do SVE2's histogram instructions fit? Or even NEON's VLD3/VLD4, dating to armv7? (which can decode into over two dozen µops, depending on CPU) RISC has been definitively dead since Dennard scaling ran out; complex instructions are nothing new for ARM.
- garmaine 5y ago
  RISC-V?
  - pjmlp 5y ago
    Just wait until they get finished with all ongoing extensions.
- ksec 5y ago
  >RISC has been definitively dead since Dennard scaling ran out Except this is still not agreed upon on HN. Every single thread you did see more than half of the reply about RISC and RISC-V and how ARM v8 / POWER are no longer RISC hence RISC-V is going to win.
  - foxfluff 5y ago
    The RISC-V hype is crazy, but I feel like it must be a product of marketing. Or I'm missing something big. I've read the (unprivileged) instruction set spec and while it's a nice tidy ISA, it also feels like pretty much a textbook RISC with nothing to set it apart, no features to make it interesting in 2021. And it's not the first open ISA out there. Why is there so much hype surrounding it? If anything, I got the vibe that they were more concerned about cost of implementation and "scaling it down" than about a future-looking, high-performance ISA. And I'd prefer an ISA designed for 2040s high end PCs rather than one for 2000s microcontrollers..
    - SavantIdiot 5y ago
      It is both. RISC-V has some big names promoting it heavily. What open ISA would be a real competitor to RISC-V?
fay59 5y ago
ARM already has several instructions that aren’t exactly RISC. ldp and stp can load/store two registers at a given address and also update the value of the address register.
sifar 5y ago
Some references for FISC. The medium article [1]. The Ars Technica article it refers [2]. The paper which the Ars Technica refers to[3]. [1] https://medium.com/macoclock/interesting-remarks-on-risc-vs-cisc-microprocessors-1f034dca16ff https://medium.com/macoclock/interesting-remarks-on-risc-vs-... [2] https://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-5.html https://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-5.htm... [3] http://www.eng.ucy.ac.cy/theocharides/Courses/ECE656/beyond-risc.pdf http://www.eng.ucy.ac.cy/theocharides/Courses/ECE656/beyond-...
hyperman1 5y ago
I think one less visible aspect of RISC is the more orthogonal instruction set. Consider a CISC instruction set with all kinds of exceptional cases requiring specific registers. Humans writing assembler won't care much. When code was written in higher level languages and compilers did more advanced optimizations, instruction sets had to adapt to this style: A more regular instruction set, more registers, and simpler ways to use each register with each instruction. This was also part of the RISC movement. Consider the 8086, eg with http://mlsite.net/8086/ http://mlsite.net/8086/ * Temporary results belong in AX,so note in rows 9 and A how some common instructions have shorter encodings if you use AL/AX as a register. * Counters belong in CX, so shift and rotation only work with CX. There is a specific JCXZ, jump if CX is zero, intended for loops. * Memory is pointed at with BX,SI,DI, the mod r/m byte simply has no encoding for the other registers. * There are instructions as XLAT or AAM that are almost impossible for a compiler to use. * Multiplication and division have AX:DX as implicit register pair for one operand. * Conditional jumps had a short range of +/- 128 bytes, jumping further required an unconditional jump. Starting from the 80386 32 bit mode, a lot of this was cleaned up and made better accessible for compilers: EAX EBX ECX EDX ESI EDI were more or less interchangeable. Multiplication, shifting and memory access became possible with all these registers. Conditional jumps could reach the whole address space. I heard people at the time describing the x86 instruction set as more RISC-like starting with the 80386.
- lokedhs 5y ago
  I think this is specific to x86, which is not the only CISC CPU. Other CISC architectures are much more regular. I'm familiar with M68k which is both regular and CISC. You then have others, like the PDP-10 and S370 which are also regular but doesn't have these register-specific requirements that the Intel CPU's are stuck with.
  - hyperman1 5y ago
    True, the 8086 instruction set is ugly as hell. The 68000 was much better. I never saw the PDP-10 or S370 assembly , so I can't comment there. AFAIK it was a quick and dirty stopgap processor to drop in the 8080-shaped hole until they could finish the iapx432. Intel wanted 8080 code to be almost auto-translatable to 8086 code and give their customers a way out of the 8bit 64K world. So they designed instructions and a memory layout to make this possible, at the cost of orthogonality. Then IBM hacked together the quick and dirty PC based on the quick and dirty processor, and somehow one of the worst possible designs became the industry standard. Thinking of it, the 80386 might be Intel coming to terms with the fact that everyone was stuck with this ugly design, and making the best of it. See also the 80186, a CPU incompatible with the PC. Maybe a sign Intel didn't believed in the future of the PC ?

by addaon 5y ago

marcodiego 5y ago

> Thus begins the slide from RISC to (what POWER/PowerPC ended up calling) FISC. You mean from RISC to CISC, right?

jamesfinlayson 5y ago
Looks like FISC is Fast Instruction Set Computing (maybe - all I could find was a Medium article that says that).
galdosdi 5y ago
Fair, haha. But I think the distinction intended lies in that the old CISC ISAs were complex out of a desire to provide the assembly programmer ergonomic creature comforts, backwards compatibility, etc. Today's instruction sets are designed for a world where the vast majority of machine code is generated by an optimizing compiler, not hand crafted through an assembler, and I think that was part of what the RISC revolution was about.
addaon 5y ago
No, although one could make that argument. RISC (reduced instruction set) has a few characteristics besides just the number of instructions -- most "working" instructions are register-to-register, with load/store instructions being the main memory-touching instructions; instructions are of a fixed size with a handful of simple encodings; instructions tend to be of low and similar latency. CISC starts at the other side -- memory-to-register and memory-to-register "working" instructions, variable length encodings, instructions of arbitrary latency, etc. FISC ("fast instruction set") was a term used for POWER/PowerPC to describe a philosophy that started very much with the RISC world, but considered the actual number of instructions to /not/ be a priority. Instructions were freely added when one instruction would take the place of several others, allowing higher code density and performance while staying more-or-less in line with the "core" RISC principles. None of the RISC principles are widely held by ARM today -- this thread is an example of non-trivial memory operations, Thumb adds many additional instruction encodings of variable length, load/store multiple already had pretty arbitrary latency (not to mention things like division)... but ARM still feels more RISC-like than CISC-like. In my mind, the fundamental reason for this is that ARM feels like it's intended to be the target of a compiler, not the target of a programmer writing assembly code. And, of the many ways we've described instruction sets, in my mind FISC is the best fit for this philosophy.
- microtherion 5y ago
  > RISC (reduced instruction set) has a few characteristics besides just the number of instructions Many (or all?) of the RISC pioneers have claimed that RISC was never about keeping the number of instructions low, but about the complexity of those instructions (uniform encoding, register-to-register operations, etc, as you list). "Not a `reduced instruction set' but a `set of reduced instructions'" was the phrase I recall.
  - monocasa 5y ago
    It's both. Most of RISC falls out of the ability to assume the presence of dedicated I caches. Once you have a pseudo Harvard arch and your I fetches don't fight with your D fetches for bandwidth in inner loops, most of the benefit of microcode is gone, and a simpler ISA that looks like vertical microcode makes a lot more sense. Why have a single instruction that can crank away for hundreds of cycles computing a polynomial like VAX did if you can just write it yourself with the same perf?
- Gaelan 5y ago
  > Thumb adds many additional instruction encodings of variable length, load/store multiple already had pretty arbitrary latency Worth noting that, AFAIK, both of these were removed on aarch64 (and aarch64-only cores do exist, notably Amazon's Graviton2)

baybal2 5y ago

Both x86, and 68xxx started that way. Old silicon actually game had a premium for smarter cores, which can do tricks like µOp fusions to compensate for smaller decoders. RISC was originally about getting reasonably small cores, which can do what they are advertised, and nothing more, and µOp fusing was certainly outside of that scope. Now, silicon is definitely cheaper, and both decoders, and other front-end smarts are completely microscopic in comparison to other parts of a modern SoC.

dehrmann 5y ago

When transistor density is growing and clock speed isn't, specialized instructions make a lot of sense.

brigade 5y ago

Begins? Where do SVE2's histogram instructions fit? Or even NEON's VLD3/VLD4, dating to armv7? (which can decode into over two dozen µops, depending on CPU) RISC has been definitively dead since Dennard scaling ran out; complex instructions are nothing new for ARM.

garmaine 5y ago
RISC-V?
- pjmlp 5y ago
  Just wait until they get finished with all ongoing extensions.
ksec 5y ago
>RISC has been definitively dead since Dennard scaling ran out Except this is still not agreed upon on HN. Every single thread you did see more than half of the reply about RISC and RISC-V and how ARM v8 / POWER are no longer RISC hence RISC-V is going to win.
- foxfluff 5y ago
  The RISC-V hype is crazy, but I feel like it must be a product of marketing. Or I'm missing something big. I've read the (unprivileged) instruction set spec and while it's a nice tidy ISA, it also feels like pretty much a textbook RISC with nothing to set it apart, no features to make it interesting in 2021. And it's not the first open ISA out there. Why is there so much hype surrounding it? If anything, I got the vibe that they were more concerned about cost of implementation and "scaling it down" than about a future-looking, high-performance ISA. And I'd prefer an ISA designed for 2040s high end PCs rather than one for 2000s microcontrollers..
  - SavantIdiot 5y ago
    It is both. RISC-V has some big names promoting it heavily. What open ISA would be a real competitor to RISC-V?

fay59 5y ago

ARM already has several instructions that aren’t exactly RISC. ldp and stp can load/store two registers at a given address and also update the value of the address register.

sifar 5y ago

Some references for FISC. The medium article [1]. The Ars Technica article it refers [2]. The paper which the Ars Technica refers to[3]. [1] https://medium.com/macoclock/interesting-remarks-on-risc-vs-cisc-microprocessors-1f034dca16ff https://medium.com/macoclock/interesting-remarks-on-risc-vs-... [2] https://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-5.html https://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-5.htm... [3] http://www.eng.ucy.ac.cy/theocharides/Courses/ECE656/beyond-risc.pdf http://www.eng.ucy.ac.cy/theocharides/Courses/ECE656/beyond-...

hyperman1 5y ago

I think one less visible aspect of RISC is the more orthogonal instruction set. Consider a CISC instruction set with all kinds of exceptional cases requiring specific registers. Humans writing assembler won't care much. When code was written in higher level languages and compilers did more advanced optimizations, instruction sets had to adapt to this style: A more regular instruction set, more registers, and simpler ways to use each register with each instruction. This was also part of the RISC movement. Consider the 8086, eg with http://mlsite.net/8086/ http://mlsite.net/8086/ * Temporary results belong in AX,so note in rows 9 and A how some common instructions have shorter encodings if you use AL/AX as a register. * Counters belong in CX, so shift and rotation only work with CX. There is a specific JCXZ, jump if CX is zero, intended for loops. * Memory is pointed at with BX,SI,DI, the mod r/m byte simply has no encoding for the other registers. * There are instructions as XLAT or AAM that are almost impossible for a compiler to use. * Multiplication and division have AX:DX as implicit register pair for one operand. * Conditional jumps had a short range of +/- 128 bytes, jumping further required an unconditional jump. Starting from the 80386 32 bit mode, a lot of this was cleaned up and made better accessible for compilers: EAX EBX ECX EDX ESI EDI were more or less interchangeable. Multiplication, shifting and memory access became possible with all these registers. Conditional jumps could reach the whole address space. I heard people at the time describing the x86 instruction set as more RISC-like starting with the 80386.

lokedhs 5y ago
I think this is specific to x86, which is not the only CISC CPU. Other CISC architectures are much more regular. I'm familiar with M68k which is both regular and CISC. You then have others, like the PDP-10 and S370 which are also regular but doesn't have these register-specific requirements that the Intel CPU's are stuck with.
- hyperman1 5y ago
  True, the 8086 instruction set is ugly as hell. The 68000 was much better. I never saw the PDP-10 or S370 assembly , so I can't comment there. AFAIK it was a quick and dirty stopgap processor to drop in the 8080-shaped hole until they could finish the iapx432. Intel wanted 8080 code to be almost auto-translatable to 8086 code and give their customers a way out of the 8bit 64K world. So they designed instructions and a memory layout to make this possible, at the cost of orthogonality. Then IBM hacked together the quick and dirty PC based on the quick and dirty processor, and somehow one of the worst possible designs became the industry standard. Thinking of it, the 80386 might be Intel coming to terms with the fact that everyone was stuck with this ugly design, and making the best of it. See also the 80186, a CPU incompatible with the PC. Maybe a sign Intel didn't believed in the future of the PC ?