| Summary: | OPF ISA External RFC ls002 - fmvis and fishmv | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Luke Kenneth Casson Leighton <lkcl> |
| Component: | Specification | Assignee: | Luke Kenneth Casson Leighton <lkcl> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | libre-soc-isa, paulus, programmerjake |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| URL: | https://libre-soc.org/openpower/sv/rfc/ls002.fmi/ | ||
| See Also: |
https://bugs.libre-soc.org/show_bug.cgi?id=887 https://bugs.libre-soc.org/show_bug.cgi?id=945 https://bugs.libre-soc.org/show_bug.cgi?id=1015 |
||
| NLnet milestone: | NLnet.2022-08-051.OPF | total budget (EUR) for completion of task and all subtasks: | 0 |
| budget (EUR) for this task, excluding subtasks' budget: | 0 | parent task for budget allocation: | 1009 |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: | ||
| Bug Depends on: | |||
| Bug Blocks: | 952, 1009, 1092 | ||
|
Description
Luke Kenneth Casson Leighton
2022-10-05 14:26:58 BST
suggestion to use fli2 instead of fishmv and to add fli3-4 to load the rest of a f64: https://libre-soc.org/irclog/%23libre-soc.2022-10-07.log.html#t2022-10-07T16:33:27 > fli3: RT <- SINGLE(RT) || imm || [0]*16 > fli4: RT[48:63] <- imm > so flis; fli2; fli3; fli4 ends up being simply the 4 16-bit quarters > of the final fp64 in sequence from msb to lsb > and to do a whole fp64 with ext001 64-bit ops would just be pflis pfli3 > pflis is a whole f32, pfli3 is RT <- SINGLE(RT) || imm[0:31] <snip> > i'd like to prioritize instruction names that are easier to understand... > imho fli2 is quite memorable because it's similar to li > and it's the second step of loading fp immediates lkcl mentioned he wanted to prioritize funny mnemonics because he thought they were more memorable and made better PR. (In reply to Jacob Lifshay from comment #1) > lkcl mentioned he wanted to prioritize funny mnemonics because he thought > they were more memorable and made better PR. yes. imagine doing a FOSDEM talk, getting a laugh when presenting, because adding an instruction to an ISA could be considered very intimidating. Comments from IBM architects and toolchain developers about problems with the proposal: Regarding instruction names and mnemonics, the architecture uses "m", not "mv", for moves. The relative order of "Immediate" and "Move" differs between the two instruction names (fmvis and fishmv). found some useful statistics on which fp constants are commonly used: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/PlNSsNy-oA8/m/8u0i_LVAAAAJ I did some analysis on the values given to see if just fmvis, both fmvis/fishmv, or a full BFP64 are needed: | Value | Occurrences | Fits in BFP32 | Fits in BFloat16 | |------------------------|-------------|---------------|------------------| | 1.0 | 1466 | 1 | 1 | | 2.0 | 615 | 1 | 1 | | 3.0 | 530 | 1 | 1 | | 4.0 | 413 | 1 | 1 | | -1.0 | 391 | 1 | 1 | | 10.0 | 333 | 1 | 1 | | 5.0 | 296 | 1 | 1 | | 0.5 | 238 | 1 | 1 | | 6.0 | 208 | 1 | 1 | | 120.0 | 201 | 1 | 1 | | 60.0 | 164 | 1 | 1 | | 70.0 | 147 | 1 | 1 | | 7.0 | 143 | 1 | 1 | | 9.0 | 134 | 1 | 1 | | 150.0 | 132 | 1 | 1 | | Infinity | 130 | 1 | 1 | | -2.0 | 128 | 1 | 1 | | 16.0 | 115 | 1 | 1 | | 17.0 | 111 | 1 | 1 | | 130.0 | 110 | 1 | 1 | | 12.0 | 109 | 1 | 1 | | 18.0 | 107 | 1 | 1 | | 1280.0 | 102 | 1 | 1 | | 3600.0 | 99 | 1 | 1 | | 11.0 | 91 | 1 | 1 | | 90.0 | 83 | 1 | 1 | | NaN | 83 | 1 | 1 | | -3.0 | 81 | 1 | 1 | | 8.0 | 81 | 1 | 1 | | -90.0 | 79 | 1 | 1 | | 2700.0 | 77 | 1 | 0 | | -4.0 | 75 | 1 | 1 | | 14.0 | 73 | 1 | 1 | | -5.0 | 67 | 1 | 1 | | 25.0 | 67 | 1 | 1 | | 30.0 | 64 | 1 | 1 | | 1000.0 | 64 | 1 | 1 | | 1.234 | 63 | 0 | 0 | | 20.0 | 63 | 1 | 1 | | 26.0 | 62 | 1 | 1 | | 2.2 | 59 | 0 | 0 | | 1.100000023841858 | 59 | 1 | 0 | | -1.7363228039172371 | 56 | 0 | 0 | | 10000000000.0 | 56 | 1 | 0 | | -60.0 | 56 | 1 | 1 | | 1.1 | 53 | 0 | 0 | | 5.0e-324 | 52 | 0 | 0 | | 1.0e+35 | 49 | 0 | 0 | | 99.0 | 48 | 1 | 1 | | 100.0 | 48 | 1 | 1 | | 1.0000000000000001e-35 | 48 | 0 | 0 | | 5.4324 | 47 | 0 | 0 | | 13.0 | 46 | 1 | 1 | | -0.5 | 45 | 1 | 1 | | -6.0 | 44 | 1 | 1 | | 110.0 | 44 | 1 | 1 | | -Infinity | 41 | 1 | 1 | | 0.25 | 41 | 1 | 1 | | 28.0 | 41 | 1 | 1 | | 21.0 | 40 | 1 | 1 | | 162.0 | 38 | 1 | 1 | | 3.3 | 38 | 0 | 0 | | 1.5 | 37 | 1 | 1 | | 15.0 | 37 | 1 | 1 | | 0.0 | 36 | 1 | 1 | | 123.0 | 35 | 1 | 1 | | 22.0 | 35 | 1 | 1 | | 80.0 | 34 | 1 | 1 | | 180.0 | 34 | 1 | 1 | | 23.0 | 33 | 1 | 1 | | 31.0 | 28 | 1 | 1 | (In reply to Paul Mackerras from comment #3) > Comments from IBM architects and toolchain developers about problems with > the proposal: > > Regarding instruction names and mnemonics, the architecture uses "m", not > "mv", for moves. The relative order of "Immediate" and "Move" differs > between the two instruction names (fmvis and fishmv). i think it would be appropriate to rename the instructions like so: fmvis -> fmis (floating move immediate shifted, like addis) fishmv -> either fmil (floating move immediate lower) or fmi2 (floating move immediate 2nd-half/part-2 -- allows future extension for fmi3/fmi4 for full bfp64 if desired) |