Talk:RISC-V

The main non-technical difference between RISC-V and other instruction sets is the licensing. Other instruction sets are either not explicitly licensed at all (at this point, I don't think anybody can license IBM patents on z/Architecture, so no mainframe clones), licensed selectively (I think Intel and AMD cross-license some patents etc. so Intel can make x86-64 processors and AMD can make processors using the non-64-bit parts of x86-64, but I don't think either of them offer licenses to third parties), or licensed but not with a free license (ARM has an architecture license but it's not a free license; MIPS and IBM's Power ISA may be similar). RISC-V doesn't charge for use of the ISA, and allows modifications, although non-compliant extensions can't use the trademark.

RISC-V#Significance doesn't mention instruction sets until the third paragraph. The first two paragraphs mainly talk about chip design; they speak of Arm and MIPS Technologies as selling chip designs, not as licensing an instruction set. In particular

To cover the costs of such a team, commercial vendors of computer designs, such as ARM Holdings and MIPS Technologies charge royalties for the use of their designs, patents and copyrights.

talks about vendors of "computer designs", presumably meaning core designs not ISA designs, and speaks of "designs" (again, presumably core designs, not ISA designs), "patents" (which could either be patents on ISA features or on chip features), and "copyrights" (which could be copyrights on the ISA specification or on chip designs).

I don't think the RISC-V Foundation even offers core designs; they have a page listing cores, but those are cores designed by various other organizations.

So:

• if you're developing a processor core, the non-technical advantage of RISC-V is that you don't have to ask for an architectural license - the ISA is freely licensed - much less pay money for that license;
• if you're designing an SoC around somebody else's core design, the main non-technical advantages of RISC-V would be those that follow on from the previous advantages that the core designer had.

I'm not sure what the best way is to express that. Guy Harris (talk) 20:15, 25 October 2019 (UTC)

The trouble when you say "main", is you have to ask what ISA? AFAIK, both OpenSPARC and OpenRISC are also available under fairly free licences. However neither had much success, as no ecosystem really developed around them and by now, some considered them somewhat flawed. In the SPARC case, I'm also not particularly sure what the structure of whoever was in charge of development of the ISA was like, so while the ISA may have been open, if you wanted to adopt it I'm not sure how much ability you had to influence it's development other than by forking. (I believe OpenRISC and RISC-V have a fairly "free software" like set-up.) In the OpenSPARC case, it probably didn't help that the the key drivers had variable interested in being open, so only a few of their implementations were open.

People also wondered whether MIPS would become a proper open ISA, but this didn't end up really happening and the stuff that was happening seems to have been abandoned . (I'm also not sure how clear the MIPS patent situation was.) And now of course (well after RISC-V although before your post) the Power ISA seems to be really heading down the open route .

If you mean compared to ARM or x86 then sure.

BTW, I don't quite understand your core point. AFAIK, RISC-V does not really try to be "copy-left" in any way. People are free to make proprietary RISC-V cores if they want, and I think some may already be doing so. If your simply copy someone's proprietary core, you can probably expect a lawsuit. Especially if they have patents covering something they did.

If their chip simply exposes standard RISC-V ISA, then you're free to make your own design and you should be able to do so without violating anyone's patent, and software should work on your design the same as it does the proprietary chip without much effort. But that harks back to the ISA, and isn't to do with your ability to simply copy someone else's design without considering their rights to their specific implementation.

Nil Einne (talk) 15:56, 15 December 2019 (UTC)

The "Significance" section, at the time I posted my comment, opened up talking a lot about the costs of designing a CPU, and spoke of ARM and MIPS charging fees for licensing their implementations of their ISAs:

Developing a CPU requires design expertise in several specialties: electronic digital logic, compilers, and operating systems. To cover the costs of such a team, commercial vendors of computer designs, such as ARM Holdings and MIPS Technologies charge royalties for the use of their designs, patents and copyrights.^[2][3] They also often require non-disclosure agreements before releasing documents that describe their designs' detailed advantages and instruction set. In many cases, they never describe the reasons for their design choices.

This expense and secrecy make the development of new hardware and software harder. It also prevents security audits. Also, modern, high-quality general-purpose computer instruction sets have not been explained or available except in academic settings. This expense and secrecy make the development of new hardware and software much more difficult.

