3 ms·

> I think if x86 get rid of their legacy instructions, they could reduce their core size Aren't those legacy instructions already emulated in microcode? I don'

> I think if x86 get rid of their legacy instructions, they could reduce their core size Aren't those legacy instructions already emulated in microcode? I don't think they take up much physical footprint.

emidln 4y ago
Yes. People bandying about "legacy x86" instructions miss this often. This isn't much different, conceptually, from Apple's Rosetta, except it's provided in microcode automatically rather than a discrete transform you need to run once and cache. This is very convenient for broad x86 backwards compatibility (e.g. I can run a Java 1.4 JVM and StarOffice or a libc.so.5 to play Unreal Tournament 2004 just fine on my 5900x). Can I run x86 apps, even ones from the last couple years on an M1 with no questions asked? Well, we abandoned local dockerized development at work because Docker for Mac's qemu couldn't hook into Rosetta and qemu alone couldn't handle JIT'd instructions from a jvm11[0]. Maybe that changes with the new MacOS version and the next version of Rosetta (there seems to be a Rosetta that works like qemu's binfmt_misc translators for Linux), but it's been missing for 2 years so far and caused me to do a bunch of work on remote dev capabilities in the meantime. [0] Let me stop you right there before you suggest I recompile 15 years of operating systems, third party toolchains, and internal tools for ARM and then rebuild every intermediate container just so we can work around Rosetta shipping without necessary features. I know that you can ship a whole parallel stack of containers with ARM but that's not feasible in the slightest for anything but the most trivial use cases or entirely greenfield projects.
- UncleEntity 4y ago
  Do you really target the Java 1.4 JVM?
  - emidln 4y ago
    No, but I used the Java 1.4 JVM to run StarOffice for compatibility with an old document that had no other reader within the last three months. I did this from my AMD Ryzen 9 5900x running Linux. For work, I still have some third-party toolchains that were originally compiled on x86_64 linux in 2012. They are dockerized these days to make running these legacy toolchains easy. There is no possibility to recompile these on ARM to provide parallel containers that are compatible with Docker for Mac.
kersplody 4y ago
Modern x86 processors use about 10% of their power budget for instruction decode (translate variable-length x86 machine code into one or more fixed-length microcode instructions and remap registers). The primary modern benefit of this setup is that the decode logic can optimize code at the cost of power. If x86 could get rid of the x86 instruction set and compile directly to something similar to uOPs, then some power reduction use and core area reduction could be achieved, but tooling cost would be immense.

emidln 4y ago

Yes. People bandying about "legacy x86" instructions miss this often. This isn't much different, conceptually, from Apple's Rosetta, except it's provided in microcode automatically rather than a discrete transform you need to run once and cache. This is very convenient for broad x86 backwards compatibility (e.g. I can run a Java 1.4 JVM and StarOffice or a libc.so.5 to play Unreal Tournament 2004 just fine on my 5900x). Can I run x86 apps, even ones from the last couple years on an M1 with no questions asked? Well, we abandoned local dockerized development at work because Docker for Mac's qemu couldn't hook into Rosetta and qemu alone couldn't handle JIT'd instructions from a jvm11[0]. Maybe that changes with the new MacOS version and the next version of Rosetta (there seems to be a Rosetta that works like qemu's binfmt_misc translators for Linux), but it's been missing for 2 years so far and caused me to do a bunch of work on remote dev capabilities in the meantime. [0] Let me stop you right there before you suggest I recompile 15 years of operating systems, third party toolchains, and internal tools for ARM and then rebuild every intermediate container just so we can work around Rosetta shipping without necessary features. I know that you can ship a whole parallel stack of containers with ARM but that's not feasible in the slightest for anything but the most trivial use cases or entirely greenfield projects.

UncleEntity 4y ago
Do you really target the Java 1.4 JVM?
- emidln 4y ago
  No, but I used the Java 1.4 JVM to run StarOffice for compatibility with an old document that had no other reader within the last three months. I did this from my AMD Ryzen 9 5900x running Linux. For work, I still have some third-party toolchains that were originally compiled on x86_64 linux in 2012. They are dockerized these days to make running these legacy toolchains easy. There is no possibility to recompile these on ARM to provide parallel containers that are compatible with Docker for Mac.

kersplody 4y ago

Modern x86 processors use about 10% of their power budget for instruction decode (translate variable-length x86 machine code into one or more fixed-length microcode instructions and remap registers). The primary modern benefit of this setup is that the decode logic can optimize code at the cost of power. If x86 could get rid of the x86 instruction set and compile directly to something similar to uOPs, then some power reduction use and core area reduction could be achieved, but tooling cost would be immense.