ARM Announces 64-Bit Cortex-A50 Architecture

MojoKid writes "ARM debuted its new 64-bit microarchitecture today and announced the upcoming launch of a new set of Cortex processors, due in 2014. The two new chip architectures, dubbed the Cortex-A53 and Cortex-A57, are the most advanced CPUs the British company has ever built, and are integral to AMD's plans to drive dense server applications beginning in 2014. The new ARMv8 architecture adds 64-bit memory addressing, increases the number of general purpose registers to 30, and increases the size of the vector registers for NEON/SIMD operations. The Cortex-A57 and A-53 are both aimed at the mobile market. Partners that've already signed on to build ARMv8-based hardware include Samsung, AMD, Broadcom, Calxeda, and STMicro." The 64-bit ARM ISA is pretty interesting: it's more of wholesale overhaul than a set of additions to the 32-bit ISA.

Comments

Eventually...

[Anonymous Coward]

As much as I love to read about these kind of announcements, I know it will be ages before I actually get to use something like this. It seems like I've been hearing about 64bit ARM processors forever now.

Relaunch

[Anonymous Coward]

The 64-bit ARMv8 became available over 12 months ago and no one is making any yet.

Re:Relaunch

[Anonymous Coward]

The 64-bit ARMv8 became available over 12 months ago and no one is making any yet.

That was the instruction set. These are the chip designs.

Re:Relaunch

[TheRaven64]

The first drafts of the ARMv8 architecture became available to a few ARM partners about 4-5 years ago. They've since been working closely with these partners to produce their chips before releasing their own design. The aim was to have third-party silicon ready to ship before anyone started shipping ARM-designed parts to encourage more competition.

ARM intentionally delayed releasing their own designs to give the first-mover advantage to the partners that design their own cores. In the first half of next year, there should be three almost totally independent[1] implementations of the ARMv8 architecture, with the Cortex A50 appearing later in the year. This is part of ARM's plan to be more directly competitive with the likes of Intel. Intel is a couple of magnitudes bigger than ARM, and can afford to have half a dozen teams designing chips for different market segments, including some that never make it to production because that market segment didn't exist by the time the chip was ready. ARM basically has one design, plus a seriously cut-down variant. By encouraging other implementations, they get to have chips designed for everything from ultra-low-power embedded systems (e.g. the Cortex-M0, which ARM licenses for about one cent per chip), through smartphone and tablet processors up to server chips. ARM will produce designs for some of these, and their design is quite modular, so it's relatively easy for SoC makers with the slightly more expensive licenses to tweak it a bit more to fit their use case, and companies like nVidia, TSMC and AMD will fill in the gaps.

The fact that ARM is now releasing their own designs for licensing means that their partners are very close to releasing shipping silicon. We've seen a few pre-production chips from a couple of vendors, but it's nice to see that they're about to hit the market.

[1] ARM engineers consulted on the designs, so there may be some common elements.

Re:Relaunch

[Nutria]

The fact that ARM is now releasing their own designs for licensing means that their partners are very close to releasing shipping silicon.

2014 doesn't seem "soon".

Re:Relaunch

[TheRaven64]

It helps if you read what I wrote, rather than pasting random bits out of context. ARM Cortex-A50 chips are likely to appear in 2014 (maybe earlier, but probably not much earlier). ARM partners such as TSMC, nVidia, and Qualcomm, who have been developing their own ARMv8 implementations for the last 3 or so years are due to release production silicon in the first half of next years - they're shipping samples to their partners now.

Re:Relaunch

[pchan-]

In the first half of next year, there should be three almost totally independent[1] implementations of the ARMv8 architecture, with the Cortex A50 appearing later in the year.

Can you name the three vendors? Qualcomm for sure. Marvell seems likely. Nvidia says they will have a chip out, but I have serious doubts about their ability to deliver.

Pretty close to a dupe

[Freshly Exhumed]

http://hardware.slashdot.org/story/12/10/30/0413251/amd-licenses-64-bit-processor-design-from-arm

Re:Pretty close to a dupe

[Anonymous Coward]

Wow, you actually found another story on /. talking about a new technology? Do you provide this service for iPhone stories as well?

Re:AMD?

[Anonymous Coward]

I work at a tech company, and almost everyone I know there owns an APU based machine - generally for HTPC uses, or so they say. Yes, it is true that the fastest chips are made by Intel, but when you look at the cost of typical (not high end) machine, AMD is hard to beat, especially when the graphics in and APU will work fine for you.

What a clusterf**k.

[Anonymous Coward]

most advanced CPUs the British company has ever built, and are integral to AMD's plans to drive dense server applications beginning in 2014

OK. Got it.

The Cortex-A57 and A-53 are both aimed at the mobile market.

Huh?

Re:What a clusterf**k.

[TheLink]

AMD wants them for dense servers. The CPUs are aimed at the mobile market. Wearable servers FTW!

We'll be doing our virtual telepathy and telekinesis using SOAP, Java, XMPP, etc. Maybe they should add hardware acceleration for base64 encode/decode and XML compression/decompression ;).

Re:What a clusterf**k.

[Anonymous Coward]

glad someone else caught that... got scared I was loosing it.

Re:What a clusterf**k.

[TheLink]

I'm actually half serious about the wearable server thing. Add thought macro tech, location/area servers and we can do that virtual telepathy/telekinesis thing.

Unfortunately I'm not confident AMD will have great success in whatever they're trying to do with ARM servers. Maybe if Facebook and Google like what they are making.

ARM builds chips?

[Gothmolly]

So ARM is producing chips now?

Re:ARM builds chips?

[NatasRevol]

Architectures.

It's the last word in the title.

Re:ARM builds chips?

[Anonymous Coward]

No. Next question.

Re:ARM builds chips?

[rwise2112]

Architectures.

It's the last word in the title.

So I'm suposed to read the whole title now!

Re:ARM builds chips?

[NatasRevol]

Why bother when I'll correct you!

Yay Cortex A-15!

[CajunArson]

Hey Guys,
    Don't you just love how it's 2010 and the Cortex A15 already out on the market!

http://www.electronics-eetimes.com/en/arm-in-servers-push-describes-the-cortex-a15-cpu.html?cmp_id=7&news_id=222903607

Oh wait.. the first real A15s just launched literally this month and except for Samsung they won't even be on sale from other manufacturers until next year.

Now we're going to be hearing non-stop about how the 64-bit ARMs will be here next Tuesday and take over the world and put Big-Bad Intel out of business so that Apple & Samsung can sell us non-modifiable devices with locked-down hardware apparently this is supposed to make Linux take over... somehow...

Re:Yay Cortex A-15!

[CajunArson]

Look at the article in detail. Isn't it funny how the A-15 is the super-miracle chip that is going to stick it to Intel in the server world! Oh wait.. now that super-miracle chip is the 64-bit ARM Miracle Chip (TM) and the A-15 has been relegated to smartphones instead of taking over the server world.

Fortunately, Intel is completely incapable of making any improvements to its chips whatsoever, so ARM's victory in 2014 is assured.

Re:Yay Cortex A-15!

[Pulzar]

Well, ARM designs the IPs that will go into those products... and they are ready to start selling the IP. It takes a couple of years to build SOCs around them, and then to build the devices.

ARM is selling their product now, their customers will announce their products when they are ready. You can't expect them to keep quiet about what they're trying to sell until it's in an actual phone.

Re:Yay Cortex A-15!

[rs79]

x86 is kind of at end of life. evolve or die.

Re:Yay Cortex A-15!

[Guppy]

Well, ARM designs the IPs that will go into those products... and they are ready to start selling the IP. It takes a couple of years to build SOCs around them, and then to build the devices.

I've been wondering about just how much lead time they gave their partners prior to this announcement. Given the rate at which AMD is burning cash and credibility, I doubt they can afford a lead-time that's too long.

More likely, there was some development going on in parallel between ARM and their partners. If I had to guess, AMD started the move to ARM about the time they began discussions on purchasing Seamicro, and soon after lost a bunch of senior executives and engineers (at least some of who probably disagreed over the migration from x86 to ARM).

Re:Yay Cortex A-15!

[friesandgravy]

Oh wait.. the first real A15s just launched literally this month and except for Samsung they won't even be on sale from other manufacturers until next year.

The Nexus 4 will be available in November.

Re:Yay Cortex A-15!

[Whiney Mac Fanboy]

Apple & Samsung can sell us non-modifiable devices with locked-down hardware apparently this is supposed to make Linux take over

The vast majority of Samsung ARM devices are modifiable & do not have locked-down hardware. Apple on the other hand does, but I have no idea why you think Apple's locked down devices are going to help Linux take over (wtf have you been smoking?).

Re:Yay Cortex A-15!

[Anonymous Coward]

IBM's PowerPC A2 on a 45nm process consumes 65-watts at 2.3Ghz, that's 4-watts per core. Now really would you rather have a slow ARM A-15 on a 32nm process consuming about a watt, yet its over twenty-times slower then PowerPC. Imagine when the PowerPC A2 goes to 32nm. Tough decision should i choose a 16-core PowerPC A2 which might use about 3-watts per core, or a ARM A-15 dual-core which is slow as hell using about a watt of power. You Union-Jacks keep pushing that slow ass ARM architecture, yet PowerPC is the obvious choice for low-wattage high performance servers.

Re:Yay Cortex A-15!

[Anonymous Coward]

Nexus 4 is using Qualcomm Krait, not Cortex A15.

Krait is smaller and more power efficient than ARM's designs. ARM also gets bugger all licensing fees on it, a few cents a core I think.

Re:Yay Cortex A-15!

[hairyfeet]

