[Cider2] Remove Cider 1 (#2193)

Remove Cider 1

.github/workflows/rust.yml

@@ -27,7 +27,7 @@ jobs:
       - name: Check calyx build
         run: ./target/debug/calyx --version
       - name: validate playground config
-        run: node web/validate-data.js 
+        run: node web/validate-data.js
 
   # Get the hash of the Dockerfile
   hash:
@@ -120,10 +120,10 @@ jobs:
         fud c stages.interpreter.exec /home/calyx/target/debug/cider
 
     - name: Runt tests
-      working-directory: /home/calyx
+      working-directory: /home/calyx/interp/tests
       run: |
         # Run the remaining tests
-        runt interp -x 'relay' -d -o fail
+        runt -x '(numeric types correctness and parsing)|(tcam testing)|(../../tests/correctness/pipelined-mac.futil)|(../../tests/correctness/std-bit-slice.futil)|(polybench)' -d -o fail
 
     - name: Source code tests
       uses: actions-rs/cargo@v1
@@ -187,7 +187,7 @@ jobs:
       working-directory: /home/calyx
       run: |
         runt -i 'cocotb' -d -o fail -j 1 --max-futures 1
-    
+
     - name: Runt tests
       working-directory: /home/calyx
       run: |

cider-dap/src/adapter.rs

@@ -1,12 +1,12 @@
 use crate::error::AdapterResult;
 use dap::types::{Breakpoint, Source, SourceBreakpoint, StackFrame, Thread};
 use interp::debugger::source::structures::NewSourceMap;
-use interp::debugger::Debugger;
+use interp::debugger::OwnedDebugger;
 use std::path::PathBuf;
 
 pub struct MyAdapter {
     #[allow(dead_code)]
-    debugger: Debugger,
+    debugger: OwnedDebugger,
     break_count: Counter,
     thread_count: Counter,
     stack_count: Counter,
@@ -20,7 +20,7 @@ pub struct MyAdapter {
 impl MyAdapter {
     pub fn new(path: &str, std_path: PathBuf) -> AdapterResult<Self> {
         let (debugger, metadata) =
-            Debugger::from_file(&PathBuf::from(path), &std_path).unwrap();
+            OwnedDebugger::from_file(&PathBuf::from(path), &std_path).unwrap();
         Ok(MyAdapter {
             debugger,
             break_count: Counter::new(),

docs/running-calyx/interpreter.md

@@ -1,53 +1,94 @@
-# The Calyx Interpreter
+# Cider: The Calyx Interpreter & Debugger
 
-The experimental Calyx interpreter resides in the `interp/` directory of the
+Cider resides in the `interp/` directory of the
 repository.
-The interpreter supports all Calyx programs—from high-level programs that
+Cider supports all Calyx programs—from high-level programs that
 make heavy use of control operators, to fully lowered Calyx programs.
 (RTL simulation, in contrast, only supports execution of fully lowered programs.)
 
-There are two ways to use the interpreter: you can directly invoke it, or you can use [fud][].
+There are two ways to use the interpreter: you can directly invoke it, or you
+can use [fud2][]. The latter is generally recommended.
 
 ## Basic Use
 
 To run an example program, try:
 
     cd interp && cargo run tests/control/if.futil
 
+You should see something like:
+
+    Z{"top_level":"main","memories":[{"name":"mem","width":32,"size":1,"dimensions":{"D1":1}}]}%
+
+
+This output contains some header information and the raw binary data of the
+memories in the program and as such is not human readable. A separate tool,
+`cider-data-converter` is used to parse this dump into a human readable json and
+vice versa. Once you've compiled it, either by running `cargo build` in
+`tools/cider-data-converter` or by running `cargo build --all`, you can run:
+
+    cargo run tests/control/if.futil | ../target/debug/cider-data-converter --to json
+
+which should produce
+```json
+{
+  "mem": [
+    4
+  ]
+}
+```
+
+
+
 You can see the available command-line options by typing `cargo run -- --help`.
 
 ## Interpreting via fud
 
-The interpreter is available as a stage in [fud][], which lets you provide standard JSON data files as input and easily execute passes on the input Calyx program before interpretation.
-
-You'll want to build the interpreter first:
+The interpreter is available as a stage in [fud2][], which lets you provide
+standard JSON data files as input and easily execute passes on the input Calyx
+program before interpretation.
 
-    cd interp && cargo build && cd ..
+You'll want to build the interpreter and compiler first:
 
-Now register the interpreter as a fud stage:
+    cargo build && \
+    cd interp && cargo build && \
+    cd ../tools/cider-data-converter && cargo build && cd ../../
 
-    fud config stages.interpreter.exec <full path to Calyx repository>/target/debug/cider
+or just run
 
-Here's how to run a Calyx program:
+    cargo build --all
 
-    fud e --to interpreter-out interp/tests/control/if.futil
+Once you've installed and [configured](./fud2/index.md#configuration) `fud2` you
+can run the same program by invoking
 
-To provide input data, set the `verilog.data` variable, like so:
+    fud2 tests/control/if.futil --to dat --through cider -s sim.data=tests/control/if.futil.data
 
-    fud e --to interpreter-out \
-        -s verilog.data tests/correctness/while.futil.data \
-        tests/correctness/while.futil
+Data is provided in the standard Calyx json and `fud2` will automatically handle
+marshalling it to and from Cider's binary format, outputting the expected
+result. Note that `fud2` _requires_ a provided data file, so in cases where you
+do not initialize memory you will still need to provide the initial state of the
+memories. Such files can be generated via the
+[data gen tool](../tools/data-gen.md) or you can invoke Cider directly to bypass
+this constraint.
 
 By default, fud will not transform the Calyx code before feeding it to the interpreter.
 To run passes before the interpreter, use the `calyx.flags` variable in conjunction with the `-p` flag.
 For example, to fully lower the Calyx program before interpreting it:
 
-    fud e --to interpreter-out \
-        -s calyx.flags '-p all' \
-        interp/tests/control/if.futil
+    fud2 --to dat --through cider \
+        -s calyx.flags='-p all' \
+        -s sim.data=tests/control/if.futil.data \
+        tests/control/if.futil
+
+## Cider outputs
+By default, Cider's output memory dump will only contain the `@external`
+memories on the entrypoint component. If you want to see other memories in the
+main component, the flag `--all-memories` will force Cider to serialize all
+memories. For prototyping, it can occasionally be useful to serialize registers
+as well, this can be done by passing the flag `--dump-registers` which will
+cause Cider to serialize all registers in the main component as single entry
+memories.
+
 
-In particular, the interpreter does not currently support [`ref` cells][ref-cells].
-To run the interpreter on a program that uses these, you must first compile them away by running the `compile-invoke` pass.
 
-[fud]: fud/index.md
+[fud2]: ./fud2/index.md
 [ref-cells]: ../lang/memories-by-reference.md#the-easy-way-ref-cells

fud/fud/main.py

@@ -11,7 +11,6 @@
 from .stages import (
     dahlia,
     futil,
-    interpreter,
     relay,
     systolic,
     vcdump,
@@ -101,13 +100,6 @@ def register_stages(registry):
             "Generate the XML metadata for Xilinx",
         )
     )
-    registry.register(
-        futil.CalyxStage(
-            "interpreter",
-            "-p none",
-            "Compile Calyx for interpretation with CIDR",
-        )
-    )
     registry.register(
         futil.CalyxStage(
             "resources",
@@ -150,11 +142,6 @@ def register_stages(registry):
     registry.register(xilinx.XilinxStage())
     registry.register(xilinx.HwExecutionStage())
 
-    # Interpreter
-    registry.register(interpreter.InterpreterStage("", "", "Run the interpreter"))
-    registry.register(interpreter.InterpreterStage.debugger("", "", "Run the debugger"))
-    registry.register(interpreter.InterpreterStage.data_converter())
-
 
 def register_external_stages(cfg, registry):
     """
@@ -166,7 +153,7 @@ def register_external_stages(cfg, registry):
     """
 
     # No externals to load.
-    if not ["externals"] in cfg:
+    if ["externals"] not in cfg:
         return
 
     for ext, location in cfg[["externals"]].items():