Talk:RISC-V/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
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

  1. ^ https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/wRKRfIqu_L8/LNL427KbAAAJ
  2. ^ https://groups.google.com/d/msg/riscv-xbitmanip/1hPXV-lXN2s/JngrYJztBwAJ

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)

Should extensible be more prominent?

Even in the first sentence? I think chapter 21(?) of the 2.2 specification is about extensions, Ch 10 of the 2.1 specification "Extending RISC-V"

In addition to supporting standard general-purpose software development, another goal of RISC-V is to provide a basis for more specialized instruction-set extensions or more customized accelerators. The instruction encoding spaces and optional variable-length instruction encoding are designed to make it easier to leverage software development effort for the standard ISA toolchain when building more customized processors. For example, the intent is to continue to provide full software support for implementations that only use the standard I base, perhaps together with many non-standard instruction-set extensions.

RDBrown (talk) 04:22, 29 June 2018 (UTC)

ARM FUD

Here is also a webarchive link to the whole site https://web.archive.org/web/20180708231736/https://riscv-basics.com/ . The "theregister" article you linked dismantles all claims made and properly labels them as FUD. All reasons for deleting it from the article are refuted by statements from Arm themselfs... Sadly I don't think it will be part of the article as long as User:Sbmeirow is fiercely protecting Arms image. — Preceding unsigned comment added by 84.158.114.188 (talk) 16:48, 11 July 2018 (UTC)
But, given that Arm took it down it fairly quickly, is it still notable? Guy Harris (talk) 16:51, 11 July 2018 (UTC)
Since there are many articles about it, it produced a lot of backlash and it was actually made by arm and not some random guy from the internet, I think it is quite notable. Just because it backfired and arm pulled back pretty fast, it doesn't undo it. So IMO it was an attempt made by arm to discredit RISC-V with FUD, it should be in the article. Like Microsofts FUD campaigns are documented on wikipedia this is pretty much the same. 84.158.114.188 (talk) 17:21, 11 July 2018 (UTC)
I think better ignore. The register supported the various points the page make but said they were weak and described it as a smear site. I particularly don't like pointing at The Register because it advertised some RISC-V fanboy going to set up a site to show people how to write malware for Arm. Dmcq (talk) 18:05, 11 July 2018 (UTC)

Article cleanup required

Instead of posting this at the top of the article, I'm giving editors a chance to thin out the hype / peacock boasting / marketing fluff from the top half of the article. The technical design section has some, but at a lesser extent. • Sbmeirow • Talk • 22:42, 10 July 2018 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:RISC-V/Archive_1&oldid=924233287"