[Libre-soc-dev] SimdSignal update

[lkcl]

On October 29, 2021 3:08:45 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:

>Since all SimdSignals in the ALU's externally-visible API are always
>*exactly* `SimdSignal(XLEN, ...)` and because the shape of the
>underlying
>signals are always completely determined *at construction time*, they
>will
>always be exactly 64-bits (for SimdScope set as expected) because
>that's
>what you get from XLEN with/without width_hint or fixed_width.

yes.  this means two things:

1) interaction between fixed width priority and elwidth priority as both LHS *and* RHS is essential.
2) i forgot the other thing. my short term memory's going to hell.

>Therefore, fixed_width isn't necessary for correctness. A width hint is
>sufficient *and preferred* over fixed_width because element widths
>*must
>always take priority for correctness*.

yes, this is emerging in the wiki page, please read it and help update it to cover all cases.

https://libre-soc.org/3d_gpu/architecture/dynamic_simd/shape/

however i disagree strongly that it should be called a "hint".  this says "if you feel like it it will get completely ignored".

if the arithmetic operators (as part of their internal implementation) *do not set* a fixed width on detecting the conditions when it is problematic to do so, and this is clearly documented behaviour...

see how that works?

the non-use of fixed_width by an internal procedure achieves the expected end-result, just in a different way that happens to also make it explicitly clear to developers that when they set a fixed width thry damn well get a fixed width.

combined with error messages on exit/output to ALU outputs (which will be fixed width), all the bases are covered.


>we can create a warning for code that uses an impossible width_hint,

no, this is again bad practice, especially when developing something complex.

it would be as if a static compiler threw a warning instead of an error.

we will need all the errors that we can get, so as not to miss critical cases during development.

and the same logic holds even when the API's finalised

>*please* don't use the name BOTHDASHNEITHER, it's unreadable. use
>BOTH_OR_NEITHER instead.

i threw in PRIORITY_BOTH as a temporary name.  i used BOTHDASHNEITHER to indicate to you in english words that when both lane_shapes and fixed_width are not None, both take priority thus neither _have_ priority.

l.