If, for example, ARM were to offer architectural licenses for free, under the same terms as RISC-V, even if they continued to offer proprietary implementations (just as RISC-V allows), would that mean there'd be significant competition for ARM implementations that makes the development of new hardware and software easier? Would it allow security audits that are now impossible? Would there now be non-academic explanations of the ARM instruction sets? If not, then those two paragraphs don't describe advantages of RISC-V.

The current version of that section, renamed "Rationale":

CPU design requires design expertise in several specialties: electronic digital logic, compilers, and operating systems. To cover the costs of such a team, commercial vendors of computer designs, such as ARM Holdings and MIPS Technologies charge royalties for the use of their designs, patents and copyrights.^[4][5] They also often require non-disclosure agreements before releasing documents that describe their designs' detailed advantages and instruction set. In many cases, they never describe the reasons for their design choices.

is better, having removed the second paragraph. Still, it mainly appears to be talking about licensing core designs, which doesn't directly apply to RISC-V given that there's no big "RISC-V Inc." pumping out core designs; it briefly mentions requiring NDAs for instruction set documentation, but I haven't had to sign an NDA to read either the ARM or MIPS ISA documentation online, so I've asked for a citation on that part of the claim.

And as for "there are other open ISAs", there are three sets of ISAs to be compared with RISC-V:

• non-open ISAs (most);

• ISAs that were open before RISC-V (SPARC, OpenRISC);

• ISAs that became open after RISC-V (Power, maybe MIPS).

The third category may argue in favor of RISC-V's openness as an ISA being significant, if they were following its lead. The question is why the two in the second category didn't take off. Perhaps the issue is the extent to which they were "open" to influence on the ISA design to others. SPARC may have been deemed too much "Sun's baby", with Fujitsu being the other significant player. That leaves OpenRISC; why is it tired and RISC-V wired?

AFAIK, RISC-V does not really try to be "copy-left" in any way.

I didn't say it did. And GNU Emacs LISP is not a copyleft language - somebody could make a proprietary implementation, although the implementation would also have to have independent proprietary reimplementations of GPLed LISP "library" code, if there's any such code that's part of the language. The GNU Emacs implementation is, however, copyleft.

A licensed ISA is the equivalent of a programming language covered by some form of intellectual property restrictions such that you would have to get a license to implement the language. The GPL could conceivably be used as such a restriction, e.g. requiring that anyone who receives any implementation of the language must be able to receive the source code for the implementation. Other restrictions could be "you have to pay for the license", whether in the form of a single up-front payment, a per-unit charge, or something else.

RISC-V is more like a programming language that anybody's allowed to implement, without any licensing requirements other than on the trademark - proprietary implementations are allowed, and there's no charge for making an implementation; C and C++ are languages of that sort, with both free-as-in-speech (and as-in-beer) and proprietary implementations. Guy Harris (talk) 23:06, 15 December 2019 (UTC)

The Rationale section no longer claims that NDAs are needed to read the definition of some instruction sets, which is good as there don't currently seem to be any such major instruction sets. That does indicate, however, that "you don't need an NDA for the ISA" isn't an advantage of the RISC-V instruction set over ARM or MIPS; "you don't need an NDA for the design of RISC-V chips is only an advantage of RISC-V to the extent that there are free-as-in-speech-and-in-beer RISC-V chip designs, given that there are a lot of non-free designs. Guy Harris (talk) 18:26, 17 December 2019 (UTC)

@Guy Harris: I came across this a long time later but for the benefit of future talk page watchers, it might help if you explain what you meant by "if you're designing an SoC around somebody else's core design, the main non-technical advantages of RISC-V would be those that follow on from the previous advantages that the core designer had." You later seem to acknowledge that RISC-V doesn't try to be copy-left in terms of cores but you had already said this hence my response above. I don't see how RISC-V offers any real advantage in terms of designing an SoC around somebody else's core design compared to proprietary ISAs other the the fact you only likely need a licence from the core designer which is not insignificant, indeed was what I was trying to say in my first post, but irrelevant to what you said.

In both cases, if you have a licence for the core design, you can implement the design bound by any possible patents held by others etc. In both cases if you don't have a licence for the core, but do have a licence for the ISA (explicitly for the proprietary ISA, implicitly for RISC-V or some other open ISA), you can sort of try and copy the proprietary core although frankly it's very risky and I suspect most aren't going to try instead just making their own implementations albeit informed by what the literature and previous experience has shown works.

So what makes RISC-V special in terms of designing an SoC around somebody else's core design such that you can from the "previous advantages that the core designer had" but do not do so when you are copying someone else's ARM design?

