freenode/#sbcl - IRC Chatlog
Search
17:00:46
dougk_
hi, yes i've been using ppc64be gnu/linux. One of the more important issues to sort out is that user code is not allowed to affect r13. I think I had some workaround in place which grabs r13 and stashes it somewhere, then restores it when calling C. That doesn't work for signal handlers. The proper solution is to rearrange ppc64-lispregs to avoid r13.
17:24:04
stylewarning
karlosz: yes, a little homebrew JIT compiler for a quantum programming language
17:38:01
pkhuong
stylewarning: i wouldn't use vops for that. i'd generate CL calls to intrinsics, or stick to a fixed calling convention and assemble directly
17:39:18
pkhuong
the latter gives you more control (e.g., you want to use mask registers), and makes it easier to swap in llvm or specialised low level passes
17:39:55
xristos
i did the direct assembling (following pkhuong's blog post) with my own JIT compiler
17:50:30
karlosz
stylewarning: you can define a fixed set of intrinsics with vops like pkhuong suggested. you can have arguments to the intrinsics that conditionally control how code is generated if you need more control over the assembly generated
17:50:52
karlosz
but the VOP templates should be enough - you can always conditionalize huge chunks of code based on some info argument
21:42:25
dougk_
i just took a look at my ppc64 work after rebasing to current head, it gets as far as FLOAT-COLD-INIT-OR-REINIT and then dies. That seems possibly like some negative progress, but definitely feasible for someone to pick up.