
About the Rosetta Translation Environment - loun
https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment
======
mkl
> 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.

~~~
amaranth
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](https://www.qemu.org/docs/master/user/main.html)

~~~
vmception
> 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.

~~~
coldtea
> _That 's par for course with Apple. They never acknowledge competitors_

Unlike which company that does?

~~~
vmception
[https://www.google.com/search?ei=CWzzXqODOLK90PEPhbi7uAY&q=%...](https://www.google.com/search?ei=CWzzXqODOLK90PEPhbi7uAY&q=%22leading+competitors+say%22&oq=%22leading+competitors+say%22&gs_lcp=CgZwc3ktYWIQAzoECAAQRzoGCAAQBxAeOggIABAHEAoQHjoECAAQHjoGCAAQCBAeOgYIABAWEB46CAgAEBYQChAeOgUIIRCgAToFCCEQqwJQjT1Y9klg7ktoAHABeACAAVeIAcADkgEBNpgBAKABAaoBB2d3cy13aXo&sclient=psy-
ab&ved=0ahUKEwjjq6ma3ZrqAhWyHjQIHQXcDmcQ4dUDCAw&uact=5)

~~~
coldtea
That's not acknowledging competitor technologies.

That's referencing them to tell how better you are: "Optional Clear View™ mast
offers up to 40% greater visibility than leading competitors."

Apple does that too.

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

~~~
monocasa
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.

~~~
BeeOnRope
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.

~~~
monocasa
Expect you'd need to do that with every single store since the x86 instruction
stream doesn't have those semantics embedded in it.

That'd kill your memory perf by at least an order of magnitude, and kill perf
for other cores as well. It'd be cheaper to just say "you only get one core in
x86 mode". Essentially you'd be marking every store as an L1 and store buffer
flush and only operating out of L2.

~~~
phire
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 preformance atomic operations.

And I'm willing to bet Apple has made sure their implementation is good at
atomics.

~~~
monocasa
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 with an unlock, and L2 would now allow this cache line to be accessed

So you're looking at ~15 cycles of contention from L2 through the CPU core and
back down to L2 of a lock for that line.

If this all looks really close to a subset of hardware transnational memory
when you realize that the store can fail and the CPU has to do it again if
some resource limit exceeded, you're not alone.

Then somebody figured out that you can just stick an ALU directly in L2, and
send the ALU ops down to it in the memory requests instead of locking lines.
That reduces the contention time to around a couple cycles. These ALU ops can
also be easily included in the coherency protocol, allowing remote NUMA RMW
atomics without thrashing cache lines like you'd normally need to.

This is why you see both in the RISC-V A extension as well. The underlying
hardware has implementations in both models. I've heard rumors that earlier
ARM tried to do macro op fusion to build atomic RMWs out of common sequences,
but there were enough versions of that in the wild that it didn't give the
benefits they were expecting.

However, all that being said, atomics are orthogonal to what I'm talking
about. It's x86's TSO model, and how it _lacks_ barriers in places that ARM
requires them, with no context just from the instruction stream about where
they're necessary that's the problem here, not emulating the explicit atomic
sequences.

~~~
brigade
On the other hand, the ARMv8.5 flag manipulation instructions almost certainly
were added _specifically_ for x86 emulation.

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

~~~
CoolGuySteve
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.

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

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

~~~
snowwrestler
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.

~~~
phs318u
> 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...](https://web.archive.org/web/20071031005603/http://www.microsoft.com/mac/products/virtualpc/virtualpc.aspx?pid=virtualpc)

------
DCKing
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
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

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

~~~
GeekyBear
The more interesting point...

>The demo wasn't perfect: the game ran at 1080p with fairly middling settings,
but did so at what appeared to be at the very least a steady 30FPS, all while
being run as an emulated x86 version of the game. That is: the game wasn't
even natively compiled for ARM.

But consider that Intel's most powerful laptop chipset GPU, found in the 10th
generation Ice Lake series, is not capable of breaking single digit frame
rates on this game at 1080p.

Apple received some snark about this demo being lame, but it's only lame if
you don't understand at all just how terrible modern integrated laptop GPUs
are.

[https://www.androidpolice.com/2020/06/22/apples-chipset-
adva...](https://www.androidpolice.com/2020/06/22/apples-chipset-advantage-
has-me-more-jealous-than-ever)

~~~
monocasa
We all know that Intel iGPUs are terrible (at least until the new Xe based
GPUs start to come out).

The comparison I don't see enough people making is to throw out as an option
the one company that regularly ships semi custom, secure, x86 SoCs with GPUs,
AMD. An Xbox One SoC is literally half of the transistor count of an A12Z (5B
and 10B respectively).

And the frame rate was anything but steady there. And calling it "middling
settings" is pushing it as well, the env lighting wasn't even on Lara. It
looks like they dropped the settings as far down as they would go.

~~~
GeekyBear
Yet the marketing push for Ice Lake was that even if the CPU cores lost most
of their IPC gains to lower clock speeds, the GPU itself was to be a massive
improvement.

I'm looking forward to seeing if the demos were on the Dev Kit hardware,
because if that was the performance on a specially binned two year old iPad
Pro chip, it's pretty darn impressive.

~~~
monocasa
It's Tiger Lake that's supposed to see the passable GPU, when they use the
same cores as their new discrete GPU.

Not that I'm really defending Intel here, they fell behind the curve.

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

~~~
leeter
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.

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

~~~
leeter
True, but they did have the license IIRC. Otherwise they'd be licensing from
VIA or whomever owns that license now. That license AFAIK would include up to
SSE4. It's not like Apple is going to tell us. But the JIT nature makes me
think it's Transmeta as the company currently holding that IP is a "Patent
enforcement entity".

~~~
monocasa
Or they're just giving Intel the finger, banking on having a warchest of
defensive patents from acquiring nearly every promising fabless CPU startup of
the past 15 years.

Edit: Also, I don't think Transmeta's license would include SSE4. They were
defunct at that point.

~~~
leeter
Possible, I kinda doubt they would as Intel could just cut them off at the
knees as they threatened MS with for the Surface Pro X. There is the remote
possibility they are licensing from Intel too. At the end of the day I doubt
they are going to tell us. Once people start getting the dev machines they can
find the edges of the implementation. I suspect it has some quirks we'll
discover over time. Regardless this is speculation.

~~~
monocasa
> I kinda doubt they would as Intel could just cut them off at the knees

And then Apple would cut Intel off at the knees in return. Microsoft doesn't
really have any CPU design patents, Apple has thousands, so they'd be treated
differently.

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

~~~
jjcon
> 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.

~~~
PaulDavisThe1st
Intel can't (maybe). AMD can. In fact right now, AMD doesn't even have to keep
up, because it's substantially out in front.

~~~
jjcon
AMD has worse thermals than intel does which is likely the reason Apple is
switching in the first place

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

~~~
cpuguy83
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.

~~~
lsllc
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).