If you were not trying to say RISC-V was special, I'm not sure the relevance of your point since the issue was the advantages RISC-V has being an open ISA compared to proprietary ISA. I mean it has been expected there would be more open core designs because it's an open ISA so it's been hoped a ecosystem around open designs with each benefiting from previous ones, would develop. Compared to the situation with proprietary ISAs where which each implementation may learn at a broad level what works and what doesn't but they're often not based on improving the specific implementation since they either can't or don't want to pay for a licence. However that's not specific to copying one implementation but instead an ecosystem thing.

Nil Einne (talk) 06:16, 28 August 2021 (UTC)

I suspect reimplementing an existing programming language or processor architecture hasn't been tested so well. In days past, some would claim copyright on assembler mnemonics, but others could invent their own. Patented instructions are possible, but also I suspect not well tested. In days long past, there are stories that IBM would patent things, or buy patents, to be sure that they didn't get sued, but not that they would sue others. I do remember Sun open-sourcing veriog code for later SPARC processors. (That might have stopped after Oracle.) In any case, I suspect that a freely licensed ISA isn't well understood, even by those who understand software licensing. Gah4 (talk) 08:02, 28 August 2021 (UTC)

it might help if you explain what you meant by "if you're designing an SoC around somebody else's core design, the main non-technical advantages of RISC-V would be those that follow on from the previous advantages that the core designer had."

It means that if you're not designing a processor core - for example, if you're designing an SoC by gluing together other designs by other developers, including the processor core and peripherals, or have designed some components other than the processor core and are gluing them together with somebody else's processor core design, and the ISA isn't "free as in beer" - then you probably aren't the one directly licensing the ISA so that you can implement it in a processor core, whoever designed the processor core probably is, so you probably aren't the one directly paying the licensing fee, you're paying the designer of the processor core for their design, and they're presumably passing on some part of the fee you paid them to the owner of the ISA. The previous bullet item said:

if you're developing a processor core, the non-technical advantage of RISC-V is that you don't have to ask for an architectural license - the ISA is freely licensed - much less pay money for that license

which is one of the "previous advantages that the core designer had".

I don't see how RISC-V offers any real advantage in terms of designing an SoC around somebody else's core design compared to proprietary ISAs other the the fact you only likely need a licence from the core designer

Umm, yeah, that's pretty much what I'm saying. Assuming the core designer isn't the ISA owner, the ISA owner probably charges the core designer a license fee, or requires them to collect a license fee for the ISA from anyone to whom they license the core design. If the core designer is the ISA owner (for example, if the core you're licensing has "Cortex" in its name :-)), then it may not be possible to determine how much of the license fee is for the core design and how much is for the ISA, and the question becomes "is it cheaper to license a RISC-V core rather than an core design from ARM if the two cores have equivalent capabilities?" - if the answer is "yes", that might be due to RISC-V being "free as in beer" and ARM not being "free as in beer", but it might also be due to the core designer for the RISC-V core deciding to undercut ARM for some undetermined reason other than "I don't have to pay RISC-V International for the right to design and sell a RISC-V core, but I do have to pay ARM for the right to design and sell an ARM core".

So what makes RISC-V special in terms of designing an SoC around somebody else's core design such that you can from the "previous advantages that the core designer had" but do not do so when you are copying someone else's ARM design?

The core designer doesn't have to pay RISC-V International for the right to design a RISC-V core, nor do they have to pay them for the right to license their design to others for use in their SoCs. That's not the case for ARM if Arm are the core designer and, as far as I know, it's not the case for ARM if somebody who holds an architectural license from ARM are the core designer. Guy Harris (talk) 08:38, 28 August 2021 (UTC)

Quick reminders of some important and possibly relevant WP policies, because reading the introductions and skimming the rest of them every so often is commendable, and because we still have to follow them even if we all love RISC-V for what it will make possible: WP:OR WP:POV WP:VERIFY WP:RS WP:! WP:ENC WP:MOSLEAD

In no particular order:

1. The lead seems to rely heavily on the RISC-V specifications. The authors of the specifications may be biased towards RISC-V and specifications are primary sources.

2. What does "a design that is architecturally neutral" mean?

3. Again, I don't understand this: "placing most-significant bits at a fixed location to speed sign extension". And it seems like neither explaining nor listing that is appropriate for the lead.

