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

chore: Move some sdk::core types to their own crate, sdk-core-types #1693

Closed
wants to merge 12 commits into from

Conversation

codeblooded1729
Copy link
Contributor

Main benefit is that circuits and runner no longer have sdk as dependency.

@codeblooded1729 codeblooded1729 changed the title chore: Move some sdk::core types to its own crate chore: Move some sdk::core types to their own crate, sdk-core-types May 10, 2024
edition = "2021"
keywords = ["sdk", "types"]
license = "Apache-2.0"
name = "sdk-core-types"
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
name = "sdk-core-types"
name = "core"

I'd argue you could even just name this core. ecall IDs and poseidon2 constants aren't really types, and they aren't really constrained to SDK usage only.

Copy link
Contributor

Choose a reason for hiding this comment

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

core sounds like functionality. These are not such elements if I understand correctly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right. Creating a separate crate for extracting out constants doesn't seem like the best thing to do.

@@ -2,45 +2,16 @@
use core::arch::asm;

#[cfg(target_os = "mozakvm")]
Copy link
Contributor

@spiral-ladder spiral-ladder May 13, 2024

Choose a reason for hiding this comment

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

One of the benefits of moving the consts and the log fn out of this file is that we can now put this cfg file-wide at the top of the file:

#![cfg(target_os = "mozakvm")]

And remove all the per fn/import configuration.


#[must_use]
pub fn log<'a>(raw_id: u32) -> &'a str {
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO, please either:

  1. provide a doc comment on what this is meant to log,
  2. or just put this fn within ecall(), since that's the only place this is used. Then there would be no ambiguity in what this fn is meant to log.

Comment on lines +3 to +4
use mozak_runner::reg_abi::REG_A1;
use sdk_core_types::constants::poseidon2::DIGEST_BYTES;
Copy link
Contributor

Choose a reason for hiding this comment

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

Doesn't this look weird?

@@ -523,7 +523,7 @@ pub fn create_poseidon2_test(
op: Op::ADD,
args: Args {
rd: REG_A0,
imm: ecall::POSEIDON2,
imm: ecall_id::POSEIDON2,
Copy link
Contributor

Choose a reason for hiding this comment

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

We moved from ecall_id -> ecall -> ecall_id again

plonky2 = { workspace = true, default-features = false }
proptest = { version = "1.4", optional = true }
sdk-core-types = { path = "../sdk-core-types" }
Copy link
Contributor

Choose a reason for hiding this comment

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

why not just types?

@@ -0,0 +1,4 @@
#![cfg_attr(target_os = "mozakvm", no_std)]

pub mod constants;
Copy link
Contributor

Choose a reason for hiding this comment

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

pub mod poseidon2hash maybe.

@codeblooded1729
Copy link
Contributor Author

The goal of this PR was to break the dependency of circuits and runner over sdk, so that we can add these as dependencies for sdk itself. Turned out there isn't much to gain from this PR other than migrating constants to a separate crate. I came up with hopefully better solution, by introducing a variant of sdk which has the abovementioned dependencies. Closing this in favor of that PR #1701

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

Successfully merging this pull request may close these issues.

3 participants