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.

Sign up for GitHub

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

Jump to bottom

Support for large unsigned integer constants up to 256 bits #35

Merged
merged 1 commit into from
Dec 20, 2023
Merged

Support for large unsigned integer constants up to 256 bits #35

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 22 additions & 1 deletion bberg/src/relation_builder.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ use ast::analyzed::{
};
use ast::parsed::SelectedExpressions;
use itertools::Itertools;
use num_bigint::BigUint;
use std::collections::HashMap;
use std::collections::HashSet;

Expand Down Expand Up @@ -328,7 +329,27 @@ fn craft_expression<T: FieldElement>(
collected_public_identities: &mut HashSet<String>,
) -> BBIdentity {
match expr {
Expression::Number(n) => (1, format!("FF({})", n.to_arbitrary_integer())),
Expression::Number(n) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could all of these be covered by the FF("hex string") constructor ?

Copy link
Collaborator Author

@jeanmon jeanmon Dec 20, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. According to the current cpp source code, this constructor takes only zero-padded/fixed size hex representation. This means that the cpp generated code would have very long string even for small constants which is not so nice I would say.

See relevant cpp source code:
https://github.com/AztecProtocol/aztec-packages/blob/f1eb6d5b6e3221e5a5b8f55632dba066d4cfbc24/barretenberg/cpp/src/barretenberg/numeric/uint256/uint256.hpp#L61

let number: BigUint = n.to_arbitrary_integer();
if number.bits() < 32 {
return (1, format!("FF({})", number));
}
if number.bits() < 64 {
return (1, format!("FF({}UL)", number));
}
if number.bits() < 256 {
let mut chunks: Vec<u64> = number.iter_u64_digits().collect::<Vec<u64>>();
chunks.resize(4, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the endianness of this concrete ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You meant "correct"? Yes I checked this.

return (
1,
format!(
"FF(uint256_t{{{}, {}, {}, {}}})",
chunks[0], chunks[1], chunks[2], chunks[3],
),
);
}
unimplemented!("{:?}", expr);
}
Expression::Reference(polyref) => {
let mut poly_name = polyref.name.replace('.', "_").to_string();
if polyref.next {
Expand Down
Loading