Johan Euphrosine

dslx/stdlib: add iterative_div_mod

5

- add `iterative_div_mod` based on https://github.com/google/xls/blob/fa7af6cbda69d02d2d50b28fa5d95f51fe8cdfb1/xls/ir/abstract_evaluator.h#L513-L581 - unify implementation with existing `iterative_div` function

examples: add gcd

2

- stacked on top of #932 - add `gcd_euclidean` - add `gcd_binary` - cross-test both implementation using `quicktest`

GitHub workflows should use more restrictive bazel cache line

1

Currently we use `{{ github.sha1 }}` as the main cache line for storing bazel cache in GitHub actions. This effectively cause a new cache to be created on each commit...

When running `interpreter_main` with `--alsologtostderr` and `--compare=jit` (the default), it seems that it fails to find test function to validate against the JIT: ``` 🍊 interpreter_main --compare=jit --alsologtostderr xls/dslx/stdlib/std.x ......

It seems that `codegen_main` now returns an empty `output_schedule_path` when being called with `--generator=combinational`: ``` $ bazel-bin/xls/dslx/ir_convert/ir_converter_main --top=main xls/examples/crc32.x | bazel-bin/xls/tools/opt_main - | bazel-bin/xls/tools/codegen_main --generator=combinational --delay_model=unit --output_schedule_path=/tmp/schedule.proto - > /dev/null...

can call send/recv from helper fn

1

it seems that `send` and `recv` operation fails when being called from helper `fn`s invoked from a `proc` (even if being passed the appropriate `token` and `chan`): ``` output: chan...

can't use std::upow in parametric expr

1

trying to use `std::upow` in a parametric expr, like in the following example: ``` fn pow_param() -> uN[N] { P as uN[N] } ``` result in the following error: ```...

Currently IR `Bits` class can only convert into (U)Int64: https://github.com/google/xls/blob/main/xls/ir/bits.h#L200-L201 It would be nice to support other common bits size as well: - (u)int32 - (u)int16 - (u)int8

It would be nice if https://github.com/google/xls/blob/main/xls/jit/jit_wrapper_generator.cc generate C++ enums (or constexpr) from DSLX enum definitions. Ex: ``` enum Opcode : u3 { FIRE_THE_MISSILES = 0, BE_TIRED = 1, TAKE_A_NAP =...

dslx should support struct level constant

1

DSLX currently supports top-level, `proc` and `fn` constants, it would be nice to have struct level constant as well to allow users to define bit-width constants related to a type...