9 ms·
Can someone explain why it's a big deal they are using an x86 chip? It seems ARM is the standard in the mobile world, but I'm not sure what the motivations migh
by chrisfosterelli 8y ago
Can someone explain why it's a big deal they are using an x86 chip? It seems ARM is the standard in the mobile world, but I'm not sure what the motivations might have been for the change or if this has drawbacks that make it so surprising.
- jannes 8y agoI was under the impression that x86 is not energy-efficient enough to be used on a phone. But I guess that applies to the modern variant of x86 with a quite bloated instruction set. Who knows if this version of x86 has a more restricted instruction set.
- umanwizard 8y agoWhat is the relationship between the instruction set and the power efficiency?
- ZirconiumX 8y agoA more complex instruction set needs more silicon to decode, and thus is less power efficient. However, I'd imagine that Intel are pretty good at decoding x86 at this point; they've had plenty of practice, so it might balance out.
- flamedoge 8y agoyes, but usually complex = variable length encoding. size is also a factor.
- astrodust 8y agoA 7nm process Pentium III is going to use almost no power and take up very little space. An 80486 would be even tinier.
- tracker1 8y agoCould even be a modernized 386 with cache and integrated co, effectively a 486dx without all the additional instruction support.
- Symmetry 8y agoIt depends on the regime you're operating in. In a processor that's superscalar but in order the higher cost of decoding two x86 instructions versus decoding two ARM instructions is actually significant. But if you're reading instructions in at one or two bytes per clock tick x86's more complicated instructions make a lot of sense since they save on instruction stream size. And if you're dealing with a modern wide issue out of order machine the decoding costs are just lost in the noise. EDIT: Oh, and load-op-store instructions make the level below superscalar a bit harder to design at least. And x86's strong versus ARM's weak memory ordering guarantee have effects even in OoO-land though which one is better is a very complicated issue I'm not going to try venturing an opinion on.
- monocasa 8y agoThere's give and take here. Instruction set density is correlated with variable length instructions (which makes sense from an information theory sorta huffman encoding perspective). Even most modern RISC instruction sets designed for code density are variable length (looking at Thumb2 and RISC-V C here). So your choices are either you pay the power cost on the increased I$ size, you pay it on the decoder, or you take a hit on perf.
- klodolph 8y agoPeople like to get in hot fights about this all the time, and I could be taking the bait, but there is an overhead to instruction decoding and fetching that changes with the complexity of the encoding, and there is also a cost of implementing all the instructions. Simpler instruction set means fewer gates means less power draw, with some hand waving. The ARM 1 had 25,000 transistors and the ARM 2 had 30,000. The contemporaneous Intel 386 had 280,000 and the 486 had 1,200,000. Intel had the engineering resources to design powerful chips that people bought in droves, ARM had a very small number of engineers and had to design something smaller but as a consequence the ended up with very low power consumption, which wasn’t important until people put it in phones. Since then Intel has optimized for power consumption but they were catching up for a long time. In most modern CPUs, other factors dominate and instruction set is less important. Nowadays we have plenty of gates to spare and the question is how much can you accomplish at a given price and power envelope. And it’s irrelevant to talk about power consumption of a baseband processor unless you’re also talking about the power consumption of the radio, since they get used together.
- minipci1321 8y ago"Empirical Study of Power Consumption of x86-64 Instruction Decoder" https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool... From the conclusion: "The result demonstrates that the decoders consume between 3% and 10% of the total processor package power in our benchmarks. The power consumed by the decoders is small compared with other components such as the L2 cache, which consumed 22% of package power in benchmark #1. We conclude that switching to a different instruction set would save only a small amount of power since the instruction decoder cannot be eliminated completely in modern processors."
- klodolph 8y agoYep, that pretty's pretty much it. Back in 1985 when the 386 and ARM 1 came out, neither had any cache at all. But I think the paper is a bit narrow in scope, relative to the discussion here. For any given application, you want to find a cheap part that can run that application. If you can run the application on an 8051 with a few K of ROM, then you can save a lot of money and reduce power consumption by switching to the 8051. If you need a powerful DSP to do some SDR for your cell phone radio, you're going to pick a different instruction set and pick a part that draws a lot more power. I think the paper is taking as fixed the part functionality and considering how the encoding can be changed, but for a core running code that is not user accessible, the engineers are free to choose a core with functionality that suits their particular needs (which you can't do with the main CPU). What's surprising to some people is that Intel has successfully scaled down their x86 cores so you can use them as embedded cores in larger ASICs, essentially. You can reuse a successful core design like the Pentium 4 and adapt it to a modern 14nm or 10nm process and you end up with something cheap and easy to use. 10 years ago that wouldn't have worked. Even recently it was much more common to use dedicated DSPs everywhere, but these days I feel like people are ditching the DSPs for cheap and ubiquitous general purpose CPUs and microcontrollers.
- bitwize 8y agoIt's probably something like a Quark, which is basically a Pentium SoC that can leverage modern manufacturing techniques to get the die size and power consumption down.
- kevin_thibedeau 8y agoCortex family chips take compressed Thumb instructions and translate them into ARM. PentiumPro and up does roughly the same with x86 -> uOps. There is no telling what the internal instruction representation is on these parts and how CISCy it actually is. Though Intel have been using updated low power 486 cores as microcontrollers for the past few years it could just as readily be Atom.
- awalton 8y agoThe Quarks (rip) had a reduced and improved x86-compatible instruction set and they were quite low powered... they really failed to catch on because Intel didn't think to put them in a friendly package to be integrated into anything - they thought teeny tiny pitch BGA was fine for the Maker community that still loves their throughhole components. (And they were kinda buggy chips, but they had roughly shaken them down well by the next silicon spins). I had kinda hoped the Quark would stick around, just so Intel could start sundowning some of those terrible old instructions and execution modes and start properly decrufting x86 - it's 2018, we don't need 32-bit Real Mode anymore, we can emulate it a thousand times on a PC and still have processor power left to play video games. But, that being said, these things probably have a "Mobile Core" processor (i.e. an Atom), which are quite low powered still, and they probably don't run them at all that high of a clock rate either, saving more power.
- chx 8y agoThis is just baseband. It doesn't need an Atom, hell no. It could be like a 486 core manufactured on a ten year old process and it'd still be ridiculously overpowered for the task. More likely it's a P5 core because Intel have repeatedly used that core to produce things -- Bonnell and Larrabee. Anyways it probably runs at like 100 MHz or such and consumes a few tenth of a watt. Maybe an ARM consumes less but compared to the main CPU it's negligible anyways.
- ksec 8y ago>It could be like a 486 core manufactured on a ten year old process and it'd still be ridiculously overpowered for the task. I think you have vastly underestimate the amount of processing power required for modern days 4G LTE computation requirement. Even with an Modern DSP.
- nimish 8y agoIntel is obviously going to use the x86 core they own so they don't have to pay license fees for embedded ARM cores
- uluyol 8y agoI believe that all of Intel's mobile networking products were purchased from infineon. So it wouldn't be surprising if they used ARM until now given that it takes time for these things to change. They even manufactured these chips at TSMC for a while.
- detaro 8y agoIntel is a pretty large ARM customer, so them using ARM here wouldn't be that surprising either.
- vl 8y agoRemember when Intel sold StrongARM division? :)
- btian 8y agoIs that the same as XScale, or something else?
- gsnedders 8y agoI presume they mean so; they bought StrongARM, later replaced it with Intel designed IP (marketed as XScale), and sold on that team. I don't actually know that the StrongARM team and the XScale team are one and the same.
- gip 8y agoThey were - I was on that team. StrongARM came to Intel when it acquired DEC. The CPU was developed thanks to an 'architecture license' from ARM. Intel renamed the processor XScale and later sold it to focus on embedded x86. https://en.wikipedia.org/wiki/StrongARM https://en.wikipedia.org/wiki/StrongARM
- deleted 8y ago[deleted]
- monocasa 8y agoThere isn't a big deal. Hell, AArch32 has something like 1400 instructions, it's just as complicated as an embedded x86. And as someone who's ported a kernel to both, it has just as many weird parts of the architecture built up over decades (ARM is about as old as 32 bit x86). The motivation for the change is that Intel's making the baseband instead of Qualcomm now, so it's not an ARM/Hexagon like it once was. The author is just bent around a decade plus out of date view of chip architecture.
- jonstokes 8y agoThis ^^. The "OMG... HORROR" in this article about the mere fact of x86 usage is deeply silly. The stuff about C64 and so on at the end... there's just no redeeming this mess. The mods should nuke it.
- monocasa 8y agoSo, I just want to throw out there that your arstechnica uarch articles are one of the things that pushed me into computer engineering rather than straight CS. And Inside The Machine I consider to be up there with Patterson & Hennessy. Thanks for all of that! : )
- jonstokes 8y agoThanks!
- evancox100 8y agoHey, same here! Your articles are what inspired me to go into chip design /computer engineering. Still have my signed copy of Inside the Machine on my bookshelf :) Thanks a ton!
- godelmachine 8y agoThanks for the info! Now there's a pundit I can follow and read the books he authored.
- 8y ago
- sempron64 8y agox86 is considered a much more complex instruction set than arm, with multitudes more side-effects. This makes baseband firmware exploits potentially more likely. That said, modern ARM architectures are also quite complex and calling them RISC is a stretch.
- Symmetry 8y agoThere isn't anything to really indicate that this processor has many more instructions than a 8086, befitting its role as an embedded device. I'm not aware of any difference in x86 and ARM semantics in embedded that might cause a problem. Now, the fact that an x86 instruction stream isn't self-synchronizing can represent a danger in theory. That is, you can craft a sequence of x86 instruction such that if you start executing form 0x0000 they're safe and friendly but if you start executing from 0x0001 you'll see a different, equally valid, stream of instructions that might do something malicious. But that doesn't seem like a credible attack vector in this case given the embedded nature of the code.
- monocasa 8y agoI'll throw out there that unaligned, unintended instructions can give an attacker more options from an ROP perspective. But it's only a small benefit for the attacker. And for something like this 30MB binary it's six of one, half dozen of another practically speaking.
- dfox 8y agoWell, the disassembly in the article contains LGDT, so it is certainly significantly more complex core than 8086.
- stefan_ 8y agoThere was no change. Presumably Intel always used a x86 CPU for their baseband, because they own all the patents on that stuff so they don't need to pay any royalty on it. Chances are this isn't even a true x86 CPU, just some ad-hoc smaller version of it. Wonder what cpuid returns on it :)
- heisenbergs 8y agounlikely. intel's baseband originates from infineon which intel bought a couple of years back. Hence it probably was a pure ARM baseband until intel purchased them and insisted on using x86 cores?! very weird move, particularly as i'd assume it also still has ARM cores in the baseband, making it a mix of x86/ARM cores.
- stefan_ 8y agoA lot of the acquired expertise is just the analog stuff, which obviously doesn't care what the processor is very much. If you're shipping one of the highest-dollar chips in the iPhone, I'm sure cutting out ARM is one of the juiciest moves possible. That would have been a very big target for them.
- anticensor 8y agoIllegal instruction exception, then randomly mocking the instruction stream?
- MBCook 8y agoMy guess is simply that Intel has wanted to be on the iPhone for a long time instead of ARM and, in a very tiny way, it’s finally happened. Just an interesting find/factoid more than anything earth shattering or important.
- sounds 8y agoWell, just for one: Spectre affects almost all CPUs. It affects ARM CPUs. But Meltdown only affects x86 CPUs. [1] [1] https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability) https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili... Maybe Intel used such an old core design in their baseband that it's not affected? Nah, that'd just be too good to be true.
- zamadatix 8y agoYour source that Meltdown only afects x86 CPUs literally starts with "Meltdown is a hardware vulnerability affecting Intel x86 microprocessors, IBM POWER processors, and some ARM-based microprocessors.[1][2][3]" and that iOS needed to be patched. Also worth noting AMD x86 CPUs were not affected. Meltdown was definitely more a "how good was your implementation" question not a "are you x86" question.
- agency 8y agoCan you describe a situation where an adversary would be able to run user code on a phone's baseband processor? This is a serious question - I don't know anything about smartphones. Do apps have access to the baseband processor? As an uninformed bystander I would think not...
- atq2119 8y agoIt might be possible to find and exploit a buffer overflow by impersonating a cell phone tower. Not exactly trivial to pull off, but certainly not a priori impossible.
- acoye 8y agoThis comment is down-voted as other archs are vulnerable to Spectre/Meltdown not just x86. True. Yet, as of right now Intel as not fixed in silicon all spectre/meltdown issues. Given the R&D / QA time on a specific arch, I'd bet it is still hardware flawed if they took an of the shelf in house x86 design. Atom based maybe? So I do not feel confident for a chip that runs the broadband and moreover one that is not auditable by the end user (unlike a main CPU would be). I would be supper interested in knowing if the reverse engineering show traces of retpolines.
- deleted 8y ago[deleted]
- bitwize 8y agoBecause x86 is symbolic of the peecee world, which Apple supposedly historically opposed. Beyond that, Apple fans seem to get a raging hardon from Cupertino gaining more and more control of every aspect of the supply chain, from silicon to bits to services, and Apple still depending on third parties for their baseband -- let alone Intel, of the dread Wintel alliance -- just seems so... tacky. Besides, it's CISC, and everybody knows RISC architecture is going to change everything.
- draw_down 8y agoCome on. Every Mac available for almost 15 years now runs on Intel x86 arch
- detaro 8y agoIt's IMHO not a big deal, but still interesting. Intel has seemingly invested less and less into their small embedded stuff in the past few years, is known to use ARM in various parts, so it's interesting to see that they've made this switch here and are using their embedded developments in their integrated products.
- tracker1 8y agoDefinitely interesting.. I mean a 486dx class processor with modern mfg, bigger cache and higher clocks than in the late 80's would totally sip power and be very capable... even the p2/3 designs could work well in a lot of embedded scenarios.
- omarforgotpwd 8y agoIt's not a big deal, you just wouldn't expect that your iPhone is running x86 instructions.