6 ms·

Chisel is pretty cool in its own right. But the best I can say about RISC-V is that it's clean and open source. It is clean. Basically, it's a clean up. Get rid

Chisel is pretty cool in its own right. But the best I can say about RISC-V is that it's clean and open source. It is clean. Basically, it's a clean up. Get rid of register windows, branch delays slots, tagged integers, ..., every wart that previous RISCs thought were a good idea but turned out very bad. Clean is good but in 2016 that's not enough for me. x86 is very ugly but Intel has spent decades making it fast, low power, ... Anything you want it to be but never perfect. I think RISC was sort of a good idea in the 80s. Not great but good. It continued the ld/st/register approach of Saint Seymour. IBM ran with it and arguably started it. But it's been tried and found ... wanting.

MrBuddyCasino 10y ago
> Get rid of register windows The ESP32 is a very new chip and has them too (xtensa arch). Why are they bad? > RISC was sort of a good idea in the 80s This is where people usually come in saying that x86 is internally RISC, and that the ISA helps with code density which is otherwise a problem for RISC. Is there any truth to that?
- yaantc 10y ago
  Code density used to be a problem at first for RISC, due to a fixed instruction size of 32 bits typically. But most RISC (or VLIW) ISA have solved the problem by introducing some level of variable size instructions encoding. It's Thumb2 for ARM, but there's the equivalent for MIPS and others. XTensa from the start used mixed 16/24/32 bits instructions IIRC. Now it used to be clunky at first. For example the first generation Thumb required a processor mode switch between 16 bits instructions only and 32 bits only, with a performance penalty in thumb mode. But with Thumb2 there is no mode switch, both kinds can be mixed freely and the compilers are now smart enough that the performance impact is negligible (could be a gain sometimes with reduced I-cache pressure). For deeply embedded designs, where code size probably matters most, such variable encoding is always supported nowadays with good results, and it's a way to differentiate for more exotic ISA like Cortus or Andes for example. In some specific benchmarks I did the lowest code sizes where from such embedded RISC ISAs, better than x86 for example (YMMV, benchmark your code for best results ;). I haven't benchmarked the RISC-V optional compact code support, but I would expect it to be competitive with x86. Code size is no longer an intrinsic difference for CISC vs RISC from what I've seen, although there are variations between implementations. ======== Edit: one precision, there's no Thumb mode in ARMv8 64 bits mode. One can run 32 bits code using Thumb on an ARMv8 processor in 32 bits mode, but to use 64 bits mode means not using variable size instructions (Thumb), at least for now. But I see this as just an implementation specific decision from ARM. The high level message stays: it's possible to have good code density with a RISC ISA, and all deeply embedded RISC ISA have some form of variable instruction size (at least 16 and 32 bits).
- userbinator 10y ago
  As mentioned, the whole RISC approach came out of the 80s, but it's important to remember that this was at a time when RAM was (briefly) faster than the CPU, so memory bandwidth was largely unused and the CPU instruction execution was the bottleneck. Thus the idea of sacrificing fetch bandwidth to achieve lower cycle times and thus more instruction throughput, along with simplifying the CPU core in the effort to speed up instruction decode/execute to allow raising clock speeds. Today, memory bandwidth is the bottleneck, caches are essentially mandatory for reasonable performance, and newer implementations of even architectures classically considered RISC, e.g. ARM, do uop-based decoding. Physical limits also put an end to increasing clock speeds, and because of OoO execution and the memory bottleneck (which becomes even more of an issue with multiple cores), it makes more sense for a CPU to consume more complex instructions and decode them internally into "RISC-like" uops for scheduling and execution, even if each one takes a few more cycles. This is where people usually come in saying that x86 is internally RISC, and that the ISA helps with code density which is otherwise a problem for RISC. Is there any truth to that? This comparison might be of interest: https://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient https://www.extremetech.com/extreme/188396-the-final-isa-sho... It shows that x86 and ARM are very close, while the MIPS, the "purer RISC", lags behind in terms of efficiency despite having twice as much cache as the next smaller system in the list. IMHO, as someone who has a long experience working with x86 Asm, I rather like it. I think its predecessor, Z80/8085/8080, is pretty nice too. The 32-bit extension (i386) was quite orthogonal and retained a compact encoding. If there's anything I'd consider "ugly", it'd be what AMD did to it with their 64-bit extensions. From this perspective, all the RISCs look absolutely boring and limited, more so the "cleaner" they are. (ARM is slightly less of a "pure RISC", and that may be one of the reasons why it has remained competitive.)
  - dfox 10y ago
    The main proposition of RISC is that you can get near 1 IPC without caches provided that you have enough fetch bandwith (which still is not significant problem for deeply embeded harvard designs). Doing >=1 IPC on CISC architecture with variable length unaligned instructions is essentially impossible without I-cache and significant complexity. The reason why ARM implementations do uop-based decoding partly lies in the fact that while ARM ISA maps well to traditional RISC pipeline, it does not map so well to superscalar pipeline be it with or without OoO.