4. This whole part also seems inappropriate for the lead: "because 60 years of industry experience has shown that the most unrecoverable error in instruction set design is a lack of memory address space. As of 2016, the 128-bit ISA remains undefined intentionally, because there is yet so little practical experience with such large memory systems."

5. I think the lead should mention as one of RISC-V's notable practical advantages the availability of a wide range of open source synthesizable RISC-V cores in VHDL, Verilog, etc.

6. Haven't read the complete thing yet, but I have a feeling the article is written a bit too much like an advertisement. For example: "RISC-V has features to increase computer speed, yet reduce cost and power use." EDIT: that example sentence is gone now.

7. "Sign extension is said to often be on the critical timing path." - see WP:WEASEL EDIT: I removed that sentence now.

8. Lead's last paragraph could, I believe, be improved by changing it to only list which parts of the RISC-V spec are frozen and since when are they frozen. I don't think we need to list the version codes, also that is difficult to keep up to date.

Notrium (talk) 23:11, 8 June 2020 (UTC)

I assume this is what "architecturally neutral" is referring to:^[1]: 1

An ISA that avoids “over-architecting” for a particular micro-architecture style (e.g., microcoded, in-order, decoupled, out-of-order) or implementation technology (e.g., full-custom, ASIC, FPGA), but which allows efficient implementation in any of these.

Doerakpoes (talk) 19:15, 27 July 2024 (UTC)

Granted, the quote I used is about what their goals were/are, and is not about an explicit ISA feature causing it to be the case; where as "a design that is architecturally neutral" implies some feature(s) actually leading to it. Doerakpoes (talk) 13:07, 28 July 2024 (UTC)

In this edit,

RISC-V has features to increase computer speed, yet reduce cost and power use. These include a load–store architecture, bit patterns to simplify the multiplexers in a CPU, simplified standards-based floating-point, a design that is architecturally neutral, and placing most-significant bits at a fixed location to speed sign extension.

was changed to

RISC-V has features to increase computer speed, yet reduce cost and power use. These include a load–store architecture, bit patterns to simplify the multiplexers in a CPU, IEEE 754 floating-point, a design that is architecturally neutral, and placing most-significant bits at a fixed location to speed sign extension.

with the edit summary "clarify".

Presumably that clarifies what "standard-based floating point" is, but omits the "simplified". Going with IEEE 754 is hardly an innovative RISC-V feature - almost all instruction sets these days support it, with even IBM mainframes adding support back in System/390, and one of the first implementations was in the Intel 8087, implementing the floating-point part of the early CISC x86 instruction set.

So is the "simplified" part the key? Are there simplifications in the RISC-V implememtation of IEEE 754, e.g. punting some parts of the implementation to software that are done in hardware in other implementations? If so, "simplified" should probably be restored. Guy Harris (talk) 23:14, 8 June 2020 (UTC)

You missed the intermediate edit's "summary". The issue is that the word 'simplified' is unclear (compared to what is it simplified), and also makes the sentence read like an advertisement. Another possible issue is that explaining what exactly is simplified and compared to what properly belongs in the main space of the article instead of in the lead. Notrium (talk) 23:19, 8 June 2020 (UTC)

So perhaps don't mention IEEE 754 at all? "RISC-V uses IEEE 754 for floating point" is like "RISC-V uses two's complement binary for integer arithmetic" - it would be unique and different if it didn't do that. Guy Harris (talk) 23:46, 8 June 2020 (UTC)

Sorry, but I don't understand quite where the discussion is going here. I mean, my comment was about 'simplified', and know you talk about the standards. These are two separate issues.

EDIT: the reason I linked to IEEE 754 is because that is much clearer than "standards-based". Notrium (talk) 23:50, 8 June 2020 (UTC)

OK, here's a really simple explanation of the issue.

There is a paragraph in the article that says

RISC-V has features to increase computer speed, yet reduce cost and power use. These include a load–store architecture, bit patterns to simplify the multiplexers in a CPU, IEEE 754 floating-point, a design that is architecturally neutral, and placing most-significant bits at a fixed location to speed sign extension.

A load/store architecture may be a feature that "[increases] computer speed, yet [reduces] cost and power use"; that's one of the tents of RISC.

Choosing bit patterns (presumably instruction bit patterns) to simplify the multiplexers in a CPU may be such a feature as well, if, for example, it means fewer transistors in the instruction decode path.

Placing most-significant bits at a fixed location to speed sign extension may be such a feature as well.

