OSDev.org

Intel produced the first microprocessor (a major leap in its own right), and gained traction in the marketplace with the 8008 and increasingly the 8080. Their meteoric rise, of course, is attributable to the 8086/8088, which IBM picked because it was, of the processors available at the time, (A) cheapest, (B) could address more than 64kB of memory (a necessity of the era), (C) had a large suite of peripheral chips (simplifying the design and making it cheaper), and (D) required minimal external glue.

AMD started as a second source of Intel; they never had to break into the market to anywhere near the same extent. Consider that, if you sell a compatible microprocessor to an existing market-dominant party, then it is only the capabilities of your hardware, your cost, your marketing and any contracts your competitors may have taken out which restrain you. AMD64 was a simple offering of what everybody wanted (x86 compatible 64-bit CPUs) while Intel was caught with their pants down (they believed their own IA64 kool-aid, while anybody with in-depth knowledge of CPU design should have seen the disaster of a design that was a mile away)

ARM, of course, was purpose built by Acorn for their RISC PCs; it kind of fumbled along in that space for a while. When developing the Netwon, Apple went hunting for a low power, low interrupt latency, high performance processor. ARM was closest to their requirements, so they worked with Acorn to spin off the ARM division as Advanced RISC Machines, where they co developed the ARM610, which was used in the Newton. ARM cores were low power, small, and available for licensing; they were the right core at the right time, and therefore started getting designed into everything from PDAs to fridges.

Note that, in both the cases of Intel and ARM, they were architectures with cores available in the right place at the right time. Or, they happened to find their niche before anybody else did. This is a market where inertia is not to be underestimated.



The Mill will always suffer the intrinsic disadvantage that it will never be able to match Intel's fabs, nor volumes. Unless they have managed to secure very significant investments, they will not be able to afford leading edge process nodes. This will limit clock speeds, power efficiency, and therefore performance. They will be paying higher prices per CPU, because their CPUs will cover a higher silicon area and will be produced in lower volumes, plus the need to recoup high setup costs. Additionally, larger silicon areas mean lower yields.


Some of the benefits will be available while running 'legacy software', but not all. Unmodified apps will be unable to exploit portals, for example



I wish them luck; they have good people. I think their architecture design commits some sins (there are already something like 4 sub variants of it, for example; all upwards compatible, but of course you need to recompile your code for each variant for best performance. They are nearly committing the VLIW sin). Their best bet is to enter the supercomputer space, I think; but I'm not sure they can muster the resources to do that.

A lot of their performance comes from the Belt. This is very clever, but hard to implement into existing processors. In other words, I would not expect it to transition to other hardware. Some of their other functionality might. Things like portals are cool, but probably difficult to transfer. Additionally, much existing software is engineered around the expense of system calls; in other words, "legacy software" is written to avoid system calls, which means system calls are not generally a major optimization target for processor designers.

Hi,



Exactly. If you have a look at CPUs, we've mostly got 80x86, ARM and MIPs dominating different markets. They are all about 30 years old, and nothing that's been introduced in that time (including Intel's own Itanium) had significant market penetration. The closest is PowerPC/Cell (still 20 years old), and only due to major funding from a massive company who had their own foundries (IBM).



Until working chips are actually available they can estimate whatever they like. If the chips are ever available in usable/working systems, then we can find out how wrong their worthless estimates were.



Yes; and without software that's able to exploit key features (e.g. portals) they aren't going to get the "10x performance/power increase" they've estimated.



I wish them luck too (I honestly do hope to see systems using Mill one day, I just don't think I ever will).

I'm not too sure about the super-computer space (I doubt there's a lot of profit to be had there, and suspect a lot of CPUs used in super-computers were sold at little or no profit just for marketing/publicity). Instead; I'd be tempted to look at gaming consoles (much larger number of units sold, no backward compatibility, minimal OS if any, etc).


Cheers,

Brendan

On Owen's points- I agree, the Mill will need to start from some smaller niche before it has any chance of getting bigger, and it will probably take a while to grow from there. But there are definitely niches they could fit in, and they are designing their business model around that. I mentioned server farms because they care a lot about power usage and parallel processing, both areas the Mill's design is strong in. Another possibility, like Brendan mentioned, is game consoles, which care a lot about price, and for mobile games/phones which also care a lot about power consumption. It's also much easier to try out new CPUs in both those fields because they care less about backwards compatibility.

Legacy software will be able to take advantage of portal calls as a fast version of system calls and IPC, since that stuff is in libraries that need to be ported to new architectures anyway. For their subvariants, recompilation is in fact required to run at all, not just for best performance- but they also have a standard format that's compatible with all of them. This is probably the biggest hurdle to porting any OS, but it's not like it's an unsolved problem- OS X has been handling similar situations for years, for example.

Why so skeptical of their performance estimates? It's not like it's a brand new concept with no precedent to compare with- the design is heavily inspired by DSPs, which actually achieve those numbers. The 10x increase is not due to OS-area features like portals anyway- it's due to the belt, static scheduling with deferred loads rather than OoOE (yes this is a win, not an almost-sin-of-VLIW), the fast call mechanism, asynchronous state saving/restoring, the improved cache architecture, the unprecedented issue width (30+ MIMD per cycle!), and the strong software pipelining and vectorizing support (no prelude/postlude, no early exit cost), etc. Those are all performance/power wins at the level of just recompiling random application code, and that's where they get their "10x" number.