Add support for ppc64le-linux-musl

[jirutka]

@mksully22, @rgdoliveira, @gromero or @leitao, could you please help with porting Crystal for ppc64le?

Reference: #5861, #5689 (there’s important https://github.com/crystal-lang/crystal/issues/5689#issuecomment-375890198 and https://github.com/crystal-lang/crystal/issues/5689#issuecomment-375908315)

[RX14]

This will be much harder than #5861, since the compiler will have to be modified to support the powerpc ABI, instead of just the stdlib. Adding a new architecture is far more work than just a new libc. A more relevant reference of the amount of work to be done would be https://github.com/crystal-lang/crystal/pull/3424 and https://github.com/crystal-lang/crystal/pull/3491.

[ysbaddaden]

Don't be afraid by the ABI, thanks to Rust it's easy to bootstrap.

The very boring part are the LibC bindings, it takes forever to write and fix them.

The real fun starts when writing the assembly for fibers' context switch (look at coroutines in the LLVM version of the D compiler), then dealing with specific issues with the new architecture...

[kaniini]

out of curiosity, can crystal make use of makecontext/swapcontext? if so, alpine's libucontext is already working on powerpc

[RX14]

@kaniini i'd be reluctant to add a new dependency when we can do it on all existing architectures in a few lines of assembly. D seems to do it in assembly too, you can copy that (it's linked in a comment in the sourcecode linked).

[kaniini]

libucontext is a core system dependency, it's on basically every alpine machine :)

(edit: and it should be noted that the BSDs and glibc systems have the makecontext/swapcontext functions too)

[ysbaddaden]

We could probably use makecontext(3) (in fact we did) but these methods save and restore too much than required for switching fibers. The man pages says they're basically setjmp(3) with signal information, which we don't need —signals are handled in in a non-switching context, and later processed in a safe context.

We used to rely on libpcl that itself relies on setcontexts(3) or setjmp(3) but using a few lines of assembly for each architecture to store/restore a few registers to/from the stack proved enough and noticeably faster. See for example https://github.com/crystal-lang/crystal/issues/2072#issuecomment-175783546

[RX14]

All crystal needs is a stack switch, no other state needs to be kept. Switching stacks on most platforms is easy (write callee preserved registers to the stack, switch out stack pointer, pop preserved registers from the stack in reverse), and super fast.

Regardless, stack switching is still only a small part of the porting process to a new architecture (libunwind, misc. bugfixing, etc.) There's little point getting hung up on it.

[ysbaddaden]

Ah ah, "small part". It took me days to get the switch working on ARM, and a bunch more to get it working on AArch64 because of return branching restrictions :smirk:

[gromero]

@jirutka Hey! How are you? Well, unfortunately I won't be able to take a closer look at that atm since I'm pretty swamped with other stuff. I think somebody at IBM is trying to find out someone to address that readily but I can't tell for sure. Either way if that issue does not "get resolved by itself" in 2 months I can look at it for sure. Thanks for you concern on Power arch. Much appreciated. Regards!

[jirutka]

@gromero I’m fine, thanks! Don’t worry, I’ve talked with @leitao about it and he already talked with the toolchain team at IBM regarding Crystal. It’s not a high priority right now, but they look at it once finished some other projects. 😺

I’m fan of (Open) Power Architecture and you’ve made very good impression on us in Alpine, helping with (not just) porting to ppc64le! I’m just a bit sad that I don’t have access to any physical ppc64le machine. I’ve been thinking, does IBM offer some discounts or partnerships for universities (CTU in Prague, to be specific)? (Please let me know on e-mail or IRC about it, thanks!)

[rgdoliveira]

hi @jirutka, guess I will not be able to help porting of Crystal to ppc64le now, sorry. I'm a bit stuck in some other tasks and doing just minor contributions to Alpine in my free time.

[gromero]

@jirutka Take a look at Unicamp, Brno, and Oregon providers. You might be able to get a baremetal access from them: https://developer.ibm.com/linuxonpower/cloud-resources/ (I assumed you didn't ask for buying a Power machine, but instead just to have access on a physical one :) ) HTH. Regards.

[jirutka]

I assumed you didn't ask for buying a Power machine, but instead just to have access on a physical one :)

No, I meant buying Power machine. :)

[gromero]

@jirutka ha! That's even more interesting :-) I have to ask around. Probably the machines from OpenPOWER are the most affordable ones, lilke those from Tyan. Anyway I'll check.

[jirutka]

@gromero Any news about this? :)

[gromero]

@jirutka Hi! :) I'm on vacation right now returning on May 7. Once I return I can check what's happening internally and give you a heads up on that.

[leitao]

hi @jirutka,

I am trying to put it on our toolchain plan, but, at this time, it didn't get the priority it deserves, and I do not think we can get someone allocated to work on this in the near term. I will try to prioritize it again by the end of this year.