IEEE 754 is not such a feature; there are a number of processors that implement IEEE 754, with different speeds, different costs, and power use.

I very strongly doubt that RISC-V chose IEEE 754 "to increase computer speed, yet reduce cost and power use"; I'd need a direct quote from a designer to believe that, with details including what other forms of floating-point they considered. I very strongly suspect they didn't even consider other floating-point formats, given that the only systems that only use other formats are either no longer being made and sold (PDP-10, PDP-11, VAX, older DEC systems, various others) or are very much in the minority (UNIVAC 1100/2200 series, possibly others), and systems that offer other formats in addition to IEEE 754 offer them only for backwards compatibility (DEC Alpha, for backwards compatibility with VAX, and z/Architecture, for compatibility with machines going back to IBM System/360), so:

• going with another format and not supporting IEEE 754 would have to bring a huge benefit for the incompatibility;
• supporting another format in addition to IEEE 754 complicates, rather than simplifying, so is unlikely to "reduce cost and power use" and would only "increase computer speed" if the other format could be processed faster and there were applications where compatibility isn't required and the performance increases were worth it;
• offering a choice to implementers, so that, for example, processors for embedded systems for which IEEE 754 compatibility isn't necessary could use another floating-point, and processors for general-purpose systems could use IEEE 754 for compatibility with the vast majority of the general-purpose computing world.

So "IEEE 754 floating-point" would belong in a section entitled, for example, "Unsurprising characteristics of RISC-V", along with "two's complement binary integer arithmetic", "byte-addressable", "8-bit bytes with word lengths that are power-of-2 numbers of bytes in size", etc., or in a general summary of all of RISC-V's characteristics.

Now, perhaps there are details of the floating-point instructions in RISC-V that "to increase computer speed, yet reduce cost and power use", e.g. punting some operations to software, perhaps with some hardware help. That's what would be "simplified". Guy Harris (talk) 03:39, 9 June 2020 (UTC)

Thank you. I think my latest edit renders your concerns moot. Notrium (talk) 12:21, 9 June 2020 (UTC)

It seems that there are two things. One is implementing the data format for IEEE-754, while the other is following all the rules. That applies more to high-level languages using IEEE-754, but also for hardware. Implementing all the rounding and such modes, for example. Also some of the effects of negative zero. Gah4 (talk) 14:39, 10 October 2021 (UTC)

The article mentions version numbers like 2.2 and 1.11 in several places, but it seems RISC-V abandoned that form of version codes since the relevant manuals are currently versioned by date, e.g. 20191213. Notrium (talk) 23:26, 8 June 2020 (UTC)

I previously removed a reference to WepSim from the RISC-V page because WepSim has poor RISC-V support, there are many better alternative simulators to spotlight, and it seems to have been added by people who worked on developing it. On this modification I was accused of vandalism. That was certainly not my intent, and I still believe that the relevant text should not be on the RISC-V page. I haven't edited much on Wikipedia though so it may be considered vandalism. I am adding this to the talk page to ask someone with more experience on Wikipedia to decide what to do with it.

I previously had only removed it without adding an alternative addition because it was late at night when I saw the change and removed it, but adding a reference to the official software list seems like a very nice way to include a bunch of simulators and other software without taking up much space.

Technical reasons WepSim is not a high quality RISC-V simulator:

x0 is modifiable. For example addi x0, x0, 1 actually modifies the zero register. This is a huge issue because a lot of jumping psuedo-instructions set x0 when they want to ignore the result of jalr and branch pseudo-instructions expect x0 to actually be -.

Immediates that are too large for RISC-V instructions can be used. For example addi t0, t0, 0x8FFF would set t0 = 0xFFFF8FFF. Additionally that example shows that immediates are sign extended from the 16th bit rather than the 12th.

auipc is super broken. auipc t0, 1 should not leave the address in t0 % 2 = 1. The lower 12 bits of an auipc immediate should be all 0. Additionally, the address of the suipc instruction should be whats offset not the address after the auipc instruction activates.

There are probably more reasons, but this is what I could quickly find. I think WepSIM is interesting for being able to switch out microcode to support RISC-V at all, but it was not originally built to support RISC-V and it is very apparent.

-- TheThirdOne

You are free to add the issues found in the current version of the project to the GitHub repository: https://github.com/wepsim/wepsim/issues

The issues listed here were resolved some time ago, and the links provided for adding to software repositories are not longer valid. — Preceding unsigned comment added by 95.39.171.129 (talk) 14:39, 30 December 2024 (UTC)

