Talk:RISC-V/Archive 1

This is an archive of past discussions about RISC-V. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

First cut

I wrote the first cut of the article, and I'd welcome any edits that could reduce any sound of commerce in it. Of course, the project is completely noncommercial. For the record, I'm an enthusiast not connected to the development group in any way. I think my enthusiasm is showing through. Ray Van De Walker 03:14, 21 September 2014 (UTC)

The description of the ISA itself (sec:design) should probably pull inspiration from the DEC Alpha ISA article. - 8 April 2015 — Preceding unsigned comment added by 2602:306:CDD1:1B60:29D7:E07:E906:30A8 (talk) 08:37, 8 April 2015 (UTC)

I agree in principle that it should be the best possible article, and that the Alpha article is very good. I tried to arrange it in a logical order. There are significant differences in the design philosophy of Alpha and RISC-V. I tried to include most of the same types of data in the recent change that put the ISA design near the end of the article. I didn't include ISA layout diagrams, because I think those are too detailed, but if you disagree, I can add them. Any particular suggestions would be welcome. Ray Van De Walker (talk) 01:13, 1 December 2016 (UTC)

Trim

Done :-) UCB = Berkeley? Anyway, hope I have not been too brutal. Snori (talk) 05:57, 15 July 2015 (UTC)

OpenRISC GPL?

There are two references to OpenRISC, marking it as GPL. This is not completely true, as the implementation mor1kx is offered with an OHDL license (which is basically an LGPL for hardware designs). — Preceding unsigned comment added by 62.96.220.14 (talk) 14:16, 2 December 2016 (UTC)

Ideas

It would be nice to have a section that easily decodes the instruction set names. From the article I was able to infer the following

G = General = IMAFD
I = Integer
M = Multiplication
F = Floating point
D = Double precision floating point
Q = Quad precision floating point
E = embedded, which requires no floating point (F,D,Q) and recommends "C"
C = compressed instructions
A = atomic instructions
P = privileged instructions

--24.22.132.166 (talk) 00:47, 30 November 2016 (UTC)

I tried to do this; Feel free to correct. Ray Van De Walker (talk) 00:58, 1 December 2016 (UTC)

Done. Design - ISA Base and Extensions now contains a list with all extensions (M/A/F/D/Q/L/C/B/J/T/P/V) and base ISA (I/E). Still missing is the current draft for privileged extension and profiles. Profiles are currently discussed to contain a set of extensions (to bundle them for certain use cases and to express dependencies between extensions) 84.140.204.11 (talk) 12:09, 5 January 2018 (UTC)

I didn't want to make the edit directly in case I was misunderstanding... Given this example from the article: "A small 32-bit computer for an embedded system might be RV32EC. A large 64-bit computer might be RV64GC; i.e., shorthand for RV64IMAFDC.", wouldn't a large 64-bit computer actually be RV64IGC? The base is RV64I, G is MAFD plus the C extension? Jerry507 (talk) 20:28, 21 September 2018 (UTC)

@Jerry507: General purpose would encompass the integer, multiplication, atomic, floating point, and double precision instruction sets. So the G is short for IMAFD, and RV64GC is the same as RV64IMAFDC. See the spec for more info. — AfroThundr ^{(u · t · c)} 18:39, 22 September 2018 (UTC)

Byte order

The table says little endian but I read that, while most implementations will be little endian, big endian is possible?

24.22.132.166 (talk) 00:50, 30 November 2016 (UTC)

The article says Early iterations supported big-endian, the Internet's standard byte order. This was dropped as unnecessary complexity. Gah4 (talk) 01:17, 30 November 2016 (UTC)

Branch delay slots

Devon Sean McCULLOUGH (See history) Asked for a reference that a single branch delay slot is optimal for a five-stage pipeline. delay slot says that "the number depends on the number of stages and the stage where the instruction decode occurs." Would this be less controversial? I thought that most pipelines begin decode (at best) on stage 2, already too late to predict the next fetch, so I don't know why this needs a reference... Ray Van De Walker (talk) 00:58, 1 December 2016 (UTC)

Pulling this number "five" out of thin air needs explanation, reference or removal. Devon Sean McCULLOUGH (talk) 23:02, 1 December 2016 (UTC)

Removed Ray Van De Walker (talk) 08:32, 15 December 2016 (UTC)

