ARM’s Rebuttal to RISC-V: “The Case for Licensed Instruction Sets”
linleygroup.com
linleygroup.com
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.
>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).
I can't say anything about OS X
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.
Things are a lot better for this in 2014 than they were in 2004 (much less 1994) but I still regularly run into things that need quite a bit of handholding to build.
err = open("/path/to/the/file/I/want/to/make", "rw");
err = CreateFile(TEXT("input.txt"), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
In Linux if I want to fork a process to create a sub-process I call
err = fork();
err = exec(a.out);
//now two instances of a.out are running!
bRet = CreateProcess ("myapp.exe",NULL,NULL, NULL, FALSE, 0,NULL, NULL,&sui,&pi);
//now one instance of my app is running...
Show me the full linux/POSIX code to open a file with different security access modes, with different sharing models, with different dispositions (when should the new file be created, if it should be created, and what should happen to an existing file with same path), with hinting to the OS how to handle the file (should it be encrypted, should it be deleted once all handles are closed to it, etc.).
Show me the full linux/POSIX code to open a process while setting the security ACLs and whatnot for it, setting its priority level, setting the environment strings, setting up the stdin/stdout/stderr file descriptors, setting the window position (if any), etc.
Linux/POSIX aren't nicer than Windows/NT--they're simpler APIs for a simpler world. That doesn't make them better or worse, they're just different tools.
Maybe now you've 'outgrown' video games you can outgrow thinking that your user experience is authoritative. Better, nicer, whatever, these are all just words people use to praise things that they like.
But saying Linux / Unix has a lower barrier to entry than Windows is the kind of thing only a long-time Linux user can say with a straight face. Unless you are talking about money, and then, well... yeah.
Python/Ruby/etc. are also available on Windows, usually with friendly installers.
Look, I'm all for Linux/POSIX from an operations standpoint, but the programming story is merely different, and to pretend otherwise makes one look foolish.
EDIT:
Also, as cobrausn pointed out, what about when the official sources for the package are hella out of date? Not so friendly then, eh?
Except that everyone and their grandmother knows how to use a windows machine and no one(relatively speaking) knows how to use linux.
Don't get me wrong I use OS X/Ubuntu daily and die when I have to use Windows with it's lack of POSIX compliance and abomination of a shell but that doesn't mean it's the right choice for the masses.
> The irony here is that ARM resembles this Tower of Babel
> situation a lot more than x86 does.
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."
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
Which problem is worse is hard to decide.
This is how Apple and nVidia can design their own ARM-compatible chips (Apple A8/NVidia Tegra K1 "Denver") without relying on Cortex cores.
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.
Have to admit history would support that.
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.
All the ones that I'm aware of are either games or half-arsed ports of iOS apps.