
ARM’s Rebuttal to RISC-V: “The Case for Licensed Instruction Sets” - kasbah
http://www.linleygroup.com/mpr/article.php?id=11268
======
ajross
Odd that ARM even bothered to reply. And the arguments are the expected stuff
you'd expect to see from an entrenched leader. Basically it's "benefits of
standardization trumps openness", though not stated that way.

A few bits struck me as amusing, like the chart with all the extensions to the
ARM ISA over the years, most of which have been abandoned in modern cores.
Citing the original VFP standard or Jazelle as "innovation" seems laughable.

If I were to write a ARM-vs-RISC-V paper, I'd start with the important things
that are actually missing from RISC-V still, like a MMU spec.

~~~
valarauca1
Fundamental problem with the classic:

>benefits of standardization trumps openness

Is that openness provides the same benefits of a standard. A ground floor that
everyone can stand on, build on, and has no cost of entry (unlike a business
ran standard).

~~~
cwyers
Well, that's not really the whole story, though. Look at Linux. Linux is
"open." Linux is also a much harder target to write software for than OS X or
Windows, because a lot of people do a lot of different things with that
openness, and so you can't count on a specific version of certain APIs or ABIs
being there. If modern CPUs looked like modern Linux distributions, a lot more
effort would be required to make software portable and to run widely. (The
irony here is that ARM resembles this Tower of Babel situation a lot more than
x86 does.)

~~~
Zardoz84
I found that programming for Windows is a pain in the ass compared to
GNU/Linux. If I need a library, I only need to do a apt-get install XXX or
download the source ode and it will compile with usually zero problems.

I can't say anything about OS X

~~~
cwyers
I'm not talking about writing software, so much as I am talking about
distributing software. Yes, you can use apt-get to install whatever libraries
you need, but you can't guarantee that users are going to have access to the
same version as you through their distro's repo, so you have to either
statically link the version of each library you wrote the code with, or wait
for your software to be picked up by a maintainer for all the common distros
out there.

~~~
zanny
Packages do fix this problem though. You specify dependencies in your target
distros package you make, and either you duplicate that dependency graph
across distros (bad idea) or you let that distros packagers handle it (good
idea).

For example, you can make a deb that works on Debian, Ubuntu, and any of its
derivatives with its dependency graph. You can do the same with Fedora. And
the Arch ecosystem will just use PKGBUILDs of the rpm or deb to package it
themselves.

~~~
cwyers
This only works if you let the distros handle all the work for you. But say
you need an Apache version RHEL 6 doesn't have, so now you have to build from
source. And now you have to build PHP from source, because now RHEL's PHP
package won't run with your new Apache. On Windows, this requires that you run
two MSI files and hit okay a few times. On Linux, this means you're compiling
everything from source. Linux apps are less portable between distributions
than Windows apps are among Windows versions (hell, thanks to WINE a randomly
picked Windows app is more likely to run on both Fedora and Ubuntu without
modification than an actual Linux app is, the distribution just hides that
work from you most of the time).

------
kazinator
Note that the whole ARM ecosystem relies on a crapload of open source stuff,
like the entire GNU toolchain, kernel and on up.

So any criticism of the call for openness in the RISC-V paper from the ARM
camp is sheer, sheer hypocrisy.

In economic terms, the free stuff that helps ARM be popular is a
"complementary good". When you sell something, you want the complementary
goods to be commoditized and as cheap as possible, while keeping your
ingredient as proprietary as possible.

Obvious table reversal:

"No, no! Open source the CPU cores, and buy my compiler instead! __That 's
__how you keep costs low, and everything from fragmenting. "

~~~
zwieback
Agree that the free GNU stuff is key to ARM's success today but the original
armcc compilers came from ARM, though. The GNU toolchain came much later.
There are other non-GNU compilers for ARM that are very widely used. Remember
that ARM was super popular long before phones.

