Overview
One of the main primitives required when constructing the vm is a generic api for lookups. Take for example the following PIL code, taken from the riscv bitwise operations machine:
https://github.com/powdr-labs/powdr/blob/88858fe6264916b3cd587c4ade13b66dd659cd2f/std/binary.asm#L42
This asserts that for every row, the lhs must be a lookup into the rhs.
As the code above is a submachine, I am assuming that the relation has a relevant selector. Perhaps the latch?
Perhaps the above example can be represented with the above:
std::vector<HandleType> lookup_lhs() override
{
// Show the left hand side of the operation here
std::tuple x = { operation_id_shift, A_byte, B_byte, C_byte }
return {
x,
};
};
std::vector<HandleType> lookup_rhs() override
{
// Right hand side of the operation here
// These columns should all be pre computed tables, hence we will need a way to mark them as such
// So that they can be part of the vm program's preprocessing key?
std::tuple y = { P_operation, P_A, P_B, P_C }
return {
y,
};
};
Overview
One of the main primitives required when constructing the vm is a generic api for lookups. Take for example the following PIL code, taken from the riscv bitwise operations machine:
https://github.com/powdr-labs/powdr/blob/88858fe6264916b3cd587c4ade13b66dd659cd2f/std/binary.asm#L42
This asserts that for every row, the lhs must be a lookup into the rhs.
As the code above is a submachine, I am assuming that the relation has a relevant selector. Perhaps the latch?
Perhaps the above example can be represented with the above: