I'm not sold on the idea that we have to start from scratch to get an industry standard open ISA. As the article notes, we already have OpenRISC, which comes with an open bus standard (WishBone). The architecture is based on something well proven (DLX, of which David Patterson was half the design team), for which there is plenty of tutorial material.
It takes a long time to build all the software infrastructure around a new ISA. Surely far better to start with something like OpenRISC that has spent 15 years invested in its software.
The OpenRISC architecture doesn't tick all the author's boxes, but it is extensible, and the missing features (do we really need 128-bit addressing) could be added.
One feature that is not mentioned is multiprocessor support. Thanks to the work of Stefan Wallentowitz at TU Munich and others, this is something that OpenRISC now supports. It seems to me this ought to be a key feature of any new ISA.
The authors are two engineers for whom I have the greatest respect. I wish RISC-V well, because this team is certain to innovate, and that can only be good for the field. But as the basis of an industry standard open ISA? I wish they had built on what was already there, rather than starting again from scratch.
We started in 2010, when OpenCore only had a 32-bit address space, which was a fatal flaw that was later corrected. It is still missing the small code size option, which is requirement for IoT.
And I am not sure if everyone understands the importance of the "Base+Extension" approach to instruction sets. This is a new approach to coping with software compatability of instruction sets. As we wrote in the associated technical report:
"RISC-V is aimed at SoCs, with a base that should never change given the longevity of the basic RISC ideas; a standard set of optional extensions that will evolve slowly; and unique instructions per SoC that never need to be reused."
Software compatability with controlled evolution.
(And it's really hard in 2014 to embrace an ISA that offers delayed branches:)
Thanks for the quick reply. I've used it as an excuse to go off and read the V2.0 ISA spec for RISC-V instead of doing the day job :-) I see that RISC-V does have multicore support in its memory model.
OpenRISC has a core instruction set, which is stable and then various extensions around that core. We have debated the number of extension sets - there are too many at present, meaning compilers need too many multilibs to use them efficiently.
As we have found with the OpenRISC GCC implementation, combinatorial explosion of multilibs may be a challenge for RISC-V. There are a 32-bit base, 64-bit base, 128-bit base and 10 standard extensions, so a compiler potentially needs 8192 multilib variants to efficiently support all possible combinations of ISA. It is possible that some extensions will have no impact on compiled code, but the number of multilibs will still be too high, so the compiler will need to restrict itself to likely popular combinations, degrading efficiency - 15-20 multilibs is a practical limit. Alternatively the user builds a compiler just for their specific architecture, but that still puts a demand on the compiler writer to be able to juggle all the possible options (consider for example how to optimally compile a * b for all C/C++ types with all possible combinations of optional ISA extensions).
BTW, OpenRISC made delayed branches optional a few years ago. All the recent implementations (e.g. Julius Baxter's mor1kx implementations) don't have delayed branches. The online version of the OpenRISC 1000 architecture spec should reflect this.
I hope RISC-V is successful, but I would rather it focussed on forward-looking innovation in ISA development, instead of industry standardization, which is innevitably backwards looking.
Do you envision having variants of the architecture for different domains (like MIPS and ARM) or do you think we should move forward with a heterogeneous apporach (different ISAs/approachs for different tasks)?
btw. Love the fact that it runs on Zynq! We will give it a try on Parallella immediately.:-)
"Thanks in part to the open-source Chisel hardware design system, one 64-bit RISC-V core is half the area, half the power, and faster than a 32-bit ARM core with a similar pipeline made in the identical process."
This is hardly a valid comparison. The Cortex-A5 supports fast multiplies, DSP extensions, SIMD extensions, large TLBs and caches, branch prediction, compressed instructions, hardware Java execution, security extensions, interrupt control, multi-core etc etc. The base RISC-V ISA is more similar to a Cortex-M0 which is significantly smaller and more efficient than a Cortex-A5. But like RISC-V's basic ISA it is not suitable to run eg. Android.
It is easy to make a simple MIPS-like RISC ISA and a bare-bones CPU which appears to do well on Dhrystone. However that's hardly proof of anything. MIPS used to have various CPUs that showed that with 64-bit load/store and delayed branches you get amazing 32-bit Dhrystone scores from a simple pipeline - nice trick, just a shame that it didn't help nearly as much when running real code. Cortex-A5 actually runs Android pretty well, and I bet RISC-V with its very basic ISA won't be able to keep up.
Also this appears to be a comparison of a 5 year old widely used CPU with a simulation of an unfinished CPU. Let's compare when actual hardware is available - and instead of Dhrystone, compare with the 64-bit A53 running eg. SPEC2000.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.