3 ms·

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 implementati

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.

WorldMaker 4y 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.
Mindwipe 4y 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.
- andy_ppp 4y ago
  I think the issue is probably games devs don’t want to use Xcode so they don’t get simple upgrades. If you use Xcode almost every change Apple make there is a path to be supported by these changes.
  - KerrAvon 4y ago
    I think it's little a bit more complicated than that. Game devs don't actually update their old games very often, if at all. 32 -> 64 is not a trivial upgrade if you have external dependencies; you might even need to pay new license fees.
    - philistine 4y ago
      It’s clear Apple dropped 32-bit to make the transition to ARM go smoothly. It also highlighted the issue with game development on Mac. Most of the time, it’s done by a subcontractor who’s paid to deliver it once. No one is there to keep the lights on and maintain development, with a few exceptions like Civ 5.
    - StillBored 4y ago
      And why should they? Did the games suddenly have new bugs? Are the game companies going to get more money for basically porting to a new OS? People here complain about software subscription models, but then also like to complain about OS's that maintain backwards compatibility. I mean someone has to pay for engineers to spend their days keeping up with all that frequently pointless churn. Why would a game that works perfectly well with a 32-bit address space need 64 bits? There isn't any reason for old programs to suddenly stop working because someone in the OS/library chain was to lazy to provide backwards compatible ABIs.

WorldMaker 4y 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.

Mindwipe 4y 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.

andy_ppp 4y ago
I think the issue is probably games devs don’t want to use Xcode so they don’t get simple upgrades. If you use Xcode almost every change Apple make there is a path to be supported by these changes.
- KerrAvon 4y ago
  I think it's little a bit more complicated than that. Game devs don't actually update their old games very often, if at all. 32 -> 64 is not a trivial upgrade if you have external dependencies; you might even need to pay new license fees.
  - philistine 4y ago
    It’s clear Apple dropped 32-bit to make the transition to ARM go smoothly. It also highlighted the issue with game development on Mac. Most of the time, it’s done by a subcontractor who’s paid to deliver it once. No one is there to keep the lights on and maintain development, with a few exceptions like Civ 5.
  - StillBored 4y ago
    And why should they? Did the games suddenly have new bugs? Are the game companies going to get more money for basically porting to a new OS? People here complain about software subscription models, but then also like to complain about OS's that maintain backwards compatibility. I mean someone has to pay for engineers to spend their days keeping up with all that frequently pointless churn. Why would a game that works perfectly well with a 32-bit address space need 64 bits? There isn't any reason for old programs to suddenly stop working because someone in the OS/library chain was to lazy to provide backwards compatible ABIs.