[HN Gopher] RISC-V: The New Architecture on the Block
___________________________________________________________________
RISC-V: The New Architecture on the Block
Author : johnblood
Score : 22 points
Date : 2021-09-29 16:56 UTC (6 hours ago)
(HTM) web link (klarasystems.com)
(TXT) w3m dump (klarasystems.com)
| cepher wrote:
| I've recently gained an interest in computer architecture and
| systems programming in general after some high performance
| computing projects. Have been hearing about RISC-V from a
| distance, and am wondering if delving into it would be one of the
| best ways to satisfy this interest and gain some valuable
| knowledge/skills at the same time.
| Symmetry wrote:
| Depends on your background I guess? If you've taken a course
| like Computation Structures sure!
|
| https://ocw.mit.edu/courses/electrical-engineering-and-compu...
| cepher wrote:
| That class looks amazing. Took a higher level computer
| systems course in undergrad that roughly followed
| http://csapp.cs.cmu.edu/ (great course).
| ncmncm wrote:
| RISC-V is an OK design, but quite atypical. So, being simpler
| than others, it will be easier to understand; but for the same
| reason, does not acquaint you with details seen in designs
| currently used industrially.
|
| Some of the design decisions, and their expressed rationale,
| are considered unpersuasive by many involved with other
| architectures. For example, a status register, cited as
| interfering with optimal out-of-order execution, turns out not
| to be a problem in actual chips (where they rename it like
| other registers), so was omitted from the RISC-V design on what
| amounts to superstition. Some instruction sequences that would
| need to be "fused" to match performance of common chips involve
| many more instructions than are fused in any extant design, so
| it is unclear that such fusion would be practically achievable.
| Symmetry wrote:
| If you're working on a student or hobby project then
| simplifying the scoreboard or whatever OoO scheduling
| structure you use by having all instructions be 2 inputs and
| 1 output is a big help. Compared to the complexity of a
| modern core that's a drop in the bucket but for a single
| person or a few friends or grad students it can be a big
| deal. And by doing that project you're still learning the
| important things. So for someone in the position OP is in I'd
| certainly recommend RISC-V. Don't ask "Is RISC-V good or
| bad?" but rather "For what purposes is RISC-V suited?"
| 1MachineElf wrote:
| Lately I find myself upvoting every submission from Klara
| Systems[0]. Focus of the articles seems to be consistently good.
| I'm not affiliated with them, just an impressed onlooker.
|
| [0] https://news.ycombinator.com/from?site=klarasystems.com
| ncmncm wrote:
| I do not. This article is fluff, with at least one glaring
| falsehood noted in a sibling comment.
| hlieberman wrote:
| At least one of the points in this article isn't true. The
| article states "RISC-V is not affected by the Meltdown and
| Spectre vulnerabilities... [because it does] not perform any
| speculative memory accesses" -- but that's only true for some
| designs, not anything done by the ISA.
|
| Many of the higher performance RISC-V designs do, in fact, do
| speculation. RISC-V BOOM[0], by Berkeley, is vulnerable to
| Spectre[1][2]. One of the attempts to create an extension to the
| RISC-V ISA that has integrated security features (CHERI, [3])
| itself was shown to be vulnerable to Spectre-like attacks[4].
|
| The fact that most RISC-V chips were not vulnerable to Spectre is
| simply because they hadn't implemented a particular kind of
| performance optimization, not because there was anything
| intrinsic to the ISA that prevented them from being so.
|
| [0]: https://boom-core.org/
|
| [1]: https://github.com/abejgonzalez/boom-attacks
|
| [2]: https://boom-
| core.org/docs/replicating_mitigating_spectre_ca...
|
| [3]:
| https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...
|
| [4]: https://kth.diva-
| portal.org/smash/get/diva2:1538245/FULLTEXT...
| ncmncm wrote:
| Yes, it is a fundamentally misleading assertion.
| brucehoult wrote:
| What you say is true, but it's not the end of the story. Higher
| performance RISC-V CPU cores that do speculation are under
| development or in some cases have been announced but not yet
| shipped. They have the opportunity to design to avoid those
| vulnerabilities from the start, which is a lot easier than
| fixing things up afterwards -- or simply losing a lot of
| performance on already-shipped CPUs by turning features off.
|
| It's not actually very hard to avoid these kids of
| vulnerabilities. All that is needed is to not permanently
| update state until the instruction is no longer speculative.
|
| For example:
|
| - don't update the branch prediction tables until the branch is
| proven to execute
|
| - if loading a cache line causes another cache line to be
| evicted, keep both until it is known whether the load is
| supposed to execute
|
| This requires provisioning a few more of these kinds of
| resources than you might previously have had, which costs a
| little silicon area, but it doesn't cost speed. Sometimes
| particularly demanding code might cause you to run out of these
| speculation resources and then you have to stall until an entry
| is freed up. This can already happen with things such as store
| buffers. If it _never_ happens then you 've probably over-
| provisioned :-)
___________________________________________________________________
(page generated 2021-09-29 23:02 UTC)