14 ms·
A secret Apple Silicon extension to accommodate an Intel 8080 artifact
- eigenform 4y agoalso see previous thread: https://news.ycombinator.com/item?id=33533132 https://news.ycombinator.com/item?id=33533132
- wyldfire 4y ago> A generic Snapdragon ARM SoC, say, would deliver notably less performance in this specific scenario that is critically important to Mac users. In some senses it's even more important for Snapdragon - Google doesn't yet ship a native Windows ARM build of Chrome. So for MacBook competitors using Windows on Snapdragon, you either have to use Edge or the emulated x86_64 Chrome.
- mgalgs 4y agoI didn't understand the author's point here... Do they think Qualcomm couldn't make these hardware changes as well? Of course they can, though they may not have considered it until now.
- jeffbee 4y agoI wonder why Chrome doesn't ship one. They can demonstrably target that CPU, since they ship a mac/arm64 build, android builds, and of course ChromeOS for arm both 32 and 64. Perhaps the market share of Windows on arm is just negligible?
- wyldfire 4y agoYes that's probably the most likely factor. For a while, clang didn't have all the support necessary to build chrome on win-aarch64 but that's no longer the case. Chromium builds exist already so there's probably not much except a business commitment to build/test/support the platform. And yes maybe the share just isn't enough to justify that yet.
- cozzyd 4y agoDo they license codecs for Windows or something?
- userbinator 4y agoI know PF is used in the inner loop of at least one lossy compression algorithm implementation.
- mark-r 4y agoWow, until now I thought Microsoft were the kings of absurd dedication to backwards compatibility. Of course credit goes to Intel here, because they're the ones that retained that 8080 behavior even in their latest x86 chips.
- anyfoo 4y agoMicrosoft and Intel have been sharing that throne for a long time. Look up the A20 Gate for another detail that illustrates how dedicated Intel is (or at least was) to backwards compatibility.
- philistine 4y agoMicrosoft is the king in another way. Apple has made Rosetta 2, one of the most impressive software/hardware mixture ever, and they can’t wait to get rid of it. Microsoft will make a crappy conversion shim and keep it in their code forever. For. Ever.
- TheCondor 4y ago+1 to this.
- StillBored 4y agoI know, its almost like the job of an operating system is to run the programs their users have, rather than just churning the innovation wheel at the expensive of the users who have to replacing perfectly working solutions. This is such a BS take, the nice thing with opensource is that you can go look at the commits that say remove windows 7 support from python. And pretty much anyone who isn't a child can see its less a technical move, and more political. Because out of a million line codebase those half dozen lines were causing so much grief. Frankly, all this "we have to remove legacy ports" and "legacy code" is some kind of OCD levels of mental illness.
- philistine 4y agoThere is such a thing as technical debt. Apple couldn't have gotten so much performance with Rosetta 2 if it had to support 32-bit code. By dropping 32-bit support a year before the transition, they forced everyone to drop their last vestiges of old code. When the ARM transition then happened, it was smoother for everyone. That you have to call this approach a mental illness is poor criticism.
- AtlasBarfed 4y agoI understand there's probably licensing and crap and all the things that are the reason we can't have nice things, but with the very very ... very ... large amount of silicon real estate these days and the "we have so many cores we don't know what to do with them", ... why not have an x86 core or two on the chip? I bet it can share the most of the caches, which are most of the silicon real estate these days anyway. At least Intel could make some more revenue for a few years off of the Apple arm switch with some licensing.
- jffry 4y agoThat sounds like a nightmare of complexity to get right, and I don't see why Apple would want to Frankenstein together cores when they could build something like Rosetta2 instead.
- AtlasBarfed 4y agoRosetta2 was/is far from perfect. Seemed like a coin flip since most of the things I needed it for were "hard" apps that weren't going to be ported anytime soon, but were "harder" for Rosetta to run properly. An actual hardware core would have the advantage of better compatibility. And you only spin it up when needed. But it would probably slow adoption too....
- crazygringo 4y agoPower, of course. The defining characteristic of these ARM chips is low power. Throw on fully functioning x86 cores and you've defeated the entire point. Remember, running x86 code in emulation on ARM uses less power than running the native code on Intel.
- kens 4y agoThe article describes how Apple included support for the x86 parity flag which comes from the 8080. Parity is relatively expensive to compute, requiring XOR of all the bits, so it's not an obvious thing to include in a processor. So why did early Intel processors have it? The reason is older than the 8080. The Datapoint 2200 was a programmable computer terminal announced in 1970 with an 8-bit serial processor implemented in TTL chips. Because it was used as a terminal, they included parity for ASCII communication. Because it was a serial processor, it was little-endian, starting with the lowest bit. The makers talked to Intel and Texas Instruments to see if the board of TTL chips could be replaced with a single-chip processor. Both manufacturers cloned the existing Datapoint architecture. Texas Instruments produced the TMX 1795 microprocessor chip and slightly later, Intel produced the 8008 chip. Datapoint rejected both chips and stayed with TTL, which was considerably faster. (A good decision in the short term but very bad in the long term.) Texas Instruments couldn't find another buyer for the TMX 1795 so it vanished into obscurity. Intel, however, decided to sell the 8008 as a general-purpose processor, changing computing forever. Intel improved the 8008 to create the 8080. Intel planned to change the world with the 32-bit iAPX 432 processor which implemented object-oriented programming and garbage collection in hardware. However, the 432 was delayed, so they introduced the 8086 as a temporary stop-gap, a 16-bit chip that supported translated 8080 assembly code. Necessarily, the 8086 included the parity flag and little endian order for compatibility. Of course, the 8086 was hugely popular and the iAPX 432 was a failure. The 8086 led to the x86 architecture that is so popular today. So that's the history of why x86 has a parity bit and little-endian order, features that don't make a lot of sense now but completely made sense for the Datapoint 2200. Essentially, Apple is putting features into their processor for compatibility with a terminal from 1971.
- thecompilr 4y agoParity is one of the cheapest thing you can compute in hardware
- twoodfin 4y agoBy itself, sure, but fidelity to x86 requires the PF calculation be made alongside a wide range of common instructions, which is a significant cost either for the microarchitecture or for an emulator.
- 1letterunixname 4y agoFactoid: the 8080 was used in the Space Invaders arcade game.
- Brian_K_White 4y agoMy take away is this is why riscv is so important, because everyone should be able to enjoy the same ability to provide for themselves.
- x_xxx 4y agoAjskwie
- mananaysiempre 4y agoThe extension is putting Intel-compatible parity and adjust / aux carry flags in (architecturally zero) bits 26 and 27 of the ARM flags (NCZV) register, to avoid the ahead-of-time translator that is Rosetta 2 having to defensively compute them when it can’t tell they’re unused. No information on how to enable that extension.
- ehutch79 4y agoIt's probably a bad idea to enable this for your own use. I would bet real money that this goes away with the generation that no longer supports rosetta2
- mjevans 4y agoImplicit phrasing in the article suggests guests cannot enable the flag at all, as it's a CPU mode change. It might be important to bare metal OS writers though, hopefully those teams have already reverse engineered the method or are kindly answered by the manufacturer.
- dougall 4y agoI've only messed around in user-space, so I'm not sure how it's enabled. But if I were to guess, it might be bit 4 ("Enable APFLG") of ACTLR_EL1 ("(ARM standard-not-standard)"): https://github.com/AsahiLinux/docs/wiki/HW:ARM-System-Registers#actlr_el1-arm-standard-not-standard https://github.com/AsahiLinux/docs/wiki/HW:ARM-System-Regist...
- skissane 4y agoNot loading for me but https://web.archive.org/web/20221117080006/https://bytecellar.com/2022/11/16/a-secret-apple-silicon-extension-to-accommodate-an-intel-8080-artifact/ https://web.archive.org/web/20221117080006/https://bytecella... does
- mkj 4y agoApple must know of some not-too-obscure software that did rely on those flags, curious if anyone's found what it might be.
- userbinator 4y agoThere's this somewhat well-known sequence that uses AF: cmp al, 10 sbb al, 69h das
- irdc 4y agoIt could very well be that they cannot reliably prove those flags are unused in enough cases to optimise out their (expensive) calculation.
- Someone 4y agoThe flags get saved and restored on task switches and interrupts. I would think deciding whether those bits actually get used across that is infeasible, but yet, https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/ https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f... says: “This almost entirely prevents inter-instruction optimisations. There are two known exceptions. The first is an “unused-flags” optimisation, which avoids calculating x86 flags value if they are not used before being overwritten on every path from a flag-setting instruction.” Does this mean the emulator is buggy (if I write a loop that sets and clears flags, but doesn’t do anything with them, an interrupt handler that samples the flag values would need to see both values), but in a way that no sane code would notice?
- atq2119 4y agoIt does technically sound like there is a gap in the emulation, yes. Though, since interrupts are normally transparent to user space software, you'd have to use something like ptrace or be messing with the signal delivery mechanism to even have a chance at noticing the gap. And you'd have to do quite obscure and absurd things even by those APIs' standards.
- erincandescent 4y ago
- klelatti 4y agoIt's interesting what this tells us about Apple's approach to the Intel to Arm transition. They must have performed deep analysis of the requirements of Rosetta down to the level of individual instruction emulation before they finalised the design of the M1. Also the Rosetta team had enough influence to get the hardware team to build it. Not necessarily a given in all organisations. What would be interesting - and perhaps not surprising - is if Arm added this to the standard Arm ISA in order to facilitate x86 to Arm translation elsewhere. After all they added the infamous FJCVTZS instruction which speeds up x86 derived floating point conversions in JS.
- hedgehog 4y agoIt's useful to think of the transition as starting close to 15 years ago with Apple buying PA Semi and Intrinsity, shaping ARMv8, doing test ports of macOS, etc. Of course deep analysis too, but some pretty empirical evaluation of multiple generations of running prototypes to find the gaps that mattered (product and performance). They telegraphed the plan pretty plainly when they announced the A7 as "desktop class."
- klelatti 4y agoAbsolutely. I suspect that someone has had 'develop Rosetta 2' on their job description since c2011 at the latest.
- hedgehog 4y agoVery possible. I think of their approach as "experiment and remix," that is they test a lot of the technical and supply chain ingredients for new products years in advance, then combine at the last moment to create a widget for the public to buy. I've been watching the pieces of their VR/AR effort come together and my guess is they will do surprisingly large volume for how expensive the headsets will be. Collaboration, but done well.
- klelatti 4y agoThat's really interesting. Anything interesting on the processor / SoC side on their VR/AR work?
- rockdoe 4y agoI think the conclusions are a bit far fetched: "A generic Snapdragon ARM SoC, say, would deliver notably less performance in this specific scenario that is critically important to Mac users." The usage of these flags is NOT common. And as observed above, if they're not used, then you can "have an “unused flags” optimisation that avoids the computation a lot of the time". So I don't see how it follows that this is a "critically important" scenario. Reality is that adding the logic to compute these flags is almost free, so it's a cheap (in terms of hardware) optimization to do to squeeze some marginal extra performance. But to say it's a deal breaker? If it is, I don't think you can conclude that based on the evidence presented.
- klelatti 4y agoBroadly agree but how easy is it for Rosetta to prove to itself that these flags aren't used somewhere in the code path?
- delusional 4y agoI'd think it would be fairly easy considering it transpiles the entire binary in a single shot. I don't see a lot of cases where you'd branch to read either of these flags. I suppose it would be much harder for JITs and other dynamically generated code.
- klelatti 4y agoFair comment. If these flags are hardly used then I guess it is a bit surprising that this is necessary.
- toast0 4y agoThe flags are hardly read, but computed often. Computing them while doing operations is nearly free in hardware, so it makes sense to add them in hardware if you can. It's not nearly free in software, but it's important to do it where not doing it might be obervable in normal flow (tricky things with interrupts are out of luck, even if you always do the software calculation, you could interrupt in the middle of it). In many cases, it's easy to determine the flags aren't observable and you can skip software computation.
- Karliss 4y agoCouldn't rosetta (or other x86 emulator) do some static analysis and emit the instructions for computing PF and AF only in cases where there is a chance that they will be inspected? And not emitting extra instructions if nothing until the next instruction which overwrites flags reads the problematic flags. That way in most case it could use the regular arm add instruction. And only in the rare cases where analysis fails you would need the extra instructions. Or are there some common patterns where making such analysis is difficult? Something like copying the whole state of status register for later use (don't remember if x86 even allows that) instead of checking flags directly. Although in that case you would need an extra code anyway to reorganize value so that it matches the strucutre of x86 flag register. I assume the order on x86 and arm is not identical.
- thegeomaster 4y agoI assume there is no extra cost to the extra subs/adds instructions, so there is no reason to perform this extra analysis when those are available. The author does say: >In a VM, it isn’t able to configured the host CPU, so it can’t use this functionality. There are two other options. Either, you can skip computing the flags, because they’re mostly useless and most software won’t care. Or you can compute them the long way shown above. Rosetta 2 chooses the second option, and this mostly works out fine, because they have an “unused flags” optimisation that avoids the computation a lot of the time. So there's an optimization pass that does what you mentioned, it's just not needed when you have the right instruction available, and the thing is probably a wee bit faster if you don't do it.
- stevefan1999 4y agoif you got a jit in between you are doomed
- dougall 4y agoEvery time there's an indirect branch (including a return) there's a chance that they will be inspected. The "unused flags" optimisation does remove most of them, in a way that gets it right 100% of the time (excluding signals/interrupts inspecting state at random points, and possible bugs), but the pattern "an add or subtract or compare followed by an indirect branch or return" is still very common. (I haven't looked at Linux Rosetta 2, other than to note the parity-flag computation coincidentally showing up in a screenshot posted to Twitter, so I'm not sure exactly how often they do the manual computation, but I'm guessing it's anywhere flags are used, in which case the unused-flags optimisation could be extended further by tracking AF and PF separately to the usual flags, which is roughly your suggestion.) You could still remove the vast majority of the remaining computations with some heuristics that work well, but then you've gone from 100% correct to 99.9% correct, which is nice to avoid when you have the option.
- nailer 4y ago> While almost no modern applications read these AF and PF bits > A generic Snapdragon ARM SoC, say, would deliver notably less performance in this specific scenario that is critically important to Mac users. Sorry, I'm not following. If almost no modern applications read these AF and PF bits, why is it critically important to Mac users?
- codedokode 4y agoDoesn't Rosetta infringe on Intel's copyrighted instruction set and architecture of a CPU? Why Apple can use this instruction set and others cannot? UPD: and ARM seems to be infringing as well: > There’s a standard ARM alternate floating-point behaviour extension (FEAT_AFP) from ARMv8.7, but the M1 design predates the v8.7 standard, so Rosetta 2 uses a non-standard implementation. > (What a coincidence – the “alternative” happens to exactly match x86. Good luck persuading a judge that this was "a coincidence".
- wmf 4y agoThese quirks appear to be over 20 years old so the patents should be expired.
- doh 4y agoMaybe they license it? Maybe they cross license things to each other?
- CodeArtisan 4y agoThe x86 instructions are translated, not directly executed; There is no implementation of the x86 instruction set in the circuitry.
- codedokode 4y agoIn this case AMD could also claim that they translate instructions in their CPU before execution.
- klelatti 4y agoBack in the 386 days Intel sued AMD for copying their microcode (which is copyrighted) not for reimplementing instructions.
- mark-r 4y agoAnd as I recall Intel lost that suit due to an old cross-licensing agreement. In this case there would be no copying of microcode since the underlying hardware is completely different.