~~~
dannyw
There are heaps and heaps of ARM containers around thanks to the Raspberry Pi.

I've never had a problem running Docker on my Pi, and I don't expect anyone
will have a problem running Docker on a Mac given Apple's much much larger
developer market share.

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

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

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

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

~~~
perardi
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...](https://developer.apple.com/support/kernel-
extensions/\]\(https://developer.apple.com/support/kernel-extensions/\))

~~~
selsta
Apple ARM will support kexts.

[https://developer.apple.com/documentation/apple_silicon/inst...](https://developer.apple.com/documentation/apple_silicon/installing_a_custom_kernel_extension)

~~~
perardi
Well color me surprised. I figured that’d be on the chopping block.

~~~
monocasa
I was surprised too. I wonder which crazy peripheral (or maybe it was
antivirus/intrusion detection?) made them not go all in on "only apple gets to
be in kernel space".

~~~
perardi
Judging by this horrible Bitdefender Endpoint Security that IT has foisted
upon me: device management and anti-malware stuff.

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

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

~~~
qubex
The “ARM world” is almost inconceivably varied by _x_ 86 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.

~~~
Dunedan
> 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.

There is a rumor that Apple developed USB-C and donated it to the USB-IF [1].
Apple was also one of the first users of USB-C when they introduced the 12"
MacBook in 2015.

Since then they've continuously grown their adoption of USB-C, first in the
MacBook Pro in 2016, then in the iMac and iMac Pro in 2017, the iPad Pro,
MacBook Air and Mac Mini in 2018 and most recently in the Mac Pro in 2019. In
fact nowadays the only Apple devices still not featuring USB-C are the iPhone
and the (non-Pro) iPads.

There are probably good reasons why Apple hasn't replaced Lightning with USB-C
for the iPhone and iPad yet. If they replace Lightning with USB-C now, the
whole 3rd-party accessory ecosystem has to adapt to that. While that's
probably fine, if the rumors are true that Apple plans to remove all physical
ports from iPhones [2] next year, that would result in USB-C equipped
iPhones/iPads only being sold for 2-3 years, before there is another interface
again. So Apples thinking is probably that it's more customer friendly to
stick to Lightning until they replace it with a wireless solution and I'd
agree with such an assessment.

[1]: [https://www.macrumors.com/2015/03/13/apple-invents-
usb-c/](https://www.macrumors.com/2015/03/13/apple-invents-usb-c/)

[2]: [https://www.macrumors.com/2019/12/05/kuo-iphone-without-
ligh...](https://www.macrumors.com/2019/12/05/kuo-iphone-without-lightning-
connector-2021/)

~~~
qubex
Regarding USB-C I agree with you entirely and think you entirely missed the
point I was trying to make.

I am well aware Apple participated in the USB-C connector specification
processes and only introduced the Lightening port when it became clear to it
that USB-C would take longer to define than their urgency to ditch the old
iPod 30-pin connector would allow, forcing them to ‘defect’. They’re probably
rather sour about this deep down (since it forces them to have different “one
size fits all” interfaces on different lines of products, which kind of
undermines its own point).

At any rate, the thought I was trying to express is that I would be very
surprised if Apple adopted any kind of ‘standard’ ARM architecture from upon
which to begin its new era of ARM-based Macs. They’re not even calling them
ARM-based, they’re using the term “ _Apple Silicon_ ” (which is only a
marketing gimmick but it’s pretty indicative).

So... they might, during the course of their preliminary analyses and
feasibility studies identified a pre-existing ARM system architecture that
they are comfortable with, but most likely they’ll go for something
unashamedly homegrown such as whatever architecture they developed for the
iPhone and iPad and consequentially whatever boot procedure they follow, which
as far as I know is undocumented and subject to change (though it is the
regular target of reverse-engineering, because of jail-breaking... and that
game of cat-and-mouse has probably greatly enhanced code quality and reduced
exposed surface area).

The end result is that “from the inside” from a very low level (the kinds of
hardware levels) that matters when booting an OS and that it subsequently
screens userland and the users from, these details matter, and I don’t expect
them to be standard, I don’t expect them to be clear, and I expect that
unsigned OS images won’t be bootable.

That said I read that Apple has had a session at the WWDC 2020 about booting
other OSes from external drives on the ARM Developer Transition system, so who
knows, I could be wrong.

------
loph
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...](https://web.stanford.edu/class/cs343/resources/binary-
translation.pdf)

~~~
reaperducer
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.

~~~
classichasclass
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.

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

~~~
jayyhu
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.

~~~
throwaway2048
it would be a lot more normal to trap the illegal instruction, the same thing
that happens if you give a CPU a nonsense nonexistent instruction.

------
tomduncalf
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](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?

~~~
monocasa
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.

~~~
mrpippy
Microsoft is working on it.

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

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

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

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

------
underdeserver
Translating JITted code is a pretty cool trick.

~~~
ATsch
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](https://en.wikipedia.org/wiki/Project_Denver)

~~~
monocasa
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-intro/)

[https://www.realworldtech.com/crusoe-
exposed/](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. : \

------
viro
So does this mean no windows VMs?

~~~
tonyedgecombe
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.

