[Libre-soc-dev] clamping/saturation semantics

[Luke Kenneth Casson Leighton]

On 12/12/20, Lauri Kasanen <cand at gmx.com> wrote:

>
> Added, and with Hendrik's point I used a div for the narrowing wrong
> example.

star.

in my initial thoughts 18 months ago people were advising
(particularly for FP) that ops should be done at the larger width,
followed eventually by narrowing (where dstwid < srcwid)

this because you introduce rounding errors otherwise.

i really wanted to save resources and have the width be at the narrow
end, and require macro-op fusion or follow-up mvs to expand/contract.

i'm seeing now particularly in light of sat/clamp that yes the
max(srcwid, dstwid) is needed, and that this can even apply to FP.

even FP could be saturated to max range rather than +/-INF.

btw the storing of results when narrowing is done is hairy as hell :)

remember that the 64 bit SIMD backend ALUs have a byte-level mask of
which bytes of the reg in the regfile they are allowed to write to.

when predication occurs the predicate bit interacts with
(enables/disables) these byte-level write lines.

a narrowed operation would *also* mask out some of those bits.

however it's not that strsightforward: data that was sourced from 64
bit that is going into 32 bit dest, the SV-loop reg# increments *twice
as much* for the src as it does for the dest.

i think this was one of the reasons why i came up with the rules for
SV elwidths.

designing the regfile data routing to deal with max(src, dest) will
need some thought.

l.