Release consistency?

In the section "Atomic memory operations", the phrase "release consistency" seems to be used to describe the design choice of the lr/sc primitives rather than the cas primitive. But i don't see the connection with https://en.wikipedia.org/wiki/Release_consistency (i see why 'release consistency' is appropriate for describing other design choices of RISC-V, for example the acquire and release bits, just not why it is the appropriate name for the decision to use lr/sc over cas). Perhaps 'release consistency' is not the right term for this design choice? Bayle Shanks (talk) 20:43, 16 March 2017 (UTC)

The RISC-V ISA specifications discuss "release consistency" as if it is a common academic description (among computer designers) of a generic scheme for atomic instructions, and "CAS" is a parallel term (My understanding is that it is actually the typical instruction mnemonic) for a competing scheme. The term is used in this way in the design rationale sections of the original RISC-V documents, so if I try to reconcile it with wikipedia's topic article, that would be original research, (forbidden in this encyclopedia). I know that this inconsistency is not very satisfying. I encourage you to submit any technical discussion of the term to the RISC-V ISA mailing list. They've actually been quite kind with my naive questions. And, possibly I misunderstood... Ray Van De Walker (talk) 00:15, 26 April 2017 (UTC)

Is "Commercially Available" actually "Advertising"?

It's starting to get close enough to make me uncomfortable. On the other hand, I'm genuinely interested in the information. What does the community think? Ray Van De Walker (talk) 00:23, 26 April 2017 (UTC)

What is the rule on advertising? There are many articles related to commercial products that are much more useful than they are advertisements. Consider, for example, Ektachrome. This could be considered advertising for Kodak, but is also a useful reference for film users. Mentioning that there is a commercial version, but not linking to the appropriate web site, wouldn't seem bad. Gah4 (talk) 08:26, 26 April 2017 (UTC)

I propose remove the "advertisement warning" from here because all companies named here adopted an open standard, just like Ubuntu adopted Linux Kernel; of course free software (or free hardware in this case) don't meant free of charge. With all due respect I post here my suggestion, please consider it, thanks a lot!--Jimmy Olano (talk) 21:03, 17 February 2019 (UTC)

1) The section formerly titled "Commercially available", and now titled "Commercial", lists adopters of RISC-V; I consider that to be interesting information about RISC-V, just as I consider the list of holders of an "Architectural licence" to the ARM architecture to be interesting information about that architecture. I don't see a list of adopters as being advertising.

2) The advertisement warning was added in this edit, which wasn't done by the person who started this talk page section, so I'm not sure that the advertisement warning was put there in reaction to the "Commercially available"/"Commercial" section of the article, so "the "Commercial" section isn't advertising" isn't necessarily sufficient to mean that the warning should be removed. Guy Harris (talk) 21:28, 17 February 2019 (UTC)

It's NOT an advertisement warning, it's a written like warning, which means the article had/has too many marketing/peacock fluff words/statements that sounds more like advertisement wording than encyclopedia wording. I thinned out some of it in September 2018. • Sbmeirow • Talk • 03:27, 18 February 2019 (UTC)

This was of interest, but in an inappropriate section.

I'm going to dump it here so that someone else might find a proper place for it. It is gone from the article for now.

