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

[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

[toonces33]

Just 3-d print the things.

Re:No

[K. S. Kyosuke]

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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]

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

[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

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

[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 (;-))

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!

[kaizendojo]

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

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?

[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?

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

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

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

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.

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

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

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?

[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?

[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?

[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?

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

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.

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

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

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.

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

[hcs_$reboot]

Or you could disable the current CPU cache...

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

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

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.

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.

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.

RISC-V

[whoever57]

Is no one going to mention RISC-V?

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

[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

[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

[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?

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.

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.

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

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

Re:Transmeta?

[schematix]

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

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.

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

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

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.

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.

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!

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.

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.

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

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.

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.

Re: Are you not an idiot?

[Hal_Porter]

Yup.

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.

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.

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.

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.

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

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

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.

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.

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.

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

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.