1

Please indulge my pipe dream for a moment :pray:

If I wanted to be able to target PowerPC / Darwin9 (Leopard), what would need to be added to the Swift compiler?

Would it be enough to add PowerPC / Darwin9 support to LLVM, and then the Swift infrastructure would automatically gain that target? Or would additional work be needed specific to the Swift compiler?

Thanks!

3 Likes
2

You probably couldn't get Objective-C support in this theoretical build of Swift because that requires support form the Objective-C Runtime support. But I'm sure it wouldn't be that hard considering someone ported a lot of Swift to Mac OS 9 at one point.

2 Likes
3

Have you seen this? Swift on Mac OS 9 // -dealloc

5 Likes
4

I have, what an excellent hack! His post is what made me think this might be doable.

2 Likes
5

Aside from reviving LLVM's support for PowerPC Darwin, it's likely you'll have to modify the Swift runtime a bit; you could disable ObjC interop to avoid depending on the integration we get in newer versions of libobjc, but the runtime code also generally takes for granted a newer version of the C++ standard library than shipped in those older OSes. You might be able to treat it as an Embedded Swift target if you want to subset out any runtime support at all.

2 Likes
6

Yep, these days I’d probably start from embedded, so I wouldn’t have to chop the stdlib down and build the runtime up myself like I did with the hack. As has been said, you won’t get free ObjC interop, so no backporting Swift AppKit apps. You probably can get CF interop to work the same way I did, but that might take the wind out of your sails somewhat.

  • Get modern Clang to compile for powerpc-apple-darwin again
  • Go find all the places in the Swift codebase that use “darwin” as a shorthand for “has ObjC interop”. I got to skip this because I used “aix” as the name of the OS. (But you’d get to skip a lot of things I had to deal with about XCOFF.)
  • Make some module maps for the old OS SDKs, or find an SDK that still declares ppc things but is new enough for module maps.
  • Turn things off in the compiler until you have a subset that works. :upside_down_face: Get optimizations-on, no-debug-info working first, because it’s closest to what you would have had with C.

P.S. …it’s possible that you could get ObjC messages to work, just not subclassing. But the compiler right now only has “ObjC is present” and “ObjC is absent” modes, so this would be yet more work to disentangle.

7 Likes
7

Thanks so much for the in-depth replies!

I've just recently started looking at Iain Sandoe's fork of LLVM-7.x, the goal of which was to complete the unfinished PowerPC/Darwin work in LLVM. Might be a while before I can circle back around to Swift support :sweat_smile:

1 Like
8

Not a pipe dream, but a reality! :wink:

image
image800×600 147 KB

You can already target Darwin/PowerPC today, see x.com (and many other systems, see x.com), by cross-compiling to WebAssembly, and then further compiling to native code, via e.g. w2c2, or wasm2c.

This requires no changes to the Swift compiler or LLVM.

This approach comes with support for WASI (essentially a POSIX-like/subset API), but you can also import and call "host" C functions. I'm currently working on GitHub - turbolent/W2C2BridgeGenerator: Generate bindings for w2c2 from a bridgesupport file, a tool that automatically generates bindings for C and Objective-C code, so it's possible to use all Mac OS X frameworks, e.g. AppKit (via GitHub - turbolent/BridgeSupport-Tiger: Modern BridgeSupport (LLVM/Clang-based), adjusted for Mac OS X Tiger (10.4) and Leopard (10.5)).

Even small Swift binaries are quite large, as they include the whole Standard Library. Those binaries can be translated to C very quickly with w2c2, but the final compilation with gcc takes quite a while, especially on era-appropriate hardware.

The new Swift Embedded feature greatly improves the size and performance of WebAssembly binaries, see Some feedback from my short experience with SwiftWasm - #5 by Max_Desiatov. However, this feature is still experimental and seems to have some bugs (Bug in Embedded/ARC/WebAssembly combination?).

10 Likes
9

omg this is amazing!

10

Happy to finally announce TigerSwift:

11 Likes
11

Oh my God

12

You made this tool work with Rhapsody OS!!!!

13

Bastian is on fire! Wow!

14

@jrose What hath you wrought?

15

Personally, I'm still hoping to run Swift on my Amiga 500 one day :crossed_fingers: Can we get a 68000 backend going?

2 Likes
16

I need to look into what @turbolent’s done to make the ObjC parts work, I kinda assumed it just wouldn’t! Though I did say maybe objc_msgSend was going to be sufficient…

1 Like
17

To be clear, though it is possible to call into Objective-C APIs, this isn't accomplished by getting Swift's Objective-C bridge working.

Instead, GitHub - turbolent/W2C2BridgeGenerator: Generate bindings for w2c2 from a bridgesupport file parses bridgesupport files, which describe Objective-C classes and methods, and generates C functions for all Objective-C methods.
The bridge generator also optionally translates between little-endian and big-endian (WebAssembly is little-endian), so that the bridging code and application also works on PowerPC systems.

5 Likes
18

With w2c2, you should be able to run Swift on Amiga OS. I have not tried it myself, but as long as a C89 compiler is available, it should be little effort.

4 Likes
19

It would be so awesome if PowerPC/Darwin support could return to LLVM. Please let us know if you are planing some kind of GitHub Sponsor.