Can We Replace Intel x86 With an Open Source Chip? (zdnet.com)

An anonymous reader quotes Jason Perlow, the senior technology editor at ZDNet: Perhaps the Meltdown and Spectre bugs are the impetus for making long-overdue changes to the core DNA of the semiconductor industry and how chip architectures are designed... Linux (and other related FOSS tech that forms the overall stack) is now a mainstream operating system that forms the basis of public cloud infrastructure and the foundational software technology in mobile and Internet of Things (IoT)... We need to develop a modern equivalent of an OpenSPARC that any processor foundry can build upon without licensing of IP, in order to drive down the costs of building microprocessors at immense scale for the cloud, for mobile and the IoT. It makes the $200 smartphone as well as hyperscale datacenter lifecycle management that much more viable and cost-effective.

Just as Linux and open source transformed how we view operating systems and application software, we need the equivalent for microprocessors in order to move out of the private datacenter rife with these legacy issues and into the green field of the cloud... The fact that we have these software technologies that now enable us to easily abstract from the chip hardware enables us to correct and improve the chips through community efforts as needs arise... We need to stop thinking about microprocessor systems' architectures as these licensed things that are developed in secrecy by mega-companies like Intel or AMD or even ARM... The reality is that we now need to create something new, free from any legacy entities and baggage that has been driving the industry and dragging it down the past 40 years. Just as was done with Linux.
The bigger question is which chip should take its place. "I don't see ARM donating its IP to this effort, and I think OpenSPARC may not be it either. Perhaps IBM OpenPOWER? It would certainly be a nice gesture of Big Blue to open their specification up further without any additional licensing, and it would help to maintain and establish the company's relevancy in the cloud going forward.

"RISC-V, which is being developed by UC Berkeley, is completely Open Source."

Comments

Not sure what you mean by that

[squiggleslash]

OpenSPARC is open source, the entire reason for the existence of that word was to brand Sun's open-source SPARC project. So, given it's a relatively mature and respected design, you could definitely use OpenSPARC as the basis of an open source CPU design.

The question is really whether the OS hardware community is actually likely to produce something comparable to Intel or AMD, even given a start with the SPARC design. I... don't want to say it's impossible, but it certainly seems somewhat more difficult than producing a better operating system than Microsoft can.

Re:Not sure what you mean by that

[OrangeTide]

RISC-V's specification is a lot more flexible and permits a wider range of variants on capabilities in implementations than OpenSPARC. I've worked on 32-bit RISC-V based microcontrollers embedded in ASICs, and theoretically you can put together a multiprocessor 64-bit RISC-V with advanced features such as speculative execution.

I think that RISC-V has a pretty good future because it is a specification rather than a single implementation. There are multiple implementations, some of them are open source. And it can cover a broad enough range of needs to suit multiple industries. For research RISC-V is interesting because how to add extension instructions to it is well defined and the toolchain is easy to set up with your custom extensions.

No

[Anonymous Coward]

Figure out some way to fund the billions in development costs, legal/IP issues and marshal the necessary talent then maybe... Of course, there is no reason to believe the result would be any better: RISC-V memory model has severe problems due to underspecified memory ordering that were revealed by formal testing and are still being resolved. Perhaps this is an example of an open process working well, but just throwing out RISC-V doesn't guarantee a bug free design.

Re:No

[DontBeAMoran]

The same people who paid to develop Linux, Red Hat, etc?

Just one way to get everything you want

[Bruce Perens]

If you really want an Open Source, after-market bug fixes, and security, the best way to do that is to use not a CPU at all but a programmable gate-array. This also gives you the ability to have evolution in purchased hardware, for example improvement of the instruction set. The problem is finding a gate-array that is fast enough, dense enough, and power-conserving enough.

It would be cool to code your own special-purpose algorithm accelerators in VHDL or Verilog, etc.

This is sort of on the edge of practical, if you have the money to spend. Not as fast, not as powerful, uses more electricity, infinitely flexible. Certainly there would be some good research papers, etc., in building one.

Re:Oh Really

[Bruce Perens]

t Raspberry Pi, while not exactly open source, is pretty close, and it's available now. Feel free to trick that out and use it as your primary workstation.

I do have some issues with documentation. Have they now documented the GPU (or whatever it is) that first has control at boot time, before the main CPU is enabled? I'd also like to use the LVDS for an SDR rather than the camera and display, and that was not documented either the last time I looked. There was also some chat about additional entirely undocumented coprocessors on the die.

Re:Nice

[TheRaven64]

Proof of correctness is elusive, because it first requires that you specify what 'correctness' means. Processors vulnerable to this would have passed formal verification until recently, because processor vendors explicitly did not consider side channels to be easily exploitable. Now people are scrambling to add things like 'speculative execution must not change any observable aspects of microarchitectural state' to their specs. That's easy to write in English, but defining what 'observable aspects of microarchitectural state' are in a formal specification is really hard (particularly given that temporal aspects are really hard to talk about at all in most existing specification languages). That said, I'm collaborating with a group that is working on some of this.

seL4 (not L4) is actually a really good example. It was about 6 hours between the release of the formally verified microkernel and the first exploit being released. The implementation was correct with regard to the specification, but the specification didn't account for everything. It's worth remembering that Goedel's Incompleteness Theorem basically tells you that this kind of verification is impossible: a sufficiently detailed specification of what 'correct' means will, for any nontrivial system, be more complex than the implementation and must itself be correct for the proof to be useful.