[Libre-soc-isa] [Bug 1184] Proposal for fixing XLEN: XLEN always is type-len, add FTYPE and FSTYPE for FP

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1184

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    NLnet milestone|---                         |Future

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #0)
> I have an idea for how to handle XLEN for FP:
> currently, for FP, XLEN is poorly-defined for BFP16 and BFloat16, since we
> currently need XLEN to both match element size and allow distinguishing
> between BFP16 and BFloat16, which are conflicting requirements since they're
> both 16-bit types.

a function helps there. or, a global variable inserted into the
namespace (and spec)


> This still leaves the issue of what to set XLEN to for instructions like
> ctfpr that are both integer and fp operations, I had proposed having FLEN
> for FP and XLEN for integer, but that was rejected (maybe reconsider?).

it's the one crossover point that makes the different elwidths a bit
hairy.  INT ops can get away with overcalculating then truncating
(dropping bits) but FP ops can't.

i really wanted to avoid two XLENs. fp-int converts i think make them
unavoidabe but i am sure there is a workaround.

good to record: can we leave detailed discussions until much later.

-- 
You are receiving this mail because:
You are on the CC list for the bug.