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
Because I happen to want to run a grpc server written in Common Lisp on GNU/Linux aarch64 (arm64), I'm interested in what it would take to upstream support for this. Most notably, aarch64 is (by default) big endian.
Based on some cursory looking, it looks like only define-fixed-width-encoder needs to be implemented?
For implementing this, would it be acceptable to bring in a whole or parts of a library like swap-bytes? This particular library is available under the MIT license. The strategy could be then to:
Add htonl/htonq equivalents that convert integers to protobuf wire format (little endian)
Wrap fixed with integer accessors (e.g. sb-sys:sap-ref-N) to a call to those equivalents
On little-endian machines the conversion functions would become no-ops, and on big-endian machines it would call the internal swap-bytes implementation.
This library currently does not implement a native byte-swap routine for arm64 and would resort to a portable fallback, but a faster implementation using arm64 intrinsics could be upstreamed.
The text was updated successfully, but these errors were encountered:
Because I happen to want to run a grpc server written in Common Lisp on GNU/Linux aarch64 (arm64), I'm interested in what it would take to upstream support for this. Most notably, aarch64 is (by default) big endian.
Based on some cursory looking, it looks like only
define-fixed-width-encoder
needs to be implemented?For implementing this, would it be acceptable to bring in a whole or parts of a library like swap-bytes? This particular library is available under the MIT license. The strategy could be then to:
htonl
/htonq
equivalents that convert integers to protobuf wire format (little endian)sb-sys:sap-ref-N
) to a call to those equivalentsOn little-endian machines the conversion functions would become no-ops, and on big-endian machines it would call the internal
swap-bytes
implementation.This library currently does not implement a native byte-swap routine for arm64 and would resort to a portable fallback, but a faster implementation using arm64 intrinsics could be upstreamed.
The text was updated successfully, but these errors were encountered: