[Libre-soc-dev] clamping/saturation semantics
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sat Dec 12 19:32:10 GMT 2020
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
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
designing the regfile data routing to deal with max(src, dest) will
need some thought.
More information about the Libre-soc-dev