[deleted]
Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
51–60 of 105 posts
Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#52Instruction set baselines should ideally be well-regulated open standards. They should also be good, and not moronic academic projects running of 32B opcode space because of religious dedication to silly extensions and the uniformity of an ISA for saving pennies on microcontrollers to high performance CPUs. RISC-V in principle is a great idea. Hopefully we’ll get something that’s at the caliber of a well-oiled machin…
> Avoiding flags also has some interesting effects on encoding density.
That's one thing I liked about the Mill CPU was the belt, but I thought it was misplaced for data, and would be a great way to just carry the FLAGS register instead.
This would make conditional testing much easier and would mean you don't have to be as concerned about intermediate instructions updating flags before you use them.
I never had time to deeply think about it. Does someone want to tell me why this is actually a bad idea?
Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#53Would copying an instruction set and ABI to make an interoperable processor and system be fair use in light of Google v. Oracle (2021) [0][1]? [0] https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf [1] https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_... . Edit: Changed phrasing of question. Also, to be clear I think the answer is probably yes.
The case Amdahl brought against IBM tackles this question directly. It may have settled, though. (I was a CPU logic designer at Amdahl for a while. Some people had access to info from IBM under the terms of the settlement. They could read and make plans. Then one day they could walk down the hall and tell me about new tasks on my to-do list. )
Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#54Would copying an instruction set and ABI to make an interoperable processor and system be fair use in light of Google v. Oracle (2021) [0][1]? [0] https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf [1] https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_... . Edit: Changed phrasing of question. Also, to be clear I think the answer is probably yes.
You can patent an ISA. And then everyone who implements that ISA, in hardware or emulation, is infringing. Intel actually threatened lawsuits against Microsoft for implementing emulation of recent x86 instructions on ARM Windows.
Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#55The title of the piece is somewhat misleading - the actual point was, "there is no good technical reason for the lack of free, open ISAs."
I wonder why this hasn't been an issue for Apple (or maybe it has?).
Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#56Instruction set baselines should ideally be well-regulated open standards. They should also be good, and not moronic academic projects running of 32B opcode space because of religious dedication to silly extensions and the uniformity of an ISA for saving pennies on microcontrollers to high performance CPUs. RISC-V in principle is a great idea. Hopefully we’ll get something that’s at the caliber of a well-oiled machin…
I don't see why "moronic" was needed there. Also Risc-V has profiles that group multiple extensions together for specific use cases. For example RVA23[0] which requires 64 bit and vector extension among many others. Operating systems like android can (and most likely will) specify that they only support certain profiles.[1] Lastly, ARM is also fragmented between Armv8 and Armv7 which android developers are still supp…
>All the "high performance CPUs" right now are just dev kits, so I don't see how there can be fragmentation in a market that does not yet even exist.
It comes straight from the "RISC-V know the facts" FUD campaign ARM infamously ran.
Yet, not even these dev kits suffer from "fragmentation". Basically:
- Previous wave implements RVA20, some of them with custom extensions, such as a harmless pre-ratification V extension.
- The open software ecosystem is built for RVA20, which the hardware supports. Vendors run their experiments within custom extension space, no harm is done.
- Current wave implements RVA22 with the ratified V extension, some of them with harmless custom extensions. As newer RVA profiles build on older RVA profiles, these chips run RVA20 code no worse than the previous wave.
Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#57There is also a response from ARM, The Case for Licensed Instruction Sets . https://web.archive.org/web/20140926222155/http://www.linley...
It's such an obvious hit piece by a competitor where many of the arguments boil down to essentially "they did it differently to us and hence they're wrong".
Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#58Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#59There is also a response from ARM, The Case for Licensed Instruction Sets . https://web.archive.org/web/20140926222155/http://www.linley...
It's such an obvious hit piece by a competitor where many of the arguments boil down to essentially "they did it differently to us and hence they're wrong".
The main argument may be "we want to keep making money."
Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)
#60There is also a response from ARM, The Case for Licensed Instruction Sets . https://web.archive.org/web/20140926222155/http://www.linley...
None of those arguments have held up over the last 10 years. RISC-V has all of the things they say you need.
Apple has a licensing deal with ARM through 2040, but they might get tired of the license fees at some point.