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

No

[Anonymous Coward]

No

Re:No

[negRo_slim]

Because who is going to pay for the initial research and design to get it up to snuff?

Re:No

[DontBeAMoran]

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

Re:No

[swamp_ig]

IC design isn't something you can do in your spare time. You need a full-scale industrial process.

Re: No

[Anonymous Coward]

The open source software model is different. It works because businesses that need custom software find it less expensive to contribute to open source and make it provide the desired functionality rather than building the entire software project from scratch. Rather than building an OS from scratch, it's far cheaper for IBM and others like them to contribute to Linux. For the most part, there isn't a need for this with hardware. The only place I could see this working is if some of the large cloud providers like Google, who do use custom hardware, wanted to open source their projects. Basically, you'd need lots of businesses to decide they want to contribute to open source hardware when creating their clouds. Unfortunately, you still need to scale up the production processes to keep costs down. That leaves you at the mercy of overlords like Google, Amazon, and Microsoft. It might have open specifications, but you probably won't have much more freedom than with Intel and AMD as your overlords.

Re:No

[K. S. Kyosuke]

IC design isn't something you can do in your spare time. You need a full-scale industrial process.

You mean IC manufacturing? I'm pretty sure design is largely independent. If it weren't, ARM wouldn't be able to sell synthesizable CPU cores.

Re:No

[rkordmaa]

Oh yes you can and lots of people do it, it's not that different from writing programs really. The chip logic is written as code. Just having the chip logic doesn't get you latest and greatest CPU tho, having the manufacturing processes up to snuff is entirely different thing and major R&D effort, but that is completely separate from actual chip logic. Chip developer writes the logic, foundry handles the manufacturing process, Intel does both and it's the latter where they really earn their bread. You can take your chip logic to any foundry, but not all are equal on how latest and greatest their manufacturing process is and all of them lag behind Intel. Moore's law will eventually plateau tho and foundries will equalize on what is possible with silicon, then you can take your logic anywhere and get more or less same results. But we are not quite there yet.

Re: No

[guruevi]

Google, Amazon etc already have open source hardware for anything from storage to compute nodes (a lot of it is still ARM, Broadcom and Intel chips but everything around it is custom)

It's not cheap for a single system nor very well understood by the regular sysadmin to put the system together, hence you don't see them unless you buy them in datacenter-bulk, I have pondered them for a Ceph buildout because at scales of petabytes they start making financial sense.

I imagine that open source hardware has the same problem. Until you reach a certain scale it won't be cheap and thus it won't reach the majority of the market.

Re: No

[misnohmer]

Sure chip design in mostly code. The difference is every patch costs a few hundred thousand dollars, and of course everyone who wants the patch will have to buy a new chip. This is why over 80% of code written for an ASIC is test/verification code.

Re:No

[Rick Schumann]

Exactly. Also good luck with trying to 'open source' 10nm die fabrication.

Re: No

[Anonymous Coward]

Except if you install a buggy open source software, you have a shot at a patch that fixes whatever makes it dodgy.

As we just learned thanks to Intel, hardware mostly can't be fixed after it goes out the door. That means you need a shitload of QA and qualification to make sure the billion dollar fab isn't turning out crap.

Re:No

[toonces33]

Just 3-d print the things.

Re:No

[K. S. Kyosuke]

That's technically what the fabs are doing, though.

Re: No

[Anonymous Coward]

Intel and AMD and...?

Re:No

[sanf780]

ARM does sell synthesizable cores. What synthesizable means is that you can convert that code into logic gates. So you need at least a standard cell library with the fine detail of those logic gates. Memories are not included, as memories are not synthesizable code if you really want a high bit density and low power usage. In order to get data in and out of the chip, you will also need a DDR interface (this is not synthesizable) with also a DDR memory controller (this one is). Add to this one that you need to generate internal clocks, so you might also want to get a few phase locked loop blocks. Recent CPUs also include some sort of dynamic voltage scaling, frequency scaling, thermal protection, etc. You also want to have peripherals connected through SPI, I2C, maybe UART, and maybe you want an interconnect fabric so that the CPU can talk to them. I am sure I am missing a lot of these things.

So, it is not just the CPU core, you need a lot more of things in order to get some product. FPGA manufacturers give you both the hardware and the software to translate the code into something you can upload to that FPGA, and usually give you some freebies like DDR and PLLs. However, there are limitations on what you can get from an FPGA. ICs are the way to go if you want to be on the bleeding edge on either performance, price or power efficiency. And as far as I know, the tools to do ICs in advanced processes like 10nm are not either free to use or open source. They are probably also a patent field. At the end of the day, you do not want to spend over one million dollars with tools that tell you "USE AT YOUR OWN RISK".

Re:No

[phantomfive]

I know a guy whose entire job is to build clocks in CPUs. That's all he does. He's really good at it.
I mention that to give you an idea of the specialization that has taken place in the hardware industry. In Software, you can still be a full-stack developer. In Hardware, those days are past.

Re:No

[K. S. Kyosuke]

Of course it's much more complex that that. But to say that IC design - especially CPU design - "isn't something you can do in your spare time" is clearly not true. At least substantial portions of the design process are something people could do in their spare time. Skills and education are a much more prominent entry barrier there. The lower level details, yes, that's still a problem. Physically dependent lower-level details such as voltage and power control even worse. I guess it all depends on your expectations. For some designs, the latter things may not matter so much.

Re: No

[PoopJuggler]

I now have this image in my mind of tiny little cuckoo clocks chiming away inside CPUs.

Re:No

[Pulzar]

Clock guys are like driver guys... the stuff they write and develop is quite a bit different from everything else.

The guys who work on caches, decode, fetch, etc. are all fairly interchangeable, if you've got a good architect to direct and oversee the work.

Re:No

[TooManyNames]

Yeah, no. That's very, very wrong.

Much of a processor can be designed in RTL (the type of code you could open source), but there are critical components (as in, CPUs do not function without them -- at all) that require detailed knowledge of the underlying process. Any sort of clock distribution, selection, skewing, or balancing, for example, pretty much requires not only detailed knowledge of the types of gates available in process libraries, but also exhaustive simulations across all kinds of different timing scenarios to ensure that designs work as intended. Additionally, these types of circuits are not trivial to design, and they're often tightly integrated into the rest of a design in a way that isn't exactly modular (as in, even if there are separate clocking modules, design assumptions make removal or modifications of those clocking modules quite difficult).

Maybe you could get away with an open core on an FPGA, but if you do that, you're going to sacrifice a lot in terms of performance -- as in getting at best into the 100s of MHz range compared to GHz for an ASIC. Moreover, you're not going to squeeze multiple cores and huge caches onto a single FPGA, so you'll need some sort of stitching to get anything even remotely close to your most basic Intel off-the-shelf processor.

Basically the best you'll be able to say with a purely open source CPU is, "buy this for 10x the cost and at 1/10th the performance... but you can feel good that it's open source." At that point, all I can say is, "good luck with that."

Re:No

[NicknameUnavailable]

You mean IC manufacturing? I'm pretty sure design is largely independent.

Well, I'm pretty sure you're an idiot. I also know only one of us is right in our certainty. Chips average about a million dollars per prototype run. You can simulate things and have them work flawlessly, but you still have to manufacture a masks, run through the steps of chip fabrication, then do your tests to see if it even remotely works. On the scale of GHz with nanometers of precision things happen like inductive and capacitive effects you can't properly simulate but will utterly fuck over your design. All of hardware development is like that, and there is very little open source hardware (depending on your quality standards you might even argue there is none.) IC design is the apex of painfully-expensive-hardware-design.

Re:No

[malditaenvidia]

What are the odds of IBM giving away POWER? Is the architecture susceptible to the same vulnerabilities?

Re:No

[Anonymous Coward]

I knew a guy who's entire job for over a year at HP was to *route* the clock signal across a single chip (this was on the Superdome chipset).

Yes, anyone can design the basic ISA logic of a chip. But it takes *huge* teams of people to design a *good* chip with all the modern features that we seem to take for granted such as variable clock and power states, or even more complicated letting them vary across different portions of the same chip. Not to mention coordinating the design and validating the DRC against the manufacturing process.

There's a really good reason that CPU chip design is only done these days by a very small handful of billion dollar companies with billion dollar budgets. These designs are very complicated and it's no wonder that they keep the IP--they've invested a *lot* to develop it.

Trivializing it by suggesting that an open source development model could equal or best these products is a tad naive. Unless we were living in a Star Trek economy and there were a few thousand contributors working on it full-time (the same size workforce as these big vendors), I don't see any chance of a competitive result.

Re:No

[thegreatbob]

As I don't think it has been mentioned in this thread, AMD has been fabless for the better part of a decade.

Re:No

[Riceballsan]

To get the ground going on software, you need a smart coder, a computer good enough to run it, and a boatload of free time, if you treat your time as worthless, the high end of the cost is probably in the tens of thousands of dollars. Developing microscopic computer chips... you'd likely need billions of dollars worth of equipment, not to mention a huge team of people specialized in the extreme levels of multiple fields.

Re:No

[hcs_$reboot]

Yes. But it'll be 100 times slower.

Re: No

[Anonymous Coward]

is this like leakage from 4chan or something?

Re: No

[aglider]

Why not? Why not trying?

Re:No

[Anonymous Coward]

Have a look at this and stop spouting nonsense.

You sound like Billy Gates a couple of years ago, as he said "Ummm. Kernel, that's easy. But the Open Source[1] movement won't ever be able to come up with something as complex as a web browser" -- this was a couple of years before Mozilla wiped the floor with his Internet Explorer.

Idiots gotta idiot. I guess.

Remember: there's already one RiscV on silicon out there (SiFive), and the other one (much more ambitious) is not far, judging by the people behind it and their commitment.

Re:No

[AmiMoJo]

There are plenty of open source cores out there. Unfortunately we lack good enough free tools to synthesise really good ones into viable hardware. Basically we don't have a good free compiler.

Re:No

[Anne Thwacks]

Luckily, the Chinese are here to help:

Loongson produce a MIPS (open source) based CPU with an open source BIOS, and laptops are available. They just need a new iteration to get the performance up to near western standards, and make a ton of them. There are laptops available too! (Just not in the West).

Re: No

[chthon]

I am busy desiging a CPU using the Spartan-6 FPGA. The problem with designing a CPU on an FPGA is that you need to learn the strengths and weaknesses of FPGAs.

Coding a simple CPU in VHDL is indeed possible. And I have been able to build a 230 MHz CPU. Unfortunately, that was with up to 8kB of memory. When using larger memories, there is a big delay involved.

The problem with FPGAs is that there are big interconnection delays. So I am now re-designing the system using a cache and pipelining. But I am still busy on the instruction fetch part: main memory, cache and IF, and the system is not even 32 bit, only 16 bit.

Re:No

[TheRaven64]

Actually, it is. IC design is now pretty cheap. IC fabrication, on the other hand, is incredibly expensive, especially on a recent process and especially on low-volume runs.

The reference RISC-V designs are written in Chisel, which is a Scala-based high-level HDL. The Berkeley guys have taped our versions of it at over 1GHz, but only because they have really good deals with some fabs that want Berkeley graduates to go and recommend them to whatever company hires them. Most of the same pipelines are used by BOOM, which is an out-of-order implementation (and is probably vulnerable to Spectre).

Re:No

[TheRaven64]

No architecture is vulnerable to Spectre. It is a microarchitectural vulnerability. Any core that performs any speculative execution (i.e. anything pipelined that's not a DSP or GPU) is going to have some side channels related to speculative execution and anything with an out-of-order pipeline will likely be susceptible to Spectre / Meltdown-style attacks (they're not the first side-channel attacks on this kind of thing, but they're worrying because previous ones have let you extract a bit every few seconds, whereas these can run at around 0.5MB/s, making it feasible to scan all of physical memory in a fairly short amount of time).

Re:No

[BlueStrat]

Luckily, the Chinese are here to help:

Loongson produce a MIPS (open source) based CPU with an open source BIOS, and laptops are available. They just need a new iteration to get the performance up to near western standards, and make a ton of them. There are laptops available too! (Just not in the West).

You mean i can finally have a MIPS-based laptop to match my MIPS-based SGI Octane desktop? Will it be as fast as the Octane? Will it run IRIX UNIX too? :)

Strat

Re:No

[lkcl]

You mean IC manufacturing? I'm pretty sure design is largely independent. If it weren't, ARM wouldn't be able to sell synthesizable CPU cores.

in a traditional environment it takes around 18 man-months to design (and formally test) around 3,000 gates. it's pretty insane. 3,000 gates is about the size of a RISC Core. look up the numbers for an Intel processor (number of transistors - yes many of those are in the cache) - and you get an idea of just how much work is involved.

also, the actual layout (like a PCB only for transistors and tracks etc.) by automated tools tend to be... well... rubbish, basically. which means that much of the design has to be done by hand, with assistance from tools to assess things like parasitic capacitance (so that you can minimise it... by hand).

it's not a straightforward process, basically.

Re:No

[Bert64]

Depends on how much of a head start someone will give...
SPARC is relatively open and oracle seem to have lost interest in developing it, perhaps they would donate the latest designs to the community...
IBM have been pushing POWER as an open design too?
There's also abandoned architectures like IA64 and Alpha.. An Alpha EV7 built on a modern fab process and clocked a bit higher could work well, and they did have unfinished designs that were going to be among the first multicore chips (https://en.wikipedia.org/wiki/Alpha_21464)

Re:No

[Bert64]

I was looking at these a while ago, and tried to get hold of one... Even went so far as to get a chinese speaking friend to contact them directly, but to no avail.

Re: No

[Bert64]

The world is becoming more paranoid, governments are starting to worry about foreign influence...
The US has already banned Russian antivirus software, do you think the Russians are especially happy about using processors designed in the US and manufactured in China, running software also written in the US?
Larger countries like Russia, China and the US can afford to do things inhouse, but smaller ones can't and an open collaborative model is the next best option. Even for larger countries, it's much cheaper.
So you'd have not just large cloud providers, but also governments potentially contributing towards open hardware.

Re:No

[jellomizer]

Linux systems are a collection of a bunch of small programs. That is why it can work for open source. Ideas can be forked new methods can be tried...
most distributions like Red Hat just glue together all the open source apps into a full OS. I am not saying this is easy and not impressive. But for a chip designed it requires man hours of unified work. No compromises like if we should have vi or emacs of just putting both on there. You pick one and give no option to upgrade to the other.

Re:No

[Anonymous Coward]

Dude, designing and even fabricating IC's is hobby stuff these days. I remember when slashdot used to post stories whenever somebody implemented a CPU in minecraft for christsakes, but these days ADD addled children are doing it in every sufficiently moddable game engine and nobody is impressed. Meanwhile the retired greybeards are handwiring them out of copper nails and transistors.

Re:No

[SurenEnfiajyan]

By selling the chips.

Re:No

[religionofpeas]

It's certainly possible to design a CPU in your spare time. I've designed a couple myself.

Designing a modern Intel CPU replacement is something else though. That's a lot of man years of work, and most of it is in tedious work like testing and validating that very few people find joyful.

Re:No

[mikael]

https://micro.magnet.fsu.edu/c...

Re:No

[toonces33]

IA64 in many ways was a very elegant architecture, but to really get the best performance out of it, one demands a lot of the compilers, as it is their job to do the optimizations.

The thing that really doomed IA64 was poor performance of x86 emulation. And while all this talk of alternate on architectures is a trip down memory lane, you *know* that x86 emulation is going to be one of the first things that people ask about.

Re:No

[AmiMoJo]

Maybe we don't need to replace the main CPU, just add a second one that handles secure stuff for us. Performance doesn't need to be as good if it is only managing secrets and does some crypto, i.e. the stuff we are worried about being stolen.

That's basically what a lot of these CPUs do anyway, with things like TrustZone and Intel's management engine stuff. The difference will be that it's under our control.

Re: No

[Anonymous Coward]

Sure, go ahead.

But there isn't really any point in open hardware unless you intent to run open software on it too so there is not really any reason to go for the x86 architecture.

You can grab something from OpenCores if you don't want to start from scratch.

Have a look at the Amber project.
Presumably it should be able to boot Linux, but without MMU support.

Re:No

[Anonymous Coward]

What are the odds of IBM giving away POWER? Is the architecture susceptible to the same vulnerabilities?

Pretty good:

* https://en.wikipedia.org/wiki/OpenPOWER_Foundation

The summary mentions, OpenSPARC as well. Sun at least released a lot of stuff under GPL license:

* https://en.wikipedia.org/wiki/SPARC#Open_source_implementations

POWER only has one major vendor (IBM), while SPARC has (at least) two--Oracle and Fujitsu--and you can still license it:

* http://sparc.org/faq/#q3

Licensing is free, it's just that if you want to use the "SPARC" trademark you have (a) be member of the above foundation and (b) your product has to pass the compliance tests.

Re: No

[Anonymous Coward]

According to you Linux is either impossible or not modern. I remind you that many people are getting paid for developing Linux. Many companies also benefit from Linux.

Re: No

[Anonymous Coward]

This is where AI and evolution algoriths come into the picture.

Re: No

[Anonymous Coward]

"developing Linux"? umm...huh?

Re: No

