Enable arm64 and ppc(32/64) targets

[zeldin]

I tested this on NVIDIA Jetson TX1 (arm64) and on AmigaOne X1000 (ppc32 and ppc64).

[zeldin]

Thanks for reviewing. It appears that during the 9 months since I submitted this, arm64 has already been enabled on master. I'll update the pull request to merge with that.

[madscientist159]

@zeldin Yeah I was mostly interested in the POWER (ppc64el) support 😄

[zeldin]

@madscientist159 I can imagine. Too bad the Talos thing didn't work out for you, I was really looking forward to getting one. 😞

[madscientist159]

@zeldin We're actually going to be launching a Talos II based on POWER9 in the next couple of months; no crowdfunding w/ prototypes already in house, as well as being significantly cheaper.

Still interested in a Talos? 😉

[zeldin]

@madscientist159 Woo! Sounds awesome. 😆 I'd definitely want in on that. 👍

[barracuda156]

Is the version of context here working on Darwin PPC? In Boost upstream it is broken. Here it seems corrections were made, but I do not see ppc-specific commits in history.

[zeldin]

@barracuda156 Good question, I only tested it on Linux. I can test it later and report back.

[barracuda156]

@barracuda156 Good question, I only tested it on Linux. I can test it later and report back.

@zeldin Thank you, will be great!

I wanna fix Boost for PPC in Macports. As a temporary solution, we disabled context & coroutine on <10.6 && 10.6 PPC: https://trac.macports.org/ticket/64978
But some dependents of Boost actually need these libs.

Another question, beside building, is whether assembler code itself should be updated for specific version of Boost or not. For example, context in Boost176 differs quite a bit, and while it is broken as-is, it may have some features which lack in this version of libcontext. For instance, it has an additional component ontop_ppc32_sysv_macho_gas.S (and the same for other archs).

P. S. If you test it on Darwin, you may want this: #3

UPD. Ok, I was able to build boost176 for ppc now on 10.6.8 Rosetta with context & coroutine libs enabled. Whether it will work correctly is another question LOL
Cannot test for ppc64 right now, away from my PowerMacs.

[zeldin]

@barracuda156 Ok, I've tested now.
The code in this repo does in fact work on macOS 32-bit PPC (10.5.8 Leopard). In addition to the fix you pointed to, I also had to rename the label l1 in one of the two asm functions or gcc would complain that it was double defined.
I also tested the macOS 64-bit ARM implementation (on 12.5 Monterey) and that worked as well.
I could not test the 64-bit PPC or 32-bit ARM implementations, as I don't have any such hardware running macOS.

[barracuda156]

@zeldin Thanks for an update!
Interesting, I did not get an error with l1 (10.6.8 Rosetta, ppc32, gcc12, boost176). Which compiler and Boost did you use?

[zeldin]

powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
I have boost 1.58 installed through homebrew, but AFAICT the test program does not use boost.

[zeldin]

@barracuda156 Hm, were you by any chance using jump_ppc32_ppc64_sysv_macho_gas.S (which does not have an l1 label)? I'm using jump_ppc32_sysv_macho_gas.S. Edit: No wait, that't just a wrapper that includes the other file, which is why it doesn't contain any labels at all. 😄

[barracuda156]

@zeldin BTW have you built Fibonacci test? Assembler code in upstream still has issues and requires extra fixes. I will try to use the code from here and see if it works better (but it lacks one function altogether).

[zeldin]

@barracuda156 The only tests I have built are tests/coroutine_example.cpp, and KiCAD.

[barracuda156]

@barracuda156 The only tests I have built are tests/coroutine_example.cpp, and KiCAD.

I tried using the code from here, and it also fails, unfortunately: macports/macports-ports#16407 (comment) (test and results below in the thread).

It looks like the thing was/is fundamentally broken, and required substantial rewrite for some other platforms:
boostorg/context#120
boostorg/context#51

[zeldin]

@barracuda156 Well, the fibonacci.cpp in that issue uses boost::context, not libcontext. It runs fine for me under Linux/ppc32 with boost 1.79.0.

[barracuda156]

@barracuda156 Well, the fibonacci.cpp in that issue uses boost::context, not libcontext. It runs fine for me under Linux/ppc32 with boost 1.79.0.

I meant I have built Boost context replacing assembler sources with ones from here (plus minimal changes to missing ontop_ppc32), and that also fails the test. It can be that something else is broken in Boost aside of assembler, of course.

I didn’t think to build stand-alone libcontext and link to it, to be honest, but I could try that as a matter of experiment.

P. S. I should have compared headers too, maybe something incompatible there.

[zeldin]

@barracuda156 Ok, so i shimmed the fibonacci example to use libcontext, result is here. This runs just fine on Mac OS X 10.5.8 PPC32, compiled with g++ 7.3.0 from Tigerbrew.

If it runs for you as well then I guess your problems with Boost is either due to your changes to adapt the libcontext code to the new Boost API (it looks like the argument of the entry function is a struct with two elements rather than an intptr_t now for example, so that would mean two registers have to be set up), or the problem is in some of all the other Boost code that makes up boost::context::fiber (stack allocation or whatnot).

[barracuda156]

@barracuda156 Ok, so i shimmed the fibonacci example to use libcontext, result is here. This runs just fine on Mac OS X 10.5.8 PPC32, compiled with g++ 7.3.0 from Tigerbrew.

If it runs for you as well then I guess your problems with Boost is either due to your changes to adapt the libcontext code to the new Boost API (it looks like the argument of the entry function is a struct with two elements rather than an intptr_t now for example, so that would mean two registers have to be set up), or the problem is in some of all the other Boost code that makes up boost::context::fiber (stack allocation or whatnot).

@zeldin Thank you very much for checking! I will try to fix the thing in Boost.

your problems with Boost is either due to your changes to adapt the libcontext code to the new Boost API

It was broken in Boost to begin with, so no changes can make it worse LOL
Initially I made minimal changes just to make in compile. Turned out, that is not enough.

[zeldin]

It was broken in Boost to begin with, so no changes can make it worse LOL Initially I made minimal changes just to make in compile. Turned out, that is not enough.

Yeah, no that's not going to be enough. The calling convention changed -- in the variant which is in libcontext you send in a pointer to fcontext_t where you want the old context stored when you call jump_fcontext, but in the variant currently in boost instead the context you jump to gets both the old fcontext_t and the generic pointer as a two-element struct instead of just the generic pointer. Meaning that both the argument to the entry function and the return value of jump_fcontext is now a struct (two registers needed). So the code needs to be adapted to pass two registers (R3 and R4) out to the new context instead of just one (R3).

[barracuda156]

It was broken in Boost to begin with, so no changes can make it worse LOL Initially I made minimal changes just to make in compile. Turned out, that is not enough.

Yeah, no that's not going to be enough. The calling convention changed -- in the variant which is in libcontext you send in a pointer to fcontext_t where you want the old context stored when you call jump_fcontext, but in the variant currently in boost instead the context you jump to gets both the old fcontext_t and the generic pointer as a two-element struct instead of just the generic pointer. Meaning that both the argument to the entry function and the return value of jump_fcontext is now a struct (two registers needed). So the code needs to be adapted to pass two registers (R3 and R4) out to the new context instead of just one (R3).

Thank you.
I have opened an issue with upstream by the way, in case you wanna take part: boostorg/context#211