A secret Apple Silicon extension to accommodate an Intel 8080 artifact

https://bytecellar.com/2022/11/16/a-secret-apple-silicon-extension-to-accommodate-an-intel-8080-artifact/

by ecliptik • 4 years ago

269 140 4 years ago

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

mjevans• 4 years ago

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

dougall3• 4 years ago

I'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-Regist...

ehutch79• 4 years ago

It'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

skissane• 4 years ago

Not loading for me but https://web.archive.org/web/20221117080006/https://bytecella... does

mkj• 4 years ago

Apple must know of some not-too-obscure software that did rely on those flags, curious if anyone's found what it might be.

irdc• 4 years ago

It could very well be that they cannot reliably prove those flags are unused in enough cases to optimise out their (expensive) calculation.

Someone3• 4 years ago

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

mrweasel2• 4 years ago

Yeah that seems odd.

The article says: "While almost no modern applications read these AF and PF bits"

It can't really be legacy software, as most AMD64 software on the Mac is fairly recent (2006) and I suspect that we're talking software older than that for the AF and PF to be in regular use. So it also have to be something fairly important like virtualization or something used in image processing or compression. It seems like overkill for something that would be a problem for an end-user application that would transition to Apple Silicon anyway.

rockdoe3• 4 years ago

Isn't it more like that computing these flags is basically free in hardware? So might as well add support for it.

mrspuratic• 4 years ago

AF is more commonly known as half-carry flag, used in BCD, it's uncommon that anything other than BCD opcodes would use it, in which case a correct implementation of DAA/AAA (6 ops in total) would suffice (though the state of the previous calculation has to go somewhere).

Since flags can be load/stored or push/pop-ed I'd speculate avoiding the hit in correctly handling every flags access was deemed to be worth it. Based on experience from a long time ago (8-bit micros, z80 in particular, and implementing a 6800 emulator, DAA was more code than any other): unusual opcodes and edge case behaviours are common in optimisations, and anti-debug/disassembly. Games perhaps?

In any case, I find the idea of a correctly behaving, deterministic binary translation more appealing than a bunch of beartr^W on-the-fly software fixups.

Mindwipe• 4 years ago

Games perhaps?

It's very hard to conclude Apple care much about breaking a bunch of games on the Mac when they cut off 80% of the Macs gaming library a year earlier by removing 32bit execution, presumably mostly to ease the use of Rosetta 2.

And, y'know, literally every other action Apple has taken for twenty years.

WorldMaker• 4 years ago

I've learned more than once in my education and career to never underestimate how common (and weirdly useful sometimes) BCD is. Lots of random hardware still uses BCD for all sorts of strange timing tasks. The classic 7-segment display is easiest to program against in BCD as one bit of still somewhat ubiquitous types of hardware displays (though slowly disappearing as other screen formats have gotten cheaper).

There's a reason that BCD is in the middle of EBCDIC, IBM used BCD math so heavily in its decades of history that even their text encoding and punch cards were built around it. I've seen Enterprise software that still needs to read/write and sometimes even do math in BCD for compatibility with old Mainframe apps and software still written in COBOL.

dougall3• 4 years ago

They might know of some, but I'm of the opinion that it's worth it to support the specification. It only takes one previously undiscovered application to rely on that specified behaviour, and then you need to fix it. If it were solely a game emulator I wouldn't expect this - performance probably comes first... But for running professional software, I'd choose correctness any day.

I don't know of any applications the use AF, or the PF result in question, but I haven't looked into it. I'd maybe check some of the big professional things with a lot of legacy history like Photoshop or Excel. As I understand it Rosetta 2 also supports 32-bit x86, not for native macOS applications (where 32-bit isn't supported), but to allow Wine/Crossovers to work, so a whole bunch of ancient 32-bit Windows games might be in scope too.

Someone3• 4 years ago

My money (but not a lot of it) is on Microsoft Excel. Its number arithmetic is, let’s say, special.