[Anonymous Coward]

Yeah it wont happen.

At the time when other archs had peformance advantages it did not really matter becus most software had better optimizations for x86 and THE other arches often only got some generic code path.

Today with the huge librarys optimised for x86 i cant even imagine the amount of man houers needed before a new or old architechture would be able to compete.

It would most likley never be cost effective.

Re: No

[Anonymous Coward]

This isn't even close to correct. If it is taking you 18 months to prove a 3000 gate design works, then your methodologies are horrible.

Re:No

[Anonymous Coward]

This is why I no longer value slashdot user's moderation.

Re:No

[K. S. Kyosuke]

And yet, Charles H. Moore was able to do all that single-handedly, for fairly performant chips, including extensive physical-level simulations that actually predicted the silicon outcome well enough for those chips to just work. And did the design and simulation with tools he wrote himself in his spare time. Surely it's more complex than that if you need lots of standardized interfaces, but, hey, we didn't assume replacing those, I hope. Likewise, if your feature set requirements are greater, you'll obviously need a bigger team, but you have a whole world to work with. Ultimately, I'm convinced it all boils down to organizational skills: you need a "Hardware Linus". Without organization, any such effort would fail. One can only hope the RISC-V people have what it takes.

Re:No

[K. S. Kyosuke]

If you meant an x86 chip, I most certainly hadn't *that* in mind. That would be a whole another level of complexity, and maybe even a misguided effort. I was thinking more of what Alan Kay and his pals are working on for the computing machines and systems of the future.

Re:No

[K. S. Kyosuke]

in a traditional environment it takes around 18 man-months to design (and formally test) around 3,000 gates. it's pretty insane.

So you're basically saying things haven't changed since 1985 when the ARM people designed ARM1 roughly at a similar speed of design, in terms of gates per man-hour? That's rather disheartening to hear.

Re: No

[Anonymous Coward]

Well, you could in theory create a development team using the apache model--a bunch of companies field some developers onto a shared project. However, this is a *large* endeavor. Yes, on par with Linux or X.org in scope. It takes a lot of time to build these teams. Hardware projects like these aren't as easy to just jump in and start contributing as software projects can be. (I realize that big projects like Linux and X.org are *not* easy to just jump in and start contributing to--so there's a reference point for you).

The manpower to develop anything can be funded from any model--so long as it can see the project through to the end... the trick is of course convincing enough people/companies to accept whatever chosen model and actually do it.

Re:No

[K. S. Kyosuke]

I knew a guy who's entire job for over a year at HP was to *route* the clock signal across a single chip (this was on the Superdome chipset). Yes, anyone can design the basic ISA logic of a chip. But it takes *huge* teams of people to design a *good* chip with all the modern features that we seem to take for granted such as variable clock and power states, or even more complicated letting them vary across different portions of the same chip. Not to mention coordinating the design and validating the DRC against the manufacturing process.

And yet, this whole guy might have been avoided by employing something like asynchronous logic. And likewise, variable clock and power has been in the past avoided in some asynchronous designs merely by employing an asynchronous design. Now I'm aware that the software tooling is deficient these days for such designs, but I wonder if that isn't a chicken-and-egg problem. My understanding is that at least the past asynchronous designs were shown to be rather promising - performant, low-power, noise-resilient - maybe even somewhat more resistant to timing attacks, perhaps?

There's a really good reason that CPU chip design is only done these days by a very small handful of billion dollar companies with billion dollar budgets. These designs are very complicated and it's no wonder that they keep the IP--they've invested a *lot* to develop it.

But there's a nasty question right there. Is that accidental complexity or intrinsic complexity? If a large portion of that complexity is accidental - and things like backwards compatibility with ancient PCs and even with ancient programming languages can easily induce a lot of it - then the argument becomes much less relevant. You need all that complexity to run a single thread of instructions at high speed? Maybe, but would you, e.g., need similar complexity to run a system written in an actor language? How did we screw things up so badly from the elegant systems of the 1980s to paint ourselves into a corner like this? Did the cheap workstation/PC revolution bite us in the ass here?

Re:No

[Anonymous Coward]

Neither you nor the guy above you have even a basic idea of what die fabrication entails.

Re:No

[K. S. Kyosuke]

I've commented on it above. Yes, as you go down, you need process details. A nasty part of that is that unlike in the past, fewer and fewer details of the physical processes are openly available to begin with. That's the one obvious obstacle to any kind of independent design. I'm not sure how far one can go with independent design rules these days.

Re:No

[K. S. Kyosuke]

So you mean the fabs are NOT additively manufacturing a piece of pure silicon into a piece of doped silicon with additional SiO2, Si and metallic structures by means of epitaxy and other kinds of material deposition? I guess they just shove the magic smoke into a package and it works...

Re:No

[Anonymous Coward]

I'm responsible for a certain function in my employer's CPUs. I'm the architect and I write the HDL and spend 90% of my time developing hardware test algorithms and test structures for test chips, so make sure it works in future silicon.

It's interesting and rewarding work, but it is less that 0.01% of a desktop CPU die.

People who think CPU design is basically just designing an instruction execution engine are hopelessly ignorant of all that has to go on in a modern CPU so that it works as you would expect. It takes many thousands of people because that's what it takes.

Re:No

[TechyImmigrant]

>And yet, this whole guy might have been avoided by employing something like asynchronous logic.

No, no and no again.
Asynchronous logic looks great on paper. It is not great in silicon. It's been tried many times and everyone who tries concludes it's not just the lack of tools - It's that async logic is not a tractable solution. It will always be slower and bigger than synchronous. It's impossible to validate.

Modern CPUs are synchronous islands in an async fabric. This is normal and is a good engineering tradeoff.

Re: No

[aglider]

I cannot find any reference to FPGAs into the upstream answer I was commenting to.

Re:No

[TechyImmigrant]

Modern CPUs are a mix of APR (Automatic Place and Route) and hand layout. The cores, memories, clock trees, IO, PLLs and so on tend to have the hand layout. The logic that's not running at core speed tends to get APRd.

I don't think the 18 months per 3000 gates is really accurate. The number of gates for a thing does not vary linearly with its complexity. A complete new 100K gate design might take 6 months to validate sufficiently to put in a product, but you wouldn't rely on it. Once it's proven in silicon, then you are in a better position to rely on it.

We do a lot of test chips so the building blocks are well validated before going into products.

Re:No

[K. S. Kyosuke]

Funny that it seemed to work for AMULET and stuff. I'm wondering, though, when you say "not a tractable solution" - is it *proven* to be untractable or we just haven't found any way to deal with it (in an analogical way to the one in which Dijkstra suggested to embrace (bounded) non-determinism in programming)? I know that Furber once wrote a book on it but I have no idea if the field has moved since then. I also assume that fab process changes might have disadvantaged it further still since a large part of those older designs' performance relied on not switching needlessly, but today you seem to see power-gated domains instead, so there's that.

Re:No

[DontBeAMoran]

Not sure about 10nm, but E3D did release a 0.15mm nozzle a while back...

Re:No

[DontBeAMoran]

Yes they do. That's why products such as these exists.

Re:No

[Anonymous Coward]

Basically the best you'll be able to say with a purely open source CPU is, "buy this for 10x the cost and at 1/10th the performance... but you can feel good that it's open source."

How much is your security worth to you?

Re:No

[NicknameUnavailable]

No, that's not even close to what that guy did. A "performant chip" at the scale of 1980's tech doesn't even work on a nanometer scale. Anyone can feasibly make a chip with micrometer scale (cutting edge for Moore's time was 3um) transistors, which won't be able to do dick by modern standards. When you talk about designing an open hardware spec you are implicitly speaking of a design which is interchangeable with modern hardware, which in this context means 12nm (at absolute most) or less scaled transistors. Just to test your prototype you need special machines to construct the mask, or a million dollars to give to a fab for them to make it for you (for every fucking prototype.) Unless you have a billion dollars laying around that you are willing to risk for the purpose you aren't going to be designing an open hardware chip that works. Keep in mind AMD and Intel recycle components in addition to all of that - e.g. from one chip to the next they might add a new module or replace an existing one or just try to scale down to smaller transistors and add more cores. If you took the complete R&D process leading up to that, even excluding everything that isn't "start from ground zero but with all the knowledge we currently have, so there's no iterative cycle," then you'd be looking at a billion minimum (and that only gets you about 1,000 tests - think about it this way - could you write an enterprise class piece of software applicable to literally every industry on Earth, get it right without the hope of ever patching it again, and do it without hitting the "debug" or "build" buttons more than 1,000 times? That's hardware design.)

Re:No

[Anonymous Coward]

I knew a guy who's entire job for over a year at HP was to *route* the clock signal across a single chip (this was on the Superdome chipset).

Jesus. I would have just built that into the chip. Poor guy.

Re:No

[Bert64]

It would make Intel and AMD file lawsuits against whoever was making the clone chips, while also charging more to cover the cost of the lawsuits. Only the lawyers would benefit.

Re:No

[Bert64]

Well in that respect Alpha (FX!32) and PowerPC (VirtualPC) had much better x86 emulation, which is tried and tested...

Alternative architectures will never shine so long as people are trying to run alien binaries on them... Emulation will always carry overhead, resulting in inferior performance and inferior battery life.

That said, the playing field is levelling... The Android runtime is theoretically cross platform, so many apps will run just fine irrespective of the underlying architecture, and a lot of software is now delivered via a browser or a connection to a remote server...
And of course anything that is open source can be fairly painlessly ported to a new architecture, and indeed all the mentioned architectures already have mature Linux and/or BSD ports and a full suite of software available.

Re:No

[K. S. Kyosuke]

A "performant chip" at the scale of 1980's tech doesn't even work on a nanometer scale. Anyone can feasibly make a chip with micrometer scale (cutting edge for Moore's time was 3um)

Uh, 3 um? Did I miss something? Moore got down to 130 nm with his recent designs (asynchronous 130 nm designs with picojoules per instruction performed, in fact). Mostly likely because of fab costs, I presume. For his purposes, it wouldn't make sense to go lower anyway.

When you talk about designing an open hardware spec you are implicitly speaking of a design which is interchangeable with modern hardware

Not really. Partly because current hardware and software are crap, partly because I care about goals more than about micromanaging the process. I don't really care about replicating what we have now for no apparent reason (why? The best x86 chip is the one you already have!) but rather about achieving what would be possible within a larger-scale VPRI-like project. Chances are that the same goals at least in the area of personal computing which I care most about are achievable through entirely different means. It's very likely, actually, judging from history of personal machines.

Keep in mind AMD and Intel recycle components in addition to all of that - e.g. from one chip to the next they might add a new module or replace an existing one or just try to scale down to smaller transistors and add more cores.

Yeah. Sadly, within a project like the one above, such activities are infeasible. Or maybe not sadly - one consequence of the VPRI approach is that you get to completely avoid them and get a machine not based on brute force.

Re:No

[Anonymous Coward]

Intel played with async design years ago--but that was back when there really was no tooling.

Not asynchronous entirely, per-se, but for several generations of cpus (possibly still current) Intel implemented large portions of their integer unit with domino logic.

The guy I knew at HP, well, he was on the Superdome team--the same team that Intel bought years ago. I don't think they knew exactly how good of a resource that team was--at the time it was the *best* chip design team on the planet. They regularly shipped revision *1* silicon with *0* bugs. This was in large part down to two factors:
1) they had a guy that wrote the most advanced simulation software in the world (at the time)--and he helped them catch lots of bugs very early
2) they explicitly refused a siloed approach. all teams coordinated their efforts through all stages of the design process

#2 is exactly the opposite of Intel's historical approach. Intel, for years, completely siloed all development departments. The "Intel Fellows" would sit in an ivory tower producing designs and tossing them over the wall to the devs who had to implement them (possible or not). The testers would throw requests at the devs for features to help them debug and validate, (but features based on the previous models--maybe not even relevant to the current project since they hadn't seen it yet until the devs tossed it over the wall to them). The devs, up against a deadline to get their own stuff done, of course, leave the test request features for last if at all.

You can see the train wreck happen over and over, just by counting (or weighing on a scale?) the pages of errata ("erratum not bug as Tomshardware calls them") for *every chip* Intel produces.

The difference in these design and management approaches was made evident in the whole IA-64/Merced debacle. It was a joint project between Intel and HP. HP originally asked Intel if they wanted HP to also produce a chip based on the design. Intel said "no, we got it covered." HP internally said, "we'll do our own anyways". Intel's came out late, slow, and buggy. When that blew up in their faces, HP revealed that in the same timespan they had produced one that worked, was faster, and didn't have bugs.

Go HP. HP used to be an excellent company.

Re:No

[DaveV1.0]

But, the solution doesn't scale.

Re:No

[kallisti5]

... or an open source friendly FPGA like the lattice and some genius.

Re:No

[kallisti5]

https://rwmj.wordpress.com/201...

Re: No

[kenh]

Red hat had a revenue model, based on a retail product they charge for, and soon went public based on revenue projections and profit targets.

Do you want to build a new chip company that sells these 'open cpus' at a profit?

Re: No

[kenh]

Remember: there's already one RiscV on silicon out there (SiFive), and the other one (much more ambitious) is not far, judging by the people behind it and their commitment.

Great, a completely new architecture, which means you'll port Debian to it, no one will care, and it will fail to attract a tiny percentage of the fraction of Debian users, who are also but a small fraction of Linux users, who are in turn a tiny fraction of user desktops around the world.

Woo-hoo! It would be much simpler to simply start scavenging old Sun UltraSPARC desktops and running Solaris on them.

Re: No

[kenh]

How much is your security worth to you?

Enough to not trust my personal data & security to random bits of software downloaded from random sites onthe internet.

I don't know what you do on your computer, but personally my desktop or laptop could go tits-up and losexall it's data, and it wouldn't be so traumatic - but I also mail checks to pay bills, don't manage my bank accounts online, and don't keep my SSN or other high value information on my desktop/laptop. My biggest loss would be to have to recreate my resume, and possibly have to reset my Amazon password.

Re:No

[Anonymous Coward]

You know nothing then. A simple look at history would reveal that you're very far off base... for example the first Intel Core processor vs NetBurst... where NetBurst drew a lot more power than the Core processor did using the same process technology, due to differences in transistor designs for the same process. And never mind the crazy lengths the engineers had to go through to make 14nm and 10nm manufacturing work, like FinFETs and all that...

You're also neglecting to account for the fact that it costs several billion dollars to start up even a relatively small modern semiconductor fab.

Re:No

[Anonymous Coward]

What is laser lithography, Alex?

Re:No

[Anonymous Coward]

This guy wants to replace the families (DNA, get it?), behind the development and design of chips as if all people were inter-exchangable, but it is not that easy nor possible. You cannot just throw money around and come up with a new solution to chipology! It requires vocation and easiness to go into it, talent! On the short (and middle) term. This all seems like media anti-hype wanting something different than the usual blame-the-OS approach. So we have bad software programming, now we get bad chip design and manufacturing! See? Business-as-usual, not this disgusting post-XXth Century state of affairs where...

Re:No

[Anonymous Coward]

No klein bottles here, keep moving, keep moving...

Re:No

[KingBenny]

ask Bill Gates xD ... nicely ... he sponsors fucking toilets for poor people , so ... has anyone tried ?

Re:No

[KingBenny]

actually, and don't ask me , if i had that amount of clout i'd be sponsoring people to enhance the zyka virus or make it rain oestrogen at the risk of growing tits, simply to prevent the inbreed locusts from gnawing the planet to a quantum-crisp cos they're clearly not smart enough to realize themselves. Twelve monkeys, baby ... luckily i havent, and im not really interested in that amount, a 100 million will do .. so i can live the rest of my life without worries in a place that hasnt even heard of here without posing an actual threat cos im sure my yap attracts attention
SO DONT WORRY ... i don't have kolwynia

Are you not an idiot?

[Anonymous Coward]

Same answer!

Re:Are you not an idiot?

[Anonymous Coward]

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...

What a fucking retard.

"The Cloud" is nothing but a bunch of private datacenters.

Apparently the position of Senior Technology Editor doesn't require much thinking.

Re: Are you not an idiot?

[Anonymous Coward]

protip: the USA isnot a meriticracy buddy

Re: Are you not an idiot?

[Hal_Porter]

Successful companies probably are. The problem is Zdnet editors haven't gone through the purifying fire of the free market and thus haven't been cleansed of their impurities, like ore in a blast furnace being converted to steel.

Re: Are you not an idiot?

[Anonymous Coward]

ZDNet hasn't even been ZDNet since it was acquired by CNET in 2000 (and CNET was bought by CBS in 2008). Any distinctiveness long ago vanished.

Re: Are you not an idiot?

[Anonymous Coward]

American tech companies are currently undergoing a purge of meritable talent, in favor of judgment by skin, political opinion, and sex.

Re: Are you not an idiot?

[Hal_Porter]

Yup.

Can We Replace Intel x86 With an Open Source Chip?

[Local ID10T]

No.

Sure, that's easy

[Anonymous Coward]

Didnt take much engineering effort or money to develop modern intel processors - this should be easy to do.

Re: Sure, that's easy

[mnemotronic]

