I'm trying to update an old AI research project from my college days that was fun...it actually self-coded new heuristics dynamically, so the Lisp would write and add in new Lisp to itself! It was playing Othello, but it was fun as the glue was AppleScript and the user interface was all done up in HyperCard. While I know HyperCard is not on macOS, I'm sure there must be a good Common Lisp replacement out there!

Thanks, I have never heard of that program! The application area is pretty focused on trying to treat PTSD and doctors that work in trauma centers. The pupil diameter is a great stress measurement for seeing how they progress in training/therapy when presented with either a VR training environment or, what I think is a great angle I had only to start exploring with the SMI glasses, stress in real-world scenarios where the doctor can see a real world patient and the other doctors in the ER.

Oh good thought! Let me take a look into clang as, yes, this is user space only and really has nothing to do with the kernel.

Yes, that is the dilemma...either maintaining something for setjmp/longjmp or maintaining assembly code long-term. Neither of which are great options, I admit. I've got the assembly lying around, but I figure even if it needs maintenance going with setjmp/longjmp stands a better chance of maintaining any new vector registers or such in future iterations of Apple Silicon! I miss having a path forward for porting the older cooperative MP code into macOS, but that's been the case ever since Rhapsody, really.

Just as a followup...setjmp/longjmp do not appear to be following the clang libc project. Inside of the jmp_buf, after storing x27 it deviates from the clang libc and immediately stores x10 and x11, and the rest of the information is zeroes after that. So it seems there is a custom Apple implementation of setjmp/longjmp (perhaps inside of libsystem_platform.dylib?) that deviates and is using some kind of different buffers.. Bummer as it would kinda been nice to find a solution that isn't trying to maintain low level assembly that will be more difficult to maintain across architecture revisions. Still, I'll spend more time digging (maybe those x10 and x11 are buffer addresses?) and see if there's a little bit of magic to be had with a setjmp/longjmp approach :) It's an oddball case, but I'm sure implementing coroutines are still fairly common as we need to slice and dice the main thread up for GUI operations and libraries such as Qt that are not fully pre-emptive safe.

Well, it's working! Thanks for the starting off points. I'll not give the full details as it's not a recommended solution from Apple, but for those on the same path the breadcrumbs will lead to libplatform and getting some understanding of thread specific data storage. But it all works now, coroutines with setjmp/longjmp in user space! Sadly the open source project for this specific library is now defunct so nowhere to upstream the new code, but it's nifty that it will now work for macOS running on PowerPC, i386, x64 and Apple Silicon. I believe it's time for a disco party.