14 ms·
ARM’s Rebuttal to RISC-V: “The Case for Licensed Instruction Sets”
- ajross 12y agoOdd 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.
- deleted 12y ago[deleted]
- monocasa 12y agoIMO, the fact that they decided to respond at all is a really good sign for the viability of RISC-V.
- valarauca1 12y agoFundamental 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 12y agoWell, 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.)
- niklasni1 12y agore: linux I find that's less true than it used to be, at least on x86; I run a few pieces of non-free software, binary software (Xilinx tools, Renoise) and it's problem free. Huge statically linked blobs though.
- Zardoz84 12y agoI 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 12y agoI'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 12y agoPackages 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 12y agoThis 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).
- dang 12y agoUrl changed from https://blog.riscv.org/2014/09/arms-rebuttal-to-risc-v-the-case-for-licensed-instruction-sets/ https://blog.riscv.org/2014/09/arms-rebuttal-to-risc-v-the-c..., 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.
- pessimizer 12y agoWas 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 12y agoClosest 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 12y agoI think that's it.
- fidotron 12y agoThis 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.
- deleted 12y ago[deleted]
- sagargv 12y agoDoes 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?
- Narishma 12y agoThat's true in theory. In practice, a not insignificant number of popular Android apps (mostly, but not limited to, games) are written in non-Java languages. That limits those apps to ARM unless the developers bother to provide versions for other ISAs, which practically nobody does.
- niklasni1 12y agoIt doesn't matter a lot, no. But you do have to pick one for your platform, and decide if you want to be tied to, say, Intel's specific offerings, or (in principle) anyone with an ARM license. If RISC-V gets off the ground, you'll be able to pick a completely open standard.
- redraga 12y ago> Also, is binary ISA translation restricted by patents? Intel has binary translation software to run ARM apps on x86 phones, so I'd guess it's not limited by patents.
- marssaxman 12y agoMost 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.
- deleted 12y ago[deleted]
- wtracy 12y agoWhat 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.
- kazinator 12y agoNote 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 12y agoAgree 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.
- higherpurpose 12y agoI 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 12y agoIt'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.
- _yosefk 12y agoThe 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 12y agoNot 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.
- asb 12y agoIf 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.
- zwieback 12y agoImportant 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.