For consistency.
Also trying a new thing: only rebuilding objects that use the pybind11 library. The idea is these are the only objects that include the Python/pybind headers and thus the only ones that depend on the Python ABI in any capacity, so other objects can be reused across wheel builds. This has the potential to cut down build times.
- Rewrite all Python features to use the pybind11 library instead of boost::python.
Unlike boost::python, pybind11 is a header-only library that is just included by Pyosys code, saving a lot of compile time on wheels.
- Factor out as much "translation" code from the generator into proper C++ files
- Fix running the embedded interpreter not supporting "from pyosys import libyosys as ys" like wheels
- Move Python-related elements to `pyosys` directory at the root of the repo
- Slight shift in bridging semantics:
- Containers are declared as "opaque types" and are passed by reference to Python - many methods have been implemented to make them feel right at home without the overhead/ambiguity of copying to Python and then copying back after mutation
- Monitor/Pass use "trampoline" pattern to support virual methods overridable in Python: virtual methods no longer require `py_` prefix
- Create really short test set for pyosys that just exercises basic functionality
This fixes some edge cases the previous version didn't handle properly
by simplifying the logic of determining directly driven wires and
representatives to use as buffer inputs.
This hasn't been an issue when using -l to redirect or when stdout is
line buffered, explaining how we didn't notice this earlier, but for
`yosys ... > log` that extra flush is required to ensure all messages
preceding the fatal error are flushed.
This is a complete rewrite of the RTLIL-kernel-side bufnorm code. This
is done to support inout ports and undirected connections as well as to
allow removal of cells while in bufnorm mode.
This doesn't yet update the (experimental) `bufnorm` pass, so to
manually test the new kernel functionality, it is important to only use
`bufnorm -update` and `bufnorm -reset` which rely entirely on the kernel
functionality. Other modes of the `bufnorm` pass may still fail in the
presence of inout ports or undirected connections.
Now that we only call `bitvectorize()` in non-const methods, we can move the casting-away-const to only happen
in `bitvectorize()`, which is deprecated so only some plugins (maybe) are using it.
This means `const` `Const` methods don't change the underlying data, which means
they'll be safe to use from multiple threads if/when we want to do that.