- valarauca1 10y ago
  This is where people usually come in saying that x86 is internally RISC, and that the ISA helps with code density which is otherwise a problem for RISC. Is there any truth to that? Yes/No. Modern x86_64 chips are likely RISC-y in their core post μOP decoding. More-over it is way more complicated then that because port forwarding stalls point to what is presented as a core likely being 15-20 specialized cores working in conjunction. But then Skylake fixed this so who knows. The RISC instruction density is just a hold over from the 80's when RAM was fast, and decoding was hard. Modern iCache's + Moore's Law has more or less solved these problems.
- rwmj 10y ago
  RISC-V has a compressed extension that compares favourably to even x86. See https://youtu.be/Ii_pEXKKYUg?t=13m55s https://youtu.be/Ii_pEXKKYUg?t=13m55s (bottom of the slide).
- CalChris 10y ago
  No, internally modern x86s are NOT (reduced) RISC. Instead they translate x86 instructions into long (100+ bits) horizontal microcode (mu-ops). This approach actually got started at Bell Labs by Ditzel (who also co-authored Case for a Reduced Instruction Set and started Transmeta) as the Crisp project, the decoded i cache.
  - mafribe 10y ago
    Interesting. Could you point me towards an accessible and up-to-date description of this? I've been telling my compiler students that internally modern x86 commands are translated to RISC. I need to update my course material.
    - MrBuddyCasino 10y ago
      Seconded, first time I've heard of this.
    - CalChris 10y ago
      Sure. I'm on my iPhone right now. But I'll add to this. Back in the 80s everyone called everything RISC. Check the Bulldog compiler book; the VLIW people were calling VLIW a RISC. Odd since Fisher had worked on microgramming but RISC was very much in vogue. Before there was RISC there was micro programming, horizontal wide microprogramming. The VAX 11/780 was microprogrammed. I think what people are saying when they say Haswell is a RISC is it's microprogrammed. With the Pentium III the uop was 118 bits wide. Bandwidth not an issue. Latency always an issue. http://www.tomshardware.com/reviews/intel,264-6.html http://www.tomshardware.com/reviews/intel,264-6.html With Haswell, the scheduler can Macro Fuse a test and conditional branch. I've never been happy with the shape shifting definitions of RISC over the years but that just doesn't fit any definition of RISC I've seen. Lastly RISC started out as a critique of complex ISAs at a time when the VAX ISA was interpreted with microprogramming loops. Not with RISC loops. So I think history has conflated the terms RISC and horizontal microcode and really they're different. Lastly lastly, there is a difference between the interpreter loop approach VAX took and the translate approach Haswell takes. Also Transmeta compiled x86. But this does not a RISC make. All that's really going on is that Haswell is decoding an x86 instruction and caching the decoding step. The uop cache is relatively more recent (2000?) and long after RISC. But it saves decoding power and latency. The micro architecture wasn't that different before the cache was added.
- tjalfi 10y ago
  Register windows help with code size but bring along other costs. http://yarchive.net/comp/register_windows.html http://yarchive.net/comp/register_windows.html explains some of the tradeoffs.
  - MrBuddyCasino 10y ago
    Thanks! The tl;dr is you'd expect register windows to be at their best for single-thread user programs, so I guess it makes sense for embedded stuff like the ESP32.
andreiw 10y ago
FWIW 64-bit ARMv8 is clean as well, designed without all the weird baggage that came with the 26->32 legacy ARM architecture. More importantly, ARM had reduced the impedance mismatch with x64, making porting various kinds of software (including system and virt) to ARM64 a relatively trivial affair. IBM seemed to have taken a few cues from that, finally implementing similar MMU and MMU virt support in Power ISA 3.0 (Power9).
- rwmj 10y ago
  This is a strange analysis. Aarch64 is very complex, and they screwed up virt the first time and are now working to fix it in ARMv8.1.
  - andreiw 10y ago
    wat? v8.2 is out and soon in products, v8.3 has been announced. What do you consider to be very complex, if you throw away 32-bit support? What specifically do you consider to be "screwed up", beyond the virt hole with cntfrq_el0, which affects migration between different vendor implementations? The whole VHE affair is more about enabling specific design decisions made by the AArch64 Linux implementation, if that's what you're alluding to. Certainly an ARMv8 implementation without VHE is not broken, virtualization works just fine.