Microsoft claims they use IEEE 754 floats (https://learn.microsoft.com/en-us/office/troubleshoot/excel/...), but they don’t completely do that.

For example, do

  A1: 0.3
  A2: 0.2
  A3: 0.1
  A4: =A1-A2-A3
  A5: =(A1-A2-A3)
  B4: =A4=0
  B5: =A5=0

A4 will show as “0”, A5 as “-2.77556E-17”, and B4 and B5 show these aren’t purely display issues. B4 shows “TRUE”, B5 shows “FALSE”.

My hunch is that they sometimes use BCD arithmetic.

More info at http://people.eecs.berkeley.edu/~wkahan/ARITH_17.pdf.

jonhohle• 4 years ago

Is `B5: =_A6_=0` intentional or should it be A5?

lobochrome• 4 years ago

You are shaking my foundations here. I frequently, when writing complicated formulas, leave in a set of parentheses too much, just because when writing the formula, I wasn't sure yet whether I'd need them.

Bill - j'accuse!

ezfe• 4 years ago

iWork/Numbers does this properly, and repost 0/0/TRUE/TRUE in each case

userbinator2• 4 years ago

There's this somewhat well-known sequence that uses AF:

    cmp al, 10
    sbb al, 69h
    das

eigenform• 4 years ago

also see previous thread: https://news.ycombinator.com/item?id=33533132

klelatti9• 4 years ago

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

rockdoe3• 4 years ago

Previously people pointed out that a lot of the extra M1 stuff (like TSO, x87 FP) is already standardized and/or has shipped in other ARM chips.

stephencanon• 4 years ago

x87 FP hasn’t been standardized or added to any ARM cpu. What was added is a mode where underflow is detected “after rounding” (as x86 SSE/AVX instructions use) rather than “before rounding” (what all ARM FP instructions default to).

hedgehog4• 4 years ago

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

klelatti9• 4 years ago

Absolutely. I suspect that someone has had 'develop Rosetta 2' on their job description since c2011 at the latest.

bcrl• 4 years ago

It started even further back almost 34 years ago. The first PowerPC Macs shipped with Motorola 68000 emulation in 1994, but development was being investigated back in 1988 or so. Apple has successfully made this kind of transition before, and it's entirely possible they will do so again in the future!

vbezhenar• 4 years ago

Why is it important to keep some particular quirk of floating point conversion in JS? JS breaks stuff all the time. Nobody would notice if some floating point conversion will change its lowest bit.

nfriedly• 4 years ago

JS breaks stuff all the time.

JS libraries break all the time. APIs and experimental language features break sometimes.

But the low-level core fundamentals of the language, such as the way math works, have never changed in it's entire existence. Even the fairly minor changes in strict mode require explicitly opting-in.

MikeRichardson3• 4 years ago

This adds to my ongoing theory that "Notarization" (the process where you have to send your binaries to Apple) really has nothing to do with security.

Instead, they really just wanted a deeper selection of binaries to analyze for other various reasons.

rockdoe3• 4 years ago

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

klelatti9• 4 years ago

Broadly agree but how easy is it for Rosetta to prove to itself that these flags aren't used somewhere in the code path?

delusional3• 4 years ago

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

Karliss• 4 years ago

Couldn'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• 4 years ago

I 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• 4 years ago

if you got a jit in between you are doomed

dougall3• 4 years ago

Every 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• 4 years 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?

codedokode2• 4 years ago

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

doh• 4 years ago

Maybe they license it? Maybe they cross license things to each other?

CodeArtisan• 4 years ago

The x86 instructions are translated, not directly executed; There is no implementation of the x86 instruction set in the circuitry.

codedokode2• 4 years ago

In this case AMD could also claim that they translate instructions in their CPU before execution.

klelatti9• 4 years ago

You can copyright code / implementation but you can't copyright the behaviour of an individual instruction!

It's very unlikely but there could conceivably be a patent, but it would have long since expired.

No case to answer.

Edit: Just to clarify - referring to treatment of one instruction here. As peer comment has said Rosetta translates ISA rather than implements so it's even further removed from being a copyright issue.

cesarb• 4 years ago

It's very unlikely but there could conceivably be a patent, but it would have long since expired.

For those who weren't following the 32-bit to 64-bit transition on the x86 world back then, the x86-64 ISA is from the year 2000 (https://web.archive.org/web/20000817014037/http://www.x86-64...), so any patent which applies to that ISA (without the ISA being prior art for the patent) is now over 20 years old.

wmf4• 4 years ago

These quirks appear to be over 20 years old so the patents should be expired.

wyldfire2• 4 years 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• 4 years ago

I 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• 4 years ago

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

wyldfire2• 4 years ago

Yes 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• 4 years ago

Do they license codecs for Windows or something?

userbinator2• 4 years ago

I know PF is used in the inner loop of at least one lossy compression algorithm implementation.

mark-r2• 4 years ago

Wow, 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• 4 years ago

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

philistine3• 4 years ago

Microsoft 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• 4 years ago

+1 to this.

StillBored4• 4 years ago

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

GeekyBear3• 4 years ago

they can’t wait to get rid of it

Apple developed the 68k emulator used in PowerPC Macs in-house, and never removed it.

Apple licensed Rosetta from Transitive at a time when they didn't have tens of Billions of dollars in cash lying around.

Rosetta 2 was developed in-house, but even if they were still paying a licensing fee every time they shipped a new OS version, it wouldn't even be a rounding error to their bottom line today.

Why would they be in any rush to remove Rosetta 2 at all?

becurious• 4 years ago

You’re going to love the ARM64EC ABI target on Windows.

AtlasBarfed2• 4 years ago

I 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• 4 years ago

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

AtlasBarfed2• 4 years ago

Rosetta2 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• 4 years ago

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

kens4• 4 years ago

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

thecompilr2• 4 years ago

Parity is one of the cheapest thing you can compute in hardware

twoodfin• 4 years ago

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

kens4• 4 years ago

Compared to what? The sign flag has zero cost since it's just the top bit of the result. The zero flag is one NOR gate to compute. You get the carry flag for free with addition. (Although processors usually throw a lot of other functionality into carry (such as shifting) so the carry flag often ends up complicated.) A signed overflow flag is confusing but one gate to implement. In comparison, parity is difficult. You'll note that other early microprocessors such as the 6800, 6502, and 68000 did not have a parity flag. Same with early computers such as the System/360 and PDP-11.

Parity is expensive to compute with 1970s hardware. If you look at the die of the TMX 1795, the parity flag computation is a substantial part of the die, about half the size of the register file or the ALU. The first problem is that XOR is an inconvenient gate to implement, especially if you use standard MOS logic. Processors usually have special pass-transistor tricks to make XOR more compact. The second problem is that parity needs to XOR all the bits together, so you don't get parallelism.

assttoasstmgr• 4 years ago

Compatibility with a terminal from 1971 yet I can't run a copy of Logic Pro 9 I bought 10 years ago - and haven't been able to for years - because Apple.

musicale• 4 years ago

Do you find Apple's contempt for backward compatibility surprising?

I'm still displeased with macOS Catalina and iOS 11 dropping support for 32-bit apps (including many games) but Apple has a long history of old apps not running on newer OS versions and newer hardware.

Over time macOS dropped support for 68K, PowerPC, Classic, Carbon, and 32-bit apps. We'll undoubtedly get a macOS that won't run on x86, and I will be unhappy, but not surprised, if/when Apple removes Rosetta 2 and x86 app support. I can even imagine an unpleasant time when they remove the Objective-C runtime and frameworks.

I'm sure there were some Apple 1 users who were unhappy that their software didn't work well on an Apple 2, even if the Apple 2 had much better hardware and software.

rob74• 4 years ago

Thanks, I wasn't aware of the iAPX 432! Funny that history repeated itself almost exactly 20 years later, when Intel introduced the 64 bit Itanium architecture, but eventually had to copy AMD's 64 bit extension of the x86 architecture because x86 just refused to die. And today, 40 years later, it's still around - although maybe Apple's efforts will finally manage to put a stake through its shriveled heart...

sliken• 4 years ago

Heh, refused to die seems like a weird way to state it.

Intel tried to force a split in desktop/server design with a significant price premium and shipped a very complicated CPU that moved significant complexity/work into the compiler. It managed to scare Alpha, Mips, and PA-risc out of the market, and generally shipped years late and hit performance milestones even later.

AMD on the other hand doubled the x86's registers, added 64 bit support, improved performance and did so with basically zero increase in cost. So suddenly a random x86-64, even a desktop, could gasp make full use of over 4GB ram at zero cost.

So Itanium retreated from servers, to HPC, to enterprise, and HA enterprise then of course died.

1letterunixname• 4 years ago

Factoid: the 8080 was used in the Space Invaders arcade game.

Brian_K_White• 4 years ago

My 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• 4 years ago

Ajskwie

A secret Apple Silicon extension to accommodate an Intel 8080 artifact

Related Stories