Just need a couple dozen people doing it part-time as a hobby, but only if they've got no motivation (like stock options, a VP breathing down their neck or their job) to make it dramatically better, faster, cheaper, smaller and less power consumptive than the competition.

Re:Sure, that's easy

[PolygamousRanchKid]

Didnt take much engineering effort or money to develop modern intel processors - this should be easy to do.

Oh, this will all be designed and engineered using advanced AI technologies. Hiring humans will not be necessary. Hey, AI kicked chip designers out of their jobs. Talk about the revolution eating their children!

This will all be financed by mega-giga high yield cryptocurrencies, so it won't cost any real money, either.

Re:Sure, that's easy

[RightwingNutjob]

You don't even need real silicon, just a shared belief that it exists and that production targets will be met next quarter.

Re:Sure, that's easy

[Bing Tsher E]

Also some Venture Capitalists to buy the expensive office furniture and the Foosball table.

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

[therealspacebug]

How is OpenSPARC vs RISC-V?

I really hope we get one open hardware taking off.

It does not have to replace the existing arcitechtures but could act as a suppliment.

Many people would like something more open now after all ME bugs etc.
Specially in the INFOSEC community and like.

Re:Not sure what you mean by that

[Anonymous Coward]

shouldn't be too hard, microsoft doesn't make a great OS

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.

Re:Not sure what you mean by that

[davecb]

The newest T-series SPARCs were based on two persons' work using a much earlier variant, contemporary with the open SPARC design. It takes brilliance, not huge companies, you see.

Re:Not sure what you mean by that

[Bing Tsher E]

It isn't really 'open source' in the traditional sense, though, if the 'several brilliant persons' would be interrupted if anybody else barged into the design process. And that's just the deal with 'open source.'

Re:Not sure what you mean by that

[TheRaven64]

You can't compare OpenSPARC and RISC-V. OpenSPARC is an implementation of the SPARCv9 ISA. RISC-V is a specification. There are about a dozen open source RISC-V designs now, ranging from simple in-order 32-bit cores to out-of-order superscalar 64-bit cores.

OpenSPARC is the full Verilog implementation of T1 (Niagara) and T2. Unfortunately, both are written in the traditional disposable style of commercial CPU implementations: there are some reusable building blocks, but the general idea is that each CPU design is a complete from-scratch rewrite. Unlike software designs, there's no thought to long-term maintenance or making the designs easier to refactor. Such concerns are often at odds with getting the best possible performance from the current process (the next generation process may have completely different constraints).

In contrast, the reference RISC-V design, Rocket, is written in Chisel, a high-level Scala-derived HDL that can generate Verilog. It is designed to be used to be reusable and this was shown by the Berkeley Out-of-Order Machine (BOOM), which is an out-of-order superscalar design that reuses most of the Rocket core's execution units.

If you just want to send something to a fab now, the OpenSPARC cores are probably better, but if you want to make significant modifications then Rocket or BOOM is orders of magnitude easier to work with. In addition, the RISC-V ecosystem is growing, whereas the SPARC ecosystem is contracting or dead.

Re: Not sure what you mean by that

[kenh]

And did those two guys go from specifications to silicon without the help of hundreds, upon hundreds, of engineers?

I think not.

Re: Not sure what you mean by that

[davecb]

No, they stood on the shoulders of the work of the engineers who came before them. And yes, there were hundreds in the history of the project, just not all at one time. SPARC started out as the "Berkeley RISC" project, which also had two leading proponents, David Patterson and Carlo Séquin, qv.

Re:Not sure what you mean by that

[ebvwfbw]

And my understanding is they're probably fired by now. Oracle fired around 80% of the SUN people.

Re:Not sure what you mean by that

[davecb]

Sure, but the question was could the community produce something as good at those two guys? Bearing in mind that the community still includes folks like David Patterson and Carlo Séquin, I think that's trivially true (;-))

Why?

[Anonymous Coward]

Open source hardware is tricky and not really analogous to open source software.
With open source software, anyone with a compiler can build their own software without the need for external involvement. It's far, far more complex and difficult when dealing with open source hardware. People generally don't have the ability to manufacturer their own chips, especially with the processes necessary in modern processors. While I support more openness about the hardware and it's functionality (especially the ME and equivalent systems), and I support giving the user more control over their hardware, open source hardware just won't work in this instance.

Of course we can!

[cheesyweasel]

What version of DOS would you like to run on it?

Re:Of course we can!

[Anonymous Coward]

Maybe Gnu Hurd

Re: Of course we can!

[Anonymous Coward]

Even running DOS is asking too much, given the x86 nature of it.

Re:Of course we can!

[Anonymous Coward]

There is no DOS for SPARC.

Re:Of course we can!

[kaizendojo]

The Year of the Linux Desktop: {insert year here}

Re:Of course we can!

[Anonymous Coward]

FreeDOS?

Re:Can We Replace Intel x86 With an Open Source Ch

[Anonymous Coward]

Me being Devil's advocate: Yes.
I'm so going to hell for that.

The law of lame Slashdot question posts continues.

[Anonymous Coward]

Seriously, look at the last 20 Slashdot posts that end in a question mark. The answer is always NO.

High, so very high

[Anonymous Coward]

you must be

The onboard L1 L2 cache designs alone would take years of effort to produce fully custom, multi-GHz physical designs. This effort isn't about writing some pretty Verilog/VHDL.

How does an open source chip solve the problem?

[JoeyRox]

Being open source doesn't magically prevent bugs from reaching the silicon stage of a chip's design, nor does it make it any easier to fix bugs baked into a completed design. There are only so many people in the world smart enough to even fully understand modern superscalar designs let alone contribute usefully to it.

Re:How does an open source chip solve the problem?

[iggymanz]

indeed, at least one of the chips mentioned has issue. Still waiting for someone to fiddle with Power8 and UltarSparc to see if it has issue. Itanium is claimed not to, haven't heard of evidence to contrary yet.

Re:How does an open source chip solve the problem?

[StormReaver]

There are only so many people in the world smart enough to even fully understand modern superscalar designs let alone contribute usefully to it.

I remember those same arguments being made about why an Open Source video driver was impossible. But now, all of my video card purchases are AMD solely because of the fantastic Open Source driver. Also, the same thing was said about Linux for a LONG time. But now it completely dominates everything but the desktop, and that is almost entirely because of vendor lock-in.

The more FOSS you use, the less the platform matters. All of the software I use is FOSS, and the vast majority of data center software is FOSS. As such, the CPU architecture won't matter much.

Re:How does an open source chip solve the problem?

[Nemyst]

Itanium handles speculation so differently that it's unlikely to be vulnerable. IBM has released an advisory indicating that Power7+/8/9 are vulnerable to some extent (they don't distinguish between Meltdown and Spectre) and that patches would be rolling out soon.

Re:How does an open source chip solve the problem?

[Anonymous Coward]

That's not true. Microprocessor architecture, notably superscalar designs, are a standard part of computer engineering courses at the BS level and it's not uncommon to have students designed pipelined and superscalar processors as lab assignments. The concepts aren't that difficult to understand.

The only difficulty is in financing the fabrication, distribution, and support of such a CPU. It takes a lot of money and a very deep supply chain which the giants like IBM and Intel have spent decades building it up.

Roughly speaking "anyone" can make a CPU, and put a fully functional one on an FPGA without needing a foundry or even silicon-level design knowledge. Making something you can get off a store shelf is a huge endeavor financially speaking.

Re:How does an open source chip solve the problem?

[JoeyRox]

Agreed, but what does matter is designing CPUs to be fast and efficient, which involves many different disciplines and skillsets, some of which are highly proprietary on the manufacturing side of the equation. That's what's hard.

Re:How does an open source chip solve the problem?

[iggymanz]

I also saw RedHat's statement that the power-based chip used in Z series mainframes is vulnerable.

Still looking for definite word on Sparc which is now done by Fujitsu

Re:How does an open source chip solve the problem?

[quantaman]

There are only so many people in the world smart enough to even fully understand modern superscalar designs let alone contribute usefully to it.

I doubt that's true.

The problem wasn't the lack of people smart enough to spot the bug, it was the fact the bug was created 20 years ago back when people probably weren't thinking about bugs like that. And then in the 20 years since there probably weren't many people with a reason to start digging into that level of the design.

I'm not sure open source would have made a big difference, it gives you more eyes in some cases, but as OpenSSL demonstrated people only read the code they change, so old code that "just works" tends not to get looked at too closely.

Re:How does an open source chip solve the problem?

[FithisUX]

There are only so many people in the world smart enough to even fully understand modern superscalar designs let alone contribute usefully to it.

These sentences make me say a big YES. It is imperative to replace current CPUs with something open source, peer reviewed by many eyes and understandable, even if it is slower, less power efficient and bigger.

Re:How does an open source chip solve the problem?

[lkcl]

Being open source doesn't magically prevent bugs from reaching the silicon stage of a chip's design, nor does it make it any easier to fix bugs baked into a completed design. There are only so many people in the world smart enough to even fully understand modern superscalar designs let alone contribute usefully to it.

interestingly the head of the shakti team, madhu, is an advocate of something called "bluespec". it's similar to Berkeley's "chisel" except that, because bluespec is writteen in Haskell it's possible to do *formal mathematical proofs on the designs*.

there was a talk at ccc just last week about doing mathematical proofs on designs, but it's much harder to do if the underlying programming language for the ASIC doesn't really support formal proofs.

anyway, this is extremely interesting timing as i am, puzzlingly, in a position to be the go-between to actually get this done http://rhombus-tech.net/riscv/...

Re:How does an open source chip solve the problem?

[Anonymous Coward]

Here's a nice handgrenade

1. CPUs are too complicated. They need to be simple.
2. Lots of the work implementing CPU designs (if not designing them) will be subject to AI.

Intel, for example, has relentlessly pushed more complexity in their CPUs - when what was needed was simplicity. Intel wants to control and swallow everything. If you want another example, see UEFI.. which is an Intel clusterfuck intended to wrap a machine in an Intel controlled layer. When you run Linux on your recent PC, there are 2.5 kernels running under it at higher priority levels - all closed, all guarded by private keys that only Intel knows and that it grants access via to government - thanks Intel.

You're seeing the cost for all this bullshit now.

Re:How does an open source chip solve the problem?

[Anonymous Coward]

There's this delusion that "the wisdom of crowds" will solve everything. It's silly, the best brains in CPU design already work on it, and they missed it.

And the "but muh open source! Backdoors!!" is pretty silly too. How in God's name would one verify that the design they are looking at is actually what got sent to the fab and what came out the other end? You couldn't.

Re:How does an open source chip solve the problem?

[Anonymous Coward]