detaro 10y ago
IBM still calls the POWER ISA RISC because it has fixed instruction width and load/store architecture, just like ARM it has a large number of instructions now as well (~1300 I think). The actual implementations also do all kinds of pipelining and fetching optimizations that maybe traditionally would have been more the domain of CISC CPUs (and arguably are not directly connected to the ISA).

MrBuddyCasino 10y ago

> Get rid of register windows The ESP32 is a very new chip and has them too (xtensa arch). Why are they bad? > RISC was sort of a good idea in the 80s This is where people usually come in saying that x86 is internally RISC, and that the ISA helps with code density which is otherwise a problem for RISC. Is there any truth to that?

yaantc 10y ago
Code density used to be a problem at first for RISC, due to a fixed instruction size of 32 bits typically. But most RISC (or VLIW) ISA have solved the problem by introducing some level of variable size instructions encoding. It's Thumb2 for ARM, but there's the equivalent for MIPS and others. XTensa from the start used mixed 16/24/32 bits instructions IIRC. Now it used to be clunky at first. For example the first generation Thumb required a processor mode switch between 16 bits instructions only and 32 bits only, with a performance penalty in thumb mode. But with Thumb2 there is no mode switch, both kinds can be mixed freely and the compilers are now smart enough that the performance impact is negligible (could be a gain sometimes with reduced I-cache pressure). For deeply embedded designs, where code size probably matters most, such variable encoding is always supported nowadays with good results, and it's a way to differentiate for more exotic ISA like Cortus or Andes for example. In some specific benchmarks I did the lowest code sizes where from such embedded RISC ISAs, better than x86 for example (YMMV, benchmark your code for best results ;). I haven't benchmarked the RISC-V optional compact code support, but I would expect it to be competitive with x86. Code size is no longer an intrinsic difference for CISC vs RISC from what I've seen, although there are variations between implementations. ======== Edit: one precision, there's no Thumb mode in ARMv8 64 bits mode. One can run 32 bits code using Thumb on an ARMv8 processor in 32 bits mode, but to use 64 bits mode means not using variable size instructions (Thumb), at least for now. But I see this as just an implementation specific decision from ARM. The high level message stays: it's possible to have good code density with a RISC ISA, and all deeply embedded RISC ISA have some form of variable instruction size (at least 16 and 32 bits).
userbinator 10y ago
As mentioned, the whole RISC approach came out of the 80s, but it's important to remember that this was at a time when RAM was (briefly) faster than the CPU, so memory bandwidth was largely unused and the CPU instruction execution was the bottleneck. Thus the idea of sacrificing fetch bandwidth to achieve lower cycle times and thus more instruction throughput, along with simplifying the CPU core in the effort to speed up instruction decode/execute to allow raising clock speeds. Today, memory bandwidth is the bottleneck, caches are essentially mandatory for reasonable performance, and newer implementations of even architectures classically considered RISC, e.g. ARM, do uop-based decoding. Physical limits also put an end to increasing clock speeds, and because of OoO execution and the memory bottleneck (which becomes even more of an issue with multiple cores), it makes more sense for a CPU to consume more complex instructions and decode them internally into "RISC-like" uops for scheduling and execution, even if each one takes a few more cycles. This is where people usually come in saying that x86 is internally RISC, and that the ISA helps with code density which is otherwise a problem for RISC. Is there any truth to that? This comparison might be of interest: https://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient https://www.extremetech.com/extreme/188396-the-final-isa-sho... It shows that x86 and ARM are very close, while the MIPS, the "purer RISC", lags behind in terms of efficiency despite having twice as much cache as the next smaller system in the list. IMHO, as someone who has a long experience working with x86 Asm, I rather like it. I think its predecessor, Z80/8085/8080, is pretty nice too. The 32-bit extension (i386) was quite orthogonal and retained a compact encoding. If there's anything I'd consider "ugly", it'd be what AMD did to it with their 64-bit extensions. From this perspective, all the RISCs look absolutely boring and limited, more so the "cleaner" they are. (ARM is slightly less of a "pure RISC", and that may be one of the reasons why it has remained competitive.)
- dfox 10y ago
  The main proposition of RISC is that you can get near 1 IPC without caches provided that you have enough fetch bandwith (which still is not significant problem for deeply embeded harvard designs). Doing >=1 IPC on CISC architecture with variable length unaligned instructions is essentially impossible without I-cache and significant complexity. The reason why ARM implementations do uop-based decoding partly lies in the fact that while ARM ISA maps well to traditional RISC pipeline, it does not map so well to superscalar pipeline be it with or without OoO.