LOL Wut? ARM has YET to hit even the IPC of a Pentium 4, how many years ago was that chip released? They aren't even close to the Core series, and in case you ain't noticed companies like Nvidia, that have sank BIG bux into ARM, are having to pile on the cores to get decent performance which of course blows the power budget to shit.

The simple facts are 1.- ARM doesn't scale and 2.- Its a hell of a lot easier for Intel, who already has insane levels of IPC, to scale down and have low power chips than it is for ARM to scale up and not blow their power budgets. Even the ARM group has been talking of "dark silicon" because their new designs will blow through the power if you run the whole chip, so they are gonna have to shut bits of it off and only kick them on when absolutely needed.

Lets face facts folks, ARM has just about run its course and the consumers want MOAR, MOAR performance, MOAR multimedia, MOAR everything and Intel will be able to deliver that with crazy IPC on their new Atoms and CULV Core chips while ARM will be blowing just as much if not more power than Intel trying to get the IPC up there. Its ironic that the head of AMD is trying to hitch onto ARM when they have the same problem, lack of IPC.

Re:Yay Cortex A-15!

[RightSaidFred99]

Yeah, it's amusing reading some of these posts. History is littered with cocky assholes who were going to obsolete Intel and x86.

I will take the opposing view, which I call "reality". Intel is a full process level ahead and 14nm is coming in a little over a year. They are dominant in manufacturing, that helps a _lot_. Remind me what the A6X was manufactured at? Oh, yeah - 32nm. Maybe late next year we'll see 20nm ARM chips...maybe.

They have Haswell coming out with a full blown Core architecture scaling down to 10W. It's foolish to think Broadwell at 14nm won't have at least a 5W part. These new ARM chips are running at up to 5 watts. Here's a free clue: ARM will not compete with core chips on performance, so when they are in the same ballpark of power use ARM is in deep shit.

So here's what the future looks like for ARM: It's much easier for Intel to push high performance core chips down the power scale to the 5 and sub 5 watts market (basically everything but phones) than it is for ARM to scale performance up while maintaining any kind of power use advantage.

Oh, and for the mobile phone market, there's Atom. Probably ARM is hoping Intel will keep it a process behind, e.g. it will move to 22nm next year, then only to 14nm a year later, and that's probably right. Even that will be hard for ARM to compete with, but if Intel were to move Atom to a 14nm process, ARM would be in deep shit even in the very low power market. ARM will have enough problems competing with ValleyView.

Re:Yay Cortex A-15!

[RightSaidFred99]

Concur. ARM is fucked, it's funny people don't see that. They will move back to basically providing only ultra low cost and ultra low power chips. They will see their high end aspirations kicked to the ground, and will be pushed lower and lower in the tablet and mobile phone market over the next 2 years.

What amuses me is the push to e.g. servers. Gee, can I get a server with 1000 cores that's slower in almost every operation than a 16 core Xeon server? Oh, and can you make it useless for virtualizing servers or doing anything but light load trivially parallelizable tasks?

Re:Yay Cortex A-15!

[Hal_Porter]

Smartphones with >4GB are not that far off. There are a couple of 2GB phones already.

So it's likely that Android will have 64 bit kernel and 32 bit userland before long.

Though you can probably kludge it with something like PAE - i.e. a 32 bit kernel with >32bits of address space.

Re:Yay Cortex A-15!

[dkf]

Concur. ARM is fucked, it's funny people don't see that. They will move back to basically providing only ultra low cost and ultra low power chips. They will see their high end aspirations kicked to the ground, and will be pushed lower and lower in the tablet and mobile phone market over the next 2 years.

ARM's core business is processor cores — CPU layouts to laymen — that other companies can take and add their own extra bits to before manufacturing. It's called System-on-Chip (SOC) and it's an area where Intel doesn't have much of a grasp precisely because it involves giving your design to other companies, letting them modify it by adding stuff, and then manufacture it themselves (or through a third-party). Now, it's hardly surprising that the high-end SOC guys want a larger addressing mode; the forces which pushed desktops also push mobile devices and the like.

What amuses me is the push to e.g. servers. Gee, can I get a server with 1000 cores that's slower in almost every operation than a 16 core Xeon server? Oh, and can you make it useless for virtualizing servers or doing anything but light load trivially parallelizable tasks?

I know a few scientists with tasks to do that are embarrassingly parallel and with far more data than you can shake a whole bushel of sticks at. Being able to stuff even more cores into a rack (where power and cooling are usually the main constraints) is going to be of great interest to them. Whether it will beat out GPUs is the real question though. I expect it will for some workloads (ones with more complex conditional processing in the individual units of processing) but not others. And Intel remains the fastest situations where raw single-threaded power is required, which frankly is a lot of code.

Supercomputing doesn't operate under the same constraints that desktop or normal server computing does. Supercomputer makers try to pack as much computing power in as small a space as possible (because delays effectively due to the speed of light are quite a significant problem otherwise). All too often, the main challenge with a supercomputer is stopping it from cooking itself and setting fire to the building...

Re:Yay Cortex A-15!

[Hal_Porter]

I think ARM is very safe in mobile devices. It's low power consumption most ARM chipsets have video acceleration, so it can still play HD video. It's licensable too, which is handy for SoCs. Also the cores are tiny.

Moving to Atom would give phones more CPU power but I'm not convinced there is much need for it. I've got an Samsung Galaxy S2 and it's not like there is anything I do that is CPU bound. Smartphones have poor battery life already though, and a move to x86 is going to make that worse.

Now Intel are talking about licensing Atom, but I think they face an uphill battle. ARM's mix of low thermal power/low CPU power compared to x86 and small licensable cores aimed at TSMC is basically ideal for people like Samsung, Qualcomm and so on. In fact Qualcomm have spent a lot of money developing their own microarchitecture for ARM - the Snapdragon and Krait cores. If they moved to x86 they would not be able to do that. NVidia are obviously graphics focussed. So it's hard to see the ARM SoC vendors switching to Intel.

Of course Intel is safe in servers and laptops because there you do need x86 compatibility and more horsepower even at the cost of a higher power consumption.

Re:Yay Cortex A-15!

[dkf]

I will take the opposing view, which I call "reality". Intel is a full process level ahead and 14nm is coming in a little over a year. They are dominant in manufacturing, that helps a _lot_. Remind me what the A6X was manufactured at? Oh, yeah - 32nm. Maybe late next year we'll see 20nm ARM chips...maybe.