The table of implementations is nice, but it would be nicer to know which subsets each one implements. Specifically I am interested in one implementing Q, and can't tell from the list if any of them do. Gah4 (talk) 00:18, 10 September 2021 (UTC)

I didn't find a PC register in the table within Register sets. --Alexey Vazhnov (talk) 18:31, 16 October 2021 (UTC)

PC (program counter) is special internal register inside processor holding byte address of next instruction to be executed.--84.206.12.94 (talk) 09:32, 24 February 2023 (UTC)

@Ray Van De Walker: You added the current ISA spec as a reference for "Notable features of the RISC-V ISA include bit patterns to simplify the multiplexers in a CPU"; in which version of the ISA spec does it say that? I tried opening the most recent unprivileged and privileged base specifications, as well as Technical Report No. UCB/EECS-2011-62, the 2.0 user-level spec, the 1.7 privileged architecture spec, the 2.1 user-level spec, and the 1.9 privileged architecture spec, and either 1) Safari/PDFKit's searching capabilities don't find all occurrences of "bit pattern" or "multiplexer" or 2) the spec in question doesn't say that using either the phrase "bit pattern" or the word "multiplexer". Guy Harris (talk) 05:24, 7 November 2021 (UTC)

Presumably the reference is the second paragraph of the footnote on page 17, in which case the answer is "the spec in question doesn't say that using either the phrase "bit pattern" or the word "multiplexer"" - it doesn't say "bit pattern" and says "muxes" rather than "multiplexors". This is why, at minimum, giving page numbers is an Extremely Good Idea for references to a long specification in which the location of the supporting text isn't immediately obvious from, for example, the table of contents. I've added {{rp}} items for the two claims supported by that footnote. Guy Harris (talk) 05:34, 7 November 2021 (UTC)

How can patterns simplify the multiplexers in a CPU? What patterns are they? What do multiplexers in a CPU? Or is this a simple technobabble without meaning? These are cardinal questions which the common reader will ask. As me. Please answer. -- Pkunk (talk) 20:05, 22 March 2022 (UTC)

As per my second comment in Talk:RISC-V § "bit patterns to simplify the multiplexers in a CPU", the citation for the item about multiplexors is for a footnote on page 17 of "The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA version 20191213, and the quote is

By rotating bits in the instruction encoding of B and J immediates instead of using dynamic hardware muxes to multiply the immediate by 2, we reduce instruction signal fanout and immediate mux costs by around a factor of 2.

The patterns are the locations of fields within instructions. Those are described in "Figure 2.3: RISC-V base instruction formats showing immediate variants." on page 16 and "Figure 2.4: Types of immediate produced by RISC-V instructions." on page 17.

"Multiplexers" and "hardware muxes" refer to digital multiplexers, which are a type of digital circuit.

The particular instruction formats to which the quote refers are "B" format instructions, where "B" stands for "branch", and "J" format instructions, where "J" stands for "jump". Both of those are branch instructions. I was not involved in the design of RISC-V, and am not a CPU designer, so I can't give an authoritative answer as to what they meant by that quote; I suspect that they're referring to a CPU that fetches an instruction into a register and that uses multiplexors to send various bits in the instruction to different other circuits, and that the goal was to minimize the number of different circuits to which a given set of bits need to be sent, depending on the instruction format.

I.e., these are questions to which there probably aren't simple answers; in order to understand the answer, a reader will have to read other sources of introductory information, such as information about how instructions are decoded and executed in CPUs. Central processing unit briefly discusses this in Central processing unit § Decode and Central processing unit § Execute, and more discussion can be found in processor design and pages to which it links, such as microarchitecture, datapath, as well as references and external links in those pages. Guy Harris (talk) 23:08, 22 March 2022 (UTC)

In these edits, I changed the sentence in question to read

Notable features of the RISC-V ISA include instruction bit field locations chosen to simplify the use of multiplexers in a CPU ...

to try to make it clearer what the "bit patterns" in question are and to link to a page that explains multiplexers. Guy Harris (talk) 02:15, 23 March 2022 (UTC)

