RISC-V port accepted for inclusion in GCC
gcc.gnu.org
gcc.gnu.org
Google, HP, Oracle Join RISC-V
http://www.eetimes.com/document.asp?doc_id=1328561
Adapteva: Why I will be using RISC-V in my next chip
http://www.adapteva.com/andreas-blog/why-i-will-be-using-the...
RISC-V should have a key advantage and exploit it. IDK if the advantage of openness would be key for general-purpose laptops. Special laptops would probably be available but pricey; compare to other niche laptops, like highly-protected ones.
A reasonable expectation is to get some low-end-ish CPUs out that might be on the same level (in terms of efficiency) than older, not really optimised ARM designs.
The biggest incentive RISC-V can offer is less legacy bullshit (like AArch64) and the fact that you don't have to pair royalties to ARM. Perhaps better standardisation of peripherals compared to ARM, so less time/money spent on integration, BSPs and stuff like that.
(And even then: Looking at recent POWER one can see that they can outperform related Intel offerings, while being drastically less efficient.)
Furthermore, research about architecture of chips has been published and can be used to create faster chips.
But I have to agree that it is not easy. Especially because chip design is partly generated by software and computed by many powerful machines.
Today it's a bit better, since eg. GF can (in theory) offer recent nodes (eg 22 nm and smaller), which wasn't something you could get ten years ago (back then that'd be 65 nm - most low-volume and custom stuff has been iirc 130 or 180 nm).
It's true, Intel spends more money on R&D than RISC-V is likely to ever get. But that means next to nothing. When a huge, monolithic, management-driven company spends billions of dollars on something, a lot of those billions of dollars aren't being used very effectively.
Consider Linux versus Windows. My suspicion is that Microsoft has spent more money on Windows dev than has ever been spent on Linux dev. Does that mean Windows is better than Linux? No; in fact, many people who have to use both would probably say the opposite. Why is Linux the OS of choice for many production applications in tech-savvy industries? It just works better and easier than the high-budget closed competition.
That's not to say that Linux is starved for funding; many large companies volunteer serious man-hours towards Linux development, because they want an open system that competes with (and beats) the crappy license-uncumbered alternative they would have to use otherwise. I expect the same thing to happen with RISC-V.
You also have this phenomenon in the open-source world where you have grad students, researchers, and enthusiasts embarking on ultra-high-risk projects that would never get funded at most companies, but pay off in a big way when they work. Now that we have an open ISA to work with, I fully expect a huge outpouring of automated synthesis software based on clever new ideas that beats the clunky stuff available in industry. We've already seen this happening on the HDL side of things; open-source, research-driven efforts like Clash and Chisel are orders of magnitude better than the crap that industry has been using for years (VHDL and (System)Verilog). Give it some time for the silicon side of things to improve as well.
I'm not so sure about that, if we only consider the kernel (everything else would be a lame comparison). Linux likely has had many more paid devs than the NT kernel for the last 10-15 years, if not more.
> This is a fallacy
I also don't think this is a fallacy. Yes, of course a large company has a big head and spending is generally much less directed and efficient than in smaller companies (big news). But, lots of money also tends to pay great talents.
> that I see repeated about the quality of open products all the time.
... and I didn't mention quality anywhere.
As for open source: Software has near zero initial cost, iterations are extremely fast compared to anything manufactured and software engineering is an abundant skill. Hardware has high initial costs, high manufacturing costs, iterations take a lot of time and HW design encompasses quite some areas with a much smaller pool of people being able to do it.
Also, a massive company like Intel which sucks up talent all the time from the hiring pool has the resources to evaluate multiple avenues of optimization at the same time, pick what looks best, and iterate (which, pretty much, is what Intel has been doing ever since Sandy Bridge). Another example here would be Intel developing P4, a massive and staggering failure comparable to the PowerPC970 debacle (just bigger) -- and then pulling the Core arch out of the hat (which originates, guess what, from a different engineering team in a whole different branch of Intel -- again, resources!).
What I do expect here is that some companies might think they can influence an arch early on by diverting resources to it, to maybe save some money in the future (by not paying ARM anymore and other synergetic effects I mentioned above), and perhaps in the hope of getting a product that outperforms ARM/the competition in some metric(s).
(Also we have seen in the past in quite some instances that CPU design is a very delicate art and even pouring massive monies into it might actually not get you very far - see AIM/PowerPC [although it was quite successful in some niches] - or, on the other hand, that radically new architectures that might theoretically be better don't succeed, because you don't get the fab access, or tooling access, or software, see eg. Transputer and many related examples)
I've spent my computer hobbyist life betting against Intel and losing -- 6502, 68000, PowerPC.
I don't think RISC-V will beat Intel on servers any time soon, I just hope it will establish itself in the market, get a foothold and then hope it openness will help it to grow.
That said, I think the biggest difference is the parity between OSes in in the 70s vs ARM/Intel's current dominance. That's definitely going to make it more difficult to get people to adopt RISC-V. I'd imagine if there was any likelihood that IBM, RedHat, Google, or Intel could customize a RISC-V chipset to outperform (whether it's TWP, flops/sec, whathaveyou) any current offerings they'd pour dumptrucks of money into it just the same.
That's wrong. See OpenSPARC, where you can get the Verilog code for the T1 and T2 (Niagara-based) processors. (IIRC this was only one year after their commercial release).
SPARC in general is perhaps not a bad example, since the ISA is open and royalty-free and there are actually independent implementations (well, today only Fujitsu and ofc. Oracle).
It's quite interesting to see RISC raising again after it died rather harshly in the late 90s -- were literally every year a major manufacturer announced the end of an architecture -- and early 2000s (and remained dead rather firmly throughout the 2000s).
As someone in the industry, I would have to disagree. I question this every time someone claims it's so awesome. None of those solutions can run simulations on the back annotated netlist . How do you design without a simulation tool that can work at every stage of the design flow?
RTL is a behavioral model. Post synthesis is the physical model. What do you think synthesis engineers do? Just sit around watching the tools run?
Can you explain briefly for someone not in the industry why it's not that simple? This seems like it should be a 100% automatable process.
After synthesis, your RTL becomes a gate level representation. You then place your logic i.e. Your memory logic near your memories, I/O logic near your pins etc. You then make clock trees for your various clocks. You don't want related logic clocked by different parts of the clock tree. Once you have stuff physically located, you back annotate and do your static timing analysis.
You generally run simulation on the different stages of synthesis. Someone has to debug all these simulations. They never just pass.
There is a big difference between RTL and gate level simulation. A test passing in RTL is only the 1st stage. RTL doesn't have any wire models so no delays are in there. Gate level sims can run with delays in there.
Synthesis tools can also tell you it doesn't pass timing through static timing analysis but asynchronous parts of the design can't be analyzed. You need simulation there!
Both of these designs are publicly available and under licenses which allow proprietary derivatives.
In every category; die area, power dissipation, total throughput, licensing cost, lead time, design flexibility, code density, technical debt, academic buy-in; real RISC-V cores which have been made in silicon are right-now beating ARM cores. At this point, ARM has but two things going for it: legacy and design maturity.
Once RISC-V designs are mature enough to be expected to run all general-purpose software correctly; there will be few other axes to compete on. RISC-V has an immense zero-day advantage in its clean, worldly design. I think it would be foolish to downplay the likelihood of great success.
Why should R5 compete with the big players? It doesn't need to support the bloated OSes. It would be sufficient if Linux runs with acceptable performance. If Linux is able to run on a 12 MHz 68k [1], and SiFive already runs with 320 MHz [2] then I think we don't have to wait too much to get a suitable cpu, since it could also be a "weak" massive multicore, or we could stick multiple cpus together in a cluster.
By the way, Fabrice Bellard has already published a Linux/R5 emulator [3]. As for me, I am really excited about the R5 movement!
[1] http://www.bigmessowires.com/68-katy/
OTOH this rules out laptops that OP wanted. OT3rdH ARM started with devices like these in mind, but went all the way to pretty powerful, desktop-comparable machines like current smartphones.
Open ISA and open hardware should be a major security concern for most countries.
It depends. If you want something like Opera or Firefox it won't run at all. If you are satisfied with basic functionality then you can use browsers like w3m which work well on low-powered devices. I think some developers will find a good compromise between performance and functionality.
And by the way, the very first R5 already runs with 320 MHz :-)
But there is still a very long way to go. Clock speed is not the only determinant of processor performance. Even low end laptops like the ARM-based Chromebook have out-of-order processors. The Rocket CPU used in the HiFive board is an in-order machine. There is an out-of-order implementation called BOOM, but it is not quite as mature. Whereas Rocket has been taped out and validated many times in our Berkeley test chips and now in SiFive's commercial silicon, BOOM has not yet been taped out.
And I'll be the first to admit that RocketChip is not nearly as reliable as you would like for a consumer product. SiFive's done a lot of work to improve the system, but there are probably still outstanding bugs in the memory system.
They run fine; I find Voyager 3 to be a bit bloated, but IBrowse runs quite well.
As others have mentioned, text-based browsers like w3m will probably be even smoother (although I usually run w3m via emacs-w3m, which would probably be much slower than using a normal terminal interface).
The great thing about being open is it allows academics and inventors to try out new ideas and have the ISA and associated "backend" flows just work without the worry of having to pay for licenses.
For RISC-V, the biggest issue seems to be a) actually designing a full chip with all the necessary peripherals (assuming just scaling the core bits is comparatively easy) and b) motivating someone to invest the fab time. I guess many potential commercial users will continue going with ARM, just because it is proven, designs and knowledge are available, ...
Before laptops, I'd expect more microcontroller-type stuff, where customization and license costs probably are more relevant, less complex periphery is used and the necessary fabrication capacity is more easily available.
Given the open IP and ease of customization, we might even see RISC-V inside peripherals or on the motherboard in a PC doing specialized tasks. But not as the main CPU.
But I think within the next year or two, we should get something that can run Linux resonable well and is mostly open.
Actuall production laptops is going to be difficult. Im rather waiting for "build it yourself laptop" kits, or something along those lines.
There are allready projects like it, for other hardware.
Maybe somebody from SiFive or lowRISC can comment. They probebly have the best information.
^ Related discussion from when this port was submitted.
RISC-V did make it to llvm[2], with there being healthy development there. I remember Fedora running on RISC-V successfully.
Anyone know what happened with the whole copyright assignment problem?
[1]:https://news.ycombinator.com/item?id=12633037
[2]:http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748....
EDIT: I found a comment[3] in the old submission which answers my question.