* A partial list of organizations that support the RISC-V Foundation includes: [[AMD]], [[BAE]], [http://bar.eecs.berkeley.edu/ Berkeley Architecture Research], [[Bluespec, Inc.]], [[Cortus]], [[Charles Stark Draper Laboratory| Draper]], [[Google]], [[Hewlett Packard Enterprise]] (HPE), [[Huawei]], [[IBM]], [[Institute of Computing Technology, Chinese Academy of Sciences| ICT]], [[IIT Madras]], [[Lattice Semiconductor]], [[Mellanox Technologies]], [[Microsemi]], [[Micron Technologies| Micron]], [[Microsoft]], [[Nvidia]], [[NXP]], [[Oracle Corporation|Oracle]], [[Qualcomm]], [[Cryptography Research|Rambus Cryptography Research]], [[Western Digital]].<ref>{{cite web|last1=Merritt|first1=Rick|title=Google, Oracle and HP Join RISC-V|url=http://www.eetimes.com/document.asp?doc_id=1328561&page_number=1|website=EE Times|publisher=UBM|accessdate=11 February 2016}}</ref><ref>https://riscv.org/membership/1424/rambus-cryptography-research/</ref>

2600:1015:B124:DC90:C082:D358:3562:1D97 (talk) 06:03, 30 June 2017 (UTC)

I just went ahead and put it back myself, in the Foundation section. It may need a bit more work, but it's definitely less out of place than it was. 2600:1015:B124:DC90:C082:D358:3562:1D97 (talk) 06:10, 30 June 2017 (UTC)

I can't find any source on AMD's support for RISC-V. There are some articles that mention AMD supporting it, but they are no member of the RISC-V foundation and I can't find anything official. Did they leave the foundation? 84.140.204.11 (talk) 20:23, 2 January 2018 (UTC)

I've added the membership list from riscv.org as a reference. and asked for citations for all organizations listed neither there nor in the EE Times article. For what it's worth, the membership list also doesn't mention HPE or Oracle, so maybe they left as well. Guy Harris (talk) 20:59, 2 January 2018 (UTC)

There are messages on the riscv.org isa-dev mailing list indicating that AMD had been part of RISC-V but pulled out due to patent terms. Their leaving basically stopped official development of the B extension until the community restarted it as Xbitmanip. ^[1] ^[2]74.85.80.30 (talk) 17:20, 27 June 2018 (UTC)

References

Similarity to MIPS

Perhaps it should be mentioned.

https://www.quora.com/What-are-some-notable-difference-between-MIPS-and-RISC-V

https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/-gKcbXx9jJk

Wqwt (talk) 15:48, 26 March 2018 (UTC)

The quora answer is completely wrong. MIPS was developed at Stanford while RISC was being developed at Berkeley. --bp0 (talk) 19:12, 26 March 2018 (UTC)

David_Patterson_(computer_scientist) is a big part of RISC-V, and co-wrote books with John_L._Hennessy at Stanford, suggesting that there might be a connection. Gah4 (talk) 20:00, 26 March 2018 (UTC)

But not that there's a connection between Berkeley and MIPS. The Berkeley RISC project was headed by Patterson, while the Stanford MIPS project was headed by Hennessy. Ideas from Berkeley RISC, such as register windows, showed up in SPARC, although I don't know to what extent SPARC could be viewed as a descendant of Berkeley RISC, rather than an ISA that picked up some ideas from Berkeley RISC. Hennessy was part of the group that founded MIPS Technologies, which created the MIPS architecture; the MIPS architecture was, I think, inspired by Stanford MIPS, although it wasn't just a commercialized Stanford MIPS (I think Stanford MIPS had word addressing; the MIPS architecture is byte-addressed).

So when Mr. Baines says, in the Quora post, that "MIPS is a commercial derivative of the original RISC-1 design from berkely", he's simply wrong. MIPS is a commercial derivative of the Stanford MIPS work at, err, umm, Stanford. Guy Harris (talk) 20:14, 26 March 2018 (UTC)

All I am saying, is that I suspect that many ideas went back and forth between the two groups. That is, they are not statistically independent. Gah4 (talk) 20:30, 26 March 2018 (UTC)

The two groups were working in the 1980's; RISC-V started in 2010, so there's no direct connection between RISC-V and the Stanford MIPS project - it presumably looked at several RISC designs, including the early Stanford MIPS, Berkeley RISC, and IBM 801 projects, as well as past and present commercial designs.

Whether it's any more similar to MIPS than it is to SPARC or ARM or Alpha or POWER/PowerPC/Power ISA or PA-RISC or... is not clear from the Quora post or the Google Groups post. (It's more similar to "not SPARC" (and "not Berkeley RISC"!) than to SPARC or Berkeley RISC in that it doesn't have register windows, but that's a negative influence, i.e. a difference, and that's "not SPARC" rather than "MIPS". I don't know whether any other RISC designers were inspired by MIPS not to have register windows - as opposed to being inspired by SPARC not to have register windows :-). POWER/PowerPC/Power ISA's main research-project influence was probably the IBM 801, not Berkeley RISC or Stanford MIPS.

So I see no clear reason to speak more of some "similarity to MIPS" than to similarities to any other RISC projects. The two items cited above mainly talk about differences between MIPS and RISC-V. Guy Harris (talk) 21:03, 26 March 2018 (UTC)