valarauca1 10y ago
This is where people usually come in saying that x86 is internally RISC, and that the ISA helps with code density which is otherwise a problem for RISC. Is there any truth to that? Yes/No. Modern x86_64 chips are likely RISC-y in their core post μOP decoding. More-over it is way more complicated then that because port forwarding stalls point to what is presented as a core likely being 15-20 specialized cores working in conjunction. But then Skylake fixed this so who knows. The RISC instruction density is just a hold over from the 80's when RAM was fast, and decoding was hard. Modern iCache's + Moore's Law has more or less solved these problems.
rwmj 10y ago
RISC-V has a compressed extension that compares favourably to even x86. See https://youtu.be/Ii_pEXKKYUg?t=13m55s https://youtu.be/Ii_pEXKKYUg?t=13m55s (bottom of the slide).
CalChris 10y ago
No, internally modern x86s are NOT (reduced) RISC. Instead they translate x86 instructions into long (100+ bits) horizontal microcode (mu-ops). This approach actually got started at Bell Labs by Ditzel (who also co-authored Case for a Reduced Instruction Set and started Transmeta) as the Crisp project, the decoded i cache.
- mafribe 10y ago
  Interesting. Could you point me towards an accessible and up-to-date description of this? I've been telling my compiler students that internally modern x86 commands are translated to RISC. I need to update my course material.
  - MrBuddyCasino 10y ago
    Seconded, first time I've heard of this.
  - CalChris 10y ago
    Sure. I'm on my iPhone right now. But I'll add to this. Back in the 80s everyone called everything RISC. Check the Bulldog compiler book; the VLIW people were calling VLIW a RISC. Odd since Fisher had worked on microgramming but RISC was very much in vogue. Before there was RISC there was micro programming, horizontal wide microprogramming. The VAX 11/780 was microprogrammed. I think what people are saying when they say Haswell is a RISC is it's microprogrammed. With the Pentium III the uop was 118 bits wide. Bandwidth not an issue. Latency always an issue. http://www.tomshardware.com/reviews/intel,264-6.html http://www.tomshardware.com/reviews/intel,264-6.html With Haswell, the scheduler can Macro Fuse a test and conditional branch. I've never been happy with the shape shifting definitions of RISC over the years but that just doesn't fit any definition of RISC I've seen. Lastly RISC started out as a critique of complex ISAs at a time when the VAX ISA was interpreted with microprogramming loops. Not with RISC loops. So I think history has conflated the terms RISC and horizontal microcode and really they're different. Lastly lastly, there is a difference between the interpreter loop approach VAX took and the translate approach Haswell takes. Also Transmeta compiled x86. But this does not a RISC make. All that's really going on is that Haswell is decoding an x86 instruction and caching the decoding step. The uop cache is relatively more recent (2000?) and long after RISC. But it saves decoding power and latency. The micro architecture wasn't that different before the cache was added.
tjalfi 10y ago
Register windows help with code size but bring along other costs. http://yarchive.net/comp/register_windows.html http://yarchive.net/comp/register_windows.html explains some of the tradeoffs.
- MrBuddyCasino 10y ago
  Thanks! The tl;dr is you'd expect register windows to be at their best for single-thread user programs, so I guess it makes sense for embedded stuff like the ESP32.

andreiw 10y ago

FWIW 64-bit ARMv8 is clean as well, designed without all the weird baggage that came with the 26->32 legacy ARM architecture. More importantly, ARM had reduced the impedance mismatch with x64, making porting various kinds of software (including system and virt) to ARM64 a relatively trivial affair. IBM seemed to have taken a few cues from that, finally implementing similar MMU and MMU virt support in Power ISA 3.0 (Power9).

rwmj 10y ago
This is a strange analysis. Aarch64 is very complex, and they screwed up virt the first time and are now working to fix it in ARMv8.1.
- andreiw 10y ago
  wat? v8.2 is out and soon in products, v8.3 has been announced. What do you consider to be very complex, if you throw away 32-bit support? What specifically do you consider to be "screwed up", beyond the virt hole with cntfrq_el0, which affects migration between different vendor implementations? The whole VHE affair is more about enabling specific design decisions made by the AArch64 Linux implementation, if that's what you're alluding to. Certainly an ARMv8 implementation without VHE is not broken, virtualization works just fine.

detaro 10y ago

IBM still calls the POWER ISA RISC because it has fixed instruction width and load/store architecture, just like ARM it has a large number of instructions now as well (~1300 I think). The actual implementations also do all kinds of pipelining and fetching optimizations that maybe traditionally would have been more the domain of CISC CPUs (and arguably are not directly connected to the ISA).