There really should be a table with instruction formats^[1] which would make this a little more obvious. The idea is that bit positions in different instruction formats that have a similar use, are in the same place. This is especially obvious with the immediate bits. You might think that consecutive bits for a binary value, like an offset for a branch instruction, would be consecutive in the instruction. In the CISC days, ease of use by assembly programmers, and especially those reading hex dumps, influenced instruction design. But one idea of RISC is that instructions are meant to be understood by compilers (and sometimes assemblers), and not so much by people. Instruction bits are only arranged by the compiler once, but by the processor every time the instruction is executed. The B (branch) format look like: imm[12|10:5] rs2 rs1 func3 imm[4:1|11] opcode. Note that the imm bits are not in consecutive order! Gah4 (talk) 04:09, 23 March 2022 (UTC)

Yes, I saw the tables in the RISC-V spec and noticed the split-up immediate field when answering the question.

Is the idea that most of the immediate-constant bits in S and B formats get gated to the same place and don't thus need demultiplexers governed by the format, with the exceptions being that bit 31 of the instruction is bit 12 of the immediate value in B format and bit 11 in S format and bit 7 of the instruction is bit 11 of the immediate value in B format and bit 0 in S format? (Instructions are on 4-byte boundaries unless compressed instructions are used, in which case they're on 2-byte boundaries, so the low-order bit of an instruction address is always 0.) And that bits 19 through 12 in U and J formats both are used as bits 19 through 12 of the immediate value, again not requiring demultiplexers? Guy Harris (talk) 05:45, 23 March 2022 (UTC)

I think so. I didn't try to follow the 16 bit instructions, but that might be related. Funniest, though, is that being little endian, instructions are written with the opcode field on the right. In CISC days, no-one would even think about trying all of this. Even more, in CISC days it was nice to align fields on hex digit boundaries, to make it even easier. Before VAX, DEC liked octal, and instructions with fields on 3 bit boundaries. VAX uses hex and fields on four bit boundaries. IBM S/360 branch instructions have a 12 bit byte offset, even though instructions are always on an even address. (The base address can be odd, though, but not a lot of reason for that.) Gah4 (talk) 07:08, 23 March 2022 (UTC)

(Before PDP-11, DEC liked machines with multiple-of-6-bits word sizes, so there was little reason to go with hex. The PDP-11 broke away from that, but the instruction format was still oriented towards 3-bit fields, such as register numbers and addressing modes.) Guy Harris (talk) 07:46, 23 March 2022 (UTC)

Well, 12 bits for the PDP-8 and 36 for the PDP-10 are multiples of both 3 and 4, and the PDP-10 does have 16 registers. But they both liked octal. There is a story that before VAX was released, there was a calendar internal to DEC, with the days numbered in hex. For S/360, and I believe VAX, the whole architecture was designed, including instruction formats, before building hardware. (That was less usual for earlier machines.) But I don't know the exact thoughts designing RISC-V. Gah4 (talk) 07:59, 23 March 2022 (UTC)

On the other hand, 18 bits for the PDP-1 - DEC's first machine - is a multiple of 6 (hence 3) but *not* a multiple of 4, so they started out with an ISA that was more octal-friendly than hex-friendly; the same applies to the PDP-4, PDP-7, PDP-9, and PDP-15. — Preceding unsigned comment added by Guy Harris (talk • contribs) 08:59, 23 March 2022 (UTC)

Thanks you all for the detailed answers. I started to translate the RISC-V article (to Hungarian), and I was halted at this phrase because could not interpret the meaning, could not link the multiplexers to the speedup in the CPU design. I had to read up on it to understand it, but then I got the idea and I was able to move on :) --Pkunk (talk) 16:46, 23 May 2022 (UTC)

The article does not show different instruction formats.^[1] That would seem to be useful to show. Gah4 (talk) 04:11, 23 March 2022 (UTC)

There are currently two references to "RV5". What is it? Should it be RISC-V instead? I could not find any other references to "RV5" using search engines.--Nicolas Barbier (talk) 06:57, 29 April 2022 (UTC)

It shows up as an abbreviation for what I presume is "RISC-V" (rather than, say, "RISC-V 5") in some places if you do a Google search for "rv5" "risc", and doesn't show up at all if you do a Google search for "rv5" site:riscv.org, so it doesn't appear to have any official standing.

I have edited the page so it now has zero occurrences of "RV5" (other than in the name of some named references, but those don't show up when the page is viewed, only when it's edited) and two more occurrences of "RISC-V". Guy Harris (talk) 06:36, 10 May 2023 (UTC)