------
asb
If you're interested in the development of an open-source SoC using RISC-V
then do keep an eye on [http://lowrisc.org](http://lowrisc.org). We will have
more public soon - I'm talking at the OpenRISC conference
([http://orconf.org](http://orconf.org)) next month.

------
_yosefk
The flip side of "no fragmentation" is, there's no ARM core with hardware
multithreading, and there won't be one until ARM decides to make one, which
AFAIK may well be "never". You can license a core with hardware multithreading
if you need it - say, MIPS from Imagination - but the ISA won't be ARM-
compatible. To the extent that ARM's "software ecosystem" is valuable, it's a
pity nobody can make a multithreaded ARM-compatible core. Similarly for other
features.

On the other hand, x86, which is "open" to all of Intel, AMD and VIA who
reached a patent war stalemate, has the problem of incompatible instruction
set extensions, as documented in "Stop the instruction set war":
[http://www.agner.org/optimize/blog/read.php?i=25](http://www.agner.org/optimize/blog/read.php?i=25)

Which problem is worse is hard to decide.

~~~
frankchn
Not sure about your first point. ARM does license out its architecture/ISA
(i.e. for you to implement your own processor with an ARM instruction set) in
addition to complete cores (Cortex-A57, etc...).

This is how Apple and nVidia can design their own ARM-compatible chips (Apple
A8/NVidia Tegra K1 "Denver") without relying on Cortex cores.

------
dang
Url changed from [https://blog.riscv.org/2014/09/arms-rebuttal-to-risc-v-
the-c...](https://blog.riscv.org/2014/09/arms-rebuttal-to-risc-v-the-case-for-
licensed-instruction-sets/), which points to this. The article being responded
to is
[http://www.linleygroup.com/mpr/article.php?id=11267](http://www.linleygroup.com/mpr/article.php?id=11267).

------
higherpurpose
I haven't read this yet, but I can't imagine what ARM would say that I'm not
already expecting from a company selling a proprietary product to say about an
open source competitor. I think the fact that ARM even thought they should
"address this", say quite a lot about RISC-V.

~~~
ewzimm
It's written by their marketing department. Basically, they say open
architecture poses the risk of fragmentation and designing instruction sets is
expensive, so it makes sense for everyone to pay them to do it.

------
zwieback
Important to remember that ARM is talking about instruction sets and not
cores. There's still a lot of differentiation going on among SoC vendors but
the common ISA really helps with the app ecosystem.

If you're really serious you don't have to get a core from ARM, you can do
your own (like XSCale was) and still benefit from the common ISA. Not sure how
expensive that is, though.

Anyway, it would be great to have a healthy competitor for ARM but right now
it's hard to see what problem that's trying to solve.

------
fidotron
This sounds like the idea that without someone wielding a big stick you'll end
up in fragmented hell.

Have to admit history would support that.

------
sagargv
Does the ISA matter a lot these days? If we look at the mobile world,
specifically Android, most programs are written in Java. So, as long as the
compiler, the OS, and the JVM are ported to a new ISA, most apps will run
happily.

Also, is binary ISA translation restricted by patents?

~~~
marssaxman
Most apps...? We live in different worlds, clearly! I know people use Java for
boring corporate line of business apps and boring corporate web server
projects, but none of the apps I actually care about are written in Java, and
I see no trends suggesting that this will ever change.

~~~
wtracy
What Android apps do you use that rely on native code?

All the ones that I'm aware of are either games or half-arsed ports of iOS
apps.

~~~
marssaxman
I don't really use Android apps. But now I see that I misread your comment,
and thus my reply was irrelevant.

------
pessimizer
Was the original article ever posted? Couldn't find it in search:
[http://www.linleygroup.com/mpr/article.php?pub=1&id=11267](http://www.linleygroup.com/mpr/article.php?pub=1&id=11267)

~~~
akkartik
Closest I could find was
[https://news.ycombinator.com/item?id=8242999](https://news.ycombinator.com/item?id=8242999),
which might not be the exact same article.

~~~
pessimizer
I think that's it.

