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

Optimise bounds encoding #45

Open
rmn30 opened this issue Mar 5, 2024 · 1 comment
Open

Optimise bounds encoding #45

rmn30 opened this issue Mar 5, 2024 · 1 comment

Comments

@rmn30
Copy link
Collaborator

rmn30 commented Mar 5, 2024

There is an opportunity to adopt a trick from CHERI Concentrate to slightly optimise the capability bounds encoding. In CHERI Concentrate the top bit of the length is implied from the exponent in a similar way to the IEEE floating point mantissa. We could adopt the same technique by reducing the T field by one bit to 8-bits and using this freed bit to create a full 5-bit exponent. This would result in some spare exponent values, one of which could be used to encode the denormal case. The resulting encoding would have the same precision and representable bounds as the existing one, but would also support exponents greater than 14, giving better precision for very large allocations.

@jonwoodruff
Copy link

I agree!
To fill out the design space with relation to CHERI Concentrate:

+1 bit for an "Internal Exponent" bit would allow reusing exponent bits to have 2 more bits of precision for one of the exponent sizes. (This could be used, for example, to make the 2-cap-aligned case have 4x capacity to allow larger stacks.) This is not a clear improvement, as you would probably want to gain bit rather than lose one, so you would have one bit less precision in the worst case and one bit more precision in your favourite case.

+1 bit for 2x representable space. This bit is appended to the MSB of the B field, allowing the base to be placed in a 2x space.

If both of these features were pulled in, you would have the same number of bits, one less bit of precision in the worst case, one more bit of precision in a select case, and an out-of-bounds representable space at least as big as the object itself.


The above suggestion from @rmn20 gives a strict improvement and ought to be pulled in when possible.

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

2 participants