Skip to content
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

Abstraction over [Limb] #756

Open
tarcieri opened this issue Jan 30, 2025 · 0 comments
Open

Abstraction over [Limb] #756

tarcieri opened this issue Jan 30, 2025 · 0 comments

Comments

@tarcieri
Copy link
Member

tarcieri commented Jan 30, 2025

BoxedUint contains large amount of code copy-pasted from Uint, some of which has been rewritten to perform in-place operations to reduce heap allocations.

Before Rust 1.83 it just wasn't possible to share code between Uint and BoxedUint because Uint has been carefully written to maximally support const fn which precludes &mut [Limb], whereas with BoxedUint we always want to prefer in-place operations to reduce allocations and these require &mut [Limb]. The only way to "abstract" between the two was to use macros, which wasn't great.

As of Rust 1.83 we can now have &mut in const fn which makes it possible to share a common implementation.

One option might be to define a type like this:

pub struct LimbSlice([Limb]);

(it doesn't necessarily need to be pub but might potentially be useful as part of the public API)

Then various operations can be implemented on &mut self references to this type. However, we'd have to be careful that such functions are inlined to eliminate bounds checks on the size of the slice in the case of Uint where it's known statically.

Another option is simply to define the implementation in terms of free functions that operate on &mut [Limb] which is what we have now in a few places where macro-based abstractions were used previously. However, there are various algorithms that would benefit being implemented in terms of an abstraction between Uint/BoxedUint, and in such cases it might be nice to have a real type for that rather than having to import a bunch of free functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant