31–40 of 105 posts
Earlier quoted context omitted.
With market forces being the way they are, the quality of technology is becoming increasingly irrelevant. What counts is having a dominant position so you can shove down your "product" right through everybody's throat.
product? that's so 2010s. it's all about subscriptions now. you own nothing but please keep paying that sweet monthly/yearly fee.
Would 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.
Most likely yes. In Google v. Oracle, the Supreme Court ignored whether software APIs are copyrightable and instead performed a fair use test. Oracle's Java APIs remain under copyright, but Google's use of the APIs were fair use.
There is also a response from ARM, The Case for Licensed Instruction Sets . https://web.archive.org/web/20140926222155/http://www.linley...
Instruction 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…
Also... consider how successful an insane instruction set like x86 is! The ISA definitely matters for performance, but it clearly doesn't matter that much.
Also the uniformity of the ISA is very nice for compilers. Sure in practice you're only ever going to use x1 or x5 for your return address but adding the hard constraint that you can only use those is definitely going to complicate some software.
I'm not sure what you mean about fighting fragmentation. I used to think that but I didn't know about the RVA profiles.
Earlier quoted context omitted.
Most likely yes. In Google v. Oracle, the Supreme Court ignored whether software APIs are copyrightable and instead performed a fair use test. Oracle's Java APIs remain under copyright, but Google's use of the APIs were fair use.
I rephrased the question. The instruction set may be copyrightable, but as in Google v. Oracle , we don't have to answer that question. Even if an instruction set is copyrightable, then under Google , it is probably fair use to copy it for interoperability purposes (e.g., making a compatible processor or emulator). For the actual binary encoding of instructions, there is even less of an argument for copyright protect…
What clearly is subject to copyright is the documentation describing the instruction set and its semantics.
Earlier quoted context omitted.
Most likely yes. In Google v. Oracle, the Supreme Court ignored whether software APIs are copyrightable and instead performed a fair use test. Oracle's Java APIs remain under copyright, but Google's use of the APIs were fair use.
I rephrased the question. The instruction set may be copyrightable, but as in Google v. Oracle , we don't have to answer that question. Even if an instruction set is copyrightable, then under Google , it is probably fair use to copy it for interoperability purposes (e.g., making a compatible processor or emulator). For the actual binary encoding of instructions, there is even less of an argument for copyright protect…
Would 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.
In contrast, reimplementing a copyrighted ISA would quite clearly be substantial and could easily have large market effects. So you'd have to lean heavily into the idea of interoperability to overwhelm the lack of these other factors, or argue that the ISA is not copyrightable per se.
Also, even if an ISA isn't copyrightable, you have to watch out for patent rights the owner might have over any part of the ISA.
Earlier quoted context omitted.
>the main difference is the private one can sneak in magic backdoor instructions, lost in the vastness of a 2^bit_depth space There's nothing keeping an implementation of a public ISA from adding backdoors.
I imagine, with knowledge of the ISA, can help one can define a verification algorithm, in which, the CPU is probed with some known inputs to gain confidence that there is no backdoor.
There are 2^64 possible values for a single register. It's not possible to probe all possible combinations of values for the over 60 user-accessible registers, to find the single combination which, when calling a specific one of the more than 2^30 possible instructions, silently flips a secret "disable all permissions checking" bit.
Instruction 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 think David Chisnall's article is very good. However I don't think you should oversell the few issues with RISC-V. There are definitely some design mistakes, but overall it is good. I would say as good as ARM (but not as mature yet). Also... consider how successful an insane instruction set like x86 is! The ISA definitely matters for performance, but it clearly doesn't matter that much. Also the uniformity of the I…