It is said that future Macs will use ARM, is golang ready for this move ?
588 views
Skip to first unread message
Christophe Meessen
Jun 10, 2020, 5:32:11 AM6/10/20
to golang-nuts
There is a rumor that Apple will announce at the WWDC2020, the 22 june, that the Macs of generation 2021 and beyond will use ARM processors in place of the Intel processors.
Is Golang ready to follow this move ? Will I be able to compile and run my go programs on ARM Macs ?
Jesper Louis Andersen
Jun 10, 2020, 5:51:59 AM6/10/20
to Christophe Meessen, golang-nuts
I'd say Go is as ready as you can be for that move. darwin/arm64 is currently a fully supported architecture, and I doubt you need lots of work in order to make the port to an eventual new Mac generation. By far the most complex part of that port is support of arm64, but that work has already been done.
However, it might still require some extra bits of work here and there if I should hazard a guess. So immediate support might not be present. Then again, Apple would need to have some kind of plan in place for the move in general. I can see two paths they can take:
1. Most of the Apple Store, at least to my knowledge, stores LLVM IR rather than the final machine code product. This allows Apple to recompile programs in the store for a new architecture. While this won't support certain programs with Intel assembly, the vast majority of programs would be supported almost from the first day.
2. Dynamic binary translation from machine-code to machine-code has been used in the past for these architectural changes. While this carries a penalty, it also provides a short-term solution. The added efficiency of recompiles for the new machine code target encourages people to install newer versions in the case. The history is old and long here. M68K to PowerPC, PowerPC to x86, x86 to DEC Alpha, VAX to Alpha RISC, and even more. Apple have been involved in at least two such models in the past, so I wouldn't count this out as a strategy.
On Wed, Jun 10, 2020 at 11:32 AM Christophe Meessen <christoph...@gmail.com> wrote:
There is a rumor that Apple will announce at the WWDC2020, the 22 june, that the Macs of generation 2021 and beyond will use ARM processors in place of the Intel processors.Is Golang ready to follow this move ? Will I be able to compile and run my go programs on ARM Macs ?
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f8bd2b7a-99e1-47f1-8cc5-3d37a1aeade5o%40googlegroups.com.
J.
Robert Engels
Jun 10, 2020, 6:53:10 AM6/10/20
to Jesper Louis Andersen, Christophe Meessen, golang-nuts
The App Store does not store LLVM IR code for Mac software - at least not by default. It stores compiled binaries and optional debug symbols.
On Jun 10, 2020, at 4:51 AM, Jesper Louis Andersen <jesper.lou...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiUbDPbMz_io9DMTmcxD04axZ6Ap8ff2OANfZPED8YQ3VA%40mail.gmail.com.
Jesper Louis Andersen
Jun 10, 2020, 8:21:23 AM6/10/20
to Robert Engels, Christophe Meessen, golang-nuts
Ah, I was wrong. It is the iOS, watchOS, tvOS stuff that does that. The name is "Bitcode".
J.
Ian Lance Taylor
Jun 10, 2020, 12:23:23 PM6/10/20
to Christophe Meessen, golang-nuts
David Riley
Jun 10, 2020, 3:24:24 PM6/10/20
to Jesper Louis Andersen, Christophe Meessen, golang-nuts
On Jun 10, 2020, at 5:50 AM, Jesper Louis Andersen <jesper.lou...@gmail.com> wrote:
>
> 2. Dynamic binary translation from machine-code to machine-code has been used in the past for these architectural changes. While this carries a penalty, it also provides a short-term solution. The added efficiency of recompiles for the new machine code target encourages people to install newer versions in the case. The history is old and long here. M68K to PowerPC, PowerPC to x86, x86 to DEC Alpha, VAX to Alpha RISC, and even more. Apple have been involved in at least two such models in the past, so I wouldn't count this out as a strategy.
This is certainly pedantry, but it's worth noting that the VAX to Alpha translation in VMS wasn't dynamic recompilation, but static. There are almost certainly similar examples; I'm not familiar enough with NT history to remember if there was a similar translator for the Alpha version, but given that Dave Cutler was at the helm of that transition (though not the VAX->Alpha transition at DEC), I wouldn't be surprised.
>
> 2. Dynamic binary translation from machine-code to machine-code has been used in the past for these architectural changes. While this carries a penalty, it also provides a short-term solution. The added efficiency of recompiles for the new machine code target encourages people to install newer versions in the case. The history is old and long here. M68K to PowerPC, PowerPC to x86, x86 to DEC Alpha, VAX to Alpha RISC, and even more. Apple have been involved in at least two such models in the past, so I wouldn't count this out as a strategy.
Also worth noting that IBM i (f/k/a System i and AS/400) traditionally stores its executables as an IR form to be compiled to native code (currently PPC) on execution, though my recollection is that this is a one-time process, not a JIT process like Java or WASM.
- Dave
David Riley
Jun 10, 2020, 3:25:25 PM6/10/20
to Jesper Louis Andersen, Christophe Meessen, golang-nuts
On Jun 10, 2020, at 3:23 PM, David Riley <frave...@gmail.com> wrote:
>
> Also worth noting that IBM i (f/k/a System i and AS/400) traditionally stores its executables as an IR form to be compiled to native code (currently PPC) on execution, though my recollection is that this is a one-time process, not a JIT process like Java or WASM.
Well. Actually, currently POWER, as long as I'm being pedantic. :-)
>
> Also worth noting that IBM i (f/k/a System i and AS/400) traditionally stores its executables as an IR form to be compiled to native code (currently PPC) on execution, though my recollection is that this is a one-time process, not a JIT process like Java or WASM.
- Dave
Scott Pakin
Jun 10, 2020, 7:16:45 PM6/10/20
to golang-nuts
On Wednesday, June 10, 2020 at 1:24:24 PM UTC-6, David Riley wrote:
This is certainly pedantry, but it's worth noting that the VAX to Alpha translation in VMS wasn't dynamic recompilation, but static. There are almost certainly similar examples; I'm not familiar enough with NT history to remember if there was a similar translator for the Alpha version, but given that Dave Cutler was at the helm of that transition (though not the VAX->Alpha transition at DEC), I wouldn't be surprised.
While we're off-topic anyway, I do recall hearing a nifty talk 20+ years ago on semi-static translation from x86 to Alpha, both under Windows NT, that DEC implemented. They were worried about the dearth of Windows NT/Alpha software relative to the volumes of Windows NT/x86 software so translation made a lot of sense. I recall the speaker making a point that PowerPoint posed a challenge for them because their tool looked for known compiler code-generation patterns that they could exploit for performance (correctness?), but at the time, PowerPoint was hand-coded in assembly language. Imagine!
— Scott
P.S. I just checked, and amazingly, the paper is still on the Web: DIGITAL FX!32 Running 32-Bit x86 Applications on Alpha NT
Robert Engels
Jun 10, 2020, 8:48:26 PM6/10/20
to Scott Pakin, golang-nuts
When Macs first switched to Intel the OS included a Motorola 68k emulator so that existing Mac binaries would run.
On Jun 10, 2020, at 6:17 PM, Scott Pakin <scot...@pakin.org> wrote:
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5870abde-8141-4402-b964-95f1feb4240fo%40googlegroups.com.
David Riley
Jun 10, 2020, 9:26:08 PM6/10/20
to Robert Engels, Scott Pakin, golang-nuts
Not quite. When they switched to PowerPC, that was the case; the initial one was a table-driven instruction translator in ROM originally written for the M88k, which had been the original target before Motorola canned it, but it was apparently a relatively simple thing to change the translations to PowerPC instructions (only took a weekend according to legend, but, well, legends). It eventually evolved into something much more sophisticated and performant.
The transition from PowerPC to Intel ended the Classic VM environment that ran Mac OS 9, which included the old 68k translator in the ROM file. On a PowerPC Mac running OS X 10.4 (including G5s, which are 64-bit!), you can run 68k apps from the dark ages just fine (as long as they didn't use undocumented interfaces, etc). I've been doing exactly this recently while porting a very old Mac game to modern systems.
Anyway, no Classic support on Intel, thus no 68k either (and PowerPC only for OS X apps). The PowerPC emulation for Intel (Apple called it "Rosetta") was a licensed third-party product that used JIT-style compilation, but it really only worked for userland programs; it didn't support drivers and it presumably wasn't close enough to the real deal to support the Classic environment, so they dropped it in all Intel versions of Mac OS (10.5 dropped it for PowerPC as well for reasons I don't quite understand, since that was the last PowerPC version).
Anyway, given that the PowerPC translation on Intel only lasted through 10.6, and Apple just dropped 32-bit Intel support in 10.15, I would expect backwards compatibility support for Intel apps (if they're even planning it) to drop within 2-3 revisions of macOS after the transition. Just putting that out there.
The transition from PowerPC to Intel ended the Classic VM environment that ran Mac OS 9, which included the old 68k translator in the ROM file. On a PowerPC Mac running OS X 10.4 (including G5s, which are 64-bit!), you can run 68k apps from the dark ages just fine (as long as they didn't use undocumented interfaces, etc). I've been doing exactly this recently while porting a very old Mac game to modern systems.
Anyway, no Classic support on Intel, thus no 68k either (and PowerPC only for OS X apps). The PowerPC emulation for Intel (Apple called it "Rosetta") was a licensed third-party product that used JIT-style compilation, but it really only worked for userland programs; it didn't support drivers and it presumably wasn't close enough to the real deal to support the Classic environment, so they dropped it in all Intel versions of Mac OS (10.5 dropped it for PowerPC as well for reasons I don't quite understand, since that was the last PowerPC version).
Anyway, given that the PowerPC translation on Intel only lasted through 10.6, and Apple just dropped 32-bit Intel support in 10.15, I would expect backwards compatibility support for Intel apps (if they're even planning it) to drop within 2-3 revisions of macOS after the transition. Just putting that out there.
Robert Engels
Jun 10, 2020, 10:50:40 PM6/10/20
to David Riley, Scott Pakin, golang-nuts
Yep. My timeline/memory was wrong. It was the 68k to PowerPC. Intel required dual binaries. Thanks for the correction.
> On Jun 10, 2020, at 8:26 PM, David Riley <frave...@gmail.com> wrote:
>
> Not quite. When they switched to PowerPC, that was the case; the initial one was a table-driven instruction translator in ROM originally written for the M88k, which had been the original target before Motorola canned it, but it was apparently a relatively simple thing to change the translations to PowerPC instructions (only took a weekend according to legend, but, well, legends). It eventually evolved into something much more sophisticated and performant.
> On Jun 10, 2020, at 8:26 PM, David Riley <frave...@gmail.com> wrote:
>
> Not quite. When they switched to PowerPC, that was the case; the initial one was a table-driven instruction translator in ROM originally written for the M88k, which had been the original target before Motorola canned it, but it was apparently a relatively simple thing to change the translations to PowerPC instructions (only took a weekend according to legend, but, well, legends). It eventually evolved into something much more sophisticated and performant.
Robert Engels
Jun 11, 2020, 8:15:49 AM6/11/20
to David Riley, Scott Pakin, golang-nuts
The wiki page has some neat details on this https://en.m.wikipedia.org/wiki/Mac_68k_emulator
On Jun 10, 2020, at 9:49 PM, Robert Engels <ren...@ix.netcom.com> wrote:
Yep. My timeline/memory was wrong. It was the 68k to PowerPC. Intel required dual binaries. Thanks for the correction.
Reply all
Reply to author
Forward
0 new messages