You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?)
The text was updated successfully, but these errors were encountered:
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.
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?)
The text was updated successfully, but these errors were encountered: