Live data from Hacker News

Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

www2.eecs.berkeley.edu

11–20 of 105 posts

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#11
There was a reimplementation of SuperH as https://j-core.org some years ago and AFAIK it didn't really go anywhere, sadly.

One of the things you get when dealing with OEMs, and IP licensors like Arm, is a huge amount of paperwork about patents, and I used to believe this was annoying, but have come to believe it is vital. The alternative "open" "free" approach leads to something like the cloud world, where in practice it's AWS/GCS/Azure and some others in lower tiers, because of the complexities around the open/free stacks and IP tarpits that result. Just look at how AWS behave. We must be able to pay to develop and license these pieces, or you will end up with all IP being trade secrets and the vertical monopolies will get utterly entrenched.

There are definitely patent trolls around but the free case would be much stronger if financially viable open source software development were a thing.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#12

There was a reimplementation of SuperH as https://j-core.org some years ago and AFAIK it didn't really go anywhere, sadly. One of the things you get when dealing with OEMs, and IP licensors like Arm, is a huge amount of paperwork about patents, and I used to believe this was annoying, but have come to believe it is vital. The alternative "open" "free" approach leads to something like the cloud world, where in practic…

Amazon also, of course, designs ARM cores. But they do seem a tad less “locked in via complexity” than their cloud stuff. I wonder if that is a result of the license situation. Alternatively, Amazon may just not be very good at coming up with hardware extensions, and also trying to commoditize their complement.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#13
post #7

There is also a response from ARM, The Case for Licensed Instruction Sets . https://web.archive.org/web/20140926222155/http://www.linley...

It is appalling how stupid whoever at ARM must have been, to respond and thus bring attention to RISC-V.

Back then, RISC-V was not anywhere as well-known as it is today.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#15
post #13
post #7

There is also a response from ARM, The Case for Licensed Instruction Sets . https://web.archive.org/web/20140926222155/http://www.linley...

It is appalling how stupid whoever at ARM must have been, to respond and thus bring attention to RISC-V. Back then, RISC-V was not anywhere as well-known as it is today.

Sort of like when Ballmer-era Microsoft declared war on Linux and GPL.

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#16

There was a reimplementation of SuperH as https://j-core.org some years ago and AFAIK it didn't really go anywhere, sadly. One of the things you get when dealing with OEMs, and IP licensors like Arm, is a huge amount of paperwork about patents, and I used to believe this was annoying, but have come to believe it is vital. The alternative "open" "free" approach leads to something like the cloud world, where in practic…

So rather than getting stuck in potential future tarpit of AWS or GCS or Azure, or probably a dozen other companies, we should voluntarily put ourselves into the IP tarpit developed by ARM? How exactly is that a win?

Over the last two decades ARM has developed a stranglehold on the non-x86 world, and they have already considered abusing this position to increase their profit margin[0]. As a chipmaker you're essentially stuck with ARM, as getting rid of them means you not only need to redesign your chips, but you also need to completely overhaul the entire downstream ecosystem.

With RISC-V there's at least the possibility of switching to a different IP vendor. That might not practically happen with bleeding-edge SoCs, but that kind of flexibility is quite important for the far larger dime-a-dozen MCU market. It's exactly why companies like Western Digital are investing in RISC-V and even developing open-source implementations[1]. Compute is essentially a commodity already, so why not tear down the walled gardens and force it to be one?

[0]: https://www.techpowerup.com/300385/arm-could-change-licensin...

[1]: https://blog.westerndigital.com/risc-v-swerv-core-open-sourc...

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#17
post #13
post #7

There is also a response from ARM, The Case for Licensed Instruction Sets . https://web.archive.org/web/20140926222155/http://www.linley...

It is appalling how stupid whoever at ARM must have been, to respond and thus bring attention to RISC-V. Back then, RISC-V was not anywhere as well-known as it is today.

Stupid?! The type of reader paying $500/year for the Microprocessor Report (where this response article appeared) already knew. (Similarly if they were motivated to get it free or took time to read it through their university, company, pirate it, etc.) And the ARM response you'll didn't mention RISC-V by name specifically.

The notion of an open source entity building an open or semi-open ecosystem cannibalizing even a low-end player was already happening in phone operating systems (Android/Linux vs Windows); a parallel dynamic wasn't lost on anyone looking at the hardware/ISA side, phone or non-phone.

I don't see this as any more foolish than Bill Gates making the case for software licensing vs free software at the dawn of the PC revolution. You may disagree with one party or the other, but each laying out their case is a marketing must. If you want to compete at the low end, you have to explain your value proposition vs "free".

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#18
post #16

There was a reimplementation of SuperH as https://j-core.org some years ago and AFAIK it didn't really go anywhere, sadly. One of the things you get when dealing with OEMs, and IP licensors like Arm, is a huge amount of paperwork about patents, and I used to believe this was annoying, but have come to believe it is vital. The alternative "open" "free" approach leads to something like the cloud world, where in practic…

So rather than getting stuck in potential future tarpit of AWS or GCS or Azure, or probably a dozen other companies, we should voluntarily put ourselves into the IP tarpit developed by ARM? How exactly is that a win? Over the last two decades ARM has developed a stranglehold on the non-x86 world, and they have already considered abusing this position to increase their profit margin[0]. As a chipmaker you're essential…

Arm didn't develop the IP tarpit, they're one of the few players that learned how to operate in it.

The SuperH example is relevant because what Arm did was "that's neat, let's license it" for some of the Hitachi innovations, and then licensed it to other people too. This is a positive development, and how trade and innovation has worked through the most successful periods in history.

There is a respect in which they are more comparable to the MPEG-LA than a conventional company, but they do not have a reputation for shady antics, unlike some of their customers!

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#19
free instruction sets: this "langauge" should be spoken by all! a public ISA

private instruction sets: this is a private matter, restricted to a need-to-know basis. private ISA

the main difference is the private one can sneak in magic backdoor instructions, lost in the vastness of a 2^bit_depth space

which is better for a languge? to be spoken used and known by many? or to be unkown and obscure? the funky business is that ISAs pictured as "languages" are spoken by microcontrollers; which scrambles the private/public issue

Re: Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)

#20

free instruction sets: this "langauge" should be spoken by all! a public ISA private instruction sets: this is a private matter, restricted to a need-to-know basis. private ISA the main difference is the private one can sneak in magic backdoor instructions, lost in the vastness of a 2^bit_depth space which is better for a languge? to be spoken used and known by many? or to be unkown and obscure? the funky business is…

>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.

Post reply on HN