Thanks to help in a previous thread, I now have a working LLVM codegen for the MLton compiler. Currently the stack is managed explicitly on the heap. This way the LLVM codegen re-uses the runtime layout of the other codegens, simplifying the initial porting effort. In the next phase I plan to switch to using LLVM to manage the stack, but there is a sticking point: MLton switches stacks. It does this on calls to C (which use the primordial C stack) and also between application-level threads. ML stacks automatically expand when a limit check triggers garbage collection. I understand that getting this to work will require some non-portable glue on my part. I have a number of ideas on how to get this to work, but also assume that MLton isn't the first project which swaps stacks. What's the established best practice for managing multiple stacks under LLVM?
* Wesley W. Terpstra:> I have a number of ideas on how to get this to work, but also assume > that MLton isn't the first project which swaps stacks. What's the > established best practice for managing multiple stacks under LLVM?I think this isn't really a LLVM question. For most platform ABIs, LLVM code is compatible with stack switching because historically, this was how multi-threading was implemented (and pthreads looks a lot like stack switching, too), and there is quite a bit of software around which does it (the PowerDNS recursor, Lua with the Coco patches and LuaJIT). The Coco patches for Lua have some discussion about portability and implementation choices: <http://luajit.org/coco.html>