-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing crc32c for AARCH64 #11
Comments
Hi @ossdev07, I think there are two different points in your message, so I will address them separately. Regarding the title of this ticket: our package doesn't currently support the optional ARMv8 crc32c instructions, mainly because we haven't had a use case that has pushed us to add it. However we'd be more than happy to accept such contribution, and make the package hardware-based implementation more generic rather than Intel-specific. Regarding the selection of the software-based solution, this is mostly historical (you can see some discussion in #5). Changing this interface would be a breaking change (so it would mean an increase on the major version of the library), but I do agree that it would make sense to do it now that the library supports a good fallback software-based implementation. This point is completely separate from that of adding or not ARMv8 hardware-based crc32c support to the package though, so I'd rather we open a new issue to handle it separately. |
A first version of this support has been implemented on the current |
I know that there is a software implementation of this package for non-intel architectures, but that requires an extra environment variable to be declared. ie: "CRC32C_SW_MODE"
But my concern is that, why is it only limited to intel specific instructions set ? What if I want to use this package on ARM machine, and just because the environment variable isn't declared by default it would through me an error "Unsupported platform", even though the platform does support it and has dedicated registers for it.
Or maybe if we can just set the software implementation as the default fallback mechanism, in case we encounter a non-intel arch, we can surely let the user know that we're using software instead of hardware with appropriate logs. There is no point in failing the loading of module, just because its non-intel and the user hasn't declared the environment variable.
Is there any progress done on this front ?? Or maybe you can suggest a workaround ?
The text was updated successfully, but these errors were encountered: