I wonder how/if it supports unaligned jumps which x86 supports IIRC. The consequence of unaligned jumps is that it can effectively make it impossible to know the set of instructions a binary might use.
About the Rosetta Translation Environment
171–180 of 249 posts
Re: About the Rosetta Translation Environment
#172I thought this was the most interesting paragraph. > What Can't Be Translated? > Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. I guess translation of JIT compiled stuff implies this isn't a once of translation. I guess translating plugins implies that too. It sounds like very clever stuff to me! > However, Rosetta doesn’t translate the following executables: >…
> These sound like they should be relatively straight forward to translate. I wonder why they didn't? Lack of time? Or perhaps because translating them means that they don't run fast enough to be useful and the fallback paths are likely to run quicker. Probably because ARM's NEON doesn't have 256bit registers, greatly complicating the implementation.
NEON doesn't, but SVE/SVE2 does: https://developer.arm.com/tools-and-software/server-and-hpc/...
Apple might not be using this in their first ARM Mac chips, but I wouldn't be surprised to see them use it in future chips.
Re: About the Rosetta Translation Environment
#173Does anyone have any insight into the business logistics involved in a transition like this? I presume Apple has done maintenance on transitioning desktop OS X to ARM as an option for a very long time. How many years ago would they have had to decide that was the direction they were going to make it reality? 2015? How many people would have been working on it? How many billions of dollars? How does the cost of develo…
> How many billions of dollars? Rounding-error-sized marginal costs. Even if you don't plan on pivoting architectures, it's good practice to write as much code as possible without assembly/intrinsics. If you're writing standards-compliant C/C++/Objective-C/Swift/* it's not a huge burden to change architectures. They also have past-experience with such transitions, so hopefully they kept the "keep the code portable" m…
If you have to maintain any highly optimized assembly/intrinsics code, it’s a very good idea to also maintain an “as portable as feasible” C version for comparison testing.
Re: About the Rosetta Translation Environment
#174I've been using Macs at work for a long time, but sadly this will mark the end of that era. In particular, this limitation on Rosetta rules out an ARM-based Mac for work: > Virtual Machine apps that virtualize x86_64 computer platforms My job requires me to use a piece of proprietary Windows-only software for a large portion of my work. If I can't use this software I can't do my job. Currently I run it in VMware Fusi…
Sounds like there will be Intel Macs for at least a few years coming so it's likely you'll have some time before you have to worry about it. By the time Apple quits shipping Intel Macs it may be a non-issue.
Re: About the Rosetta Translation Environment
#175I've been using Macs at work for a long time, but sadly this will mark the end of that era. In particular, this limitation on Rosetta rules out an ARM-based Mac for work: > Virtual Machine apps that virtualize x86_64 computer platforms My job requires me to use a piece of proprietary Windows-only software for a large portion of my work. If I can't use this software I can't do my job. Currently I run it in VMware Fusi…
> There is a very remote possibility that Windows for ARM could be virtualized by some future version of VMware and the proprietary toolset could run under that, but I'm not holding my breath.
How is that remote? We've already seen Parallels Desktop virtualize Linux for ARM.
Re: About the Rosetta Translation Environment
#176Earlier quoted context omitted.
Highly unlikely Apple would cede the software engineering market for a competitor to step in. Almost everyone in my company would prefer to have a MacBook vs a Thinkpad/Dell/etc if given the choice.
Speaking solely for myself, I do not intend to go with this experiment after using Macs for 16 years and change. I have found that with a few rough edges, Windows 10 and WSL fulfills my dev needs, and except for the Apple apps Logic and Final Cut Pro, virtually all my software is cross platform. Besides, I can use Ableton and Adobe Premiere which I also already "own."
> I do not intend to go with this experiment
I’m sure they lost people when they switched off of ppc too but just like last time Apple is playing the long game. Intel just can’t keep up anymore.
Re: About the Rosetta Translation Environment
#177Earlier quoted context omitted.
ARMv8.1 adds a bunch of improved atomic instructions that basically implement the same functionality as x86. Because x86 has atomic read-modify-write instructions by default; You need emulate those too. The ARMv8.1 extensions look like they have been explicitly designed to allow emulation of x86. The implication is that implementations of ARMv8.1 can (and perhaps should) implement cache/coherency subsystems with high…
So the ARMV8.1 extensions aren't for emulating x86, they're a reflection of how concurrency hardware has changed over the years. It used to be that (and you can see this in the RISC ISAs from the 80s/90s, but AIUI this is what happend in x86 microcode as well) * the CPU would read a line and lock it for modifications in cache. * the CPU core would do the modification * the CPU would write the new value down to L2 wit…
On the other hand, the ARMv8.5 flag manipulation instructions almost certainly were added specifically for x86 emulation.
Re: About the Rosetta Translation Environment
#178Earlier quoted context omitted.
RE AVX and above: My guess is that they are licensing the Transmeta IP which doesn't include those licenses IIRC. So unless they wanted to get sued they'd have to be careful. I suspect some SSE instructions may also not be supported as I don't recall if Transmeta had a license up to SSE4.
Transmeta died what, 20 years ago? All their patents have now expired.
Wikipedia says defunct in 2009, though the decline started earlier.
Re: About the Rosetta Translation Environment
#179> Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. How on Earth does it do that? If executable code is being generated at runtime, it's going to be x86_64 binary machine code still (there are too many ways to generate valid machine code, and it won't know right away whether you're JITting, or cross compiling and actually want x86_64), so Rosetta would need to dete…
My gut feeling is that it will be about the same as Itanium/HP Envy x2 emulation. Emulation of highly optimized hardware where code is generated by highly optimized compilers without an order of magnitude slowdown is just too good to be true.
Valgrind does something similar (x86->intermediate language->x86), and is only about 4x slower than native with all the analyses disabled. I’d guess they left some optimizations out to make it easier to implement the dynamic checks it supports.
Re: About the Rosetta Translation Environment
#180Earlier quoted context omitted.
That's the big piece I've been wondering about too. Three options as I see it (none of them great): 1) Pin all threads in an x86 process to a single core. You don't have memory model concerns on a single core. 2) Don't do anything? Just rely on apps to use the system provided mutex libraries, and they just break if they try to roll their own concurrency? Seems like exactly the applications you care about (games, pro…
There's another option: 4) Translate x86 loads and stores to acquire load and release stores, to align with the x86 semantics. These already exist in the ARM ISA, so it's not much of a stretch at all. This is the one I'm betting on.
That would be too expensive, unless the emulation in general is ao high not to matter.
If store releases and load aquires were very cheap already why make them distinct from normal one anyway?
I suspect that either the CPU is already TSO in practice or has some TSO mode.