The following press release may be worth adding when there's more information.
"NASA Selects SiFive and Makes RISC-V the Go-to Ecosystem for Future Space Missions" (Press release). SiFive. September 6, 2022. HPSC will utilize an 8-core, SiFive® Intelligence™ X280 RISC-V vector core, as well as four additional SiFive RISC-V cores, to deliver 100x the computational capability of today's space computers.

These describe the project and the announcement of Microchip

• Smith, Hillary (June 30, 2022). "High Performance Spaceflight Computing (HPSC)". National Aeronautics and Space Administration.
• "NASA Awards Next-Generation Spaceflight Computing Processor Contract". Jet Propulsion Laboratory, NASA. August 15, 2022. NASA's Jet Propulsion Laboratory has selected Microchip Technology Inc. to develop a high-performance spaceflight computing processor that will support future space missions.

These might be describing the hardware NASA would be using

• "First RISC-V-Based System-on-Chip (SoC) FPGA Enters Mass Production" (Press release). Microchip. June 8, 2022. ... production qualification for the MPFS250T and the previously announced MPFS025T. ... We are now writing a new chapter in the history of RISC-V with the availability of production-qualified SoC PolarFire devices.
• "Radiation-Tolerant (RT) PolarFire® FPGA Achieves MIL-STD-883 Class B Qualification, Paving the Way for Power-Saving, High-Speed Processing in Space" (Press release). Microchip. August 16, 2022. RDBrown (talk) 14:32, 10 September 2022 (UTC)

vector instructions 1.0 has been finalized, it should be added to the page in both the fields in the overview and in the text 128.116.247.207 (talk) 18:47, 8 May 2023 (UTC)

RISC-V § ISA base and extensions currently says

Together with a supervisor instruction set extension, S, an RVGC instruction set, which includes one of the RV base instruction sets, the G collection of extensions (which includes "I", meaning that the base is non-embedded), and the C extension, defines all instructions needed to conveniently support a general purpose operating system.

(I added some details so people weren't confronted with a statement about what "an RVGC defines" but that does not indicate what "an RVGC" is).

The 20191213 unprivileged instruction sepecification says, on page 129:

One goal of the RISC-V project is that it be used as a stable software development target. For this purpose, we define a combination of a base ISA (RV32I or RV64I) plus selected standard extensions (IMAFD, Zicsr, Zifencei) as a “general-purpose” ISA, and we use the abbreviation G for the IMAFDZicsr_Zifencei combination of instruction-set extensions. This chapter presents opcode maps and instruction-set listings for RV32G and RV64G.

...

We believe RV32G and RV64G provide simple but complete instruction sets for a broad range of general-purpose computing. The optional compressed instruction set described in Chapter 16 can be added (forming RV32GC and RV64GC) to improve performance, code size, and energy efficiency, though with some additional hardware complexity.

which doesn't seem to include the C extension as a requirement for a "general-purpose" ISA; does the "C" in "RVGC" refer to something other than the C extension, is there some reason why the C extension would be a requirement "to conveniently support a general purpose operating system", or should the article speak of RVG plus an S extension as being sufficient, with C being an option? Guy Harris (talk) 05:47, 10 May 2023 (UTC)

RV32G requires that all instructions be 32 bits wide, and RV64G requires all instructions be. The C extension unlocks smaller, "compressed", instructions. It is not strictly required, but it's a very nice thing to have. JGHFunRun (talk) 22:33, 14 September 2025 (UTC)

The C extension unlocks smaller, "compressed", instructions. Yes, as per my comment.

It is not strictly required, but it's a very nice thing to have. But the only increase in convenience in "[supporting] a general purpose operating system" would be if some size limit on code would be exceeded without it, which I suspect is not common, so that paragraph should be rewritten not to mention the C extension among the set of extensions that "[define] all instructions needed to conveniently support a general purpose operating system". The C extension was already discussed in the previous paragraph; that suffices. I shall fix the paragraph in question. Guy Harris (talk) 22:53, 14 September 2025 (UTC)

"... other register is the source (for a store) or destination (for a load)." Are those two parenthetical reversed? 174.82.204.131 (talk) 20:04, 10 January 2024 (UTC)

No, for a store the data comes from a register which is the source, similarly for load. Digital27 (talk) 08:30, 11 January 2024 (UTC)

As Digital27 says, a load copies data from memory to a register (the "other" register). I've edited the article so that the two descriptions are now given in normal load-store sequence rather than contrariwise. -- R. S. Shaw (talk) 05:51, 26 January 2024 (UTC)