[Libre-soc-isa] [Bug 1184] New: 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

            Bug ID: 1184
           Summary: Proposal for fixing XLEN: XLEN always is type-len, add
                    FTYPE and FSTYPE for FP
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Specification
          Assignee: programmerjake at gmail.com
          Reporter: programmerjake at gmail.com
                CC: libre-soc-isa at lists.libre-soc.org, lkcl at lkcl.net,
                    programmerjake at gmail.com
   NLnet milestone: ---

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.

Therefore, I think we should introduce 2 new variables like XLEN that cleanly
specify which types should be used for FP and FP Single instructions, allowing
XLEN to only convey type size. FTYPE specifies which format is used for FP
instructions, as well as the in-register format for FP Single instructions.
FSTYPE specified which format is used for computations in FP Single
instructions.

| SVP64 elwid | Int XLEN | FP XLEN | FTYPE    | FSTYPE | Notes          |
|-------------|----------|---------|----------|--------|----------------|
| 00          | 64       | 64      | BFP64    | BFP32  | DEFAULT values |
| 01          | 32       | 32      | BFP32    | BFP16  |                |
| 10          | 16       | 16      | BFP16    | -      |                |
| 11          | 8        | 16      | BFloat16 | -      |                |

Additionally, pseudocode will, instead of using bfp64_* or bfp32_* pseudocode
functions directly, use new f_* and fs_* pseudocode functions that switch on
F[S]TYPE and call the appropriate functions.

e.g.:

fatan2s pseudocode becomes:
FRT <- DOUBLE(fs_ATAN2(SINGLE(FRA), SINGLE(FRB)))

fatan2 pseudocode becomes:
FRT <- f_ATAN2(FRA, FRB)


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?).

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