About the Rosetta Translation Environment

https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment

by loun • 6 years ago

221 246 6 years ago

developer.apple.com

The ability to switch a universal binary between running x86 and ARM versions so as to support non-updated x86 plugins is really cool.

dsabanin• 6 years ago

From the page:

What Can't Be Translated?

Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. However, Rosetta doesn’t translate the following executables:

* Kernel extensions

* Virtual Machine apps that virtualize x86_64 computer platforms

Some people are not going to be happy about this.

Edit: But I personally am okay with that.

yjftsjthsd-h• 6 years ago

Like... it's not ideal, maybe, but kernel extensions are already a little touchy so I'm not surprised that they at least need to recompile, and VMs likewise are unfortunate but they can just rebuild and be good (i.e. I'm betting less than a month before people are running around using qemu-system-x86_64 natively built for ARM again).

unix_fan• 6 years ago

Meh, kernel extensions are on life support at this point.

perardi3• 6 years ago

Apple wants kexts gone. They announced the deprecation last year, and this is another chance to force the change. (And for good reasons, if my layman's understanding of the security is at all correct.)

[https://developer.apple.com/support/kernel-extensions/](http...

selsta• 6 years ago

Apple ARM will support kexts.

https://developer.apple.com/documentation/apple_silicon/inst...

marcinzm3• 6 years ago

However, Rosetta doesn’t translate the following executables: Virtual Machine apps that virtualize x86_64 computer platforms

How will this impact docker? Does this mean you can't run x86 docker containers on new Apple laptops?

cloogshicer• 6 years ago

Not sure about the details for how this works, but they specifically mentioned Docker to be supported at the keynote.

marcinzm3• 6 years ago

x86 docker or just docker? There's ARM docker containers as well.

dividedbyzero2• 6 years ago

Docker already runs fine on ARM64, like on Raspberry Pis, so there would be no Rosetta translation needed for ARM64 images. If Rosetta could translate binaries in x86/AMD64 images, that would be very helpful indeed.

Likewise, will it support CLI programs at all?

EtienneK2• 6 years ago

I would assume you’d only be able to run ARM Docker containers.

marcinzm3• 6 years ago

Which is less than ideal if you're using x86 servers since you no longer have the same dev containers as production containers.

linux2647• 6 years ago

My understanding is that the virtualization Apple provides is only for the same architecture as the host OS. In the demos given running Debian, they run uname -a and it reports aarch64

jedieaston2• 6 years ago

Docker on ARM will work, Docker for x86 will not. The State of the Union showed a demo of Hypervisor.framework with Parallels, and they made it clear that Debian AArch64 was running (uname -a). Since Docker runs inside a VM on the Mac, it'll have to be an ARM VM with ARM containers.

(Presumably, running docker build with your Dockerfile will make it work just fine, unless you need x86 specific libraries).

nielsole• 6 years ago

Could you run the linux docker machine on aarch64 and just the docker container/process on JIT-x86? The majority of syscalls doesn't care about architecture, do they? And the OS should theoretically be agnostic to the machine code the application is written in. Probably requires some cooperation on part of the linux docker host. Did I get the idea across?

You would go to hell for implementing that either way

mrkstu2• 6 years ago

They haven’t clarified if Docker is ARM all the way down or if they are using QEMU to emulate x86 somewhere on the stack.

monocasa32• 6 years ago

They wouldn't need qemu anywhere either way; they have their own binary translator.

cpuguy833• 6 years ago

Apple mentioned they are specifically "working with Docker to support 'these things' in coming months". Confirmed with some Docker folks they are working on "something". All very nondescript, but they said they can't talk about it yet.

lsllc3• 6 years ago

Possibly they'll do something like WSL/WSL2 to provide an ARM based Linux kernel interface and then use Rosetta2 to translate the x64 code in user space to ARM?

Having ARM only containers would be mostly useless (it's technically possible, but I bet there are very few ARM container images around).

numpad0• 6 years ago

So I had to look this up: Docker do not rely on VT-x. If kernel has cgroups it runs.

Hypothetically it could run natively on Windows NT, Linux, Darwin, Solaris, etc if it ported for appropriate APIs. However, most Docker containers contain x86_64 Linux binaries, so the runtime environment has to be binary compatible with x86_64 Linux.

Thus, instead of going through the pain similar to WSL1, Docker people just spin up a midsize Linux VM, run remote controlled Docker daemon in it and call that as the "Docker for [PLATFORM]". This will suffice because use case of Docker is to debug on a laptop and deploy to GNU/Linux servers.

So if ARM macOS runs an x86_64 Ubuntu VM it also means Docker runs.

DCKing3• 6 years ago

Docker has had an experimental feature for some time to build containers cross architecture [1]. I'm guessing this transition is a good excuse to finish that up. Running cross architecture containers with only Docker is not possible as far as I know.

I'm guessing that we're going to have to see a lot better adoption of cross-platform container builds because of this.

[1] https://docs.docker.com/buildx/working-with-buildx/#build-mu...

tomduncalf• 6 years ago

Are the limitations on x86_64 virtualization likely to be for technical reasons, or patent reasons? I read a comment on here alluding to some patents on x86_64 virtualization expiring later this year: https://news.ycombinator.com/item?id=23612256 - could that mean that there is a chance this might happen and they are keeping it quiet for now, or are patents likely unrelated?

unicornfinder• 6 years ago

If I had to guess it's because Rosetta isn't fully emulating an x86_64 instruction set but rather dynamically translating API calls for the most part.

mkl3• 6 years ago

I think it's neither of those things. The x86_64 machine code instructions are translated into ARM instructions, so there's no emulation and the API calls don't need to change.

monocasa32• 6 years ago

Those are two different concerns. Rosetta isn't emulating x86_64 kernel mode. Microsoft isn't emulating x86_64 at all.

I imagine Apple has enough patents that Intel infringes on to be able to cross licence.

mrpippy2• 6 years ago

Microsoft is working on it.

fsflyer• 6 years ago

Apple spent $1B buying Intel's modem business last year. https://www.apple.com/newsroom/2019/07/apple-to-acquire-the-... Apple knew this transition was coming. They could have easily slipped in other terms to deal with any IP licensing issues around implementing the x86_64 instruction set.

osy• 6 years ago

Except AMD owns x86_64 https://en.wikipedia.org/wiki/X86-64#Licensing

Rosetta doesn't translate i386 btw.

underdeserver3• 6 years ago

Translating JITted code is a pretty cool trick.

saagarjha9• 6 years ago

At runtime it doesn't really matter where you code is coming from, as long as you do flushes at the right spots.

jeffbee3• 6 years ago

But doesn't this mean that they are translating and running the JIT and the JIT is creating new executable x86 code which then also needs to be translated? I'm a bit baffled as to how any of this can work properly, for example if my JIT is sampling instructions to determine when to optimize, does Rosetta need to reverse-translate the actual instruction pointer back to the original x86 code offset?

ATsch• 6 years ago

You'll probably also enjoy Nvidia's Denver architecture[1] (used in the Tegra processors) which JITs ARM bytecode into their own internal instruction set inside of the processor.

[1] https://en.wikipedia.org/wiki/Project_Denver

monocasa32• 6 years ago

Historically that work is similar to Transmeta's cores, and IBM's DAISY before that for anyone wanting to dig in further.

Someone reverse engineered large parts of the Transmeta crusoe here:

https://www.realworldtech.com/crusoe-intro/

https://www.realworldtech.com/crusoe-exposed/

DAISY was open sourced at one point, but I haven't been able to find a mirror of it. I wish companies would strive to keep their URLs stable. : \

nickcw• 6 years ago

I 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: > Kernel extensions

Fair enough

Virtual Machine apps that virtualize x86_64 computer platforms

I guess most VMs rely on hardware virtualization which would be tricky to translate well.

Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. If you include these newer instructions in your code, execute them only after verifying that they are available. For example, to determine if AVX512 vector instructions are available, use the sysctlbyname function to check the hw.optional.avx512f attribute.

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.

leeter3• 6 years ago

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.

monocasa32• 6 years ago

I doubt they're licencing Transmeta. Transmeta never had an x86_64 processor.

ghaff• 6 years ago

The original Rosetta was based on technology from a company called Transitive which was acquired by IBM a couple years after Apple's PowerPC to Intel transition. [1] It's not immediately obvious what technology licenses are involved with this new incarnation of Rosetta.

[1] https://en.wikipedia.org/wiki/QuickTransit

himinlomax2• 6 years ago

Transmeta died what, 20 years ago? All their patents have now expired.

monocasa32• 6 years ago

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.

NovemberWhiskey2• 6 years ago

I would guess that's right - AVX only came onto the scene in 2011 so most code will be able to fall back on an SSE implementation if AVX is unavailable, and presumably an AVX emulation which is a bad fit versus the hardware is actually slower than the SSE emulation.

A quick search suggests a couple of people already running into this issue with the older generation Mac Pros that also don't support AVX but it doesn't seem that widespread.

ac292• 6 years ago

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.

jsjohnst• 6 years ago

I wonder why they didn't?

It could come down to licensing issues. The ISA extensions for AVX/AVX2/AVX512 are under different licensing and to my knowledge, Intel/AMD are the only legal license holders (and Intel would be the only holder were it not for the arrangement between Intel and AMD formed due to x86_64)

jayyhu2• 6 years ago

Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions.

No AVX will probably mean that the vast majority of pro/graphics intensive apps won't work out of the box with Rosetta.

beervirus• 6 years ago

Do those programs blindly try to execute AVX instructions without checking whether they’re supported? What happens if you're just running on an older intel processor?

saagarjha9• 6 years ago

Usually you'd want to check cpuid or similar and fall back to something reasonable.

jayyhu2• 6 years ago

Apple seems to suggest that all well behaving programs:

use the sysctlbyname function to check the hw.optional.avx512f attribute

So my guess it they probably just replace the AVX instructions with no-ops and let it blow up if the correct checks/fallbacks aren't in place.

makomk• 6 years ago

All well-behaving software will of course check if AVX is supported before trying to use it, but at least in some cases that just means they'll refuse to install or run on systems that don't have it: https://www.pro-tools-expert.com/production-expert-1/2019/9/... (Developing parallel code paths and keeping them working indefinitely is a lot of extra work, and AVX has been around for close to a decade at this point.)

giantrobot• 6 years ago

Most heavy math libraries that use AVX do function multiversioning. When calling the function it does a CPUID instruction check and then picks a code path appropriate for the CPU. Intel's MKL gets flak for this because non-Intel CPU's always fall back to the least optimal path even if they support a more efficient path.

I think you'd be hard pressed to find programs using AVX that didn't do some sort of feature check. While AVX debuted with Sandy Bridge in 2011, Intel's Celeron/Pentium branded CPUs don't support those instructions (or didn't for a long time).

mrpippy2• 6 years ago

The “cheese grater” 2010/2012 Mac Pro didn’t support AVX either, but supported 10.14. Apps have only been able to depend on Macs having AVX for a year, but of course they should still check at runtime.

bjpirt• 6 years ago

Having big flashbacks to the switch from PPC to x86 here. Rosetta worked relatively smoothly during that transition so fingers crossed it will be ok here too.

Though with Docker support on the mac already being a second class citizen to running on Linux I wonder if a lot of devs will stop using macs for dev

LeSaucy• 6 years ago

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.

SomeHacker44• 6 years ago

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

orangecat• 6 years ago

Highly unlikely Apple would cede the software engineering market for a competitor to step in.

If you're not specifically developing for iOS or macOS, Apple doesn't care about you. They'll take your money if you want to write Unix or web software, but they'll drop support in a heartbeat if that makes it easier to support their mobile and consumer segments.

fulafel• 6 years ago

What % of your devs are running Windows vs Linux on those?

wmf• 6 years ago

People weren't running PowerPC VMs (besides Classic which was dropped in 10.5) so they didn't notice the loss of that functionality. Many people are running x86 VMs today which won't work on ARM.

godzillabrennus• 6 years ago

The Apple transition to ARM for me is sad.

There was so much positivity around the Intel transition. It opened up the Mac platform. Now it’s going back into a closed black box.

Bigpet• 6 years ago

I think I'm missing something. How is ARM closing things up? Does Apple have a bunch of processor extensions that make it incompatible with other ARM processors? Or do you think they'll take the chance to kill boot-camp or something?

monocasa32• 6 years ago

They'll almost certainly only allow their signed kernels to run.

And that's in addition to not documenting any of the peripherals.

proninyaroslav2• 6 years ago

I think Apple has more maneuvers on ARM, since in general the PC architecture is open for modifications, unlike ARM. They will do it the same way as with iOS devices - a closed bootloader and hardware protection.

qubex2• 6 years ago

The “ARM world” is almost inconceivably varied by x86 standards. There’s not even an agreed-upon boot procedure (the Raspberrry Pi’s CPU famously gets booted by the GPU). Efforts to standardise this in the server space are only just getting off the ground with the Arm Server Base Boot Requirements version 1.2 being ratified last year. I doubt you’ll find Apple subscribing to anything that they won’t develop in-house.

This is, after all, the company that developed the Lightening connector and sticks on its iPhones to it despite the whole industry shifting to USB-C.

Basically the OS situation on Macs post-ARM is probably going to look like the Linux situation on iDevices currently: occasionally somebody manages to text-mode-boot an iPhone 7 into a profoundly unstable hacked-up kernel and there is much merriment and rejoicing, but really... macs are going to become rather exotic (on the inside).

Have you ever wondered about your iPad’s boot sequence? Because you’ve never had to think about it. Notice how you can’t install versions of i(Pad)OS that are no longer signed? You think Apple will allow booting unsigned images? And all the Secure Enclave infrastructure they’ve built up?

Nah.

ezconnect• 6 years ago

Everything will now be digitally signed, look at the iphone jailbreak scene on how hard is it to customize your own hardware to run the software you want.

haxxorfreak• 6 years ago

I'm optimistic and while the constant references to ARM as "Apple Silicon" make it sounds proprietary I see it as an example of Apple following Jobs' goal of "skating to where the puck will be".

Microsoft is toying with the same transition with Windows 10 ARM builds and the Surface Pro X, and the news yesterday about an ARM-based supercomputer taking the TOP500 crown are all signs that ARM is the future. It will take years but I foresee most "general computing" devices making the transition in the future.

proninyaroslav2• 6 years ago

Can you install something other than Windows 10 on Surface Pro X? I think not. There may be hackers who can crack these things, but this is not an ideal solution. There will also be problems with the drivers, I'm sure of that. Mac is waiting for the same fate.

DCKing3• 6 years ago

Rosetta's goal is to support legacy Mac apps. It's quite finely scoped, but I hope Apple will go above this and make it available as part of their virtualization framework. This way e.g. Parallels and Docker could use this to provide some way to tap in probably the fastest way to run x86 on ARM Macs.

This would mean Rosetta would go beyond its stated scope, and certainly go beyond what the relatively short-lived Rosetta 1 did, but would make it easier to integrate ARM Macs in what is still an x86 world.

I'm worried they're not going to do this because x86 emulation is probably too slow (people will attempt to run their AAA games in a VM). It would also mean that Apple will need to support Rosetta 2 forever. If they're not going to do this, everybody will have to rely on qemu. Qemu is great, but I hope it will perform adequately for at least basic Docker stuff...

Angostura• 6 years ago

FWIW they showed the latest Tombraider game running on Rosetta on a dev Mac said to be using the ARM chip from the high-end iPad. It ran pretty well. Not sure if I would quite count this as AAA

DCKing3• 6 years ago

I don't think that was running on Rosetta 2's dynamic recompiler, but instead used Rosetta 2's other stated feature of being able to translate existing apps at install time. In the demo they state that they downloaded the game from the Mac App store.

Certainly static recompilation yields somewhat-close-to-native performance when it is available, but that is not possible for x86 "VMs".

toyg• 6 years ago

It ran pretty well

It was a postproduced, recorded promotional video, not a live demo. They could have shown laptops reaching Mars and you’d have thought “that landing gear looks pretty solid”.

monocasa32• 6 years ago

IDK, what I saw was a several year old game running on the lowest settings and still stuttering a bit.

rezmason• 6 years ago

I think the longer Rosetta exists and macOS thereby supports a wider variety of binary executables, the more people will rely on it to deliver them day-to-day functionality in increasingly complex configurations, and the more Apple will expose itself to those users' criticisms.

If Apple's rationale for the transition is to gain further control over their product design and manufacture, the prospect of having to appease folks who won't give up their old software (like me!) but who come to expect indefinite Rosetta-type backwards compatibility doesn't sound all that appealing from Apple's perspective. We're talking about a company who denied Carbon support in the 64-bit transition while some of their largest software developers still clung to it.

Furthermore, the old software they're temporarily supporting through Rosetta represents the agreements and policies Apple followed with third party developers during earlier periods in their history, which I'm sure they want to get away from. In their eyes, the sooner they can ditch those policies and impose iOS-type restrictions on any and all macOS software development, the better.

This is probably my last Mac, after thirty years. It's been fun, watching them rise in power, but they've had to become a very different kind of company to get to where they are.

burlesona• 6 years ago

Your first two paragraphs track, but I think the second two are quite a leap.

Sure it’s possible, but I think it’s exceptionally unlikely that Apple will try to lock down the Mac the way the iPhone is.

The reason is they think of them as fundamentally different products with fundamentally different purposes, and for the most part the trend line has been moving to more opening of the iOS ecosystem rather than more lockdown of the Mac.

(For instance in the last few iOS releases they’ve added file system support, removing the default apps, and in this new release they’re allowing users to set alternative default apps, etc.)

Apple views the iPhone as a pure consumer device where the most important thing is that everything “just works.” It’s locked down in the same way a video game console is locked down, and for the same reasons: they gain a lot of “just works” benefits from keeping things very standardized. And most consumers LIKE that. Most consumers hate that their PC (or even Mac) often fails them in “mysterious” ways that require tech support or just living with a broken experience.

Apple talks about iOS as a “car” and Mac as a “truck.” They see Mac as their development platform, and literally called that out in their keynote.

There is certainly a desire on Apple’s part to make the Mac also an excellent consumer product, hence things like the existence of the App Store and app signing, but on the Mac there have always been “escape hatches” for those who know what they’re doing.

Now, the part that Apple does want to lock down and is able to lock down even more with this move is the Hardware. They’ve never made Hackintosh easy and have never done anything to indicate support for tinkering with their hardware, to the point that when the pro community began to bail they brought back a highly “configurable” Mac Pro (configurable with official parts but not really tinkerable).

But anyway, I don’t think Mac OS is going to get locked down substantially more than it already is. It’s a nice OS with some trade offs, if those trade offs have worked for you in the past they’re likely to keep being fine, and if not then you probably wouldn’t be a Mac user anyway.

Someone4• 6 years ago

AAA games spend lots of times inside system libraries. Porting those to native could be enough to get acceptable performance.

So, chess could be more of a challenge for emulation than AAA games (but probably less of an issue, as it would be easily ported, and have fewer users, anyways)

AlphaSite• 6 years ago

It would be extremely bizarre if x86 programs are linking against arm libraries.

amaranth3• 6 years ago

The page we're discussing here actually says you can't mix arm64 and amd64 code in a single process, if your binary is amd64 all your libraries will be too. I'd be surprised if they put in the work to generate thunks for all their system libraries and then didn't make it possible to use any others. More likely macOS will just have two copies of all the (non-iOS) libraries and the only point they work together is the kernel since that's a nice clear barrier.

qalmakka3• 6 years ago

I think Rosetta is mostly about userspace, and a Hypervisor is definitely not something that sticks to that - modern VMs run on the bare metal thanks to CPU acceleration and dedicated instructions (i.e. VT-x and AMD-V). Getting an app to run on a foreign architecture it's different than emulating a whole machine in order to get an unmodified OS kernel to run. You can do it this very day with QEMU, yesterday I tried just for fun to boot Windows XP on my Raspberry Pi 4 (it boots but it's horrendously slow, if you're interested). Maybe with time and effort, an emulator can get a satisfactory level of speed (probably never enough to run Windows games on emulated Windows though, but who knows).

mkl3• 6 years ago

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 detect when the code's about to be run, or when it's marked as executable, and translate the machine code in that bit of memory just in time. The length of the ARM code might be longer, so it would have to be in a different block of memory, with the original x86_64 code replaced with a jump to the new code or something.

It's late at night here, so maybe I'm missing a simpler approach, but I'm a bit surprised they have it working reliably enough to make such a general statement (there being a great variety of JIT systems). From a quick search I can't tell if Microsoft's x86-on-ARM translation in Windows 10 ARM supports JITs in the program being run.

lsllc3• 6 years ago

It probably just hooks mmap() (or mprotect()) and looks for when the JIT sets PROT_EXEC on memory it hasn't translated yet.

Here's a tutorial for a simple JIT that uses mmap() with PROT_EXEC to write machine code to before executing:

https://github.com/spencertipping/jit-tutorial

monocasa32• 6 years ago

Since they don't enforce W^X you need to go a little deeper than that since some JITs reuse the same memory later for new traces.

So what you'll do is silently enforce W^X to trap code modifications, but not propagate those traps to the emulated code.

api2• 6 years ago

"Just"

This is some serious black magic, especially if it actually works. Even if it only works some of the time I give it an A for effort, since they could easily have just said "JITs will not work with Rosetta." Most applications do not contain JITs.

My guess is there are enough important Mac apps that contain JITs of some form to merit this work, probably high performance math and graphics kernels that JIT processing pipelines or something like that. I wonder if some pro studio editing applications do this.

bluedino• 6 years ago

There might be insights from the way Dolphins PPC JIT works:

https://www.reddit.com/r/emulation/comments/2xq5ar/how_close...

TheCoreh• 6 years ago

They might be using something like an NX bit on the generated x86_64 page, so that whenever the code attempts to jump into it, a page fault is generated, and the kernel is able to handle that, kicking in the JIT compilation and translating the code / address. This is essentially a "double JIT" so there will likely be a performance hit.

Since they control the silicon, Apple might also be leveraging a specialized instruction / feature on the CPUs (e.g. a "foreign" bit that's able to mark memory pages as being from another architecture, and some addressing scheme that links them to one or more native pages behind the scenes)

Maybe the A series chips even have "extra" registers / program counters / interrupts that aid in accelerating this emulation process.

jojobas2• 6 years ago

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.

hedora2• 6 years ago

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.

eholk• 6 years ago

Typically the way systems do this is by translating small sections of straightline code, and patching the exits as they are translated. So you start by saying translate the block at address 0x1234. That code may go until a jump to address 0x4567. When translating that jump, they instead make a call to the runtime system which says "where is the translated code starting at address 0x4567?" If the code doesn't exist, it goes ahead and translates that block and patches the originally jump to skip the runtime system next time around.

This means early on in the program's run you spend a lot of time translating code, but it pretty quickly stabilizes and you spend most of your time in already translated code.

Of course, if your program is self modifying then the system needs to do some more work to invalidate the translation cache when the underlying code is modified.

derefr2• 6 years ago

Think of binary translation as just another kind of compiler. It parses machine code, generates an IR, does things to the IR, and then codegens machine code in a different ISA. (Heck, Rosetta 2 is probably built on LLVM. Why wouldn't it be? Apple already put so much work into it. They could even lean on similar work like https://github.com/avast/retdec .)

During the "do things to IR" phase of compilation, you can do static analysis, and use this to inform the rest of the compilation process.

The unique pattern of machine-code that must occur in any implementation of JIT, is a jump to a memory address that was computed entirely at runtime, i.e. with a https://en.wikipedia.org/wiki/Use-define_chain for that address value that leads back to a call to mmap(2) or malloc(2). Static analysis of the IR can find and label such instructions; and you can use this to replace them in the IR with more-abstract "enter JITed code" instrinsic ops.

Then, in the codegen phase of this compiler, you can have such intrinsics generate a shim of ARM instructions. Conveniently, since this intrinsic appears at the end of the JIT process, the memory at the address passed to the intrinsic will almost certainly contain finalized x86 code, ready to be re-compiled into ARM code. So the shim can just do a (hopefully memoized) call to the Rosetta JIT translator, passing the passed-in address, getting back the address of some ARM code, and jumping to that.

saagarjha9• 6 years ago

Rosetta 2 is probably built on LLVM. Why wouldn't it be?

LLVM is kind of slow; JavaScriptCore abandoned it years ago for their FTL backend.

The unique pattern of machine-code that must occur in any implementation of JIT, is a jump to a memory address that was computed entirely at runtime, i.e. with a https://en.wikipedia.org/wiki/Use-define_chain for that address value that leads back to a call to mmap(2) or malloc(2).

  void *region = mmap(0x100000000, 0x1000, PROT_READ | PROT_WRITE, MAP_FIXED, 0, 0);
  memcpy(region, code, 0x1000);
  mprotect(0x100000000, 0x1000, PROT_READ | PROT_EXEC);
  reinterpret_cast<(void (*)())>(region)();

tom_mellior2• 6 years ago

The unique pattern of machine-code that must occur in any implementation of JIT, is a jump to a memory address that was computed entirely at runtime, i.e. with a https://en.wikipedia.org/wiki/Use-define_chain for that address value that leads back to a call to mmap(2) or malloc(2).

This is probably mostly true. But actually reliably finding such cases, in the most hostile environment imaginable (namely, on x86-64 binary code), would require heroic program analysis that I as a compiler engineer would judge unrealistic.

I would find it much more plausible for the system to watch for something like "jump to a target in a memory page that at some point had the W flag set, has since had W removed and X set, and has not been jumped to since that", and then trigger a compilation of that page starting at the given jump address, and a rewrite of the jump instruction. As proposed in https://news.ycombinator.com/item?id=23614894 this could be done by watching for page faults, though presumably it would mean intercepting places where the application tries to set the X bit on a page and setting NX instead so that the page fault can be caught.

himinlomax2• 6 years ago

If executable code is being generated at runtime, it's going to be x86_64 binary machine code still

JITs have to explicitly make the memory they write the generated code to executable. The OS "just" needs to fail to actually make the page executable, and then handle the subsequent page fault by transpiling or interpreting the x86 code therein.

anyfoo3• 6 years ago

And it wouldn't make sense to make any x86 process originating pages actually executable on a page table level anyway, as the CPU can never actually "execute" it, as machine code.

amaranth3• 6 years ago

I'm not sure why they're making a big deal about this, couldn't the original Rosetta do this too? QEMU has been doing this since (I think) even before the original Rosetta, they call it user mode emulation. You run as if it was a normal emulator but also trap syscalls and forward them to the native kernel instead of emulating a kernel too.

I'm more interested in how they're doing the AOT conversion and (presumably) patching the result to still be able to emulate for JITs. That'd be (comparatively) simple if it was just for things from the iOS and Mac App Stores since Apple has the IR for them still but they made it sound like it was more generic than that.

https://www.qemu.org/docs/master/user/main.html

vmception2• 6 years ago

I'm not sure why they're making a big deal about this, couldn't the

That's par for course with Apple. They never acknowledge competitors including when its themselves. Everything they do or describe is awesome and magical, right now! It could be an incremental improvement, it could be a half decade old established technology, it could be something completely unexpected and science fiction turned into reality. Thats just how Apple works.

reaperducer3• 6 years ago

I'm not sure why they're making a big deal about this

Because they're trying to get the message across to regular people (not HN types) that their software will continue working with the new chips, and they don't have to flee the Apple ecosystem.

fay59• 6 years ago

The original Rosetta couldn’t do it, or couldn’t do some part of it. I remember because Sixtyforce couldn’t run. I believe that it could have to do with self-modifying code.

jmull2• 6 years ago

I'm not sure why they're making a big deal about this

Don’t they need to communicate to developers and users what software will (and will not) run on their upcoming computers?

oppositelock2• 6 years ago

The original PowerPC on Intel Rosetta was pretty amazing.

First, most programs do much of their work inside the OS - rendering, network, interaction, whatever, so that's not emulated, Rosetta just calls the native OS functions after doing whatever input translation is necessary. So, nothing below a certain set of API's is translated.

You have to keep a separate translated binary in memory, and be able to compile missing bits as you encounter them, while remembering all your offset adjustments. It worked amazingly well during the PowerPC transition. Due to so many things running natively on x86, the translated apps frequently faster than running native on PowerPC macs!

classichasclass2• 6 years ago

the translated apps frequently faster than running native on PowerPC macs!

This gets repeated a lot and it's generally false. In fact, most of the time they were slower, and realistically you would expect this. On a clock for clock basis, an OG Mac Pro 2.66GHz was about 10-20% slower than a Quad G5 2.5GHz running the same PowerPC software. In some benchmarks, the Quad G5 was still faster at running PowerPC software than the 3.0GHz (see https://barefeats.com/quad06.html ). When the Core Duo had to pay the Rosetta tax, even upper-spec G4s could get past it (https://barefeats.com/rosetta.html) and it stood no chance against the G5.

Where I think this misconception comes from is that on native apps (and Universal apps have native code), these first Intel Macs cleaned the floor with the G4 and most of the time nudged past even the mighty Quad, and by the second generation it wasn't a contest anymore. But for the existing PowerPC software that was available during the early part of the Intel transition, Power Macs still ran PowerPC software best overall. It wasn't Rosetta that made the Intel Macs powerful, it was just bridging things long enough to buy time for Universal apps to emerge. Rosetta/QuickTransit was marvelous technology, but it wasn't that marvelous.

nothis• 6 years ago

So how fast will this be compared to native? As I understand, it's not "emulation" but something more low level?

Synaesthesia• 6 years ago

Did you ever use PPC apps on Intel through Rosetta? It was a substantial slowdown, like at least 2x. But the app was usable.

rz2k• 6 years ago

Does 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 developing the software compare to the cost of developing a new processor, or compared to tooling a production line for an entirely new platform?

I'm really curious about the share of institutional resources and attention this likely involved. I wonder how important it is as context to Apple over the past few years.

I also wonder if it heralds a new direction in personal computers. Every time I've considered that my Mac isn't that great, the alternatives aren't that great either. Would Apple ever decide to seriously compete for a dominant share of the personal computer market?

And finally, I am also curious about the accounting and financial disclosures required in such decisions. How much are institutional investors informed of long range plans? There's naturally a lot more pressure to distribute cash to shareholders if you don't know about some five-year-plan, yet that pressure waxes and wanes from activist investors, and institutional investors like CalPERS always seemed to be on board with Apple's direction anyway. Do unofficial leaks prevent violations of insider trading rules?

ryanianian• 6 years ago

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" mantra close over the past 10+ years.

The choice to do this seems relatively obvious for Apple. They have spent years building up their silicon game with portables. Their frustration with Intel is also palpable, so it was probably "just" a waiting game (not "how" or "if") in deciding when to pull the trigger and start using those chips outside of iPhones/iPads.

Someone4• 6 years ago

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.

AgentOrange1234• 6 years ago

Probably a big opportunity cost though. It surely takes a lot of time from senior engineers to port the software, figure out this whole translation system, etc...

djrogers• 6 years ago

* I am also really curious about the accounting and financial disclosures required in such decisions. *

There are none, beyond the dollar figures set aside for R&D.

How much are institutional investors informed of long range plans?

In the case of Apple, very little to not at all. Other companies have different policies - most share roadmaps and long range plans rather freely compared to Apple.

CoolGuySteve• 6 years ago

Apple already supports ARM so they have the whole toolchain, most of their operating system, and many frameworks ported. Most of the heavy lifting was done in Project Purple (aka the first iPhone).

Porting from PPC to x86 was arguably more difficult as a lot more of the framework code had endianness assumptions baked in.

qalmakka3• 6 years ago

As Steve Jobs himself said in the famous Mac Intel keynote, Mac OS X ran on Intel from day one, "just in case". After all Darwin has always supported x86, and NEXTSTEP ran fine on x86 too, so probably it was not that difficult from a core system standpoint migrating to x86.

gsnedders• 6 years ago

Porting from PPC to x86 was arguably more difficult as a lot more of the framework code had endianness assumptions baked in.

Did it? The code they inherited from NeXT didn't assume endianness, and until Rhapsody Developer Release 2 they shipped x86 builds. Some applications like iTunes ran on Windows, with a partial port of the Cocoa libraries underlying them (this, too, was a descendent of old NeXT support for Windows).

It's entirely plausible that Apple didn't have to do much; as they said at the time, they never stopped supporting x86 after Rhapsody Developer Release 2, and they had the OS running on x86 the entire time. I'd assume from the point of view of most developers working on OS X they simply had requirements to avoid endian assumptions, etc., and occasionally the team maintaining x86 support would send a nondescript patch to "fix the endianness assumption".

ksec• 6 years ago

While I have talked about the financial of an All in ARM Mac platform, that was from an angle of each individual component. But you could also look at it from a company R&D perspective.

Example. Apple ship ~10M MacBook Air a year. Current spending on MacBook Intel chip is roughly $200 per unit. As long as Apple could make it below $200, they make more profits or lower the price.

That is a per unit, per model angle. i.e Apple could easily have fitted an A12Z inside Macbook Air, and save them at least $150.

Or you could look at it from a company total perspective.

Apple currently spend $2B annual R&D ( a made up number )on its Chip design. How much more additional would we need if we need to design for Mac CPU as well. $500M / $1B? Great, and do it. ( If you follow Apple closely, Apple's Net Profits and R&D has been at a fixed percentage for a fairly Long time )

And finally, I am also curious about the accounting and financial disclosures required in such decisions.

There is nothing that needs to disclose until these decision make material effect on its stock performance.

It is worth pointing out Apple receives $10B annually from Google for having it as default search engine on Safari alone. While it is expensive to design its own chip, comparatively speaking it is still peanuts for Apple.

At the rate things are going, Apple could have spend more money on Apple TV+ Originals than R&D spend on Mac CPU alone.

scarface743• 6 years ago

Institutional investors can’t know more than retail outside investors. That would be illegal. Why would they need to make any public disclosures? They don’t publish margins per segment.

andoma3• 6 years ago

I wonder how it handles the stricter memory ordering from x86? For example, this code:

  void store_value_and_unlock(int *p, int *l, int v)
  {
    *p = v;
    __sync_lock_release(l, 0);
  }

on x86_64 compiles to:

   mov     dword ptr [rdi], edx
   mov     dword ptr [rsi], 0
   ret

vs on arm64:

   str     w2, [x0]
   stlr    wzr, [x1]
   ret

Notice how the second store on ARM is a store with release semantics to ensure correct memory ordering as it was intended in the original C code. This information is lost as it's not needed on x86 which guarantees (among other things) that stores are visible in-order from all other threads.

monocasa32• 6 years ago

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 apps), would be the ones most likely to break.

3) Some stricter memory model in hardware? Seems like that'd go against most of the stated reason for switching to ARM in the first place.

andoma3• 6 years ago

3) Some stricter memory model in hardware? Seems like that'd go against most of the stated reason for switching to ARM in the first place.

I would assume that a more strict memory model would be enabled only for processes that needs it (ie, Rosetta translated ones). So a cpu-flag is set/cleared when entering/exiting user mode for those processes. Does this require a separate/special cache coherency protocol? A complete L1d flush when entering/leaving these processes (across all CPUs)? Not and expert in this field and it feels complicated for sure. Is it worth it for just emulating "legacy" applications during a transitional period? Perhaps Apple can pull it off though.

BeeOnRope5• 6 years ago

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.

AndrewStephens• 6 years ago

Elsewhere in the documentation[0] Apple explicitly calls out that code that relies on x86 memory ordering will need to be modified to contain explicit barriers. All sensible code will do this already.

[0] https://developer.apple.com/documentation/apple_silicon/addr...

gpderetta7• 6 years ago

Sure, for source translation that's sorta fine (although I wouldn't want to be the one debugging it). The issue is binary translation, there is really no such a thing as a acquire or release barrier on x86.

viro2• 6 years ago

So does this mean no windows VMs?

tonyedgecombe• 6 years ago

Yes, which is an interesting problem for Parallels and VMWare. I would imagine the key requirement for most of their Apple customers is to run Windows.

On the other hand it might be an opportunity to offer Windows in the cloud to Apple users.

p1mrx• 6 years ago

ಠ_ಠ when they refer to x86_64 as "Intel instructions": https://en.wikipedia.org/wiki/X86-64#AMD64

gabagool• 6 years ago

I don't think Apple has sold any AMD Macs, correct?

I understand your consternation, though. Dev docs shouldn't require dumbing things down.

Mister_Snuggles2• 6 years ago

I'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 Fusion on an Intel Mac, which is a perfect solution for me - I get the great features of MacOS, plus I can run the proprietary toolset that my job requires.

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.

Due to budget constraints, I don't think there's any way that my work would spring for a MacBook Pro plus a Windows machine for me.

On the flip side, Windows 10 seems to be getting really good, so I expect that I'll be just as happy and productive with Windows 10+WSL2.

empthought• 6 years ago

It will be at least several years before you will not be able to purchase a new Intel-based Mac.

Mister_Snuggles2• 6 years ago

From another article, Apple claims that the transition will be complete in two years. I have 2.5 years left before I will be eligible to have my work computer replaced.

Depending on the exact timing of Apple's product cycles and the procurement cycle, I'll either be getting one of the last Intel Macs or a Windows machine of some description.

If an Intel Mac is still available at this time, that brings other concerns - in particular, Macs are on a five-year replacement cycle at my work, so even if they are available it may not be prudent to buy one. Will it get new MacOS versions for its 5-year lifetime? Will it still get security updates five years down the road? Will the developers of the applications I use still ship x86_64 versions of their Mac applications?

Because of all of that uncertainty, it may end up being a better option to just get a Windows machine when I'm eligible. Fortunately, a lot of that uncertainty should be cleared up by the time that happens.

EDIT: Another remote possibility is that VMware figures out some way to fill in the gaps that Rosetta doesn't. After all, they did figure out how to do virtualization on a platform that didn't even support it.

JimmyAustin• 6 years ago

My understanding is that that line only refers to VM applications written and compiled for x86, and doesn't stop a VirtualBox (or any other VM provider) from compiling an ARM binary that doesn't require Rosetta.

I don't think this is a policy restriction so much as there not being support for Intel virtualisation technologies that that might rely on.

geoelectric• 6 years ago

Think this is accurate. Any modern x86 virtualization software depends on hypervisor assistance from Intel/AMD to run at reasonable speeds, and that's just virtualizing x86 on x86--more like a context shift between sandboxes. Full virtualization through a CPU emulator to boot isn't very likely to be practical anytime soon.

I suspect they'll treat it as a policy restriction, though, so they wouldn't have to deal with emulator compatibility going forward. Any solution that would be even minimally able to support virtualizing x86 would probably be ugly to keep running. If VMW or Parallels gets something going, my guess is they'll have to work through Apple to get an exception.

reaperducer3• 6 years ago

Tim Cook says new Intel Macs are coming out this year. If you can convince your company to buy you one, you should be good until 2030.

Not being able to do your job would be enough for even my craptastic company to buy me a new machine.

paxys• 6 years ago

2030 is a stretch. Apple has generally supported new Mac hardware for 5-7 years, and my guess is the timeline is only going to get shorter for Intel-based Macs going forward, considering their resources are going to be disproportionately allocated to the newer versions.

ricketycricket• 6 years ago

First Intel Macs were released in January 2006 and OS X dropped support for Power PC in August 2009 with 10.6 Snow Leopard. If the same timeline is followed here, Intel support will be dropped around 2024. I wouldn't expect to get 10 years out of an Intel Mac.

Slartie• 6 years ago

I have a very similar situation: I loved using MacBook Pros as my work computer for over 10 years now, but while my job consists of 80% of cross-platform Java development stuff, it also includes working on and compiling various custom binaries (from big fat Chromium builds down to little system-level libraries and Linux kernel modules). All three major OSes are targets: MacOS, but most importantly Windows and Linux - especially Linux, because that's the main production environment on which our end products usually run, while the others are mostly needed to enable our devs to develop on their preferred platforms.

Windows and Linux MUST be x86_64, because that stuff needs to run on that arch eventually - it's of no use if it "works on my (ARM) machine". The Mac platform has, until now, been the ideal platform for my work, because it comes with by far the best OS on which I can be as productive as possible, while at the same time being able to execute all three targets within performant VM environments, greatly simplifying all the low-level development tasks as well as testing and experimentation. Even USB hardware could transparently be routed into the VMs - something that's also very important for me, as I often need to deal with weird and rather unusual periphery, and which is highly problematic when working on remotely hosted VMs, which I did try for a while back then when MacBooks had that RAM cap at 16GB in order to be able to utilize more memory.

I'm still good with my current MacBook Pro for about two years or so, which gets me well into the transition period. I know that I'll definitely be tempted to privately buy a replacement for an old 2011 MacBook Air, which I still use for light browsing tasks and stuff at home and which will be totally fine if it's ARM-based. If anyone happens to come around with some kind of VM emulation solution for actually virtualizing x86_64 OSes on the ARM-based Macs - there at least seems to be a demand, so I haven't lost hope that one of the likes of Parallels or VMware might take up that task - I'm going to give that a try and see whether it's a solution to my remaining 20%.

If that doesn't work out, I'll have to consider either switching to ARM Mac regardless and keeping the old machine (or another PC laptop or something) around as a second machine for the low-level Windows/Linux work, or ditching the Mac platform and moving to a Linux-based machine as my main computer, with Windows in a VM, and maybe getting a small ARM Mac as a "sidekick" for that bit of MacOS compilation and testing work. Either of those will be worse than my current, nearly-perfect setup, which was originally enabled only by the beauty of ISA compatibility between the Mac and PC platforms.

ogre_codes2• 6 years ago

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.

comex2• 6 years ago

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.

ogre_codes2• 6 years ago

As far as I can tell, you can't buy Windows for ARM, you can only get a license by buying specific hardware.

Aside from that, most people who want Windows support on a Mac want support for x86 Windows, not the ARM version. So even if it does run, it's likely to be a hobbyist/ hacker thing, not a product.

jmull2• 6 years ago

Currently I run it in VMware Fusion

That’s how you’d do it on an ARM Mac too.

Rosetta is about executing Mac apps on ARM Macs. For Windows apps you’re still going to go to a third party, most likely the same third-parties as before.

m_mueller• 6 years ago

It will be very slow to emulate a Windows x86 kernel on ARM.

snowwrestler• 6 years ago

That line just means you can’t run an emulator on top of an emulator, which makes sense. Performance would suck.

What will happen instead is that companies like VMware will release emulators that run natively on Apple chips. (Rather than trying to run on top of Rosetta.) However, Intel Windows performance might still suck in those. Remains to be seen.

qalmakka3• 6 years ago

Maybe with this growing interest in ARM desktops someone could consider continuing that project that was going around a few years ago of integrating QEMU and WINE. Some old x86 Win32 apps would probably run fine under, like they do on Microsoft's emulator.

phs318u• 6 years ago

companies like VMware will release emulators that run natively on Apple chips

Exactly. This has happened before e.g. Microsoft's VirtualPC [0].

However, Intel Windows performance might still suck in those

Bingo. I remember how agonisingly slow VirtualPC was for anything remotely useful (forget gaming).

[0] https://web.archive.org/web/20071031005603/http://www.micros...

loph• 6 years ago

What's old is new again.

This reminds me of Digital's VEST technology. VEST would convert VAX programs to run on Alpha. From 32-bit CISC to 64-bit RISC. Nearly 30 years ago.

https://web.stanford.edu/class/cs343/resources/binary-transl...

reaperducer3• 6 years ago

Or the PET emulator from 38 years ago that Commodore released because it wasn't sure that the C-64 would have any software.

Ditto for the C-64 CP/M cartridge of the same vintage.

classichasclass2• 6 years ago

The PET emulator was an interesting case. It relied on the fact that BASIC 2.0 on the C64 was similar enough to that on the PET (and IEC serial devices similar enough to IEEE-488 ones, from the BASIC side, at least) that many programs ran unmodified. The interesting bits were adding some goop so that many common POKEs and PEEKs from BASIC would "just work" as well (like CB audio, screen memory, etc.). This was even enough for some machine language programs, though many choked on the different memory map.

slaymaker1907• 6 years ago

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.

benmmurphy• 6 years ago

is the translation 100% static? for example if I do something like:

    function_pointer = blackbox_function_translator_does_not_understand();
    function_pointer()

then how do we end up calling the correct address in arm64 land? there are no type tags in assembly to distinguish between integers and addresses. in QEMU my understanding is translation is done dynamically so addresses would float around in memory as x86_64 addresses and then when you tried to `call` them it would look up a mapping table. In QEMU I suspect they also try and optimise this case similar to a JIT using inline caching so most of the time you wouldn't actually hit the mapping table.

But if you are not dynamically converting x86_64 addresses to arm64 addresses then you need to understand what all the addresses in the program are and understand all the manipulations that might be performed on those addresses. now, you shouldn't actually be doing weird manipulations of addresses to functions in memory but if you are running obfuscated code this often happens.

I think in QEMU this would work assuming (myfun+4)() does something intelligent:

    uint64_t add(uint64_t v) {
      return v + 4;
    }

    void myfun();

    int main() {
      void (*x)() = &myfun;
      x = (void*)add((uint64_t)x);
      x();
      printf("%lld\n", add(4));
    }

if you are holding function addresses as arm64 addresses in memory then you need to dispatch add() based on whether the argument is an integer or an address.

About the Rosetta Translation Environment

Related Stories