That s the DNA you have to throw away and not let extend... | -|(

Power9 is a pretty good candidate

[Anonymous Coward]

Yes, look at IBM's Power9-based Talos Workstation. It has open firmware, open microcode, open BMC firmware so pretty much all of it is auditable. Is it secure? Who knows...

The downside is obviously the price.

Repositories:
https://git.raptorcs.com/git/
https://github.com/open-power
https://github.com/openbmc

Re: Power9 is a pretty good candidate

[iggymanz]

It also has speculative execution bugs, as does every power7 through 9 chip. Thanks for playing though.

Re: Power9 is a pretty good candidate

[Anonymous Coward]

The difference being that this time we don't have to trust on a single institution to make the fix...

Re: Power9 is a pretty good candidate

[iggymanz]

we've already proven that 10,000 eyes won't find shallow bug after decades. Even speculative execution as laid out and taught theoretically 20+ years ago would have been found to leave trails in caches but no one thought of that (that was believed, heh)

and there is no way in hell the open source community can design any kind of chip you'd want to use with even Pentium II level specs, people take classes in basic architecture and then think they know what a current intel CPU is like...they have no fucking idea, it's the difference between a 19th century steam engine and a turbofan.

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:The law of lame Slashdot question posts continu

[Anonymous Coward]

https://en.wikipedia.org/wiki/...

Re: Can We Replace Intel x86 With an Open Source C

[Anonymous Coward]

There are places where open source could work. Certainly opening up the ME and the AMD equivalent is a place where open source could succeed. I suppose you could also develop an open source microcode. These give the user more control over the hardware, and I think it really would be beneficial for the ME to be opened up. However, these are really still examples of software, just at a lower level and with greater control over the hardware.

Anyone with a computer can run a compiler and build their own software. However, the manufacturing processes involved in creating modern microprocessors mean that virtually no ordinary user has their ability to go and create their own processors. Sure, you can comment on the specifications and design your own if you so desire, but you remain at the mercy of the manufacturer. You can definitely make your own custom build of open source software, but no manufacturer is going to be able to charge an affordable price and let you make just a few processors. It's going to be very expensive unless you're making a lot of chips and scale the process up.

Re:The law of lame Slashdot question posts continu

[DontBeAMoran]

Do the last 20 Slashdot posts really end with a question mark?

Not an issue of having the IP

[rkordmaa]

Not every semiconductor foundry can make a modern CPU, you can get your hands on latest i7 IP but only Intel will have the foundry with equipment to make a equivalent chip out of it. When moore's law truly flattens out then rest of the semiconductor manufacturing might catch up and difference between a CPU and CPU will truly be just the IP.

Re:Can We Replace Intel x86 With an Open Source Ch

[ClickOnThis]

No.

I lean towards "not yet."

The fab cost is too high for a small company to take on. So for now, we are beholden to the Intels, AMDs, ARMs, IBMs, and so on.

There is OpenSPARC, but it lost mindshare to the x86 architecture and is unlikely to be a major player going forward.

I would see an open-source chip dominating if one of the major x86 players got the open-source religion, either because they saw a strategic advantage, or they were forced by other circumstances. But I'm not holding my breath.

Open Source Processor?

[Anonymous Coward]

Yes. It's possible. I plan to do it. Problem is I only have like 0.0001% of the money required to actually make one. (fabs are kind of exepnsive) Well I'll keep saving up!

Re:Open Source Processor?

[Anonymous Coward]

Dude, if you can't afford, then you should be investing that money in bitcoin!

Look at the introduction date for CPUs

[Hal_Porter]

To a reasonable approximation all patents must have been filed before then - as soon as details are published they cannot be patented. Post 1995 lifetime of a patent is 20 years.

So anything 20 years or older must be patent free. I.e. anything before 1998 or so should be fine. Oddly enough that means that the original 386 instruction set is OK. So is MIPS.

SSE etc is not though

Intel published a helpful chart of when each SIMD instruction set was patented

https://arstechnica.com/inform...

Since x64 requires SSE2 which was patented in 2001, there's still a bit of life in x64 patents. Also practically modern x64 and x86 applications probably all use more recent SIMD instruction sets and may not run on a chip which doesn't implement them.

Re:Look at the introduction date for CPUs

[Antique Geekmeister]

Sadly, thee is a trick to work around the 20 year patent limit. Patent a subtle feature of the old design, and if necessary tune the new patent to be more applicable to modern tools. This is an old practice with software patents, still in use by companies that create defensive and competition stifling suites of patents. A review of existing tools for patentable material is standard practice for a skilled patent attorney.

Re:Look at the introduction date for CPUs

[Hal_Porter]

Sadly, thee is a trick to work around the 20 year patent limit. Patent a subtle feature of the old design, and if necessary tune the new patent to be more applicable to modern tools.

I could see drug companies patenting a 'modified release' version of an old drug which is going out of patent. Still the non 'modified release' version still enters the public domain.

What I can't see is how you can do this for a documented CPU ISA. You could patent the details of superscalar or out of order execution. However doing that is actually creating a new invention.

Intel keep adding new instructions - SSE, AVX etc - but then those are actually new inventions too.

Re:Look at the introduction date for CPUs

[Anonymous Coward]

You don't have to speculate.

Prilosec brand name for Omeprazole, which is normally used for acid reflux, was replaced by Nexium brand name for Esomeprazole, that is also normally used for acid reflux.

Re:Look at the introduction date for CPUs

[TheRaven64]

It's also more difficult for an open source design. CPU makers generally don't bother too much patenting microarchitectural features, because it's very expensive to stick a competitor's chip under an electron microscope and get enough evidence to convince a court that it's actually infringing. For an open source design, you have access at least to the RTL and so can see very easily and cheaply whether it's infringing. If you wait until your competitor has taped out before sending your C&D, you can maximise their costs.

Re:Look at the introduction date for CPUs

[Hal_Porter]

I bet Intel and AMD pay someone to decap the chips, take die photos and do competitive analysis.

Interesting thing is if you do a search for patents on OOO and superscalar they're all rather old. E.g. This is from 1996. Which means it has expired.

Out-of-order superscalar microprocessor with a renaming device that maps instructions from memory to registers US 5838941 A

Re:Look at the introduction date for CPUs

[Hal_Porter]

Somewhat O/T but it turns out you can download the classic Computer Architecture : A Quantitative approach 5th edition, grey market PDF edition for free.

Re:Look at the introduction date for CPUs

[Antique Geekmeister]

For medication, and for software, the old version is no longer produced. The "tuning" is heralded as a new feature, if necessary, and sold on that basis, to replace the old version for new users. The relevant new patent is invalid at its core. But proving a patent invalid in court is a difficult and expensive proposition. The new, fundamentally fraudulent patent is used as an anti-competitive measure.

I'm not suggesting that this is the major software patent portfolio of, for example, Intel. But I am suggesting that it's a common practice to review older in-house technologies for patentable features and manipulate the patent system to get new patents for existing or new product lines.

Re:Look at the introduction date for CPUs

[Hal_Porter]

In the drug case suppose you make a Prozac ER which releases the drug more slowly. The original company will stop making Prozac but other companies are allowed to make the generic version. They can't make the ER version.

Re:Look at the introduction date for CPUs

[TheRaven64]

I bet Intel and AMD pay someone to decap the chips, take die photos and do competitive analysis.

With a modern process, trying to figure out exactly what is happening is incredibly difficult. AMD and Intel don't care what the other is doing, because they have cross-licensing agreements for most things. They care about companies that are making exact clones with stolen copies of the masks, but these are pretty easy to spot. Telling if a branch predictor includes a particular technique that you've patented from a gate-level layout (even if you can get an accurate gate-level description from the decap'd version) is basically impossible, especially when it's combined with other techniques. If you actually want to take them to court, you have to be able to convincingly argue that this happened. It's much easier to patent things that are visible at the ISA level, because then you can just run some code to check.

Re: Can We Replace Intel x86 With an Open Source C

[Anonymous Coward]

There are places where open source could work. Certainly opening up the ME and the AMD equivalent is a place where open source could succeed. I suppose you could also develop an open source microcode. These give the user more control over the hardware, and I think it really would be beneficial for the ME to be opened up. However, these are really still examples of software, just at a lower level and with greater control over the hardware.

Anyone with a computer can run a compiler and build their own software. However, the manufacturing processes involved in creating modern microprocessors mean that virtually no ordinary user has their ability to go and create their own processors. Sure, you can comment on the specifications and design your own if you so desire, but you remain at the mercy of the manufacturer. You can definitely make your own custom build of open source software, but no manufacturer is going to be able to charge an affordable price and let you make just a few processors. It's going to be very expensive unless you're making a lot of chips and scale the process up.

Let me give you a practical response, shaped by decades of experience, derived from the wisdom earned from countless mistakes and successes, without any sugarcoating and ambiguity as is expected in business communication.

No -OP (Yes I'm quoting the OP).

Caveat: Once we replace Syscalls with UEFI, and all applications run in a VM, then we can have a meaningful conversation about running multiple processor architectures on a single machine and doing open-source risc with open-source architecture. Until the Wintel Monopoly is slain, and that is coming, we will remain in the dark ages.

Maybe

[Anonymous Coward]

Over the years I have followed closely the development of alternative architectures and manufacturing processes.

It's not the lack of reasonable designs, or even fabbed silicon. The problem is the inertia of not adapting existing alternatives to the various industry standard busses, form factors, standard MB sizes, and standard connectors.

Until someone offers an alternative chip with support that plays nice with established standards for business and consumer computers, than it will remain a pipe dream.

For example, as ubiquitous as Arm is in the embedded market, it still remains a non-player in the productivity consumer and desktop arena. Why no standard form factor MBs with Arm or MIPS that could be popped into a standard case or rack. I'm not talking about $10,000 high end "solutions". I'm talking buisiness, SOHO, and consumer pricing.

Until you have economy of scale, x86 alternatives will remain relegated to niche, embedded markets, tablets, and cell phones.

Re:Maybe

[SurenEnfiajyan]

But of course, there're still problems. Other companies can still steal your ideas or "fork" your chips. So don't expect to be very competitive.

No way. Fragmentation and forking is worse.

[Anonymous Coward]

Open source is not a good solution for everything. In the case of hardware, you can't simply fabricate ASIC's and release new ones every time someone has a new feature that breaks backwards compatibility. Look no further than C++ and now no two compilers produce the same assembly. Now multiple that across 1000s of versions of ISA's

We are lucky that FPGA cores exist that we can experiment with and not have to invest millions of dollars in chip fabrication only to have errors during fabrication.

In software, we accept some fragmentation because it ensures that the best solution is eventually found by trying multiple versions with different goals in mind.

Spectre is not something that open source cores would solve, if anything, it will still result in millions of SoC's being abandoned just because they are older than 2020 and not patchable in software because not every core is of a known quality.

The only place for Open Source CPU cores is for FPGA systems of legacy hardware (eg Nintendo and Sega consoles, Atari and Amiga computers), because that ensures that future generations can still use software designed for these platforms.

But there will never be a market for open source SoC/cores for current generations of chips because people do not not to spend 2000$ for a CPU that runs at the same performance of a 50$ chip.

That is why Android is circling the toilet, there is no minimum capability with each version of the OS, so software that works perfectly fine on iOS or Desktops, can't even run at 1/100th of the speed on most Android devices because the CPU+GPU combination has to be patched around in software to run, or refuse to work on 90% of Android devices that are cheap rubbish.

Re: No way. Fragmentation and forking is worse.

[Anonymous Coward]

Open source is not a good solution for everything

Hey Mr Croissant, shut up.

The only question asked was about open source being a solution for Intel x86.

The answer is yes if you have the resources, and yes but simply switch to AMD if you don't have the resources.

Re: No way. Fragmentation and forking is worse.

[Anonymous Coward]

That is why Android is circling the toilet

Yep, just 88% market share!

Google must really be shitting themselves.

Re:No way. Fragmentation and forking is worse.

[Anonymous Coward]

Look no further than C++ and now no two compilers produce the same assembly.

Yet those two C++ compilers still produce output that has the same effect. If one of them doesn't, then said compiler is broken.

Likewise, if a microchip/ASIC/whatever doesn't work according to spec, then it is broken, and most likely it will manifest in being disfunctional rather than simply giving the wrong math answer from time to time.

Re: No way. Fragmentation and forking is worse.

[Anonymous Coward]

But AMD is also vulnerable, and so is ARM.

Re: No way. Fragmentation and forking is worse.

[Anonymous Coward]

AMD is not vulnerable to Meltdown. I don't care if it is vulnerable to being hit with taser just because intel also is.

AMD is not vulnerable to Meltdown.
Intel is vulnerable to Meltdown.

No-Western Digital.

[Anonymous Coward]

Western Digital has made a commitment to use it for their products like HDDs.

'You' can do whatever you want

[Anonymous Coward]

What is it with idiots using 'we'?

You can do that if you want. Good luck to you. Leave me the hell out of your stupid universe.

To what end?

[Anonymous Coward]

OpenSSL being open source didnâ(TM)t find or prevent Heartbleed.

An open chip likely wouldnâ(TM)t have affected meltdown or spectre. This wasnâ(TM)t negligence by Intel (as evidenced that some of the recent vulnerabilities were shared by AMD chips on a completely different architecture.

The problem isnâ(TM)t that Intel failed to secure something obvious. Itâ(TM)s that there was a mechanism that everyone knew about, but which all experts thought couldnâ(TM)t be used to extract data. Then someone found a clever technique nobody thought of before that made everyone realize it WAS vulnerable.

Being open wouldnâ(TM)t have prevented the issue. Indeed, the issue was found by third-party researchers who didnâ(TM)t have access to the low level details of the architecture.

Open Source is not a panacea.

Re:To what end?

[Anonymous Coward]

Well then we wouldn't have to wait for the original creators to get paid bonuses to work with the software people who are also getting bonuses to get a fix out fast. We could wait for some guy in his mom's basement to take a break from gaming so he could talk to some guy 9 time zones away.

Re:To what end?

[Anonymous Coward]

Seeing the â(TM)t throughout your post is another example of how even after YEARS of complaint, an open source project (/. in this case) can't get things right. And it'd be simple for /. to fix it.

Re:To what end?

[Bing Tsher E]

We don't want Slashdot to fix that. It's a stupid-shit issue, an example of Apple arrogance. The people spilling those characters into their comments are like the dude with the hunk of toilet paper dragging along on the back of his shoe. It's good to know who he is, so you can avoid shaking his hand, unless you're wearing rubber gloves.

Re:To what end?

[Anonymous Coward]

Wasna and wouldna are perfectly good replacements for wasn't and wouldn't - It wasna a homerun, it was a popfly; I wouldna have done that - especially if you're from Scranton, heyna?

Re:To what end?

[TheRaven64]

The open source version of Slashcode has been forked by Soylent News and is fully unicode compliant. It's the proprietary version that's developed in-house by whoever owns Slashdot this week that doesn't.

Re:To what end?

[TheRaven64]

Yes, those arrogant Apple people, who write a web browser that, when submitting a form on a web site that contains the line , expect it to support UTF-8. Clearly they should know that forms on this page actually only support 7-bit ASCII plus some random codepage. Those idiots.

Re:To what end?

[Anonymous Coward]

Lets make a comparison to building architectures, which is open source or even more. They can't be copyrighted or patented. Every blue print is registered into community archive. Any owner with enough money can hire a designer and contractors to modify the building within the constraints of the community. All this is done because the life-cycle of a single house can easily be 50 to 150 years. So what should be done with the open source software and hardware? Is it necessary to design the building blocks of the computing ecosystem to live at least 100 years into the future? Or even much further?

Re:To what end?

[Anonymous Coward]

We don't want Slashdot to fix that. It's a stupid-shit issue, an example of Apple arrogance

Say what? Using UTF-8 - the most common character encoding on the web - is an example of Apple arrogance?

Get into the 21st century, dipshit.

Re:To what end?

[Bing Tsher E]

When the 21st century includes line noise from Apple users who misconfigure their keyboard settings, I'll stick to ASCII. You KNOW what ASCII is, right?

The 'dipshit' part on the end indicates your anger. So fuck off. When something angers you the world is right.

Re:To what end?

[Anonymous Coward]

License: Apache License 1.0 and four-clause BSD License... fyi

Re:To what end?

[Anonymous Coward]

So why aren't you avoiding this site?

Re:To what end?

[jittles]

The open source version of Slashcode has been forked by Soylent News and is fully unicode compliant. It's the proprietary version that's developed in-house by whoever owns Slashdot this week that doesn't.

Well lets see... last week they were owned by Pathway Technologies. This week they merged with E-Tech Management. So I think the new company is called Path-E-Tech Management?

Re:To what end?

[Anonymous Coward]

> When the 21st century includes line noise from Apple users

It's not just Apple users. Try pasting in an article quote from a news website sometime.

And it's not "line noise," Slashdot only makes it look like line noise because it's too stupid to handle properly encoded UTF-8.

> I'll stick to ASCII. You KNOW what ASCII is, right?

*American* Standard Code, for typing in American?

> The 'dipshit' part on the end indicates your anger.

Yep. Narrow-minded luddite curmudgeons make me angry when they post stupid arguments like you did.

Re:To what end?

[Anonymous Coward]

Why fix something that makes eavesdropping harder only for non-state actors? Rather put effort on something that makes spying harder for everyone.

J-Core

[Anonymous Coward]

Another possibility is the J-Core processor.

http://www.j-core.org

It needs a business case

[Anonymous Coward]

Make the business case. The problem is everyone likes leverage, pressure for you to use their process for your chip. If any foundry/assembly house develops (or licenses IP) then it becomes "use our process and this ARM processor is 'free'" the IP is a leverage tool.
Where open designs make sense is in the research area. A number of universities should band together and make not an Open Source design but rather a minimal RAND design. Where the design is free for research and only costs a bit if you make commercial products. That way everyone can use it for research, the design gets many eyes and if someone does something unique with it they can profit off it.

What a dumb idea!

[GerryGilmore]

Is it technically possible? Sure, there are already open-source core designs available. All you have to do is come up with the hundreds of thousands of engineers, designers, and manufacturing experts, replicate about 40 years of legacy toolchains from basic compilers to OSes, languages and frameworks, add in a smidgen of semi-conductor factories, testing facilities and packaging support. Oh! Did I mention sales and marketing? Go right-da-fuck ahead!

No incremental gain

[FeelGood314]

Linux was incremental. You had the kernel, a command line and things were slowly added to it but even early on you had something people could play with. It's easy to transfer software, it's easy to work on small parts. Hardware is a bit different. Your first open source CPU is going to suck. It will have absolutely no advantage over the existing processors and won't for many years. How are you going to keep a community going with very little tangible to show.

Re:The law of lame Slashdot question posts continu

[jblues]

No.

And if the question was the topic of a Slashdot post, according to Betteridge Law of Headlines the answer would still be no, just as it was for the last 20 Slashdot posts that did end with a question mark.

You'd do better to simulate in software

[Anonymous Coward]

Realistically speaking, you aren't going to fabricate a cutting edge physical CPU by any grassroots "to hell with the incumbents" method.

Instead, you'd do better using the buggy Intel chip to *software simulate* a better architecture. The actual hardware would only ever run trusted, vetted code. Risky code would only ever run in simulation.

Note that this is distinct from typical hardware-assisted virtual machine architectures where you depend on hardware logic to turn rule violations by the client code into exceptions - some of the same hardware logic that is broken. To be fully safe, you would enforce this instead in trusted software, obviously eating a large performance penalty for doing so.

So taking yet another step back, the alleged performance degradations from software workarounds for the recently found hardware bugs start to look comparatively minor in income.

Indeed, the world sucks. And you _will_ say "thank you" for that.

Not unless the FPGA/Fab process is also Open...

[Anonymous Coward]

As mentioned, plus a few:
OpenSparc
OpenRisc 1k
RISC-V
J-Core (Hitachi SH replacement now that they are falling out of patent protection.)
opencores.org has a few others, including 486/pentium cores.

However all of these require larger expensive FPGAs to replicate, and even getting your Verilog/VHDL design manufactured on an ASIC, besides the redesign work to avoid implementation issues or improve performance/power efficiency on the process, would cost a non-trivial amount in stencils, wafer cutting, and chip packaging. And that *STILL* leaves you without a chipset.

Having said all this, as I have suggested before:
Socket 7/Super Socket 7 reimplementation with initial boards leveraging SDRAM or DDR, PCI, and if needed, 48 bit LBA IDE. If I/O performance isn't a huge concern for you, these implemented on an iCE40 should be able to reach original bus speeds (25/33/50/66/75/83/100/125/133mhz) easily, provide opportunities for modern security boundaries/performance improvements while still being hardware interface/software compatible with dos/win9x/beos/old unixes/etc, and prove the interest necessary for future manufacturing of full-stack ASIC components necessary to reclaim the clone-PC market from Intel/AMD/VIA, all of whom have shown themselves unwilling to truly compete in a free market, as they proprietary documentation, or code signing initiatives have proven again and again. And yes folks, AMD is just as bad as Intel in this regard, or else we would have unsigned AMD Secure Processors, full chipset documentation, and unsigned GPUs so that when the next round of exploits happens and our hardware turns out to be too old to recieve an official fix, we have the opportunity to attempt our own mitigations instead of realizing our hardware is signed and without the key we are never going to have power-on mitigation capabilities written into our firmware.

Re:Not unless the FPGA/Fab process is also Open...

[willy_me]

these implemented on an iCE40

The iCE40 is great - but not to synthesize a CPU. It lacks the dual-port memory required for registers. There is a reason whey Lattice offers their LatticeMicro processor for their MachXO series but not the iCE40.

The iCE40 is highly optimized and fantastic for most programmable logic. But if you compare the iCE40 to the MachXO3 you will see that the MachXO3 has "Distributed Memory" - an essential part for efficiently implementing a CPU.

Re:Not unless the FPGA/Fab process is also Open...

[Anonymous Coward]

these implemented on an iCE40

The iCE40 is great - but not to synthesize a CPU. It lacks the dual-port memory required for registers. There is a reason whey Lattice offers their LatticeMicro processor for their MachXO series but not the iCE40.

That's just gibberish. If by registers you mean CPU registers, then then they can be implemented by flip-flops and muxes. That is actually how the big guys do it, since there is no way you can get a dual-port memory to run as fast a flop based implementation

The iCE40 is highly optimized and fantastic for most programmable logic. But if you compare the iCE40 to the MachXO3 you will see that the MachXO3 has "Distributed Memory" - an essential part for efficiently implementing a CPU.

That's even bigger gibberish. What is heck "Distributed Memory"?

Are you by chance talking FPGA parlance, about using LUTs to implement SRAMs? That's worse efficiency that using real SRAM. Nobody does that.

Re:Not unless the FPGA/Fab process is also Open...

[willy_me]

What is heck "Distributed Memory"?

Distributed memory is just that - memory distributed along side the LUT/FF elements. Using this memory "consumes" some LUTs but it is far more efficient then 1 bit per LUT. See the following quote from the MachXO3 datasheet - note that a Slice has 2 LUTs and 2 FFs, 4 Slices per PFU block.

RAM Mode

In this mode, a 16x4-bit distributed single port RAM (SPR) can be constructed by using each LUT block in Slice 0 and Slice 1 as a 16x1-bit memory. Slice 2 is used to provide memory address and control signals.

All from 1 PFU block. And this is why a device with 640 LUTs can provide 5K of memory.

MachXO3 Family Data Sheet

Did everyone forget that Softbank bought ARM?

[darthsilun]

I don't see ARM donating its IP to this effort...

I don't imagine Softbank paid $32B for ARM Holdings just so they could give the IP away.

Funny you should ask

[fustakrakich]

I was just asking about that in a previous thread. So, if MIPS is really unchained by patents etc, then we might have a chance.

Re:Funny you should ask

[pezezin]

RISC-V is pretty much a modern day MIPS, and its fully open source and patent free. I really hope any of the big manufacturers makes a high performance core and it becomes the next standard.

Indeed

[nospam007]

"It would certainly be a nice gesture of Big Blue"

Indeed. Perhaps they could throw in a nice free pony for everybody.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re: How does an open source chip solve the problem

[Anonymous Coward]

I love AMD and use AMD CPUs even currently but I have always been an Nvidia user because the ATI Graphics drivers sucked on any Linux outside of the mainstream distros.

Has this really changed by that much? I'm not trying to put you down just being honest and asking for your opinion. I still prefer the binary drivers myself.

Yes, but it would be rather difficult...

[Anonymous Coward]

With very little near term reward, lots of legal hurtles and massive effort from many people from other disciplines who are not software oriented in the open source ways.

I work in the cap tooling sector of semi, and the ARM licensing model shows the feasibility of ip licensing for the Samsungâ(TM)s and the tsmcâ(TM)s who generally focus on the manufacturing side.

Companies like Synopsis supplies the cad infrastructure to simulate and design chips. Independent design houses like esilicon does the design and builds the socâ(TM)s usually through licensed modules. Say you want the Bluetooth module, well you design a block of silicon real estate and pay a royalty to the Vikings.

Problem is that mooreâ(TM)s Law is nowhere close to being over with 1nm gates in lab demonstrated. And with vertical stacks and quantium computing and quantum entangled communication and solid state batteries and mems and ... we have a very long way to go until things begin to settle.

Letâ(TM)s let the physicists and material scientists do their work for now.

There are some interesting technologies in the pipeline like programable masks that may mature to the nano level thus making it a whole hell of a lot less expensive. So maybe someday...

Re: Yes, but it would be rather difficult...

[Anonymous Coward]

Btw I feel our slashdot community shouldnâ(TM)t be so dismissive of novel and altruistic ideas. I think OP has a vision of the future and needs the support of other disciplines to help us get there

Re:Simpler solution would be

[darthsilun]

AMD chips have their own security flaw[1].

Surprising that it hasn't been reported here yet.

It's apparently easier to fix than Intel's.

[1] http://www.theregister.co.uk/2...

We Need FOSS Hardware!

[Anonymous Coward]

Say people who have no capital, no design capability, no engineering capacity, no manufacturing resources, and only the flimsiest of rationales as to why FOSS hardware is important.

FOSS uber alles! Now if only someone else could do all the hard work...

Meaning

[Anonymous Coward]

>into the green field of the cloud

Mixed your metaphors, there. Unless the promised land is on a mountain, perhaps.

uninformed

[sdinfoserv]

A fairly unthoughtful, knee jerk reaction from someone who is clearly no more involved in technology than being a writer.
Bugs happen. Everywhere on every layer. Save your outrage for true malfeasance. Get angry at Feds for storing FS86 forms (the questionnaire for top secret clearance) on OPM servers unencrypted. Get angry at Equifax management for making the conscious, criminally liable decision, of storing PIN of pretty much every US tax payer “in the clear” at rest.
But for bugs that take years or generational development and understanding to discover, it’s unavoidable.
And certainly don’t suggest replacing it with a questionably supportable ecosystem. Linux, despite global usage, outside of a few niche hardcore users has completely failed on the desktop. (I know he didn’t specifically say Linux, but it’s an example of an attempt at global open source) Not a tolerable trajectory for hardware manufacture, let alone one that already represents market majority.

Re:Can We Replace Intel x86 With an Open Source Ch

[Anonymous Coward]

It isn't even the fab cost, it is the foundry technology. Sure you can make a comparable chip that a lot of people can build at 45nm, but when you get a more advanced process, doing large chips and maintaining yields gets tough. Intel is still the leader in yield and multi-chip and multi-die packaging.

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:Just one way to get everything you want

[Anonymous Coward]

No, it's certainly practical. It's already done; complete with Linux port.

How much this costs? what the actual performance is like? I don't know in either case.

Re:Just one way to get everything you want

[hcs_$reboot]

Or you could disable the current CPU cache...

Re:Just one way to get everything you want

[Anonymous Coward]

The only people interested in a PGA based computers are also the type to eat their own toejam. I think you know a fat, unshaven slob like that. Go sell this junk to him.

Re:Just one way to get everything you want

[TeknoHog]

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

Fancy that! Well, it's fun and games until there's enough demand for an ASIC implementation. https://github.com/teknohog/Op...

Re:Just one way to get everything you want

[Darren Bane]

I found working through the new edition of the "Project Oberon" book on a cheap $99.95 board extremely educational. It could be a good starting point for personal projects. Might require some appetite for risk for commercial use though.

No

[sunking2]

Software has the luxury that you can be behind the curve in development and still manage as an alternative. That doesn't work in hardware. If you are late to the game nobody supports you. And people aren't going to spend money making hardware that nobody wants supports.

Re: Can We Replace Intel x86 With an Open Source C

[Anonymous Coward]

Sure you can, as long as you don't care if your computer performs like it was made in the 1990s.

Re: Can We Replace Intel x86 With an Open Source C

[rkordmaa]

I know a guy who designed his own CPU for the lulz, implemented on FPGA, if it was any good and he was willing to throw in megabucks he could have ordered it put on silicon too. Not much point in creating few decade old PIC equivalent chips tho. Chip design is not magic and yes people can just up and do it, getting it implemented with modern processes tho is expensive(in the realm of crowdfunding tho) and getting it implemented in bleeding edge Intel processes is basically impossible. But Moore's law is winding down and the gap between what Intel can do and what everyone else can do is reducing.

Use it for the peripheral chips.

[Anonymous Coward]

Northbridge, Southbridge, etc.

Socket 7/SS7 should be easy to implement the support chips for using iCE40's plus some voltage stepper circuits.

If you get all the other components of a motherboard running and use adapters, like PCI to PCIe and IDE to SATA, plus ensure you don't have any of the oversights that the original chipsets had (like lack of LBA-48 support, or addressing issues above certain boundaries), then you will have access to the majority of modern storage and peripheral devices. It may not all be as fast as on newer busses or using patented performance optimizations, but it can be done today and could help inspire new open FPGA designs (if the iCE40 became the FPGA equivalent of the Raspberry Pi thanks to its reverse engineered toolchain/open documentation) of sufficient LUT geometry and other features needed to perform as a cpu or more complicated logic support chips. Once that infrastructure and marketshare was in place, there would be room for an open hardware maker movement somewhere between the 3d printer/small run electronics businesses and the 'big boy' custom bitcoin ASICs that almost nobody can actually buy in time to turn a profit from. At that point in time, as long as the open hardware licenses ensure they cannot be used by people who aren't part of an (anti-)patent covenant to protect the openness of the hardware designs and IP for all, many groups of individuals can throw their designs into the market, some compatible and some incompatible, but all providing new components or designs to the pool which will help to slowly improve designs in all corners of the market, even as each groups engineers strive to stay one step ahead of the competition, or better cater to a particular client market.

Look at the history of

[AHuxley]

0. Find skilled people. The best of their generation. Hire only on merit not on social advancement.
1. Consider the CPU design needed and that existing hardware around a new CPU design can support.
2. Find yourself this generations Berkeley RISC https://en.wikipedia.org/wiki/...
3. Find some fab to help design and make the CPU, collect related parts.
4. Bring the software and hardware together so people can code with your CPU and for your CPU using your free dev tools.
Study everything thats needed and don't forget the support that people expect from any CPU. Software later cannot always undo what was not done during CPU design.
5. Learn from the past. Study past CPU efforts and their software offered. What was needed, what was supported, what attracted developers. What should have been done, what was not done, what could have been done to better support developers.
The funding, gov support, how complex software was just expected to support a CPU. Limitations that could have been worked on before using a CPU design.
Zilog https://en.wikipedia.org/wiki/...
Dragon 32/64 https://en.wikipedia.org/wiki/...
Cyrix https://en.wikipedia.org/wiki/...
Eagle Computer https://en.wikipedia.org/wiki/...
Acorn Computers https://en.wikipedia.org/wiki/... and Acorn Archimedes https://en.wikipedia.org/wiki/...

Have a programming language that works and is supported. A good CPU needs a good set of free tools to create applications.
Do not encumber your project trying to tell developers what to do on their own projects. Let them code in anyway they want.
Let your project be the platform that does not try and micromanage other peoples code. Attract the fun, smart projects away from the more restrictive OS, repository services by not "telling" them how to use your tools, code, CPU. What other people do with your CPU, tools is their project to support.
An open CPU with the freedom to get on with creating great code.

Find people to tell the world about your project from an average users perspective and that of creating very complex applications.
Cover a few languages used globally by very smart nations and have 24/7 support. Be ready to do blog, talk radio, TV, online, magazine interviews 24/7 as needed by a news cycle. Never attempt to reschedule an interview because its 4 am for you. Always thank the interviewer and be ready do any interview at any time at any skill level. That trade publication or a game, music, art blog. Win hearts and minds away from other projects.
Have a media kit ready with translations, lots of different usable images that are publication ready. The history of your design, the design now and future directions.
Have your own translator if needed who knows your CPU design ready at 4 am if needed. Let every interview spread the message of your project and CPU design.
Make sure people talking about your project are articulate, charming, charismatic, photogenic and have the skills to present complex issues to any audience.

Set up an online community thats not linked to your CPU work to support later code, projects, art work, music, games, FAQ, OS, bug reporting, security.
So it can be responsive, dynamic and ready for changes in the free code and market place. Something to keep your CPU supported for users without having to get official approval for every normal support question.
That keeps your CPU team working on the next CPU and not getting bored doing end user support work.

Be aware for what offers of gov and mil funding will do to your production line and staff. With huge tax b

Re: How does an open source chip solve the problem

[Anonymous Coward]

The quality of such designs is on par with the quality of code produced by CS grads. Most of it is fine for academic purposes but isn't worth a damn in the real world.

Emulate?

[Anonymous Coward]

If we can emulate a whole computer in the container evironments, then why can't we emulate a processor? Just stuff the box with ram and boot the processor first. Get it?

Re: Emulate?

[Anonymous Coward]

Did you fall off a large tree when you were young?

In short, no

[ndykman]

There is a massive amount of tooling and infrastructure needed to design a modern CPU architecture. Sure, you can start with open designs that are 20 years old, but you'll need to add massive amount of changes around out of order execution, speculative execution (yes, it caused this problem, it's also a critical optimization), cache management and coherency and so on. A lot of this requires highly specialized workers that expect to be paid well for their expertise.

Much better to invest to formal verification research and tools, but that is already happening at all levels from academics to industry.

No

[clay_buster]

Why is this even an idea? As an aside: Every major architecture suffered the same type of defect because it is approach that has a major performance impact. Why wouldnâ(TM)t an open source project have the same problem? This defect is so central to the design that it canâ(TM)t be fixed with microcode.

No

[8086]

x86 isn't going anywhere and too much manpower has been spent perfecting compilers, interpreters and OSs on it and the superscalar/ooe/pipelining below it. The cost of implementing any new ISA, even if open source, would simply be too much compared to an equivalent x86 chip and it still wouldn't perform as well. It would become another costly walled garden. A better idea would probably be to create an open-source x86 chip, i.e. open source the microcode and all the architecture below the ISA. It could be a community designed processor, a publicly available VHDL/verilog/whatever file that anyone with a silicon wafer etching machine in their backyard could print for themselves. Cheap chinese manufacturing would make the processor easily available to everyone, and it would be plug-in replaceable for intel/amd chips. It would probably make Intel and AMD both charge less for their IP and bring prices down all around.

Hahahahaha, thank you for that!

[Anonymous Coward]

I'm one of the 'kooks' who has been ranting and raving about both Intel ME and AMD's PSP/Secure Processor implementations for years now (AMD's dates to the FM2 or FM2+ era hardware, although finding out exact versions and whether those versions are actually correctly documented has been non-trivial.) Hint for you: Signed firmware with a separate processor, full memory access and privileges on your system above supervisor level. Both of those implementations allow the sort of damage possible with meltdown without any way for a user to mitigate them, allow other serious dangers like providing an identification code for the cpu/motherboard (lots of other components of a modern system have software visible serial numbers now, which sadly people don't consider a threat despite all that CPUID concern back in the late 90s/early '00s with the Pentium 3 was it?)

Without a system devoid of userspace accessable serial numbers and a out of band management system securable by the administrator or end-user which can provide that polling when necessary, we cannot consider our hardware either trustworthy or more importantly, pseudo-anonymous anywhere where are and anything we do. While it might not have yet been used publicly for a conviction, the time when it will be is rapidly coming, and every application you run may be the one that will leak all that information and tie it to your real life persona (thanks to all those serials being tied to the purchases you made on your credit card, or via a paper with your name on it at a store, like microcenter, or fry's, or best buy...)

There are multiple facets of danger people need to be made aware of, but I fear, outside of us techies, that it is already too late.

Wouldn't keep up

[Anonymous Coward]

Have a look at R&D expenditures by semiconductor manufacturers. Think about what you were looking for the last time you purchased a processor, or considered the processor as part of your decision to purchase a device. Are you going to buy the open source processor where they just figured out a legal way to copy what Intel did three years ago? Or, are you going to buy the processor the does the most work fastest for the least money?

RISC-V

[whoever57]

Is no one going to mention RISC-V?

Re:RISC-V

[Anonymous Coward]

You mean the last line of the article summary?

Look, this issue spans architectures; it's not just an Intel issue. Meltdown and Spectre are results of the implementations of several different complex, performance-enhancing features. It's been lurking for decades, waiting for someone to stumble upon it. Given the descriptions I've seen, I now wonder if some of my "how the hell did that ever happen" code crashes were, in some way, an artifact of these issues that were brushed away because I wasn't persistent enough to reproduce them.

If we all go back to the 8086 and give up all these performance-enhancing architectural improvements we'd likely be safe. But then your CPU would lose an amazing amount of speed and functionality. You can equally say this is the fault of every kernel implementor, since the information to date shows that it's a combination of a hardware interaction quirk and the setup of the hardware that is being fixed by setting up the hardware differently

Re:RISC-V

[Bert64]

There have been many architectures which don't do speculative execution, IA64 for example, and high performance is certainly possible... But for that to work, you need well written code (or well written compiler) to take advantage of it, and the code needs to target the specific processor revision, not be generically compiled code.

Processors in games consoles (eg Cell in PS3) were built this way because there was never any need to run the code on a different model of processor for example.

Oh Really

[Bruce Perens]

Thank you for this vast work of erudition, anonymous moron.

Someday, perhaps, when you are a pre-adolescent, you may aquire somewhat more knowledge of computers, though probably not enough to make you top-heavy. At that time, you may hear of a miraculous device called a gate-array which makes it possible to craft a running CPU similarly to the way that programmers write software. With this device, someone of greater skill than you will put together a computer that might not be as fast as you like, and might not have as many transistors as you like, and might use more power than you like, but will be capable of running an Open Source CPU with a known-bitstream so that the chance of there being nasties that we're not told about that spy on us built into the CPU die is reduced from today's horrible state (gate-arrays can still have them, but the people who make these nasties don't know in advance where we put the CPU implementation).

The instruction set and currently-fixed hardware features like the MMU and the translation look-aside buffer (a feature implicated today) will be repairable by changing the bitstream.

This will never be as efficient as a fully-custom chip, but it can be good enough. Many of us will be happier using it. And for those of us who require algorithm acceleration (hopefully for better reasons than mining cryptocoins, but that is one example) it will be possible to code it into the system and get the advantages of a hardware implementation without it being so hard.

Re: Oh Really

[Anonymous Coward]

While I don't think your post should have been modded down, it is unnecessarily rude. As you readily admit, open source hardware couldn't directly compete with Intel and AMD processors on efficiency. Most of the comments are focused on this particular issue, including the ones I've posted in this story. The main issue is the difficulty in producing such custom chips. It's an interesting and insightful idea to use a gate array instead of fully customized chips. The question is, and I'm not in a position to answer this, howuch of a hit in efficiency and performance would this likely result in? Would the performance hit be enough to limit the usefulness of gate array to create custom processors? I also suspect that many users wouldn't want such hardware because I doubt that DRM systems will run on custom hardware.

I think you do make a key point that this could protection against backdoors that are built into the hardware. I don't think that Meltdown and Spectre are the result of intentionally building in vulnerabilities, but rather from simply overlooking these issues. I doubt that open source hardware would prevent hardware bugs, but it would provide a way of avoiding backdoors that are intentionally placed. You're absolutely right in that respect.

Re:Oh Really

[Anonymous Coward]

Sorry, Bruce, sarcasm is in our DNA here, and that goes for numbered users as well as ACs. But 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.

- different AC (same age though)

Re:Oh Really

[phantomfive]

This will never be as efficient as a fully-custom chip, but it can be good enough. Many of us will be happier using it.

This is a good point: people who care about security (like AWS) have different requirements, and may be willing to forgo some performance in exchange for security.

Re:Oh Really

[TheFakeTimCook]

Thank you for this vast work of erudition, anonymous moron.

Someday, perhaps, when you are a pre-adolescent, you may aquire somewhat more knowledge of computers, though probably not enough to make you top-heavy. At that time, you may hear of a miraculous device called a gate-array which makes it possible to craft a running CPU similarly to the way that programmers write software. With this device, someone of greater skill than you will put together a computer that might not be as fast as you like, and might not have as many transistors as you like, and might use more power than you like, but will be capable of running an Open Source CPU with a known-bitstream so that the chance of there being nasties that we're not told about that spy on us built into the CPU die is reduced from today's horrible state (gate-arrays can still have them, but the people who make these nasties don't know in advance where we put the CPU implementation).

The instruction set and currently-fixed hardware features like the MMU and the translation look-aside buffer (a feature implicated today) will be repairable by changing the bitstream.

This will never be as efficient as a fully-custom chip, but it can be good enough. Many of us will be happier using it. And for those of us who require algorithm acceleration (hopefully for better reasons than mining cryptocoins, but that is one example) it will be possible to code it into the system and get the advantages of a hardware implementation without it being so hard.

Unfortunately, as you well know, this approach means goodbye to virtually very computing-type device most of us have become accustomed-to. With all due respect, IMHO, Even desktop computers would have to devolve into houselight-dimming, room-warming, five-rackspace-hogging monstrocities, with barely the compute-power of a MacBook Air. And as far as modern GPU emulation with any reasonable number of available FPGAs, forget it!

Re:Oh Really

[TheFakeTimCook]

This will never be as efficient as a fully-custom chip, but it can be good enough. Many of us will be happier using it.

This is a good point: people who care about security (like AWS) have different requirements, and may be willing to forgo some performance in exchange for security.

SOME performance???

For some pretty hefty values of "Some"...

Re:Oh Really

[Bruce Perens]

Unfortunately, as you well know, this approach means goodbye to virtually very computing-type device most of us have become accustomed-to.

Maybe you haven't been following gate-array development. There are mobile ones now. They use FLASH to store the program bits. And the rest is CMOS which we know how to power-manage. The gate-arrays of yore were more power-thirsty because nobody cared back then.

Re: Oh Really

[Bruce Perens]

I doubt that open source hardware would prevent hardware bugs, but it would provide a way of avoiding backdoors that are intentionally placed. You're absolutely right in that respect.

Use of gate-arrays would make the bugs reprogrammable. And now that we have mobile gate-arrays, performance is actually getting pretty good.

Re:Oh Really

[Bruce Perens]

Actually, if you look at this device, you'll see that gate-arrays aren't in the same class with your father's Oldsmobile any longer. We need them to be denser than the ones at that link, but the potential is there.

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:Oh Really

[Bruce Perens]

Sorry, Bruce, sarcasm is in our DNA here, and that goes for numbered users as well as ACs.

Actually, you are perpetuating the naive assumption that Anonymous Cowards are human beings who have feelings. Not so. Anonymous Cowards are actually alien beings from a planet orbiting the star Beta Anonyma. They emigrated to Middle America and have been posing as real people, having destroyed their own planet through bad political policy. Although they have developed a society nearly as intelligent as ours (not quite as intelligent, they are actually the cause of the Red States Mystery), they do not have feelings, they are thoughtless automations who have been programmed to believe that they are alive and have feelings, which they volubly protest while in fact being entirely without consciousness. Also, no matter how many Anonymous Cowards you meet, they are all one individual.

Re:Oh Really

[Bing Tsher E]

No FPGA is open source. The tools to program them are never open source. Let's see the source code 'all the way to the bottom' on these Lattice chips you are championing. Or even close to the bottom.

Re: Oh Really

[Bruce Perens]

Good point. I have championed the creation of a fully open gate array, and will continue to do so.

Re:Oh Really

[Anonymous Coward]

Anonymous Cowards are actually alien beings from a planet orbiting the star Beta Anonyma. They emigrated to Middle America and have been posing as real people, having destroyed their own planet through bad political policy.

A bunch of us ACs had a meeting last month and, since several of us are top executives in the FCC, we were talking about having the country standardize on 16-bit Windows, which everyone agrees was sort of a golden age in information technology. I mean people would still be able to use Linux or Mac or whatever they wanted, but if you want to avoid the $699 tax you'd have to connect online using Win 3.1.

Re: Oh Really

[Anonymous Coward]

Can you prove you're not a programmed alien device accepting input through a 9 pin serial port?

Because from where I'm sitting, it's time to swap cables, dust off your screen, and swap your batteries because your fuzzy login algorithm has gotten extra fuzzy.

Bruce.

Re: Oh Really

[Anonymous Coward]

I'm your neighbors. Your friends. Your brothers and sisters.

Just kidding. I'm actually fucking your sister.

Re:Oh Really

[AmiMoJo]

The really have to accept a loss of performance, no choice at all. The fix for the Intel only issue is really killing some server workloads:

https://www.epicgames.com/fort...

50% performance loss for a game server...

Re:Oh Really

[Anonymous Coward]

50% performance loss for a game server...

Any comments from the resident Intel 'nothing to see here, minor impact only' shills?

(...Tumbleweed...)

Re: Oh Really

[Bing Tsher E]

That is something really worth championing, but it's also a dragon den of proprietary technology. The FPGA vendors are cut-throat competitive about this stuff. The tool-sets to program FPGAs are always behind restrictive walls. I have a tool-chain I downloaded and a Mojo board to go with the new O'Reilly Learning FPGAbook I bought, but so far I've been standoffish about getting into it, because it's one of those 'keyed software' things.

I have never been keen to install software on my machine that requires me to 'phone home' to unlock it. What if I grow dependent on it and they decide I haven't kissed the proper ring?

Re:Oh Really

[Anonymous Coward]

1980's Usenet style pomposity aside, I'm not sure what your point is here. Is it sort of like "hey, if we only went back to horses we could save soooo many lives from car accidents"? Because that sounds like your argument and it's fucking risible.

First, these bugs are ridiculously complex and subtle. The best brains in the world making the most money designing CPUs for a living missed it for years but you think Joe Hacker, Home CPU Designer is going to notice it? Maybe we can open source medicine too, I'm sure if they showed a million morons every X-ray and MRI taken they would be able to see stuff that highly educated doctors don't. Because...power, like, to the people, or, like, something right?

Second, nobody but paranoiac nerds is going to settle for 2003 era CPU performance because they want the (false, as described above) sense of security that comes with open source hardware where .001% of the population is actually qualified to look for bugs like those recently found.

Your ideas are dated and impractical and you are a bellowing dinosaur.

The answer to the question posed in this article is a simple "no" (with a snicker as you say it). It doesn't deserve much further time or attention because it's silly.

Re:Oh Really

[Anonymous Coward]

Did you just suggest that you wouldn't want your people to be peacefully replaced by migrants who claim to be refugees, merely on the grounds that it would affect your personal quality of life?

Re:Oh Really

[Anonymous Coward]

Found the Intel employee.

Re:Oh Really

[Anonymous Coward]

Frankly? I am not SURE, why this page is sometimes logged in and sometimes rejects me like a nobody it has never heard of before. Deja vu...

If it weren't hard, they would'nt call it hardware

[williamyf]

TL;DR No, you can not replace X86, AMD64, Power, Sparc, MIPS and ARM with a FOSS design.

openSparc, openPower, MIPS-V?
Those have opened the 'ISA', but NOT the design, so you have to design your microprocessor from scratch.

ARM? MIPS? You can get the full design, if you pay. Or you can pay for rights to the ISA, and design everything from scratch.

Designing a somewhat modern microprocesor is hard enough, even if you already have the ISA, and the beast is cruft free (64 or 128 bits from the get go, without being "somewhat compatible with everything dating back to the 8080").

If, on top of that you need to make it as fast in the datacenter as X86, AMD64, Power or Sparc. Or, if you have to make it as power-saving as ARM or RISC on mobile and IoT, well, that's a mighty struggle (it took Apple, using ARM's bootstrap several YEARS to get a good design of the ground).

Here you do not have the source code (in Verilog or VHDL) of other microprocessors to study, inspire and bootstrap the stuff, like one had the Soruce Code of AT&T SystemV , BSD, and Minix (please notice that I said Bootstrap, not copy, I am very clear that Linus developed his baby on his own), nor a pool of drop-down replacement modules like in GNU, and there are orders of magnitude fewer people that understand hardware AND microprocessor design, than the people that can contribute to software design (even if we compare only to Kernel, Drivers and Compilers only, and not to Software as a general category).

So no. The only chance is if you can get a big sponsor for the initiative (Like IBM at the time was with Linux, only MUCH, MUCH bigger). Probably one or more nation-states. Perhaps the BRICS. One can dream, but at the end of the day, no, nope.

Sorry for us all, me included.

We do have consumer computers running ARM

[perpenso]

as ubiquitous as Arm is in the embedded market, it still remains a non-player in the productivity consumer and desktop arena. Why no standard form factor MBs with Arm or MIPS that could be popped into a standard case or rack. I'm not talking about $10,000 high end "solutions". I'm talking buisiness, SOHO, and consumer pricing.

You realize some chromebooks run ARM?
And that they are running the Linux kernel?
And that it is possible to install Desktop Linux to those chromebooks if the owner chooses to?

Re:We do have consumer computers running ARM

[angel'o'sphere]

iOS is run by ARM.
Half of Android is.
Rasbery Pi are run on ARM.

Re:We do have consumer computers running ARM

[perpenso]

iOS is run by ARM. Half of Android is. Rasbery Pi are run on ARM.

Sure, but I was responding to the "desktop arena" mentioned by AC.
Haven't tried Pi as a desktop, for me its just replaced the headless Linux boxes (retired PCs) in the closet. Assuming a console environment no longer counts as a desktop.

Re: Can We Replace Intel x86 With an Open Source C

[Anonymous Coward]

When people as me what makes Intel good, I tell them that it isn't the CPU designers, for the most part - it's their fab engineers. They are the best in the world at manufacturing semiconductors, period.

It's too bad that about once a decade their egos get the best of them and they have a pretty major fuck-up to set them straight...

WTF?

[Anonymous Coward]

Why? this makes no sense, an open source chip doesn't suddenly make a chip immune to design flaws and if anything makes it even harder to hold someone accountable for the fuckup. Creating chips and tooling foundries to manufacturer chips that are of sufficient performance also takes billions of investment, good luck getting that together with an open source version.

GTFO

[schematix]

Designing bug free hardware that is extremely fast and efficient is so easy i'm surprised people aren't already building this stuff in their kitchen in their spare time. It's not in Intel's interests to make hardware with bugs. Unless it comes out that they were grossly negligent or were working with the NSA, i think this just falls into one of those unfortunate categories. Besides every few years people need to buy new CPUs anyways, so the problem will resolve itself, just in time for another issue to make its appearance.

Re:GTFO

[Anonymous Coward]

> Besides every few years people need to buy new CPUs anyways

Sitting here with a Phenom 2x6 1090T Black Edition from 2011... newer stuff has all the management engine BS in it. I could overclock it a few hundred MHz and easily get more (practical) time out of it, but that would lessen its lifespan. At present, it does everything I need. The only thing that'll kill this is the material itself wearing out. We throw away far too much hardware.

Transmeta?

[Anonymous Coward]

Does everyone remember Transmeta? Self-modifying microcode, loadable...

Re:Transmeta?

[schematix]

lol and a power hungry slow piece of crap. whatever happened to them? oh yah.....

Yeah, Sure

[Anonymous Coward]

So who can tell if some group slide in a backdoor hardware design into some open source CPU?

Re:Yeah, Sure

[Anne Thwacks]

Future generations of hardware and software will need a fundamentally different approach to design and verification.

No - mostly we need illegal accesses to kernel mode memory to hare the result substituted with a value like 0xf00l like used to be done in the old days, and for a hardware signal to purge all speculative results during the "retire" instead of a allowing them to hang around.

I suspect that careful investigation will result in a few more cache refreshes, and pipeline flushing than we have now - but it won't cost more than 1% of performance, and will be a permanent fix for these problems.

Hopefully, people have learned that you need to check for security breaches even when you think the change is "more of the same".

Uh, ZDNet? Really?

[asackett]

It's not surprising that someone who doesn't seem to know that "the cloud" *is* private data centers also knows nothing of IC fab.

Very simple question

[kenh]

What socket will this ' free fantasy CPU' use? What chipset will it use? Are we talking about a volunteer clone effort to reverse-engineer the X86 processors, or something wholly new, so that we require new drivers, OS, BIOS, etc?

Only by being ignorant of what's involved can someone make such a proposition.

This is really an over-sized reaction to a minor problem that will be resolved in the next generation of silicon from every chipmaker.

Re:Very simple question

[Anonymous Coward]

What socket will this ' free fantasy CPU' use?

Anyone you like. Making a motherboard isn't nearly as hard as making a CPU.

What chipset will it use? Are we talking about a volunteer clone effort to reverse-engineer the X86 processors, or something wholly new, so that we require new drivers, OS, BIOS, etc?

Your entire question revolves around the x86 architecture.

Think of it this way: There is no point in going for an open processor if you intend to run proprietary software on it, so you can take any architecture you like and just compile the software you want for it.

The split between CPU and chipset you think of is very x86 based. Other architectures will also need peripherals, but there is no need to think of it as rigidly split as your question implies.
Or to rephrase it, what chipset does the Raspberry Pi use?

If your response is "But what about muh proprietary software?" then this discussion isn't really relevant to you. You should probably stop wasting your time.

Re: Very simple question

[kenh]

Yes, what you discuss is a bespoke system more reminiscent of a 1980's era personal computer where all I/O is provided by the system manufacturer, third-party support is minimal and limited to mainly emulating the manufacturer's options, runs bespoke software unlike any other computer platform, and performance will be a fraction of the typical "Big Two" (Intel, AMD) entry-level CPU. Your custom, 'Good Enough' computer system will be bestest Raspberry Pi clone, but little more.

For well under $100 I can get a quad-core CPU that will 'hyper-thread' to 8 cores, run at three plus gigahertz, and get a motherboard for less than the price of a big Mac meal at mcDonalds. In round numbers, what do you imagine this programmable gate array with comparable performance will cost, to get a system complete enough to add SATA storage, memory DIMMS, Keyboard/mouse and video monitor to? Add to that the unbridled joy that every software selection you hope to run will either have to be available as open source so you can build it yourself OR have been compiled for your device by the authors.

Do you really miss the days of 1980s personal computing so much that you're willing to forgo 3 decades of improvements because an obscure method exists to dump protected memory space on current CPUs? Intel/AMD will correct this issue in the next 18 months, in silicon, well before your Libre CPU Gate Array computer is able to run faster than 1 Ghz for less than $1,000/cpu.

Sadly no.

[Anonymous Coward]

To get good performance Intel basically moved _everything_ into the CPU: memory controller, PCIe controller, etc. It also tends to drive down cost I imagine -- It must be quite a bit easier to route the boards (still harder but easier than huge parallel buses). But there really isn't an open source equivalent for PCIe (or even PCI last time I checked).

This doesn't mean you couldn't write one. It just hasn't been done.

Intel may go bankrupt?

[Futurepower(R)]

The comment above mine said, "While I don't think your post should have been modded down, it is unnecessarily rude."

Bruce, I agree with that comment. Don't act out anger.

Another quote from the comment above mine: "I doubt that open source hardware would prevent hardware bugs, but it would provide a way of avoiding backdoors that are intentionally placed. You're absolutely right in that respect."

The possibility of backdoors may cause Intel to go bankrupt. How can Intel be re-organized so that it can stay in business?

Previous comments about this issue:

Intel news stories (April 17, 2017)

Articles about spyware in CPUs (June 18, 2017)

"ME is turning into a colossal dumpster fire." (December 10, 2017)

In more than 11 years, I haven't seen anything like full awareness by other people of the fact that Intel is badly managed. To me, the fact that Intel has provided forced secret access to its hardware, later found to have vulnerabilities, is a tragedy for Intel, the United States, and the world.

I mentioned that in another comment to a Slashdot story: FREE BOOK about the Intel Management Engine. Part of what I said: "A Slashdot comment of mine from 11 1/2 years ago: More Intel employees should say in public what they have told me in private: Intel CEO Paul Otellini is not a competent leader. He lacks social ability. (June 09, 2006)"

Otellini is no longer the CEO of Intel. The present management does not seem much better. For example, Intel advertising is wacky, in my opinion. I got an email message from Intel on December 18, 2017 ago that says: "Final call for awesome prizes -- train now or miss out". I don't need "awesome prizes". I need excellent technology and excellent, reliable explanation of Intel's technology.

Again, very important: Intel needs better management. Intel surviving and thriving would be good for the entire world, IMO.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Uhh....no

[Rick Zeman]

"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."

For Linux you just needed a copy of gcc. Chip design and fabrication requires just a weee bit more.

Re:Uhh....no

[iggymanz]

even gcc had to be forked from the ivory tower weenies (e.g. Stallman, who also couldn't make a useful OS to save his life) and pounded into something useful by people that had common sense, which really is quite lacking in 80% the open source community.

Already done..

[Anonymous Coward]

Well, look, it's already done by the OpenRISC project. Complete with Linux, gdb and gcc ports.

Of course; I don't know how fast this runs, or how expensive this would be.

Absolutely!

[Anonymous Coward]

Just take a look at the Freedom U500 Platform from SiFive.

I think RISC-V is going to be that thing. Although don't expect it to become competitive immediately. It will take a decade or two before we can see anything resembling the experience you have on your PC. Although you might be able to run Debian and Ubuntu very soon but with many constraints (for example lack of a good open GPU design).

If we're talking replacement...

[skaag]

then in my opinion, the next generation of CPUs should have re-programmable gate logic. Kinda like how FPGA works, but significantly faster and on a massive scale. Just imagine the kind of power you'd get if the OS switches large areas on the silicon to fit certain tasks. When you play games or do some massive 3D work, the CPU would be reprogrammed for that task. When you want to mine crypto or do some massive encryption/decryption/compression/decompression, the CPU would be reprogrammed accordingly.

Re:If we're talking replacement...

[rkordmaa]

Just buy a FPGA on PCI board, integrating one on CPU is moronic. And its not going to outperform a dedicated GPU for gaming etc. Or a dedicated crypto chip. Field programmability comes at a cost. Plus more powerful FPGA-s cost an arm and a leg, too much to have as an standard feature of regular PC. Even supercomputers don't generally bother with it, if you need raw compute power its usually faster and easier to buy it on cloud. FPGA-s are cool as frig, but they are not a universal fix to every problem.

Re:If we're talking replacement...

[skaag]

I'm not talking about the kind of tech we have now. Obviously FPGA is not suitable for the stuff I'm talking about, and I wouldn't integrate FPGA into today's CPUs. But just imagine if you could add more "FPGA Style" chips on a bus. Some would be purposed as GPU, some as Crypto chips, some would be purposed for audio processing, some for manipulating large scale 3D scenes (complex interactions, collision detection, physics), some for AI / Neural Net style compute, powerful image recognition, some even for network stack handling...

I think this style of general purpose compute platform could be pretty useful to have! You could even make very powerful routers, or very powerful database servers.

Down the road, this kind of thing might totally happen. I think it makes sense. Even from a fab point of view; it's cheaper to make a fab that produces one standardized silicone which can be repurposed, than to make 20 fabs for 20 types of chips.

Re:If we're talking replacement...

[rkordmaa]

FPGA is exactly what you are talking about, and yes you can do all that with an FPGA, in many cases with significant performance boost over CPU, while underperforming a true purpose built chip. Its costly though and hardly a panacea you are imagining it to be, it is being done in many cases nevertheless. Powerful routers are a good example, that is exactly how they are built. The technology you are talking about exists and is in fact used in some cases, but its not as all powerful as you imagine it to be and is expensive, thus it's not in every generic PC.

Re: If we're talking replacement...

[Anonymous Coward]

And the cost is huge. As a rule of thumb a FPGA design needs 10x to 100x the silicon area than an ASIC implementation for the same features. BTW manufacturing cost rises exponentially with silicon area, not linearly. It is also much slower and power hungry.

Normally FPGA are only chooses if you really like the flexibility to later change the design of your volume is so low that you can't afford an ASIC.

Re:If we're talking replacement...

[skaag]

I programmed FPGA years ago. They are still limited, even in 2018. But I imagine in the future as the use case becomes stronger, the technology may improve massively and become cheaper and more common.

Just look at external GPUs for laptops. If you told people 10 years ago it would be a thing, they'd call you mad. Same with Crypto Assets, most people didn't see Bitcoin coming, and even when it was in its first years people still bought a Pizza for 10,000 BTC because even though they knew how the technology worked, even they couldn't fathom how valuable the tech and the currency would become.

Personally, I keep an open mind so nothing is shocking to me. I wasn't even shocked when Trump got elected, even though it was presented as a joke in various media such as The Simpsons and other comedies (or perhaps as a hidden warning ;-)).

I totally expect we'll eventually be able to copy the human brain into a virtual environment, extend the life of our organs (or replace them entirely), and reach planets in other systems, it's just a question of time.

Re: If we're talking replacement...

[skaag]

Agree 100% with everything you said. It's all true.

Doesn't mean it won't change in the future though. I think it will improve massively, it's a question of demand.

Re: If we're talking replacement...

[Anonymous Coward]

Stupid autocorrect.

Normally FPGA are only choosen if you really need the flexibility to later change the design or your volume is so low that you can't afford an ASIC.

BTW even the biggest FPGAs (40k$+) available today aren't big enough to hold a modern CPU or GPU.

Can we standardize on big-endian or little-endian?

[Anonymous Coward]

I don't care which, just pick one and make all future processors compliant.

While we're at it, let's pick a standard newline code - 0x0A, 0x0D, or both - but across the board.

More possible now

[Anonymous Coward]

I'd say it's more possible now than ever before. Windows is less relevant, you just need an OS that can run a web browser and that can do about 90% of what people need a computer for these days.

CISC complexity failed, RISC good way.

[Anonymous Coward]

RISC-V + NUMA-cc + lower-consumption Wake-On-Land.

I wanted to integrate a firewall in my laptop with at-least two ethernet connectors. why not?

And to let "*.jar" as "*.exe" in linux, please. why not?
($PATH to "*.jar"s directories).

To omit the "java" except when it is needed (... java -server ...)

So, it will be nice to threat virtual machines (JVM, CLR, ...) as if they are real machines. (a kind of abstraction).

Missed opportunity

[Tumbleweed]

It's too bad the project at Sun to produce an asynchronous CPU was cancelled; that seemed like an interesting path. I wonder if anyone else if experimenting with that now.

Re: Missed opportunity

[Anonymous Coward]

Asynchronous logic design is much more complex than synchronous logic design and not well supported in existing tool chains.

hardware is not software.

[JustNiz]

Intel have poured literally billions of dollars into R&D of their products for decades to get to where they are now.

I know there's a lot of clever people out there, but I'd be amazed if the open source community could ever catch up then stay with whatever Intel's current CPUs are for features and performance.

Design automation

[Anonymous Coward]

If it were me would much rather spend my time on an open effort to meaningfully push the bounds of design automation. By necessity it is increasingly the direction everything is headed anyway. Don't focus on the goal. Focus on the process.

Re: No?

[VernonNemitz]

Before you design a core, you need to specify an assembly-language instruction set. Here is one, with main features of 64-bit addressing and 128-bit data-processing registers (and 128 bits of data at every single address, instead of 8), which was declared Public Domain (last paragraph) back in 2001. Ahead of its time, it is now easily possible to build, and perhaps, because of progress in inventing new instructions since that time, should be upgraded to 256-bit data-processing (while still using 64-bit addressing, because we can expect to not need more than that for a couple more decades). Enjoy!

Re: It has to start somewhere

[Anonymous Coward]

>Basically the best you'll be able to say with a purely open source CPU is, "buy this for 10x the cost and at 1/10th the performance... but you can feel good that it's open source." At that point, all I can say is, "good luck with that."

It absolutely has to start somewhere. With folks like you, we'd have never gotten to the moon.

Just because it's hard, and you don't personally like the potential outcome, doesn't make it unworthy, in itself.

Why not the MMIX?

[aglider]

It looks great!

Re:Can We Replace Intel x86 With an Open Source Ch

[hcs_$reboot]

And even if we had an open source CPU, the fix wouldn't be any faster: the "bug" (actually design issue) that has been existing for 20 years, is based on having as much speed as possible, while keeping data safe (data is not "retired" if it's not supposed to be seen by the user). And that work(ed) well. These new attacks based on the time taken by the CPU to load some data into the cache, or not if it's there already, are subtle, really clever, and the fix at the CPU level requires a lot of deep changes.

I have a question

[Anonymous Coward]

Today, we can easily attach many gigabytes of RAM to a CPU. It's not only possible, it's practical.

So for a home computer, with say, 64 or 256 gigabytes of ram, or hell, a terabyte, why do we need an MMU that translates memory addresses?

Wouldn't one that just enforces process execution bounds be enough? And cost a lot less silicon, and speed, and therefore tears and money?

Give me a 64 bit address bus, I'm pretty sure I'd be able to run any app that mattered to a consumer at this point in time, as long as you let me add RAM.

As an old-school ASM programmer, it also seems to me that a really good CPU design would provide a couple hundred thousand register sets, so that process, task and thread switching would not be constantly, and slowly, fudging around with context. It's not like memory is expensive any more.

Re:I have a question

[Anne Thwacks]

why do we need an MMU that translates memory addresses?

You might want to read all the stuff about Meltdown!

The MMU is supposed to keep each thread's data private

Re:Can we standardize on big-endian or little-endi

[Improv]

Conversion really is not that hard.

Re: How does an open source chip solve the problem

[aglider]

Sure. But if a cpu costed 50 bucks then you'd ready to replace it with a fixed one.

Hazarding a guess

[fyngyrz]

Do the last 20 Slashdot posts really end with a question mark?

No?

x86 Forever, Even Intel Couldn't Kill It

[MSTCrow5429]

Intel tried to kill x86 four times, to varying degrees: First the iAPX 432, then the i960, then i860, and most recently with the Itanic.

MS Windows NT tried become a popular option on PowerPC, MIPS, and DEC Alpha, because MS didn't want to be so heavily reliant on Intel. It ended up being forced to stick with x86 (Itanic doesn't count).

Intel will soon begin pumping out x86 CPUs that aren't vulnerable to Meltdown or Spectre.

Trying to create what is essentially a new and unique system architecture, for general-purpose users, is a dead end. Who's going to make the chipsets, much less the mobos?

Re:x86 Forever, Even Intel Couldn't Kill It

[Bert64]

Alternative architectures fail because of closed source code...
All of those architectures failed on NT primarily because there was little or no software available for them, whereas there are millions of (usually embedded) PPC and MIPS systems running Linux even today.

Software vendors won't port to an architecture that has no users, and users won't buy an architecture that has no software.

Re:x86 Forever, Even Intel Couldn't Kill It

[MSTCrow5429]

Yes, by general-purpose I meant servers, desktops, and laptops. I know what I have running say MIPS or ARM or SPARC (it's the printer!), but for most people that's completely invisible and beyond all thought and concern.

You had my attention until...

[Anonymous Coward]

I saw "Cloud-centric future" in the title. I'd rather have a buggy chip than live in that kind of world. Long live the desktop. There's a reason why TSA can't force people to open their cloud accounts. They don't need to. I'm a Linux user and I don't use Google services beyond Youtube as embed MP4. All those guys do is yell "open source please use our programming language (Go) and nothing else." I really wish people understood the data cattle hell this crap creates. You are not special enough for anyone to care to hack you anytime soon, but no one has to hack your cloud. There are backdoors and numerous bots crawling all over those services, on top of which the biometrics you've supplied on social networking and the digital fingerprinting that has been paired with it. Your ssl is becoming useles because they know it's you from browsing habits and canvas recording. If you do go cloud, make your own.

lots of room for innovation

[bugs2squash]

At least some of the complexity of these modern CPUs seems to be in their hardware-implemented on-the-fly code optimization. If more of that could be done by the compiler or runtime software (maybe creating CPU designs that are especially amenable to that kind of outside assistance) then maybe the CPUs could afford to be simpler

By the same token, memory technology seems to me to be overdue for a breakthrough that would improve speed

Maybe there are some ways to reduce CPU complexity by shifting the burden of mitigating sub-optimal instruction sequencing and slow memory to the point where today's hyper expensive, top-end FPGAs would be up to the job, and then drive the volume to bring down the cost and spur FPGA innovation.

An open source CPU shouldn't try to beat intel at its own game, it should change the playing field

Re:lots of room for innovation

[Bert64]

Intel tried that with IA64, an architecture that depends on compiler optimizations to get good performance...
IA64 could be extremely quick with properly targeted code, but compilers weren't up to the job and the chips were too expensive.

Another problem you have with x86, is that a lot of code is compiled to target the lowest common denominator, not to target the current model cpu, so even the latest processors have to be designed to optimize code thats been compiled to run on a 386. If you're precompiling code for wide distribution you have to set the lowest supported cpu somewhere, and if you set it too recent you'll improve performance but exclude lots of potential users.

Re:lots of room for innovation

[bugs2squash]

I think DEC Alpha had the same issue with compilers, but compilers must have moved on since then.To your point about code being compiled for the lowest common denominator I would say that :

(a) With a fresh start surely some of that baggage could be left behind

(b) A compiler can be written that takes x86 machine code as its source, it would then (re)compile and optimize it for a new platform

I suppose I see CPUs as being like web browsers, they now need an adaptation layer in the middle to bridge the gap between the features they offer and what the code calls for / the form that it takes

Re:lots of room for innovation

[Bert64]

Alpha had the same issues to a much lesser extent, it was also around longer so compilers had more time to mature on the platform, and it was so much faster than other processors available at the time that inefficient code was less noticeable.

With a fresh start some baggage can be left behind, eg 64bit x86 software generally makes use of SSE2 as the lowest common denominator become the first Opteron chip instead of a 386, but even a first gen Opteron is pretty dated these days.

Gentoo users experience a small but worthwhile increase in performance by compiling their code with the correct -march/-mcpu flags irrespective of any other optimizations they might be using, there is also a linux kernel patch that enables such flags for kernel compiles. And this is on x86 where intel/amd go to great lengths to make the processors able to execute older code quickly. There would likely be a bigger difference on other architectures.

Re:Can we standardize on big-endian or little-endi

[hcs_$reboot]

We used to have a lot of Motorola, but now that Intel dominates the market, most processors are little-endian. Not a defined standard (why would we make one), but a kind of standard by popularity.

Re: It has to start somewhere

[Anonymous Coward]

Well, you can start with it whenever you want. Tell me when youâ(TM)re finished, please.

Separate the silicon

[kfsone]

The requirements of the kernel and scheduler are largely different than the requirements of the main processing cores/threads of a CPU.

Giving the scheduler its own die/core/silicon would allow it to have cpu-reflection primitives so it can make more informed decisions, and the benefits of not having an interrupt come along and stomp your cache/bus states would help high-perf apps a lot.

Think about a big-data or finance linux server architecture for a moment. You have these finely-crafted, high-perf processes burning cpu threads to try and process expensive data loads and, when you paw thru the code, you find lots of repetition of scheduling and system reflection for self tuning, because the operating system does such a terrible job of scheduling once you stop pretending it's a 386 system.

You need a lot more insight into CPU state to be able to determine whether super-massively tuned, false-cache-avoiding, cache-warming super-app or "tail -f" would be worst affected by swapping it with a bash process or syslogd or ...

Providing some dedicated kernel silicon would (eventually) be massively advantageous. Initially for virtualization and containerization, but ultimately (if you think it through) having the bulk of the kernel or it's facilities on separate silicon would have huge benefits.

Obligatory:Intel CPU Backdoor Report (Jan 1 2018)

[Anonymous Coward]

Obligatory:Intel CPU Backdoor Report (Jan 1 2018)

Change log:
2018 Jan - Added 14 Useful Links, Intel CPU CVE links (CVE-2017-5689 CVSS Score 10.0), how to disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode.

Intel CPU Backdoor Report
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.

What we know about Intel CPU backdoors so far:

TL;DR version

Your Intel CPU and Chipset is running a backdoor as we speak.

The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.

30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.

[Quotes] Vortrag:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".

"We can permanently monitor the keyboard buffer on both operating system targets."

Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.

2017 Dec Update:
Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP bit.

Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.

If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).

Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented mode (NSA High Assurance Platform mode)
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
EEF: Intel's Management Engine is a security hazard, and users need a way to disable it
Sakaki's EFI Install Guide/Disabling the Intel Management Engine
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
CVE-2017-5689: An unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs
CVE-2017-5705: Multiple buffer overflows in kernel in Intel Manageability Engine Firmware
CVE-2017-5706: Multiple buffer overflows in kernel in Intel Server Platform Se

Re:Can We Replace Intel x86 With an Open Source Ch

[TheRaven64]

It's not the fab costs, it's the ecosystem costs. Getting an OS and a C compiler working with a new ISA is fairly expensive. Getting them working and optimised is more expensive. Now add in tools like debuggers, valgrind, and so on that all have large architecture-dependent aprts. Add in all of the other languages (Java, JavaScript, and so on) that people care about having high-performance JITs for and it's even more. The RISC-V team conservatively estimates the cost of recreating the ARM software ecosystem at $1bn (ARM estimates it at about double that, the reality is probably somewhere in the middle). You can design and fab a small run of chips for a few tens of millions, which is cheap in comparison.

No

[Anonymous Coward]

The thing is that in the software side, most widely used OS seems to be a pile of spaghetti spyware, which most have been shoveling same crap year after year with different OS name/number. To be fair spyware was introduced in 10, and updated to older ones but anyway, there weren't much if any innovation coming from Microsoft, until they introduced w8 which basic "innovative ideas" users hated. Like the idea of: " let's bring same experience from phones to a desktop", yay. Still think best things microsoft has done are Visual Studio, DirectX and AD. DirectX is the thing that keeps Windows popular. As an OS windows is actually kinda terrible (low level of customisation, still no real package management, a lot of advanced settings are now locked to enterprise version which us lowly professional users cannot get without founding company).

I might be wrong but to me, it seems that AMD and Intel actually try to refresh their design every couple of years and to be honest there are a lot of smart people employed by these folks and Intel has deep pockets when it sees something it likes. Problem is also the physical aspect, while anyone can make code basically free, making the actual physical chip would cost real money to produce. I guess you could do simulation, but i don't think simulators Nvidia uses are that cheap.

Re:No - Please forward to Lenovo -

[Anne Thwacks]

I have never used an SGI machine at all, and only used MIPS in embedded machines. However, someone needs to tell Lenovo that the present situation is opening the way for massive sales of a MIPS based Thinkpad and they have the leverage to get a new iteration of Loongson and sell it in the volume needed to be profitable - hopefully by putting it in a T5xx case with a great screen.

Loongson has targeted cheap - now is the opportunity to go up market by the targeting secure and open source markets.

MIPS is basically a good architecture, and Lenovo has a good grip on how to do volume and quality.

Secure, Open source, Volume and Quality markets: they surely should get volume from that while Intel is out of the running - and even when Intel do produce a CPU that is slightly secure, they still have the ME and trust issues! It might be a big window of opportunity - And Lenovo buying Chinese and selling in the west should be politically supported and cheap.

We have to hope that they understand NOT to go cheap on this - the cheap market won't care about quality, and will want spyware^H^H^H^H^HWindows. I normally use OpenBSD, but would try Octane if it was available - I know other people who like it.

Maybe

[SurenEnfiajyan]

I think it's possible, open source hardware is much easier to sell than open source software because unlike software it's a physical object. Just having the source code isn't enough to "compile" it, it will cost you much.

Sounds like a good idea in theory

[cyber-vandal]

Unfortunately what you'll end up with are dozens of incompatible CPUs and never ending holy wars that get in the way of getting work done.

Re:Sounds like a good idea in theory

[SurenEnfiajyan]

Intel and AMD chips are not 100% compatible either. Also chip production isn't cheap. Chips are physical objects, unlike software just having the source code isn't enough to "compile" it.

Yes we can but...

[Foske]

It is rather trivial to make a processor which can run up to, say, 500 MHz. Above that, things start to become more complicated. When Intel was getting close to 1 GHz, they actually had to throw out digital designers and get guys in who understood analoog, for the simple reason you can't get there with simple digital synthesis tools alone any more. So, the answer is no, unless you want a Pentium 3.

Re:Yes we can but...

[ledow]

Follow the links in the article and get to the place that actually sells the above "first 64-bit open-source RISC-V chip".

They tell you:

"In its standard configuration, before any third-party modifications or overclocking, the 64-bit, multi-core U45-MC Coreplex has four U54 CPUs and a single E51 CPU, each running at 1.5 GHz. SiFive said "

So, though it might be hard, it's not impossible at all. Someone's done it, in fact. And looking at any cheap laptop seller, you'll see 1.5GHz chips in there (even from Intel!).

So it certainly captures enough of the market to be viable. The other issues (of software compatibility, actual performance, power usage, security, etc.) are still to be beaten, but it looks viable to me.

With the right coding and effort, you could turn that chip into an fully-working Android-based device, for instance, and be open-source top-to-bottom.

Ahhh..the open source axiom

[Anonymous Coward]

Techno hippies believe that (open source = best way) is some kind of obligatory axiom we must all just accept without question. Fuck that noise.

Not on silicon

[CanadianMacFan]

You can't create an open source x64 chip because you would need to license the instruction sets (x86, SSE, x86_64, ...) from Intel and AMD, as they have cross licensed them from each other.

The best way to approach it would be to create a new processor (along with motherboard because it would need a new socket) running it's own instruction set. Then have the open source operating systems move over and use virtual machines to run Windows, Mac, etc. Even better would be to build something like Rosetta from Apple when they moved from PowerPC to Intel which ran the apps seamlessly together.

NOT

[Anonymous Coward]

According to wikipedia, Loongson also has "four-way superscalar, out-of-order execution, 64-bit MIPS architecture processor core". So it will most likely have the similar security issues as Intel has.

It really helps to use BRAIN before typing.

Yeah, Sure

[Anonymous Coward]

Loongson has most likely similar security issues as Intel, because they also use Speculative Execution. For a long time "speed" was the primary aspect of comparing CPUs. Now the speed chickens are coming home to roost.

Future generations of hardware and software will need a fundamentally different approach to design and verification. Or maybe we simply stop to use computers the way Amazon, Google and Mozilla want us to do. The entire "cloud" and "JavaScript in Browser" things seem to be rotten, as long as they run on almost ANY contemporary processor from x86 to IBM z.

OpenSSL

[Anonymous Coward]

OpenSSL is open source.... then my "heartbleeed". A simple validation mistake.

Nice

[Anonymous Coward]

But just because RISC-V is Open Source does not mean it is secure. It could actually be a horrible mess of thousands of security risks, if other FOSS projects like OpenSSL are taken as an example. Nobody cared to look at the mess of OpenSSL for something like 20 years, probably because it was 400k LOC of nasty shite.

What we need is FOSS plus something else: Formal Proof of Correctness, as they do in the L4 OS kernel or the Compcert Compiler. And no, that is not the same as "writing lots of unit tests".

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.

Re:Nice

[Anonymous Coward]

Bringing in Godel here for this? So all this is like a race between you... and who else, did you say? Starts sounding like a bitcoin mining scare or something...

Meh

[Anonymous Coward]

Everybody, including the Chinese ("Loongson") and the Russians ("Elbrus 2000") seems to be hypnotized by the "need for speed". Intel, AMD, ARM and the rest of the "western world" are *selling* CPUs on the meme of "mine is faster than the competitors".

All of which is understandable to a certain degree. "Speed" translates into time savings, which translates into economic efficiency. Which translates into "viability of your social system". The Russians and the Chinese now from their own mistakes how important economics is for the viability of the entire social system.

I honestly don't know how to fix these issues; maybe we need to use the Transputer Approach and allocate entire CPUs to "untrusted code". Don't share CPUs for "cloud" or "browser code". Then we can still use all the glory of caches, branch prediction caches and speculative execution. All the hostile code can do is to reconnoiter itself, which is benign by definition.

Something from a Russian guy. Judge yourself:
https://zaitcev.livejournal.com/241876.html

"out-of-order superscalar 64-bit core"

[Anonymous Coward]

May I assume this variant has exactly the same Meltdown/Spectre-type issues as Intel has with x86 ?

Then what is the advantage ?

Just because something is FOSS does not mean it is bug-free. See the OpenSSL debacle.

Re:"out-of-order superscalar 64-bit core"

[TheRaven64]

May I assume this variant has exactly the same Meltdown/Spectre-type issues as Intel has with x86 ?

I believe that BOOM is vulnerable to at least some of the variants of Spectre, though I'm not 100% sure. If it doesn't allow speculative execution to fill cache lines (no idea if it does), then it will be harder to exploit. Meltdown specifically requires speculative execution across software interrupts / system calls and I don't know if BOOM does this.

In hindsight, the fact that this kind of speculative execution is a high-bandwidth side channel is not a surprise. A few years ago, I was talking to some of the Apple folk, who found that the new version of their ARM core was much slower on one of their hot paths. It turned out that the old version was speculatively executing the wrong path and causing some data to be faulted into L1 from main memory. The speculated instructions were then quickly cancelled, but the data was in L1 for when they did need it a couple of hundred cycles later. The new core improved the branch predictor, so they weren't taking a small penalty from the mispredicted branch and were instead taking a large penalty from the cache miss later on. Once they figured this out, they could insert a prefetch instruction, but the fact that performance of a later bit of code varied so much based on speculative execution should have been a clue that there were side channels here.

Then what is the advantage ?

Of RISC-V? That there are an increasing number of competing implementations and, because a lot of them are open source, they can cooperate on common components.

Re: "out-of-order superscalar 64-bit core"

[kenh]

Of RISC-V? That there are an increasing number of competing implementations and, because a lot of them are open source, they can cooperate on common components.

Translation: because RISC-V has forked into an "increasing number of implementations" it is poised to take over the world! Just like Linux, right?

Re: "out-of-order superscalar 64-bit core"

[TheRaven64]

RISC-V hasn't forked, because RISC-V is a specification, not an implementation. For a healthy CPU ecosystem, you want a large number of competing implementations. When Intel, Cyrix, AMD, and IDT were all producing Pentium chips, prices went down and performance went up a lot. The ARM ecosystem benefits hugely from having ARM, Qualcomm, Apple, Cavium and others all designing different CPUs. Partly the competition helps push down prices, but it also means that there's less of a need for anyone to try to produce one-size-fits-all implementations. Cavium's 48-core server ARM chips aren't competing with Qualcomm's 4-core mobile ones, but both will run the same OS, use the same compilers, and so on. As a result, both benefit from sharing software costs. Similarly, some RISC-V vendors are looking at high-end superscalar designs, some at low-end microcontrollers, and so on. The open source versions targeting different markets; however, can share components. Rocket and BOOM share execution pipelines, for example, but Rocket has a single one with a fairly simple register file, whereas BOOM has a scheduler and register rename engine attached and instantiates multiple copies of the Rocket pipelines.

Don't pretend that everyone needs a $1999 XEON

[Anonymous Coward]

The vast majority of users and office workers out there could switch to ARM, and whatever per-core-loss they would experience in the same price bracket, would not hamper them or what they do.

We should've moved away from Intel on desktop long ago. With the year-long price-hikes of HUNDREDS OF DOLLARS for just consumer CPUs, and what we've seen now, it should've been clear that the Intel monopoly was only going to cause more damage. With monopoly comes irresponsibility.

Re: It has to start somewhere

[Anonymous Coward]

heh he thinks we went to the moon. whats next, you'll say the earth is round?

You missed a point I already made

[Anonymous Coward]

The MMU is supposed to keep each thread's data private

That's what this was for:

Wouldn't one that just enforces process execution bounds be enough? And cost a lot less silicon, and speed, and therefore tears and money?

IOW, if it's not your memory, you can't get at it. This is a lot less resource-intensive than actually remapping the memory to different addresses, which you shouldn't need if you actually have, you know, your own memory allocation(s).

A dream for a dreamer

[Zeekort]

Written by a dreamer for dreamers. My take on it is they're looking for something other than x86 and x86_64 that's cheap for anyone to use. Well since even IBM's Power systems (I don't recall which models) are susceptible to Specter, jumping architectures won't prevent things like this happening.

I think I understand what they're going for with being able to quickly fix these design flaws when they're revealed, but methinks they don't have any understanding what so ever of how these things are developed and manufactured or that once the chip is made it can't be altered. Sure there are some advantages to being able to jump architectures since some architectures are better for different jobs, but for general computing nothing's been able to topple the x86/x86_64 dynasty (for one reason or another). Not even Intel could do it and you need to license the instruction sets from them! If they couldn't beat their own platform....good luck.

Also, design flaws like these don't break a system. The systems are already up and running and have been running pretty well with them for over a decade. When the new chips come out without the flaw, software designers will be able to speed things back up again. It's not like other flaws that cause miscalculations or fried CPUs.

That said, it must be nice to dream.

Asking the wrong question?

[Anonymous Coward]

Are we asking the wrong question? How about designing laptops, etc so that the components (CPU, mem, etc) have an industry standard interface and are easily replaceable?
People are not going to throw their old laptops away and buy brand new ones just because some security guy says so.
If I could pull the old CPU out of my laptop (and send it back to Intel for recycling!) and pop in a fixed one, I'd be more inclined to do it.

Re: No?

[Anonymous Coward]

64 bits should be enough for anybody :)

Yes.

[Anonymous Coward]

Yes. There is already open source processor, called RISC-V:
https://riscv.org/

Re:Can We Replace Intel x86 With an Open Source Ch

[K. S. Kyosuke]

I often feel like we've designed ourselves into a corner. Or rather, the Jevons paradox allowed us to do that to ourselves. When cranking out gates and lines of codes became extremely cheap, we've taken it as a blank check to create whole systems that are very difficult to fix, duplicate or replace.

RISC V

[backslashdot]

We do need to move to RISC V, the question is how.

The easiest way I see is to convince Apple, or Samsung, or Microsoft to release flagships supporting it. That seems really difficult. But then the other ways I see to get RISC V into the mainstream seem even harder or may take longer.

Diversity is good

[Anonymous Coward]

Biodiversity is good. Some level of CPU diversity is also good.
Unfortunately, there is a huge pile of software which requires x86 and x86_64 as the underlying CPU.
So switch to AMD processors and:
1 - avoid the two recently disclosed nasty security fails in Intel chips
2 - save huge amounts of $$$
the current Ryzen/Threadripper processors are already performance competitive with Intel offerings (prior to knocking off whatever overhead due to extra overhead to fix the problem inside OS kernels)

Full disclosure - I do not currently own stock in either company. Nor am I an employee of either company

Re: No?

[Anonymous Coward]

A few more decades? Try 2.923 billion years since 1970, if we're using UNIX time.

Source: https://www.wolframalpha.com/input/?i=9223372036854775807+seconds

We will not need anything beyond 64-bit time for a loooooooong time.

POWER to the People

[Anonymous Coward]

Every one of IBM's POWER processors has taken about ten years to develop. That's why IBM works concurrently on three generations at a time so they can release a new processor about every three to four years. (POWERx will be released three years from now, POWERx+1 has been in development about four years now, POWERx+2 in development for about a year now).

Re:Can We Replace Intel x86 With an Open Source Ch

[TheRaven64]

I think a lot of the problem is a feedback cycle that I've complained about before: people write C code, because C is fast. People design processors optimised for C code, because performance-critical code is written in C. This has led to a push for high-levels of instruction-level parallelism (and therefore speculative execution), because that's the easiest way of getting good performance out of a language that's designed to be close to the metal, when the metal in question is a PDP-11. If you designed a processor for a language that had cheap thread creation and enforced immutable-xor-shared, such as Erlang, then you would have a lot of cores, much simpler cache coherency (anything where two cores are accessing the same mutable data is either a bug or a thread migration event, and so can be slow), no speculative execution, no need for high ILP. You might dedicate more transistors to making context switches fast (even allowing cores to have an arbitrarily large pool of threads that they can pull in from memory when some of the ones occupying hardware contexts are blocked). If you don't care about ILP, then suddenly the big advantage of register machine instruction sets over stack machines goes away (ILP from stack machines is hard) and you're left with stack machines giving better code density.

The thing is, we know how to build these machines. There are commercial projects with most of the characteristics that I've outlined and research projects with the others. My hope with the Spectre debacle is that we'll see a some new chips that are faster when running code written in higher-level languages than they are running C programs.

Just like Windows 10, Samsung, Roomba

[Anonymous Coward]

All are now untrust-worthy data thefting scum.

Re: It has to start somewhere

[kenh]

Just because it's hard, and you don't personally like the potential outcome, doesn't make it unworthy, in itself.

Nor does that require him to support it either. Your support of an idea doesn't require everyone else to suspend disbelief and support your idea.

So what are we really talking about?

[kenh]

How long would it take to get an 'Open Source chip' to the point that it can run xbill or support a current standards web browser? Heck, how long would it take to make a system that can handle console I/O, store data on SATA drives, and connect to an Ethernet network?

If all design decisions were made, no changes needed, how long would it take to come up with either a chip that plugs into an existing motherboard, or a board that includes both the processor and all supporting I/O, like say a Raspberry Pi does?

The answer is hundreds and hundreds, if not thousands upon thousands of worker-years, and if this is a truly free, open-source effort, don't forget to multiply the above estimate times some multiplier that each worker will only be part-time before you try and 'spit-ball' a number of calendar years before it is available.

RMS famously spent decades trying to develop his own software environment that ran on commercial hardware and failed, due to in-fighting and his constant quest for the ever-elusive, always-evolving "best" architecture for his Kernel... Then Linus came along, cane up with a 'good enough' Kernel and made 'Linux'. As RMS will tell you, Linus didn't build Linux on his own in 18 months, he leveraged countless years of work by hundreds of GNU contributors and came up with the one thing RMS was missing - that's the part that took 18 months.

How long would it take...

[kenh]

How long would it take for the imagined 'open source chip' to be as fast, feature-full, and robust as a $35 Raspberry Pi is today?

Re: Obligatory:Intel CPU Backdoor Report (Jan 1 20

[kenh]

A link would have sufficed, that was the Slashdot equivalent of sending an email with a 12 Meg attachment...

Re: Not unless the FPGA/Fab process is also Open..

[kenh]

There are easier ways to build a pree-2000 era PC than design your own CPU and scrounge Pentium MB/IDE drives.

ARM in all this

[JIDatiT4C]

ARM is now owned SoftBank Group - but I wonder what the ARM originators - Steve Furber (Manchester University) and Sophie Wilson (Broadcom) - and first ARM CEO Robin Saxby (retired but active) think about this fiasco?

Sure

[ebvwfbw]

It could be done. You'd have to find one really smart dude to pull it off. Even then, they'd give it away? Not impossible, things like that happen. Very unlikely though.

Even then the big guys would be very quick to shoot it down. Make up lies. Their bottom line depends on it after all.

Check out Amber and the OpenCores project...

[Anonymous Coward]

Amber is an ArmV2 knockoff that is open sourced. Also the OpenCore project has a lot of open sourced stuff including some processors.

Yes!

[Anonymous Coward]

And an integrated open source GPU!