Based on top of #7642. And as discussed in #7193, experiments.
This patch contains 2 parts.
---
The important part:
In the runtime, it introduces `VlWide4AB`, which is is intended to be the
representation of 4-state signals with 32-bit A/B words interleaved
(each 2x32-bit word is an `EData[2] array`, as I'm a bit paranoid about
strict aliasing issues, but could be made a struct with care).
`VlWide4AB` contains `.abits()` and `.bbits()` methods, which yields a
proxy class that through implict constructors can be passed directly to
the existing runtime functions that expect a `WDataInP`/`WDataOutP`.
Whether the `WData*` handle is for a `VlWide` (contiguous), or
`VlWide4AB` is encoded in the spare LSB of the pointer held in the
`WData*` handle. Indexing, arithmetic on the handle considers the
stride, so as long as the runtime only accesses wide state through
`WData*` handles, the routines work for both the 2-state and
4-state-interleaved formats (and the same could be done for
4-state-non-interleaved, or other exotic encodings if necessary.
Example to clarify, though I would recommend a `make test-diff` with
this patch:
```c++
// This works just like before
VlWide<10> a2, b2, c2;
VL_MUL_W(10, a2, b2, c2);
// This also works
VlWide4AB<10> a4, b4, c4;
VL_MUL_W(10, a4.abits(), b4.abits(), c4.abits());
// But this would also work no problem - note mixed strides/parts:
VL_MUL_W(10, a2, b4.abits(), c4.bbits());
```
That is, the runtime needs minimal changes. Places where a wide is
accessed without a `WData*` handle or where `WData*::datap()` is called
to get to the raw pointer will need to be fixed. (I will post a separate
patch to add a type-safe template based `scanf` implementation which will
also just work afterwards).
Regarding performance, the encoding is fairly efficient, so impact
should be small, but also most things should be V3Expanded anyway.
If there are performance issues with some, we can always add explicit
variants for those, but I would expect most time to be in the generated
code after V3Expand.
To add runtime functions that take VlWide4AB directly, one would cerate
a `WData4*` handle analogous to `WData`, then can pass the `VlWide4AB`
dierctly without `.abits()`, `.bbits()`. Tracing for example will need
this.
---
The unimportant part:
I hacked up V3Emit and friends to emit `VlWide4AB` for all wide data,
currently always using the `bbits()`, just to test this out. It passes
~94% of the test suite. You can largely ignore this demonstration hack.
---
Continuing the discussion from
https://github.com/verilator/verilator/pull/7193#issuecomment-4444858411
the runtime with the above architecture will work to do 2-state
arithmetic with minimal changes. Verilator internally will do no 4-state
arithmetic after V3Forustate (which needs to run early), which coverts
all 4-state arithmetic into 2-state over abits/bbits like it
currently does.
I came to the conclusion agreeing with Wilson that we will need an
explicit `AstABits`/`AstBBits` LValue type to represent the reference
over aggregate data types (e.g. unpacked arrays of queues of classes
that have associative arrays of 4-state values as members). With the
above runtime, the Emit rule for `AstABits` is simply to print
`.abits()`, and similarly for `AstBBits`, simply print `.bbits()`.
However, we should special case `AstNodeVarRef`, to contain an enum
value, to represent the reference directly when dealing with simple
variable references. (These are the ones that we can optimize
aggressively throughout the compiler). That is, add this to
`AstNodeVarRef`:
```c++
enum class VarPart : uint8_t {
WHOLE, // References whole variable, e.g. for `x = y`
ABITS, // References A bits, e.g `x = p.abits() | q.bbits()`
BBITS, // References B bits
};
class AstNodeVarRef {
...
VarPart m_part
...
VarPart part() const { return m_part; }
// Encoded reference if needed for map keys - can be other than
// uintptr_t, but we have a few spare bottom bits in the ptr.
uintptr_t varpart() const {
return reinterpret_cast<uintptr_t>(m_varp) | m_part;
}
};
```
`AstVarRef(AstVar, VarPart::ABITS)` is then semantically equivalent to
`AstABits(AstVarRef(AstVar, VarPart::WHOLE))`.
(We could special case other LValue nodes if it helps with the
internals, and we will probably want to do e.g. `AstWordSel`, but on the
first try it's probably enoughto have the generic `Ast{A,B}Bits` +
VarRef special.)
Rules to encode in V3Broken:
- After V3FourState, only LValue expressions can have a 4-state type
- `AstABits`/`AstBBits` (and `AstNodeVarRef` with non WHOLE flag) can only
be applied to a 4-state packed type.
- `AstABits`/`AstBBits (and `AstNodeVarRef` with non WHOLE flag) has a
2-state type matching it's operand (same width)
Change WDataInP/WDataOutP to be opaque handles types instead of aliases
to raw pointers. This subsequently eliminates needing an implicit cast
operator in VlWide, which is replaced with implicit constructors of
WDataInP/WDataOutP that can create a handle from a VlWide. This
eliminates some unsafe conversions that the previous implicit cast
operator unintentionally enabled (e.g. #7618). It also eliminates
having to insert ".data()" in various places int he generated code, which
simplifies internals (the only place ".data()" should be needed is in
calls to variadic functions where the expected type of the argument is
not WDataInP/WDataOutP).
The handles otherwise behave like pointers, implementing the minimal
amount of operators required to code the runtime. The handle is still
only a single pointer, and will be passed in registers as before, so
this patch should be performance neutral.
As part of this removed WData, which used to be an alias for EData.
All uses are now either EData*, WDataInP, WDataOutP, or VlWide directly.
When lowering dynamic event controls, destructive pre-clear updates were inserted with addHereThisAsNext() on the original node and then that node was replaced. This could leave leaked/orphaned nodes under leak-checking runs.
Build an explicit replacement stmt chain instead:
[pre-clear stmts] -> trigger loop -> awaitResumption,
and replace the original control with the chain head. Keep the loop-only path unchanged when no destructive pre-clear is needed.