I thought FAT binaries don’t work like that - they included multiple instruction sets with a header pointing to the sections (68k, PPC, and x86)
Rosetta to the best of my understanding did something similar - but relied on some custom microcode support that isn’t rooted in ARM instructions. Do you have a link that explains a bit more in depth on how they did that?
Fat binaries contain both ARM and x86 code, but I was referring to Rosetta, which is used for x86-only binaries.
Rosetta does translation of x86 to ARM, both AOT and JIT. It does translate to normal ARM code, the only dependency on a Apple-specific custom ARM extension is that the M-series processors have a special mode that implements x86-like strong memory ordering. This means Rosetta does not have to figure out where to place memory barriers, this allows for much better performance.
So when running translated code Apple Silicon is basically an ARM CPU with an x86 memory model.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
Rules
1. Submissions have to be related to games
Video games, tabletop, or otherwise. Posts not related to games will be deleted.
This community is focused on games, of all kinds. Any news item or discussion should be related to gaming in some way.
2. No bigotry or harassment, be civil
No bigotry, hardline stance. Try not to get too heated when entering into a discussion or debate.
We are here to talk and discuss about one of our passions, not fight or be exposed to hate. Posts or responses that are hateful will be deleted to keep the atmosphere good. If repeatedly violated, not only will the comment be deleted but a ban will be handed out as well. We judge each case individually.
3. No excessive self-promotion
Try to keep it to 10% self-promotion / 90% other stuff in your post history.
This is to prevent people from posting for the sole purpose of promoting their own website or social media account.
4. Stay on-topic; no memes, funny videos, giveaways, reposts, or low-effort posts
This community is mostly for discussion and news. Remember to search for the thing you’re submitting before posting to see if it’s already been posted.
We want to keep the quality of posts high. Therefore, memes, funny videos, low-effort posts and reposts are not allowed. We prohibit giveaways because we cannot be sure that the person holding the giveaway will actually do what they promise.
5. Mark Spoilers and NSFW
Make sure to mark your stuff or it may be removed.
No one wants to be spoiled. Therefore, always mark spoilers. Similarly mark NSFW, in case anyone is browsing in a public space or at work.
6. No linking to piracy
Don’t share it here, there are other places to find it. Discussion of piracy is fine.
We don’t want us moderators or the admins of lemmy.world to get in trouble for linking to piracy. Therefore, any link to piracy will be removed. Discussion of it is of course allowed.
Apple’s been doing it for years. They try to do ahead of time transpiling wherever they can but they also do it on-the-fly for things like JITed code.
I thought FAT binaries don’t work like that - they included multiple instruction sets with a header pointing to the sections (68k, PPC, and x86)
Rosetta to the best of my understanding did something similar - but relied on some custom microcode support that isn’t rooted in ARM instructions. Do you have a link that explains a bit more in depth on how they did that?
Fat binaries contain both ARM and x86 code, but I was referring to Rosetta, which is used for x86-only binaries.
Rosetta does translation of x86 to ARM, both AOT and JIT. It does translate to normal ARM code, the only dependency on a Apple-specific custom ARM extension is that the M-series processors have a special mode that implements x86-like strong memory ordering. This means Rosetta does not have to figure out where to place memory barriers, this allows for much better performance.
So when running translated code Apple Silicon is basically an ARM CPU with an x86 memory model.
That makes a lot of sense - I wonder if they also do the SIGSEGV trick like HotSpot to know when they need to JIT the next chunk of instructions