18 Commits

Author SHA1 Message Date
Linda Guiga
666a155d4a
Remove new_stack_top_channel from StackBehavior (#1296) 2023-10-26 17:52:54 -04:00
Hamy Ratoanina
8beba56903
Constrain next row's stack length 2023-08-28 16:32:04 -04:00
Hamy Ratoanina
815a02ab75
Remove is_cpu_cycle 2023-08-15 15:22:41 -04:00
Robin Salen
7829dccf83
Combine EQ and ISZERO flags 2023-08-12 11:08:01 -04:00
Jacqueline Nabaglo
87a9c002c9 Compiler errors + refactor 2022-11-28 13:19:40 -08:00
Jacqueline Nabaglo
205bd58f98 Witness generation work 2022-11-15 09:26:54 -08:00
Jacqueline Nabaglo
e978425b26
Connect stack to memory (#735)
* Connect stack to memory

* Daniel PR comment
2022-09-28 15:18:56 -07:00
Jacqueline Nabaglo
013bf6471d
Transpose memory columns (make it an array of channel structs) (#700) 2022-08-26 22:05:16 -07:00
Jacqueline Nabaglo
f48de368a9
Make jumps, logic, and syscalls read from/write to memory columns (#699)
* Make jumps, logic, and syscalls read from/write to memory columns

* Change CTL convention (outputs precede inputs)

* Change convention so outputs follow inputs in memory channel order
2022-08-26 14:39:39 -07:00
Jacqueline Nabaglo
5922c58730
Change logic limb size to 32 bits (#674)
* Change logic limb size to 32 bits

* Remove unnecessary columns (thx Daniel!)
2022-08-17 21:19:27 -07:00
Daniel Lubarov
3d83d63f0b Shared CPU columns
I was thinking we could have two sets of shared columns:
- First, a set of "core" columns which would contain instruction decoding registers during an execution cycle, or some counter data during a kernel bootloading cycle.
- Second, a set of "general" columns which would be more general-purpose. For now it could contain "looking" columns for most CTLs (Keccak, arithmetic and logic; NOT memory since memory can be used simultaneously with the others). It could potentially be reused for other things too, such as the registers used for `EQ` and `IS_ZERO` (but I know it's nontrivial to share those since we would need to use lower-degree constraints, so I wouldn't bother for now).

This PR implements just the latter. If it looks good I'll proceed with the former afterward.
2022-07-18 12:15:41 -07:00
Jacqueline Nabaglo
bc9e618967
Structured wrapper over CPU table row (#589)
* Structured wrapper over CPU table row

* Lints

* minor style

* Minor cleanup
2022-06-29 16:23:44 -07:00
Daniel Lubarov
e73d01a037
packed_field -> packed (#584)
* `packed_field` -> `packed`

For cleaner imports; "field" is usually clear from context

* fix
2022-06-27 15:07:52 -07:00
Daniel Lubarov
3346d3f902
field_types -> types (#583)
* `field_types` -> `types`

Here too, I think "field" is usually clear from context, e.g. in `use plonky2::field::types::Field;`.

* fixes

* fmt
2022-06-27 12:24:09 -07:00
Daniel Lubarov
410e03349c
extension_field -> extension (#581)
It seems redundant in most contexts, e.g. `use plonky2::field::extension_field::Extendable;`. One could import `extension_field`, but it's not that common in Rust, and `field::extension` is now about as short.
2022-06-27 07:18:21 -07:00
Jacqueline Nabaglo
1cc000d3e1
Connect logic stark to CPU (#569)
* WIP: connect logic stark to CPU

* Tests passing
2022-06-17 11:57:14 -07:00
Jacqueline Nabaglo
1e44ee3681
EQ and ISZERO (#566) 2022-06-14 17:38:42 -07:00
Jacqueline Nabaglo
49219a2b11
NOT stark (#565)
* NOT operation stark

* Daniel PR comment
2022-06-14 16:55:08 -07:00