diff --git a/benchmarks/README.md b/benchmarks/README.md index 4b6a8a5d89..d3bd2ba55a 100644 --- a/benchmarks/README.md +++ b/benchmarks/README.md @@ -29,7 +29,7 @@ lint or use rust-analyzer on the crate while in the workspace, so the recommende ### Adding the Benchmark -Our proving benchmarks are written as standalone rust binaries. Add one by making a new file in [bin](./src/bin) by following the [fibonacci example](./bin/fibonacci.rs). We currently only run aggregation proofs when feature "aggregation" is on (off by default). Any general benchmarking utility functions can be added to the library in [`src`](./src). There are utility functions `build_bench_program` which compiles the guest program crate with target set to `openvm` and reads the output RISC-V ELF file. +Our proving benchmarks are written as standalone rust binaries. Add one by making a new file in [bin](./src/bin) by following the [fibonacci example](./src/bin/fibonacci.rs). We currently only run aggregation proofs when feature "aggregation" is on (off by default). Any general benchmarking utility functions can be added to the library in [`src`](./src). There are utility functions `build_bench_program` which compiles the guest program crate with target set to `openvm` and reads the output RISC-V ELF file. This can then be fed into `bench_from_exe` which will generate a proof of the execution of the ELF (any other `VmExe`) from a given `VmConfig`. #### Providing Inputs diff --git a/book/src/advanced-usage/sdk.md b/book/src/advanced-usage/sdk.md index da21629b2c..50baf12a86 100644 --- a/book/src/advanced-usage/sdk.md +++ b/book/src/advanced-usage/sdk.md @@ -2,7 +2,7 @@ While the CLI provides a convenient way to build, prove, and verify programs, you may want more fine-grained control over the process. The OpenVM Rust SDK allows you to customize various aspects of the workflow programmatically. -For more information on the basic CLI flow, see [Overview of Basic Usage](./overview.md). Writing a guest program is the same as in the CLI. +For more information on the basic CLI flow, see [Overview of Basic Usage](../writing-apps/overview.md). Writing a guest program is the same as in the CLI. ## Imports and Setup diff --git a/crates/toolchain/tests/README.md b/crates/toolchain/tests/README.md index dff2f7afdd..89372257b2 100644 --- a/crates/toolchain/tests/README.md +++ b/crates/toolchain/tests/README.md @@ -6,7 +6,7 @@ This crate includes tests for OpenVM toolchain that involve starting from a Rust 1. Add a new guest program file to [programs/examples](./programs/examples). -See [Writing the Guest Program](../../benchmarks/README.md#writing-the-guest-program) for more detailed instructions. +See [Writing the Guest Program](../../../benchmarks/README.md#writing-the-guest-program) for more detailed instructions. The `programs` directory is a single crate to make it easier to add small test programs. The crate is **not** part of the main workspace. Your IDE will likely not lint or use rust-analyzer on the crate while in the workspace, so you should open a separate IDE workspace from `programs` while writing your guest program. diff --git a/docs/crates/benchmarks.md b/docs/crates/benchmarks.md index bc9d811242..20fdf62433 100644 --- a/docs/crates/benchmarks.md +++ b/docs/crates/benchmarks.md @@ -3,7 +3,7 @@ ### Latest Benchmark Results Latest benchmark results can be found [here](https://github.com/openvm-org/openvm/blob/benchmark-results/index.md). -These are run via [github workflows](./.github/workflows/benchmark-call.yml) and should always be up to date with the latest `main` branch. +These are run via [github workflows](../../.github/workflows/benchmark-call.yml) and should always be up to date with the latest `main` branch. ### Adding a Benchmark diff --git a/docs/specs/ISA.md b/docs/specs/ISA.md index ad8337ed1f..87d17418f3 100644 --- a/docs/specs/ISA.md +++ b/docs/specs/ISA.md @@ -21,7 +21,7 @@ The program code is committed as a cached trace. The validity of the program cod Memory is comprised of addressable cells, each cell containing a single field element. Instructions of the VM may access (read or write) memory as single cells or as a contiguous list of cells. Such a contiguous list is called a _block_, and -an memory access (read/write) to a block is a _block access_. +a memory access (read/write) to a block is a _block access_. The architecture distinguishes between block accesses of different sizes as this has significant performance implications. The number of cells in a block access is restricted to powers of two, of which the following are supported: 1, 2, 4, 8, 16, 32, 64. Block accesses must be aligned, meaning that in a block access of size $N$, the starting pointer must be divisible by $N$ (as an integer). diff --git a/extensions/keccak256/circuit/README.md b/extensions/keccak256/circuit/README.md index 5085c961cc..afd6881f65 100644 --- a/extensions/keccak256/circuit/README.md +++ b/extensions/keccak256/circuit/README.md @@ -25,7 +25,7 @@ It seems to handle padding in a single AIR row there is no alternate to having ` The absorb step must correctly constrain that the input bytes are XORed with the end-state in the last round and equals the next permutation's `preimage`. The end-state is accessed via `a_prime_prime_prime()`. Note that both `preimage` and `a_prime_prime_prime()` are represented as `u16`s. However we can only XOR at most 8-bit limbs. Without changing the `keccak-f` AIR itself, we can use a trick: if we already have a 16-bit limb `x` and we also provide a 8-bit limb `hi = x >> 8`, assuming `x` and `hi` have been range checked, we can use the expression `lo = x - hi * 256` for the low byte. If `lo` is range checked to `8`-bits, this constrains a valid byte decomposition of `x` into `hi, lo`. This means in terms of trace cells, it is equivalent to provide `x, hi` versus `hi, lo`. -The constraints are in [air.rs](./air.rs). Notably we use an XOR lookup table for byte XORs in the absorb step. +The constraints are in [air.rs](./src/air.rs). Notably we use an XOR lookup table for byte XORs in the absorb step. ## Future Improvement