Enhancement: opt-in to C-based (instead of asm) implementation
pnkfelix opened this issue · 3 comments
I want to prototype a variant of the crate that totally avoids inline asm and uses ("portable"?) C instead.
I ended up posting this crate without that in place because I wasn't sure the best architecture to use for that C dependency. (E.g. should it be a separate crate? Or can I make it a separate file that is conditionally-compiled?)
Note that the current implementation leverages generic code by generating distinct asm blocks for each concrete callback F.
It wouldn't be reasonable to do that via C code. But we don't have to; we can make the generic C version take the closure environment and the closure code pointer as explicit arguments, and then do the call itself. Its hypothetically a performance hit to do that, but my gut tells me that its not a noticeable performance hit: either you have LTO turned on, in which case I hope you'd see enough inlining to boil away the indirection, or you have LTO turned off, in which case you won't see any cross-language inlining anyway and I doubt you'd care about an indirect vs direct call.
This seems like a reasonable thing to do. To me it would make sense to fall back to C for unrecognized architectures, or to allow forcing the C version with a feature flag. That would be a nice safety net in case we discover an obscure bug with either the C version or the asm version.