Your ignorance is fascinating. Intel are the biggest single manufacturer, yes, but ARM sells to nearly every other manufacturer. It's a different business model. Let's emphasize that for you: ARM are fab-less; they don't manufacture themselves. A consequence of this is that the process scales for ARM are usually a lot larger, and that's because the non-Intel manufacturers are a generation or two behind. (Intel spends a lot on staying ahead on that front.) But that's OK; the other manufacturers are usually using those ARM cores to produce SOC, that is, a CPU plus extra bits for a specific application (such as hardware for doing 4G mobile comms or video stream processing). Specialist hardware beats a general CPU in the application for which that specialist hardware was designed, which shouldn't be a surprise (it's been true for as far back as I can think).

I'll bet that ARM will only really start worrying about Intel at the point when Intel start trying to sell high-performance CPU cores for SOC use together with the right to use Intel's own fabs to make the resulting parts. Or if Intel start helping other companies to tech up to an equivalent level so as to be able to make parts at the same scale as Intel. Also known as a cold day in hell; that's totally alien to Intel's business model. (Heck, if Intel were to help other fabs to be able to make 14nm parts, I'd bet that ARM would happily produce a 14nm core to use with that process...)

Oh, and for the mobile phone market, there's Atom.

Are Intel licensing that to other manufacturers for SOC use? No? Then it's not a real player; cutting the component count at the overall device level is more important than speed to phone makers, as it's cheaper for them like that.

Re:Yay Cortex A-15!

[hattig]

This type of early release of a core design is standard in the embedded and SoC world.

It takes some time after the core is available for it to be integrated into the SoCs that third parties are designing and building. That's why there is a gap between ARM "launching" a core design, and it being included within a device that you can buy on the high street.

Re:Yay Cortex A-15!

[hattig]

Another post by someone who doesn't consider that ARM is targetting both performance/dollar and performance/watt.

NVIDIA actually adds an extra core because the cores are small enough to do that, and thus have a special low-power core for idling processes. It works very well, it's a shame that NVIDIA's mobile graphics are so lame in comparison.

I have seen no proof that ARM doesn't scale, and indeed this design is targeting on-chip clusters (4x4cores) using the new interconnects that ARM has just started making available.

It is incredibly difficult to scale down a power hungry design to low power - it needs to be done during the design. Haswell will include a lot of that in its design, but it still won't be a 1W core. ARM's designs are targeting ultra low power consumption as a standard mode of operation, hence the big.LITTLE designs (actively switch to/from ultra-low-power ISA compatable cores and high-performance cores).

Consumers are also not asking for more, more, more performance. ARM SoCs include dedicated hardware for the multimedia and security that you mention. Intel's new Atoms (not out yet) may perform better than their old ones, but nobody wants to do comparative tests except in Javascript benchmarks that are extremely well optimised for x86.

Re:Yay Cortex A-15!

[hairyfeet]

Friend, haven't you noticed the trend? Apple is pushing retina, the HDTV companies are set to roll out 4K resolution sets, the fricking games are starting to look Crysis levels of "Holy Shit!" as far as effects and explosions...people want MOAR, moar effects, more explosions, more resolution, moar moar and moar.

Try running a phone from just 2 years ago with today's apps and see how damned pokey it feels, its like a 486DX trying to run Win98, and as I have just pointed out that is going NOWHERE but up. Does that mean ARM is fucked? Nope, i bet they'll hang onto the low end feature phones and probably the low end smartphones as well, but as Apple has shown that AIN'T where the good money is at.

The simple fact is ARM just doesn't scale well, it just don't. to get it up to even the levels of a Pentium 4 from 8 years ago will frankly blow the power budget to hell, now try to get ARM to match the new Atoms and AMD Hondo chips...you can't do it, you'd have a battery life of 10 minutes on the thing because you'd have to make up for the lack of IPC by throwing more specialized cores at it, just as you suggest with HD. This blows your power budget all to hell while Intel who has IPC coming out the ass can simply cut down existing designs and lower the power.

Re:Yay Cortex A-15!

[TheRaven64]

The A15 supports LPAE, so you can have a 40-bit physical address space with a 32-bit virtual address space. This lets you have up to 1TB of physical RAM in your tablet (which might be interesting if you wanted to memory map the flash directly), as long as no single application uses more than 4GB of address space. Given that on my 64-bit laptop, the process with the most virtual address space at the moment is using 1.2GB, I think that's probably a safe assumption for a few years...

Re:Yay Cortex A-15!

[hattig]

I agree that ARM is safe in mobile and tablets. That doesn't mean that Intel won't get a slice of the market, but I don't think that Intel will ever have the flexibility and price advantages of ARM.

Moving to Atom would give phones more CPU power

That's debatable as well, because Intel only offers a single-core, hyperthreaded Atom at 1.3GHz (with some turbo features), that only performs well in Javascript benchmarks. Quad-core A9s and dual-core A15s are more than competitive, and definitely include far better graphics these days - something that people will make use of (games, UI, etc).

ARM have a product for everyone to license. This also adds 64-bits to the mix, in time for 8GB phones and tablets in 2014/2015.

x86 compatibility in servers - only if your running Windows Server. I haven't seen Microsoft crowing about server sales for quite some time, Linux is really the leader here. And Linux runs on ARM. Java runs on ARM. Perhaps it is only a matter of time... Power consumption is already an issue in data centres...

Re:Yay Cortex A-15!

[Anonymous Coward]

With "IP" you mean imaginary property? Lol. If you want to be taken seriously, stop falling for lies and delusions.
You know as well as I do, that physics disagrees, in that information can not be owned.
What would "IP" mean anyway, with the fact that it is utterly impossible to ever control every single human being and computer you sent a copy to...
How would that even work? With DRM/TCPA chips in every brain, computer and gadget/appliance? lol. Yeah, because that *totally* works, and is absolutely realistic.

Face reality: "IP" is a delusion. A mental illness, if you will. Or a lie, if you're somebody profiting from it through what is *fraud*.

You can go "nononononnoooo" as much as you want, and roll around on the floor, screaming, all year round... But reality is that which, if you stop believing in it, doesn't go away. And people making copies, which you can never ever control, isn't ever going away.
You can either accept that, or continue acting like a madman, until nobody talks to you anymore. Your choice.

Re:Yay Cortex A-15!

[Hal_Porter]

That's debatable as well, because Intel only offers a single-core, hyperthreaded Atom at 1.3GHz (with some turbo features), that only performs well in Javascript benchmarks.

I picked a bad example saying 'phone'. Look at netbooks, and servers. Or tablets.

Most of the time the slowest Atom is about as fast as the fastest ARM, and for a bit more $ and Watts you can get a much faster x86/x64 chip.

Re:Yay Cortex A-15!

[TheRaven64]

What would "IP" mean anyway, with the fact that it is utterly impossible to ever control every single human being and computer you sent a copy to

We're talking about CPU designs. If you copy it illegally, then you have to spend a billion or so dollars on a fab. Or spend a few million to buy some time on someone else's (and hope that they don't check with ARM that you're actually a licensee). Enforcing copyright is pretty much impossible on mass-market goods, but when you're talking about something that has a target market of maybe 100 companies (if you're wildly optimistic) then it's not exactly hard to keep track of them.

And buying the ARM license doesn't just get you their core design. It also gets you access to their simulator and their (immense) verification suite, so that you can check if any of the modifications that you made broke compatibility with anything. And, most importantly, it gets you time with ARM engineers. If someone from Qualcomm or TI has a question about any aspect of the ARM architecture, they can get the engineer who designed that part on the phone almost immediately and they can probably get him put on a plane and sent over to them for a week quite quickly if they want more time. ARM doesn't just license their designs, they also license their expertise. ARM engineers spent a lot of time working with nVidia on their upcoming ARMv8 core, for example.

Re:Yay Cortex A-15!

[Hal_Porter]

Actually you're right - a 32 bit kernel with a 40 bit address space can obviously have more than 32 bits of address space.

I remember Windows had a crippled implementation of PAE - memory about 4GB couldn't be paged and could only be accessed with a special API. Basically it was like a Ram disk.

But there's no reason why you could have multiple processes taking up more than 4GB in total - the kernel would just map their address space when they were running and unmap it when they weren't.

Re:Yay Cortex A-15!

[drinkypoo]

The simple facts are 1.- ARM doesn't scale

It hasn't yet. Perhaps it will. So far, it targets a different space than amd64.

and 2.- Its a hell of a lot easier for Intel, who already has insane levels of IPC, to scale down and have low power chips than it is for ARM to scale up and not blow their power budgets

But so far, this strategy has not permitted Intel to achieve as low TDP nor as much IPC per watt as ARM. So you can say that it's easier, but so far ARM has not scaled up as far as Intel, nor has Intel scaled down as far as ARM. When intel delivers a TDP as low as ARM with the same performance, wake me up, and I'll care. Until then, ARM is working fine, and many people are pretty happy with existing ARM-based tablets, as evinced by how well they're selling.

Re:Yay Cortex A-15!

[drinkypoo]

Friend, haven't you noticed the trend? Apple is pushing retina

Except for the new mini-Pad, of course. Apple is pushing whatever people will give them money for. If people will give them more money for more speed, they'll take it. But is the market really demanding it, or has Apple simply discovered that the people who are willing to give them money for their inferior product in the first place are willing to give them even more of it for more and shinier?

Re:Yay Cortex A-15!

[Hal_Porter]

It's interesting I'm typing this on a netbook. That's got an Atom N570 a 1.6Ghz dual core, in order hyperthreaded CPU. My phone has dual core Cortex A9s which are 1.2Ghz out of order and single issue.

If you'd have said five years ago that Arm would go out of order and Intel would go in order, I'd have thought it was absurd. Then again you're comparing the (then) slowest Atom with the (then) fastest Arm.

According to this

http://www.7-cpu.com/

An Atom N270 at 1.6Ghz with two threads gets a score of 1000 MIPS Compressing and 1500 MIPS Decompressing.

An Exynos 4210 at 1.2Ghz with 4 threads gets 1380 MIPS Compressing and 2130 MIPS Decompressing.

Unfortunately there's no result for an N570 but judging by the other results doubling up the number of cores should make it a bit faster than the Exynos 4210. Still it's probably quite close. Which is remarkable actually - the Exynos uses slow mobile SDRAM and the Atom uses DDR2.

Re:Yay Cortex A-15!

[Anonymous Coward]

but I have no idea why you think Apple's locked down devices are going to help Linux take over (wtf have you been smoking?).

Reread the whole comment. Apparently you've been smoking a sarcasm-resistant blend.

Re:Yay Cortex A-15!

[Bengie]

Next gen Intel x86 has a lower idle power draw and better performance/watt than current ARM cpus. I don't know what new ARM cpus may be out next year, but that means Intel has closed the gap on cellphones.

Re:Yay Cortex A-15!

[Anonymous Coward]

Its a hell of a lot easier for Intel, who already has insane levels of IPC, to scale down and have low power chips than it is for ARM to scale up and not blow their power budgets

[Citation required]

Intel have insane levels of IPC because they use insane amounts of power. IPC and power are correlated, yeah? It takes power to run all those parallel circuits that can look ahead in the instruction stream and provide high IPC. The laws of physics work the same way for Intel as they do for ARM. So, why is it easier to scale down than scale up? ARM's major advantage is they don't have to spend power decoding the x86 instruction set. Unless Intel are proposing a new ISA, which they're not, they are always going to have lower feasible performance per Watt. Basic physics. And performance per Watt is what matters on mobile, not IPC. The funny thing is, this is beginning to matter in the server space too. So far from Intel significantly eating into ARM's mobile market, ARM are going to start eating into Intel's server market. For desktops, IPC is way more important than performance per Watt, so Intel are safe for the foreseeable future.

As for "dark silicon", that's Intel main trick for reducing power consumption, so it's a funny argument to make against ARM.

Re:Yay Cortex A-15!

[RaceProUK]

ARM is fucked

Of course they are. Their immense popularity in mobile phones and tablets, and their presence in both the DS and 3DS is such a sign of failure. Attracting enough attention fro Microsoft to port Windows to ARM is also a sign of massive failure.

Have I broken your sarcasm detector yet?

Re:Yay Cortex A-15!

[K. S. Kyosuke]

ARM has YET to hit even the IPC of a Pentium 4

Why would they do that? Do you plan to write single-threaded ARM applications for the next two decades?

Re:Yay Cortex A-15!

[marcosdumay]

and for a bit more $ and Watts you can get a much faster x86/x64 chip.

Or, in ither words, for some less batery life, you can get a computer that performs faster (notice that price doesn't even enter the equation). That may seem like a deal for you, but it is not for lots and lots of people.

The netbooks and servers market is already owned by Intel, ARM can't lose it (they can only gain market share there). Weight and batery life are two of the most important features of a tablet (only comparable to screen size/definition, and OS), it is a tough market for hungry chips.

Most people that claim that ARM is dead arguee that Intel will outinvest them, and consequently get the best portable chip once they start trying. That can't be proven false. But your argument doesn't hold any water.

Re:Yay Cortex A-15!

[TheRaven64]

But there's no reason why you could have multiple processes taking up more than 4GB in total - the kernel would just map their address space when they were running and unmap it when they weren't.

Actually, it's simpler than this with LPAE. ARM has a tagged TLB, and the way LPAE is implemented you don't even need to do the unmapping. LPAE just extends the page table format, so the translation is from a 32-bit input to a 40-bit output instead of from a 32-bit input to a 32-bit output.

Re:Yay Cortex A-15!

[K. S. Kyosuke]

We're talking about CPU designs.

I'm not sure about that. How would ARM react if you designed your own core conforming to publicly-available information on the ARM ISA?

Re:Yay Cortex A-15!

[David Gerard]

x86 will linger like COBOL or Java or Win32.

Re:Yay Cortex A-15!

[TheRaven64]

That depends. If you market it as an ARM core without passing their compatibility test suite, then they'd be very unhappy. Similarly, if you violated any of their patents. But read the rest of my post: the point is that the number of potential customers is small. We actually have an ARMv7 implementation that runs in an FPGA that ARM knows about. They're quite happy with it, because it gives our students experience working with their architecture. There's a fairly widely distributed design from Edinburgh that is very ARM-like, but omits some of the harder bits, and again ARM is fine with it because it uses a different name.

Re:Yay Cortex A-15!

[tibit]

Why oh why is this downvoted? It's +5 informative, with a touch of flamebait. I can't but agree.

Re:Yay Cortex A-15!

[tibit]

For most Linux hosting, I don't think anyone cares a damn about x86 compatibility. As long as there's a Debian and CentOS/RHEL support for the architecture, and a decent Java implementation, nobody gives a damn, I don't think. All the open source stuff can be compiled pretty much for anything you want, and the world-facing web "stuff" typically uses php anyway, so as far as the user is concerned it can run on PDP-11 architecture with paging.

Re:Yay Cortex A-15!

[hairyfeet]

The fanboys can waste mod point but truth is truth and Good Lord Man is that page old and out of date! I don't see what you are trying to "prove" with a test that 1.-Nobody with ANY common sense at all is gonna actually be doing in real life on ANY of these chips, and 2.- A test that has got to be at LEAST 2 years old in the results, which is like a decade on the mobile front! They only have the single core Atoms, they only have the AMD E350, which isn't even sold anymore,....what good is this "test" and what is it supposed to prove? I'm sure I can dig up a test from 5 years ago showing how crappy ARM's IPC is but I doubt it would be of any use except for historical purposes...which considering that actually has 486 chips listed on the page? yeah historical purposes is pretty much ALL the LZMA test is good for anymore.

BTW here is a link of my own, showing that leakage at 50nm can be as much as 40% and that below 50nm it all comes down to the fabs and who has the better process...hmm...I wonder who that gives a serious advantage to? Not to mention that again, its easier for Intel to scale down than for ARM to scale up, since they already have the powerful chips, and the fabs, and the process, while ARM is having to try to crank up the IPC without blowing the power budget AND deal with leakage.

Re:Yay Cortex A-15!

[fnj]

DDR-2? DDR-2! Welcome to the Pleistocene. I am constantly amazed at what a piece of shit the Atom design is. 45 nm and just now making it to 32 nm? Snort. It should be 22 nm like the Ivy Bridge. At least ValleyView is FINALLY getting real graphics, not that third party toy crap.

Atom as a piece of Intel's range (not as a specific design anything like the garbage it is now) has HUGE potential to improve.

Re:Yay Cortex A-15!

[spamchang]

Your Atom specs are false. The Motorola Razr i (okay, not available in the US because it doesn't have LTE) is shipping with a dual-threaded 2.0 GHz Atom core. The next chips due for the holiday sales season will be dual-core, hyperthreaded, and also spec'ed for 2.0 GHz with LTE. The graphics isn't quite there yet, but the gradual move away from third-party vendors will be a step in the right direction.

Re:Yay Cortex A-15!

[Hal_Porter]

Atom design is. 45 nm and just now making it to 32 nm? Snort. It should be 22 nm like the Ivy Bridge

I think it's because Atoms are being made on the TSMC process or one of Intel's older and cheaper fabs to make them even cheaper.

Re:Yay Cortex A-15!

[Btarlinian]

Oh, and for the mobile phone market, there's Atom.

Are Intel licensing that to other manufacturers for SOC use? No? Then it's not a real player; cutting the component count at the overall device level is more important than speed to phone makers, as it's cheaper for them like that.

Intel sells full fledged SoCs equivalent to Samsung's Exynos line, etc. with Atom cores. Sure ARM licenses cores, but they aren't even a fabeless chip company they're a processor IP company. They sell Nvidia, Samsung, MediaTek etc. the right right to use ARM IP in their SoCs, which are then fabricated by TSMC, GlobalFoundries etc. Of course Intel isn't going to license you their cores. They want to sell you an SoC they designed, not their IP. That's like saying Qualcomm isn't a real player in the SoC business because they didn't license the Krait core to anyone else.

In addition, on a more general note, comparing margins from fabless guys to Intel is always a bit disingenuous. Intel, being vertically integrated, gets to combine the margins of the foundry, core IP house, EDA guys, and final SoC integrator. Of course they'll have better gross margins.

Re:Yay Cortex A-15!

[jon3k]

I don't really understand the dynamics of how x86 will move into the smartphone arena. I can't imagine companies like Samsung, who's manufacturing their own ARM based SOCs, would pay a premium for an Intel CPU that would cut massively into their profits, right? How does Intel get their foot in the door? Who's going to use Intel CPUs in their smartphones and tablets? And why is everyone so quick to write off ARM; a company who's processor designs are actively competing in mobile, and give the nod to Intel who doesn't even have a real offering in an already very mature market. It seems crazy to me. I appreciate that Intel has the lead in the fabrication process, already producing chips at 22nm, but I still don't see any Intel phones on the shelf at Verizon/AT&T -- and it's 2012. We're on the iPhone FIVE at this point. The previous Atom chips have been an absolute disaster. Exactly when do these people expect Intel to swoop in and dominate the smartphone/tablet arena, and how???

Re:Yay Cortex A-15!

[hairyfeet]

What amazes me is how people can be blind to this, when it should have been obvious when they needed "helper chips" like the Broadcoms to do 1080P decode, something that a P4 from 8 years ago could do with relative ease.

The ARM arch was just never designed to scale to the kinds of levels we are needing in today's devices, and you are seeing that as they try to ramp up the power budgets quickly go to shit. this is why you aren't seeing 3GHz ARM chips like you did X86 during the MHz wars, the power budget to ramp the chip that high, not to mention the cooling cost, would simply be too great so instead you are seeing more and more cores "bolted on" trying to make up for the lack of IPC. We saw that same strategy with AMD, didn't work out so well.

Whether the ARM fans like it or not the future is crazy high def screens, games that look better than what the X360 is putting out now, and to do those kinds of things you are gonna need a HELL of a lot more IPC than what we are seeing now. More cores and helper chips only get you so far, as all that needs more power to run. Frankly Intel could sit on ass and end up winning the market by default, by simply letting people's demands for ever higher quality video and games come to them, but they are still shrinking dies and coming up with new designs, and I have NO doubt in less than 16 months you'll see Atom chips that will just smoke the multicore ARMs at less of a power budget. in the end they have the fabs, they have the R&D, they have the processes down, its just a matter of time.

Re:Yay Cortex A-15!

[hairyfeet]

But which would be MORE valuable to your HPC friends, a thousand cores that individually are weaker than a Pentium 2, or 250 Magny Cours or Core i7 chips that can blow through twice as many instructions per second as those 1000 chips?

As we all know TINSTAAFL and there is ALWAYS a trade off, and in the case of ARM its frankly lousy IPC. So far many companies have sunk serious R&D into ARM and they haven't solved the problems so its doubtful that the arch is gonna hit even P4 levels of IPC anytime soon. For huge parallel loads you have both the Tesla GPUs and you have the Opteron and Xeon chips, and this is actually one place where the half core design of the new Opterons would probably work well as you could stuff more per rack than you can the Xeons.

Does this mean these won't have a niche? Nope, I could see these with a custom Linux server backend being used for light loads where it switched over to the Opteron for heavy computing which is what i think AMD is gonna try to do with this, but I just have to wonder how big a market there is for that as most servers i've dealt with are either under strain a LOT of the time or almost never under strain, and guys like your HPC friend I'm sure would be pounding the living hell out of the chips so I have to wonder with such a low IPC if they wouldn't be better served with 200 Xeons or 300 Magny Cours in the same rack space.

Re:Yay Cortex A-15!

[hattig]

The Z2460's base clock remains 1.3GHz, it's only when the thermal conditions allow it that the CPU will boost up to 2GHz.

What does this mean in reality? Yes, short running benchmarks run at 2GHz before the chip gets hot, reporting high scores as a result. This is a flaw with the benchmarks, especially the javascript ones that are gravy for a CPU design that emphasises clock speed at the cost of multiple cores (and hyperthreading really doesn't add much).

Re:Yay Cortex A-15!

[hattig]

Replying again with some more concrete information, that you may be interested in:

From http://hexus.net/tech/news/cpu/47517-samsungs-exynos-5-dual-faces-off-intels-atom-n570/ and http://www.anandtech.com/show/6422/samsung-chromebook-xe303-review-testing-arms-cortex-a15/6

Latest dual-core Exynos 5 thrashes a dual-core Atom with HyperThreading.

Re:Yay Cortex A-15!

[Hal_Porter]

That is interesting.

I've always thought that a lot of the problem with ARM systems is that they typically use mobile SDRAM, Which is low power, but is also clocked slowly and has a rather narrow bus. So if you paired an ARM with the same memory you get in an Atom system, you'd see better figures. I think that is part of what has happened with the Chromebooks.

E.g.

http://www.anandtech.com/show/6422/samsung-chromebook-xe303-review-testing-arms-cortex-a15/3

There are a total of 8 x 256MB DDR3L devices (2GB total) that surround the Exynos 5 Dual SoC (4 on each side of the PCB). Each device is 8-bits wide, all connecting up to the 64-bit wide DDR3L memory controller. The DRAM is clocked at a 1600MHz data rate, resulting in 12.8GB/s of memory bandwidth to the chip. The Exynos 5 Dual integrates two ARM Cortex A15 CPU cores as well as an ARM Mali-T604 GPU.

Yeah - Finally an ARM with memory bandwidth, and it seems like it has really paid off if you look at the CPU benchmarks.

It's also worth pointing out that the Atom 570 is a rather old design. The new Atoms are going to be out of order and hopefully have better performance, though you wonder what will happen to power consumption. Lastly Atom is the slowest x86 CPU and Exynos 5 is one of the fastest ARMs. You can get x86 chips that far surpass the fastest ARM - a Core i7 for example.

Also I think Atoms have always been let down by their chipset - the first Atom chipset consumed much more than the CPU. And the Intel GPU in that chipset is like some sort of sick joke. It's not very low power and the performance is terrible.

Still for a long time Atom was better than AMD for low power and cheap and that meant that it basically owned the netbook segment. So Intel spent its R&D resources on Core i7s and i5s because you can make a lot more cash at the high end.

Now with a bit of luck getting beaten by an Exynos 5 and indeed losing the market for Chromebooks at Samsung will cause Intel to spend some R&D resources on Atom. We know there is a new ValleyView Atom core coming, and we also know they are going to put in a decent integrated GPU. With a bit of luck Atoms will get more R&D resources after that so Atom cores get revved a bit more frequently.

Then again, for what netbooks are meant for - web browsing, email etc - they are basically good enough. I'm not going to switch to ARM on netbook, because I like Windows and Windows RT is a locked down nightmare, whereas x86 Windows runs all the things I need. If I need more power for things like Visual Studio, I've got a Core i5 laptop.

And even if Valleyview is a bit of a disappointment, I'm probably going to end up buying a netbook based on it at some point, purely based on the fact that it runs x86 Windows and that is what I want to run.

This is why we need AMD

[elashish14]

Competition drives innovation.

Who knows if this will be successful or not, but a world with AMD is a world with one more innovator bringing fresh, new ideas to the table and trying things that the members of a smaller oligopoly wouldn't.

Re:This is why we need AMD

[game kid]

A world with AMD is also one that uses ARM as a DRM bludgeon. I'm not sure we need that sort of competition.

Re:This is why we need AMD

[girlintraining]

Competition drives innovation.

How is it innovation to take something that sucks and xerox it 64 times? AMDs chips consume more power and perform less computational operations, compared to Intel chips. They've been behind the curve and falling farther for awhile; And it has everything to do with poor management. AMD is not an argument for competition driving innovation. Pick a better example.

Re:This is why we need AMD

[Anonymous Coward]

Intel needs AMD, not so sure about us. An ARM world would be different, maybe better.

Re:This is why we need AMD

[Anonymous Coward]

I would disagree, We DO need TPM like security, but we need it to be open and their use to be more universal, Having to register your TPMs with your bank would stop most (if not all) banking fraud, that wasn't directly involving person(s) you know personally. Having the ability to have a signed private/public key in hardware isn't a BAD thing... just we need to use it better than JUST DRM.

Re:This is why we need AMD

[Alwin Henseler]

As much as I'd like to see AMD stay around, I don't think AMD will be important either way for the success of these chips.

They probably will be successful, as the natural successor of 32 bit ARM chips today, in a similar way as x86 chips have evolved from 32 to 64 bit. And thus find their way into tablets, netbooks, and -why not- low power (or densely packed) servers too. With or without AMD packing those chips in there.

Re:This is why we need AMD

[Anonymous Coward]

How is it innovation to take something that sucks and xerox it 64 times?

Bits are not cores.
I don't think you have the slightest idea what you are babbling about most of the time.

Re:This is why we need AMD

[Alwin Henseler]

AMD is not an argument for competition driving innovation. Pick a better example.

Yes, please do. How do you think Intel chips today would perform, and what they would cost, had it not been for AMD competing with them?

Aside from that, at most times AMD chips have been quite competitive with Intel's offerings. It just depends on what metric you're looking at. And they've had to be, otherwise AMD would have been out of business long ago.

Re:This is why we need AMD

[elashish14]

AMD are not very good engineers. But at the absolute, very least, they provide value chips which, though significantly behind the curve, still force Intel to keep their prices fairly honest. Yes, AMD is significantly behind the curve, but at least they're trying new things and hopefully something will stick.

And on an irrelevant side note, let's not forget that Intel was wildly successful with their antitrust actions. They must have made 10x in profit what they got fined in the lawsuit....

Re:This is why we need AMD

[jkflying]

Dunno, considering the budget they are working with I'd say getting performance even in the same ballpark as Intel is pretty impressive, especially once you factor in that they are a full process node behind at the fabs. Their multi-threaded top-end speed is the same or faster than Intel, it's only in IPC that they are still behind. Their performance/$ is tied or better.

Re:This is why we need AMD

[Anonymous Coward]

So you're posting this from a Itanium box, right?
Wait, so you got a 64 bit x86 CPU... what was that ISA called again?

Re:This is why we need AMD

[Anonymous Coward]

From my knowledge AMD has barely ever been competitive with Intel from their own merrits. For the majority of their history they were just an Intel manufacturere, getting Intel design work for free. They would spend their R&D money improving the Intel designs they got for free and not having to give their imporvements back to Intel. You would have to be an idiot to not be able to compete with those kind of rules.

Amazingly enough, almost the instant that legally binding agreement was over, AMD started its slide downward. AMDs current problems were seen decades ahead of time and people who knew what was going on were just waiting to see if AMD could actually compete, and it appears they cannot.

AMD can only compete with the legal system's help basically forcing them to be better than Intel. Without the legal system able to help them any more the truth has come about.

Re:This is why we need AMD

[drinkypoo]

AMD are not very good engineers

Man, why do you people keep referring to companies as multiple individuals? Why can't you just refer to the company as a single entity (which it is) and refer to the people who work for it as invidivuals? Why are the British so poor with English?

AMD used to employ some excellent engineers, who designed the K7. Then they let them go for short-term financial gain. Now they're gone.

Re:This is why we need AMD

[Paradise Pete]

Man, why do you people keep referring to companies as multiple individuals?

Sometimes it's convenient.

Then they let them go

See what I mean?

Re:This is why we need AMD

[drinkypoo]

See what I mean?

Unfortunately, that's how we refer to singular individuals when speaking in that tense too, because of one of the many weaknesses in the English language. If it wasn't so damned powerful, I'd have given up and learned something else by now.

Re:This is why we need AMD

[Tapewolf]

Man, why do you people keep referring to companies as multiple individuals?

Because that's what they're made of. IIRC it's one of those annoying subtle differences between British and American English.

Re:This is why we need AMD

[Rising Ape]

You could have used "it" to refer to AMD (if it's a singular entity rather than a group of people, then by the same logic it's inanimate). Grammar is a matter of convention, and the convention is that companies are grammatically plural. You might as well ask why French has feminine tables.

Re:This is why we need AMD

[marcosdumay]

Having the ability to have a signed private/public key in hardware isn't a BAD thing... just we need to use it better than JUST DRM.

All the technologies behing Trusted Computing are great if the master key comes printed when you buy the computer. The problem is that the consortium forbides that.

Re:This is why we need AMD

[Alioth]

English is called English because it's from England. By definition, what English people speak is correct English (the hint is in the name), and what the US speak is incorrect. Otherwise it would be called American, not English.

Re:This is why we need AMD

[DarkOx]

Wrong.

English does not have an office body governing its use. It does not have an official dictionary. English is anything another English speaker is able to understand comfortably.

The only thing even near what might be an official standard is "The queen's English" and if you use that than most of Great Britain does not use correct English.

Re:This is why we need AMD

[drinkypoo]

Grammar is a matter of convention, and the convention is that companies are grammatically plural

Well, that's the convention in UK English, and as far as I can tell all of its non-American derivatives. Perhaps this says something about our attitude towards corporate personhood, but when I refer to a company as a single entity I refer to actions taken under their trademark, I don't think of it as a single thing except insofar as it's under a single legal document.

Re:This is why we need AMD

[elashish14]

I suppose AMD can't do much about their situation with the fabs, and it would be interesting to see what Bulldozer derivatives can do when they get down to the ~22nm process. But I think IPC is more important than you're giving it credit for. Taking laptops for example, it's unfortunate that we don't have any options that rival anything i5 or above. Trinity is decent on the low-end, ie. the i3/Celeron range, but imagine if they tried to put Bulldozer on a laptop - you'd have to settle for either Celeron-comparable performance or Pentium 4-comparable efficiency and then you're left asking what's the point of a laptop with 30 minutes battery life.

I wish like nothing else that AMD would improve their per-core efficiency. Cramming more cores stopped being impressive in 2006 and the continued success of the Phenom II chips is proof of that. I suppose it'll get better with each iteration of Bulldozer, but the next generation really needs to come up with something new to achieve better efficiency. And by then, they'll probably be behind the curve again.

Upgrade ISA to PCI

[Anonymous Coward]

Why are they still using ISA bus?

Re:Upgrade ISA to PCI

[Anonymous Coward]

ISA in this case means "Instruction Set Architecture"

Re:Upgrade ISA to PCI

[Anonymous Coward]

Whoosh.

Wrong abbreviation.

[Anonymous Coward]

ISA stands for Instruction Set Architecture.

Patent move?

[cachimaster]

I always wonder, why change the ABI so often? after all the instruction set is only the interface between the C compiler and the underlying VLIW CPU engine. That's why the first 64 bit processors were actually slower in 64 bit than in 32 bits, and even today they aren't that faster in 64-bit mode.
I suspect is all a Patent game, that's why CPU designers keeps modifying the ABI. Their patents are expiring all the time.

Re:Patent move?

[Anonymous Coward]

You don't patent an ABI. If you do, then nobody could make compatible toolchains without paying to do so. And nobody could link to or use libraries across toolchains. Heck, they probably couldn't even call a function. If you don't like an ABI, then you can make your own as an ABI is just a convention that specifies the stacking order and use of registers between caller and called functions. Best to just use the standard ABI as given by the CPU designer and/or compiler designer so that you can interoperate with precompiled libraries and use different compilers/linkers. The designers put a lot of thought into creating an ABI that uses the CPU resources in the most efficient manner possible.

Usually, at any given clock speed, 64 bit processors would be expected to be faster than 32 bit processors because they deal with more bits (do more work) per each clock cycle. But that is dependent of the type of workload. Also, 64 bit processors typically do not make as efficient use of the cache and/or memory busses as 32 bit processors so that might negatively affect their performance.

How did your post get modded +2? Where have all the real geeks gone?

Re:Patent move?

[Guy Harris]

I always wonder, why change the ABI so often? after all the instruction set is only the interface between the C compiler

XXX compiler, for all values of XXX where machine code (rather than some virtual instruction set or code in some lower-level language) is generated, and also assembler.

and the underlying VLIW CPU engine.

For which instruction sets other than x86, in Pentium Pro and later, and z/Architecture, in z196 and later, is that the case?

That's why the first 64 bit processors were actually slower in 64 bit than in 32 bits, and even today they aren't that faster in 64-bit mode.

Unless you happen to be dealing with more data than fits into a 32-bit addressing space, in which case all the I/O, or memory mapping/unmapping, you're doing might slow you down a bit.

If not, pointers will be larger, so pointer-heavy data structures might have a bigger cache footprint and get a slowdown from that; data copying might get a speedup, as would 64-bit arithmetic, but other stuff might not get any speedup, unless there's register pressure and the 64-bit version of the instruction has more registers (as per x86-64 and ARMv8) or has, in newer versions, some tricks to let you use the two halves of a 64-bit register for two 32-bit quantities (as in newer versions of z/Architecture).

I suspect is all a Patent game, that's why CPU designers keeps modifying the ABI. Their patents are expiring all the time.

CPU designers "keep modifying the ABI" because they're adding new instructions; perhaps they think that they'll speed up certain operations rather than thinking it'll protect them from cloners. They don't keep making incompatible changes, at least for CPUs where incompatible instruction set changes would break binary packaged software. And, for those CPUs, if you make a 64-bit version of an instruction set, you can choose to make incompatible changes as long as the 32-bit version doesn't change; that's what, for example, AMD did (stuff such as 8 more general-purpose registers and a PC-relative addressing mode) and ARM did.

Re:Patent move?

[TheRaven64]

First, don't conflate the ABI and the ISA. The ABI, the Application Binary Interface, describes things like calling conventions, the sizes of fundamental types, the layout of C++ classes, vtables, RTTI, and so on. It is usually defined on a per-platform (OS-architecture pair) basis. This changes quite infrequently because changing it would break all existing binaries.

The ISA, Instruction Set Architecture, defines the set of operations that a CPU can execute and their encodings. These change quite frequently, but usually in a backwards-compatible way. For example, the latest AMD or Intel chips can still run early versions of MS DOS (although the BIOS and other hardware may be incompatible). ARM maintains backwards compatibility for userspace (unprivileged mode) code. You could run applications written for the ARM2 on a modern Cortex A15 if you had any. ARM does not, however, maintain compatibility for privileged mode operations between architectures. This means that kernels needed porting from ARMv5 to ARMv6, a little bit of porting from ARMv6 to ARMv7 and a fair bit more from ARMv7 to ARMv8. This means that they can fundamentally change the low-level parts of the system (for example, how it does virtual memory) but without breaking application compatibility. You may need a new kernel for the new CPU, but all of the rest of your code will keep working.

Backwards compatible changes happen very frequently. For example, Intel adds new SSE instructions with every CPU generation, ARM added NEON and so on. This is because each new generation adds more transistors, and you may as well use them for something. Once you've identified a set of operations that are commonly used, it's generally a good use of spare silicon to add hardware for them. This is increasingly common now because of the dark silicon problem: as transistor densities increase, you have a smaller proportion of the die area that can actually be used at a time if you want to keep within your heat dissipation limits. This means that it's increasingly sensible to add more obscure hardware (e.g. ARMv8 adds AES instructions) because it's a big power saving when it is used and it's not costing anything when it isn't (you couldn't use the transistors for anything that needs to be constantly powered, or your CPU would catch fire).

Re:Patent move?

[cachimaster]

You don't patent an ABI. If you do, then nobody could make compatible toolchains without paying to do so.

Alright Genius, I confused ABI with ISA.

How did your post get modded +2? Where have all the real geeks gone?

Thank for sharing you enormous knowledge, noy you can go back to your real-geek only club.

Pfff, 64bit ARM. Crusoe was 256bit x86

[u64]

http://wikipedia.org/wiki/Transmeta#Crusoe

Anyway, i welcome our new ARM-64 overlords.

Re:Pfff, 64bit ARM. Crusoe was 256bit x86

[Anonymous Coward]

The problem for Transmeta was that no manufacturers understood, or could market a low power laptop or tablet. According to popular magazines at the time, the sort with large intel ad budgets, it was 40% slower than Pentium 4 and therefore a complete and utterly miserable failure that you should avoid like the plague.

The fact that it drew only 3 watts at max load was somehow glossed over.

A better article at anandtech.com

[IYagami]

Anandtech has a better article:

http://www.anandtech.com/show/6420/arms-cortex-a57-and-cortex-a53-the-first-64bit-armv8-cpu-cores

According to them, ARM Cortex A57 core is a tweaked ARM Cortex A15 core with 64 bit support. And ARM Cortex A53 core is a tweaked ARM Cortex A7 core with 64 bit support. It is possible to mix A57 and A53 cores in the same die to improve efficiency.

What I would like to see is this kind of approach in the x86 world. Imagine having an AMD processor with two fast cores (Piledriver's successor, Steamroller) for heavy processing and two lower cores for longer battery life (Bobcat's successor Jaguar).

Or Intel with their future Haswell and Silvermont architectures...

Re:A better article at anandtech.com

[Anonymous Coward]

Aparently you don't know anything about frequency and voltage scaling according to load?

Re:A better article at anandtech.com

[romiz]

The problem is the static leakage of transistors. It increases as the node width decreases, and for a given node you have two choices to generate a transistor: either high-speed and high-leakage, or low-speed and low-leakage. Even with DVFS enabled, you will have better power results if you use the CPU with the slow transistors than the one with the fast transistors. Hence the switching between two types of cores with different optimizations but executing the same code.

Re:A better article at anandtech.com

[drinkypoo]

What I would like to see is this kind of approach in the x86 world. Imagine having an AMD processor with two fast cores (Piledriver's successor, Steamroller) for heavy processing and two lower cores for longer battery life (Bobcat's successor Jaguar).

I'll bet you a dollar it would be more efficient to spend the code creating more separate functional units that do the same work as the existing functional units, but which could be switched off when unneeded. You'd still have half the CPU, but you wouldn't have any cores that just sat around fondling themselves most of the time.

Re:A better article at anandtech.com

[Anonymous Coward]

Quite a bit, actually -- try actually measuring how much power you're really saving when you drive down that frequency vs. what happens to your performance. There's a big difference between an actual low-power chip and a high-power chip at a lower P-state.

Re:A better article at anandtech.com

[marcosdumay]

Aparently, you don't.

Arm sells 10 billion cores a year

[Anonymous Coward]

Talk up Intel all you like, Arm sells 10 billion cores per year and dwarfs Intel.

http://www.eetimes.com/electronics-news/4372693/ARM-dominates-10B-unit-CPU-core-market

It's not a dominant Intel competing against a little guy, Intel is the little guy hanging on to a fringe market that's being taken over by ARM.

Re:Arm sells 10 billion cores a year

[Anonymous Coward]

Seriously? Number of *cores*? Including *microcontrollers*?
By that definition, 4-bit CPUs outsell everything by a massive margin...

Re:Arm sells 10 billion cores a year

[Bengie]

While it is a large and growing market, Intel is probably the single largest company by revenue. They are targeting the mobile market with next year's chips.

No ARM servers

[Billly Gates]

Lets hope this can keep AMD afloat.

A fortune 500 datacenter can easily cost up to 1 million a year in electricity! I/O, not CPU performance is the bottleneck in most servers so the slower ARM wont make that much a deal. Also a kick ass GPU can improve SuperComputing a lot more than a tweaked out Xeon if AMD can pull it off with a decent graphics for scientific workloads.

Re:No ARM servers

[serviscope_minor]

A fortune 500 datacenter can easily cost up to 1 million a year in electricity!

Yes but...

Datacentres operate with an overhead of between 1.1 and 2 for cooling (i.e. cooling requires between 10% and 100% of the electricity used for compute).

If you're buying $1e6 of electricity per year then you get quite decent rates.

At those price points, the performance per watt, density and bang for buck go head to head.

A quad socket Opteron system gives pretty much the best bang per buck, and some of the highest density per U of any system. You can go better if you get really exotic, like supercomputer level exotic, but even things like those 1024 atoms in 10U get less brute floating point performance per U.

AMD can't match the performance per Watt of the Intel systems. They're quite a way off. But, the AMD systems are waaaaay cheaper. And it's roughly at the point where the lifetime cost of power+cooling is of the same order as the cost of a quad socket 1U machine with a good amount of RAM in it.

It's at the point where performance/$ including all factors is dependent very much on the task at hand. There is no clear winner, and AMD is significantly ahead of intel in some areas.

In order for the ARM machines to be competitive, they can't be super-expensive. If they cost twice the $ per performance then no power savings will be enough. If they're similar, then why go for the ARMs? A quad socket x86 box will provide the same lifetime performance/$ and with much greater flexibility (higher per-thread performance, and larger system image).

Unsurprisingly, it's cheaper and more power efficient to use a large number of single socket machines if you can. The single socket CPUs are cheaper and lower power because they don't need a bunch of fast and expensive hyper transport or quickpath links.

But to get away from commodity motherboards and tons of hackery you get into the realm of eye-wateringly expensive blade servers which struggle to match the density of the 1U quad socket machines, are vastly more expensive and have only moderate power improvements. Oh, and tie you into a single vendor really well to boot.

Re:No ARM servers

[marcosdumay]

In order for the ARM machines to be competitive, they can't be super-expensive.

The main selling point of ARM (even more important than power efficiency) that kept them alive all this time is price.

Re:No ARM servers

[serviscope_minor]

The main selling point of ARM (even more important than power efficiency) that kept them alive all this time is price.

No.

There are plenty of cheap embedded cores. AFAICT ARM actually command a bit of a premium.

And also, the point was about price/performance. Basically as soon as the hardware gets exotic in some way, the price/performance usually goes down. At which point, you may as well go with commodity hardware unless you have very specialised needs.

and NVIDIA

[Anonymous Coward]

Project Denver and it is ARMv8 and it uses transmeta technology and thus is a complete new core. This means NVIDIA has licensed with ARM to make cores, rather than simply purchasing IP from ARM Holdings.

ARM64 is a mess

[AaronW]

ARM 64's ISA is radically different than ARM32. All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more. Not only that, the binary encoding is totally different. The binary encoding for ARM64 is a total confusing mess compared to ARM32. I wouldn't say that ARM64 was a well designed ISA.

Other processors made much cleaner transitions between 32 and 64-bit such as MIPS, Power/Power PC and Sparc. Even i386 and x86-64 are much closer than ARM32 vs ARM64.

-Aaron

Re:ARM64 is a mess

[tlhIngan]

ARM 64's ISA is radically different than ARM32. All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more. Not only that, the binary encoding is totally different. The binary encoding for ARM64 is a total confusing mess compared to ARM32. I wouldn't say that ARM64 was a well designed ISA.

The binary encodings are a mess, yes, due mostly to the urge to adapt and produce some consistency with the AArch32 instructions. The ARM ABI has seriously evolved and the encoding possibilities are quite... nasty now if you look at ARMv7.

Thankfully, the assembler takes care of that for us.

Conditional execution is nice, but it really interferes with modern architectures. The ARMv8 core is a fully speculative, out-of-order with register renaming implementation. Conditional execution breaks this as the processor has to track more state since any combinations of instructions in the stream could have any combination of conditional execution.

Ditto the PC - it was nice to be able to jump by simply writing to the PC, but man does it complicate internal design if any instruction can arbitrarily move the PC to any register value. In the end, the few uses of conditional execution and the ability to move anything to the PC without using a branch or return style instruction was probably so limited, there was no point.

Oh, and there are 31 registers - X0 through X30. The 32nd register is special depending on the instruction - for ADD and SUB, "X31" means the stack pointer. For most other instructions, it means the zero register (reads as zero), something borrowed from MIPS, and allowing interesting register-only instruction forms to be used when the immediate value is zero. It does result in oddball uses though, like
      SUB SP, 0, X0 ; Set SP.
to play with the stack pointer.

If you're a system level programmer, AArch64 is MUCH nicer (no more damned coprocessors). I know, I've done a fair bit of it.

Re:ARM64 is a mess

[yupa]

> In the end, the few uses of conditional execution

That why x86 introduced cmov for doing conditional mov ?

> and the ability to move anything to the PC without using a branch or return style instruction was probably so limited, there was no point.

Well most of time gcc use pop instruction for returning of a function
push {r4, r5, r6, lr}
[...]
pop {r4, r5, r6, pc}

Re:ARM64 is a mess

[PCK]

> In the end, the few uses of conditional execution

That why x86 introduced cmov for doing conditional mov ?

I'd wager that there is n't a conditional move uOP when the x86 cmov instruction is decoded, in fact on the original P6 arch there is n't a major speed improvement by using cmov in fact cmov performance various considerably from processor to processor.

Re:ARM64 is a mess

[romiz]

Conditional instructions are also available in the AArch64 assembler. But instead of the condition affecting whether the instruction is executed or not as in AArch32, it affects its behaviour. For example, you have the following Aarch64 instruction that can do what cmov does.

CSEL Wd, Wn, Wm, cond ;Wd = if cond then Wn else Wm.

It's more efficient that the AArch32 case, where you have to use two instructions to achieve the same result (MOVcond followed by MOVcondbar)

Re:ARM64 is a mess

[TheRaven64]

All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more

The advantage of conditional instructions is that you can eliminate branches. The conditional instructions are always executed, but they're only retired if the predicates held. ARMv8 still has predicated select instructions, so you can implement exactly the same functionality, just do an unconditional instruction and then select the result based on the condition. The only case when this doesn't work is for loads and stores, and having predicated loads and stores massively complicates pipeline stage interactions anyway, so isn't such a clear win (you get better code density and fewer branches, but at the cost of a much more complex pipeline).

They also have the same set of conditional branches as ARMv7, but because the PC is not a GPR branch prediction becomes a lot easier. With ARMv7, any instruction can potentially be a branch and you need to know that the destination operand is the pc before you know whether it's a branch. This is great for software. You can do indirect branches with a load instruction, for example. Load with the pc as the target is insanely powerful and fun when writing ARM assembly, but it's a massive pain for branch prediction. This didn't matter on ARM6, because there was no branch predictor (and the pipeline was sufficiently short that it didn't matter), but it's a big problem on a Cortex A8 or newer. Now, the branch predictor only needs to get involved if the instruction has one of a small set of opcodes. This simplifies the interface between the decode unit and the branch predictor a lot. For example, it's easy to differentiate branches with a fixed offset from ones with a register target (which may go through completely different branch prediction mechanisms), just by the opcode. With ARMv7, an add with the pc as the destination takes two operands, a register and a flexible second operand, which may be a register, a register with the value shifted, or an immediate. If both registers are zero, then this is a fixed-destination branch. If one register is the pc, then it's a relative branch. Because pretty much any ARMv7 instruction can be a branch, the branch predictor interface to the decoder has two big disadvantages: it's very complex (not good for power) and it often doesn't get some of the information that it needs until a cycle later than one working just on branch and jump encodings would.

Load and store multiple are gone as well, but they're replaced with load and store pair. These give slightly lower instruction density, but they have the advantage that they complete in a more predictable amount of time, once again simplifying the pipeline, which reduces power consumption and increases the upper bound on clock frequency (which is related to the complexity of each pipeline stage).

They've also done quite a neat trick with the stack pointer. Register 0 is, like most RISC architectures, always 0, but when used as the base address for a load or store, this becomes the stack pointer with ARMv8, so they effectively get stack-relative addressing without having to introduce any extra opcodes (e.g. push and pop on x86) or make the stack a GPR.

ARMv8 also adds a very rich set of memory barriers, which map very cleanly to the C[++]11 memory ordering model. This is a big win when it comes to reducing bus traffic for cache coherency. This is a big win for power efficiency for multithreaded code, because it means that it's easy to do the exact minimum of synchronisation that the algorithm requires.

As an assembly programmer, I much prefer ARMv7, but as a compiler writer ARMv8 is a clear win. I spend a lot more time writing compilers than I spend writing assembly (and most people spend a lot more time using compilers than writing assembly). All of the things that they've removed are things that are hard to generate from a compiler (and hard to implement efficiently in silicon) and all of the things that they've added are useful for compilers. It's the first architecture I've seen where it looks like the architecture people actually talked to the compiler people before designing it.

Re:ARM64 is a mess

[Anonymous Coward]

The cmov instructions were introduced to improve code density.

Re:ARM64 is a mess

[Ed Avis]

Conditional execution is nice, but it really interferes with modern architectures. The ARMv8 core is a fully speculative, out-of-order with register renaming implementation.

Conditional execution lets you avoid a test and jump. If you rewrite code to have conditional jumps instead of conditional execution, there are still just as many code paths for the speculative execution to worry about. But I am not a chip designer so there may be some reason why it's easier.

I do wonder whether speculative out-of-order execution is truly the 'modern' way, though. For single-threaded code, certainly. But if your system is going to be multicore anyway, it might be better to spend the silicon on having two simpler, non-speculative cores rather than one more complex one.

Re:ARM64 is a mess

[Anonymous Coward]

Certainly one of the best technical breakdowns on slashdot I've seen in ages.

Thank you.

Re:ARM64 is a mess

[OdinOdin_]

What is so important about the binary encoding being total different ? i.e. most people use assemblers/disassemblers and read mnemonics. Maybe the binary encoding change optimizes for lower power in some way ? If they have a chance to rewrite the rule book and make things better ? They can potentially have versions that remove all 32bit support (i.e. use those transistors for another arm64 core instead of a 32bit mode)

Re:ARM64 is a mess

[NoNickNameForMe]

Oh, and there are 31 registers - X0 through X30. The 32nd register is special depending on the instruction - for ADD and SUB, "X31" means the stack pointer. For most other instructions, it means the zero register (reads as zero), something borrowed from MIPS, and allowing interesting register-only instruction forms to be used when the immediate value is zero. It does result in oddball uses though, like SUB SP, 0, X0 ; Set SP. to play with the stack pointer.

Hi, since you seem to be familiar with AArch64, perhaps you could explain why X31 == 0 is preferrable to X31 == FF's (all 1's). At least with FF's I can do an Increment or Decrement using 2's complement math, as well as bitwise testing for non-zero bits (though CLZ might suffice). With X31 == 0, the use case seems more limited (zero constant can be encoded pretty easily as an IMMEDIATE, and I presume that TEQ/CMP against 0 still exists)? PS. I'm familiar with ARM32, and somewhat familiar with MIPS-style fixed register constant usage.

Time to learn..

[Anonymous Coward]

Android?

Re:Time to learn..

[Ignacio]

... What?

Pretty much all you need to do is get Linux working on it and then the userland falls into place after a compile (assuming it wasn't put together by a horde of drunken monkeys in the first place).

Re:Time to learn..

[pep70]

This argument sounds so familiar to me. Isn't it the same reason why Itanium should be very easy to adopt, "just recompile".

Re:Time to learn..

[Anonymous Coward]

Nah. Unlike the Itanic VLIW mess, ARMv8 is pretty damn ordinary from the view of a compiler.

Re:Time to learn..

[Anonymous Coward]

... except that in Itanium's case, amd64 pretty much offers every improvement that Itanium has to offer (well, the ones that a typical user cares about, anyway), at a fraction of the price, while still keeping backward compatibility with what you currently have.

Re:Time to learn..

[TheRaven64]

Itanium was just a recompile. The problem was that the resulting code was then typically very slow, because Itanium is a complete bitch as a compiler target. In contrast, ARMv8 is a beautiful architecture to target. To give you some idea of how easy it is, the ARMv8 back end for LLVM was written entirely by one guy in under a year and already performs well (although there's still room for optimisation). LLVM, GCC and ICC all still suck at producing good code for Itanium, and they have had hundreds of man years of effort thrown at them.

Re:Time to learn..

[Anonymous Coward]

Apart from what SPs have said, user-space programmers are probably more disciplined now than they were then about making assumptions about the CPU.

Also, LLVM is supposedly easier to port than GCC either was or is (I know about the big GCC back-end rewrite, but it isn't done yet).

Re:Time to learn..

[pchan-]

the ARMv8 back end for LLVM was written entirely by one guy in under a year and already performs well (although there's still room for optimisation).

Where can I find this LLVM back end? It does not appear to be on llvm.org.

Re:Time to learn..

[TheRaven64]

You can currently find it in an ARM repository, accessible to ARM partners. It should be hitting the LLVM repository as soon as it's been cleared by the lawyers.

Re:AMD?

[gentryx]

Citation needed.

Re:AMD?

[Anonymous Coward]

Most percentage figures are extracted rectally. 90% in fact.

Re:AMD?

[Anna Merikin]

Yep. Intel needs them to appear to have competition so various governments' antitrust investigative units will keep their hands off Intel's business practices.

OTOH, this is (to me) an obvious long-shot that AMD can survive long enough to see and perhaps help ARM do to Intel what Intel did to Sun, IBM and other high-end chipmakers. Perhaps they (AMD) can find funding to last the time it will take for ARM to defeat x86-64.

Or perhaps it won't take very long at all, considering I could replace my ancient desktop/server/backup (Pentium-M 1.6GHz) with a modern, energy-efficient one running ARM-64 and Debian or Ubuntu, were it available.

Re:AMD?

[cbope]

And 90% of APU's suck. Coincidence?

Re:AMD?

[bemymonkey]

"Yes, it is true that the fastest chips are made by Intel, but when you look at the cost of typical (not high end) machine, AMD is hard to beat, especially when the graphics in and APU will work fine for you."

Interesting... care to give an example? In most cases, I feel I can spec out an Intel based machine for the same price (also using the IGP) that is fast enough for HTPC use and runs cooler and quieter while using half the power... unless you actually need the extra GPU power or the additional cores AMD likes to throw in at the same price point, what's the point in going with AMD? A Sandy Bridge Celeron/Pentium is more efficient and provides enough processing power for any HTPC I've seen.

I'd actually like to start buying AMD again in order to give them some support, but Intel's where the efficiency bang-for-the-buck is at right now... this may be different for those of you who don't pay your own power bill *cough*mom's_basement*cough* :p

Not a 4bit CPU

[Anonymous Coward]

Except its not a 4 bit CPU, it's a 32 bit or 64 bit CPU, just like Intel's offerings are 32 bit or 64 bit, only ARM has far higher volumes and sells far more cores.

They're not the little guy here, Intel are.

Re:Not a 4bit CPU

[hattig]

And in this case, the little guy wants a 60% margin on its products, and is wondering why the big guy, with far smaller margins, is still so popular.

Hardly anybody is complaining about performance on today's Cortex A9 based mobile phones. Next year's dual-core A15 phones (and today's Apple A6 phones) will make it even less of an issue. What people do want is decent graphics (Intel is notorious for behind behind the curve here in all markets) and hardware acceleration for media, security, and so on. The ARM SoCs provide this already. Intel is not differentiating their products at all, except for x86 support - increasingly irrelevant today, especially in mobile which is all ARM already.

AMD announces, not ARM...

[Anonymous Coward]

Typo.

Any IOMMU

[Anonymous Coward]

in this new design? uKernels will benefit (and virtualization).

Re:AMD?

[zakeria]

Yes they are and by heading more into the mobile arena than Intel I guess they aim to be around a little longer!!

Translating:

[Pope Raymond Lama]

"The 64-bit ARM ISA is pretty interesting: it's more of wholesale overhaul than a set of additions to the 32-bit ISA."

OS based on Linux and OSS just need athat GCC supports it, which it already does, and Microsoft will only need another 12 years of rewriting^w research until they can come up with Windows RT 64.

(I stand corrected: the Linux kernel itself was up and running on ARM 64 even before GCC ofically supported it: http://www.phoronix.com/scan.php?page=news_item&px=MTIwNzU )

Single? or Alone?

[Anonymous Coward]

As it stands, ARM and it's licensee dwarf Intel's revenue too. Even just counting the chip business parts.

So alone they are probably the biggest *single* chip business, agreed, but they're pocket change in the ARM chip business. That myriad of chip makers is why ARM is the core in myriad of devices, I don't believe Intel can recapture that market alone, it would be like IBM thinking it can release a PC and recapture the PC market domination.

What about Android?

[gr8_phk]

Will the new architecture run Dalvik any faster? You know, 'cause Android apps aren't native anyway.

Re:What about Android?

[Anonymous Coward]

Actually native Android apps are native. See the Android NDK. Dalvik apps are not native. But then again, Dalvik has a JIT, which produces at least some native code.

Re:AMD?

[wisty]

I'm sure Intel would luuuuve to start offering chips at 2X the price of the equivalent AMD one again; if only iPads, Phablets, web apps, the console-led stagnation of game requirements, cloud computing, and Windows XP being almost good enough wasn't killing all the demand at higher price points.

AMD speculation / question

[gr8_phk]

Might AMD just license the instruction set and not the hardware design? Could they then bolt an ARM instruction decoder onto their core right next to the x86 decoder and run code for either architecture on mostly the same hardware?

Power, MIPS?

[nellaj]

ARM gets to completely redesign their ISA to be more superscalar friendly.. like what Power and MIPS had for years. They get to do this because they now have huge mind-share from the low-end. It will be interesting if they can really compete at all in the high end. Eventually they will have to compete with things that other vendors have tuned for years, such as cache size and smart cache-prefetching. MIPS and Power really dropped the ball on the low end and are hurting for it. For MIPS I think the issue is that their ISA is not as powerful as ARM for simple single-issue CPUs. In particular, not auto-increment. Power does have this (with the pre-add offset to index register), but somehow they never made in the mobile world. Maybe Freescale and AMCC didn't try hard enough.

Re:AMD?

[MysteriousPreacher]

It helps to have AMD around, but doesn't prevent antitrust issues. Even if AMD has around 20% of market share in consumer desktops, Intel can still be dragged over the coals for anti-competitive behaviours. Any company's ability to use anti-competitive measures pretty much depends on them being dominent, in either the market in question or another that would grant them a significant advantage. e.g. John's Washing Machines using their market dominance in washing machines to break in to the toaster market by refusing to washing machines to electrical stores that sell competing toasters - even though at the time John's Toasters are about as popular as cholera.

No doubt though, having an alternative source of x86 and x86-64 chips does help intel's general case against anti-trust measures. AMD could vanish tomorrow, and Intel could remain completely free of anti-trust issues in relation to x86 and x86-64.

Re:AMD?

[Anna Merikin]

Agreed.

If it weren't for AMD, Intel would still be selling us Pentium-4 derivatives and quoting clock speed as being equal to performance.

Anyone want to imagine a 32-GHz small-pipeline CPU that sucks 1200 watts? That's what our present might have been....

Re:AMD?

[MysteriousPreacher]

Amen. And we'd still be running IE 6 with an annual coat of paint slapped on it. Seen the same bullshit in state protected monopolies and cartels, such as telecoms and banking. Airlines as well before low cost carriers came in and changed the game.

AMD though have a tough fight. Intel's manufacturing alone puts them way ahead of the game. Doesn't mean though that AMD can't grab a segment.