https://libre-soc.org/openpower/sv/int_fp_mv/ https://libre-soc.org/openpower/sv/rfc/ls006.fpintmv OPF recorded response with ID [OPF][ISA] #200570] https://lists.libre-soc.org/pipermail/libre-soc-isa/2024-February/002880.html * DONE: resolve instruction list reduction concern (bug #1016) -- rewrote wiki page to have 5 insns (not counting fmvis/fishmv) and the original insns as assembler aliases. * DROPPED: maybe replace fmvfg/fmvtg with fgrev* for byte swaps too (bug #1018) * DONE: change back to /s/./s. since PowerISA likes to have separate POs for f*/f*s variants * DONE: write RFC * DONE: remove fcvttgs/fcvtstg * DONE: remove fmvfg Rc=1 * DONE: add notes about equivalence to mtvsrd and friends * DONE: rename fmv* to be consistent with standard PowerISA move naming convention of just using m instead of mv comment #47 * DONE: rename fcvt* to be consistent with standard PowerISA move naming convention of just using c instead of cvt comment #47 * WIP: bug #1118 review RFC * DONE: rewrite moves to match standard style * WIP: rewrite conversions to match standard style * DONE: convert links to references (comment #50) * DONE: submit RFC comment #55 * DONE: address comment #39 * DONE: fix bugs found by unit tests in bug #1072 * DONE: budget for jacob on ls006 feedback bug (actually on this bug) https://libre-soc.org/irclog/%23libre-soc.2023-05-04.log.html#t2023-05-04T05:32:51
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> Date: Tue Mar 7 13:39:23 2023 +0000 add int fp move ls006 stub rfc https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=1f01686bafb78ddbe9d6bb65b01d186591aa8115
it occurred to me that we may want to submit fpr/gpr converts as a separate rfc from fpr/gpr moves/byte-swaps
(In reply to Jacob Lifshay from comment #2) > it occurred to me that we may want to submit fpr/gpr converts as a separate > rfc from fpr/gpr moves/byte-swaps I added fpr/gpr grev to a copy of int_fp_mv for review. fpr/gpr grev replaces fmvfg/fmvtg, which are now just assembler aliases: https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/int_fp_mv_replace_fmv_with_fgrev.mdwn;h=4b3a6900deafad6493b7b4a3cf1e4da91b05a994;hb=HEAD It also occurred to me that there are no fp load/stores with byte swapping, we'll want to add those too, probably as a separate RFC.
(In reply to Jacob Lifshay from comment #2) > it occurred to me that we may want to submit fpr/gpr converts as a separate > rfc from fpr/gpr moves/byte-swaps removed fpr byte swaps since tbe ISA WG likely will reject them. imho to address luke's concern that there are too many insns at once, i still think we should submit fcvt* as a separate RFC from fmv*. imho we should submit fcvt* first since it has a stronger use case. the RFCs still need to wait on luke's reviewing the new naming scheme and deciding if he wants to reject it like markos and I did.
(In reply to Jacob Lifshay from comment #4) > the RFCs still need to wait on luke's reviewing the new naming scheme and > deciding if he wants to reject it like markos and I did. clarification, markos stated he preferred the old naming scheme, "reject" is too strong a word.
(In reply to Jacob Lifshay from comment #4) > the RFCs still need to wait on luke's reviewing the new naming scheme and > deciding if he wants to reject it like markos and I did. it goes in. four instructions vs almost 30 is abolutely no contest whatsoever. please proceed with the 4 instructions as requested over six months ago.
(In reply to Luke Kenneth Casson Leighton from comment #6) > (In reply to Jacob Lifshay from comment #4) > > > the RFCs still need to wait on luke's reviewing the new naming scheme and > > deciding if he wants to reject it like markos and I did. > > it goes in. four instructions vs almost 30 is abolutely no contest > whatsoever. > > please proceed with the 4 instructions as requested over six months ago. ok, but i'm adding a note about the alternative naming scheme, that way the ISA WG doesn't think we're a bunch of idiots that don't even bother to match precedent. something like: * alternatives considered: using a naming scheme that more closely aligns with PowerISA's existing naming scheme for fp/int instruction mnemonics instead of using immediates. this was rejected because it would have dozens of instruction mnemonics instead of 4.
Just a thought, could there be just the proposed 4 instructions and the others be just aliases? That way no extra opcodes are required. At the end, it's only a syntactic convenience anyway.
(In reply to Konstantinos Margaritis (markos) from comment #8) > Just a thought, could there be just the proposed 4 instructions and the > others be just aliases? that was the original request 6 months ago. > That way no extra opcodes are required. At the end, > it's only a syntactic convenience anyway. and preserves the RISC paradigm as the mode-table is uniform.
https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/rfc/ls006.mdwn;h=92413f870c94c68d5563d7baf67518fcf95ba2ef;hb=925ee9036b97b4f990b2d9f954a5519330f23968 commit 925ee9036b97b4f990b2d9f954a5519330f23968 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 15 20:31:30 2023 -0700 move assembly aliases to new page commit e4819505b0f9a4668335714a6942346aa3236c32 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 15 20:28:40 2023 -0700 add content to ls006 <snip> commit a44938c88e66e7d2b94b065fe0bff056a8207595 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 15 19:25:45 2023 -0700 rename Java conversion semantics to Java/Saturating conversion semantics since nearly everywhere else refers to it as saturating conversion commit e6532dc95d06fe77fa118218c018307535860f74 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 15 18:52:18 2023 -0700 update ls006, filling in section numbers
commit dfcb11ca9d70335242e84d4b8d8b96fb24600ccf Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Mar 16 12:08:24 2023 -0700 clarify java/saturating only refers to java's fp->int for long/int we specifically don't mean java's float -> byte/short/etc. that saturates to int then truncates
https://libre-soc.org/irclog/%23libre-soc.2023-03-17.log.html#t2023-03-17T08:57:56 me on irc: > oh, btw, i realized that using all the pseudocode functions from the vsx section of the powerisa > spec might not go over so well, so i'm thinking of rewriting the pseudocode for fcvt[f/t]g > > it would either be based off iirc book 1 appendix A which has suggested fp models, or just write > the pseudocode without using existing fp functions > > except SINGLE/DOUBLE of course > > i did at least check that all the vsx functions i used don't refer to any vsx-only > registers afaict > > lkcl & others: any comments? > > the vsx/vmx functions i used are in powerisa v3.1b book 1 sections 6.2.1 and 7.6.2.2 > > actually mostly just 7.6.2.2
(In reply to Jacob Lifshay from comment #12) > https://libre-soc.org/irclog/%23libre-soc.2023-03-17.log.html#t2023-03-17T08: > 57:56 > me on irc: > > oh, btw, i realized that using all the pseudocode functions from the vsx section of the powerisa > > spec might not go over so well, so i'm thinking of rewriting the pseudocode for fcvt[f/t]g no there is a good reason *to* use the exact same pseudocode: it reduces IBM's workload. and also ours. please find and read my earlier IRC comments about hypothetical discussions that may take place with the IBM Hardware Architects. don't try to "hide" things like that, it will not be well received, it will be viewed as an attempt to deceive, particularly if someone after spending considerable time (a) notices they are the same or (b) finds these conversations online and sees a conclusion that we attempted to deceive. no, it is far better to make the point that has consistently been made: we're *not* doing VSX end of story, we do expect under the Anti-Trust provisions to be taken seriously from a commercial perspective that we need the SFFS Compliancy Level at an adequate standard... *without* poisoning SFFS by pulling in VSX infrastructure in any way shape or form.
(In reply to Luke Kenneth Casson Leighton from comment #13) > (In reply to Jacob Lifshay from comment #12) > > https://libre-soc.org/irclog/%23libre-soc.2023-03-17.log.html#t2023-03-17T08: > > 57:56 > > me on irc: > > > oh, btw, i realized that using all the pseudocode functions from the vsx section of the powerisa > > > spec might not go over so well, so i'm thinking of rewriting the pseudocode for fcvt[f/t]g > > no there is a good reason *to* use the exact same pseudocode: it > reduces IBM's workload. > > and also ours. well, with the way fcvttg in particular is written, i think it would be wise to rewrite it based off book 1 appendix a since that's likely to be much simpler for readers and for ibm, rather than what is there now which is working around all the vsx functions by calling them several different times and having two pages of complex confusing code. > > please find and read my earlier IRC comments about hypothetical > discussions that may take place with the IBM Hardware Architects. > > don't try to "hide" things like that, it will not be well received, > it will be viewed as an attempt to deceive, particularly if someone > after spending considerable time (a) notices they are the same or > (b) finds these conversations online and sees a conclusion that we > attempted to deceive. it was never my intention to deceive, but that the functions used are from a different section of the book than where we want the code to end up, so we should base it on the fp code from the scalar floating point section rather than the vsx section. this also helps avoid issues like us accidentally using vsx functions that access vsx/vmx registers when we don't want them to, e.g. si32_CONVERT_FROM_BFP32 can set VSCR.SAT also, the pseudocode would definitely have comments explaining where the code came from and what's different, so imho that shouldn't be easily confused with "hiding" things.
commit d827d9e11ce635d52652f8936a454319fa2ebea9 (HEAD -> master) Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> Date: Wed Mar 22 16:06:18 2023 +0000 whitespace cleanup on ls006, remove duplication, add "special registers altered" section https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=d827d9e11ce635d52652f8936a454319fa2ebea9 (do keep to under 80 chars per line except ridiculously-long URLs)
ok so i forgot to say that reducing the number of instructions by merging FP32 and FP64 would be a step too far, because what IBM typically does is allocate separate MAJOR opcodes for each. so the "s" and non-"s" variants have to be separated out. annoyingly. however that does result in a reduction in the individual pseudocode length.
(In reply to Luke Kenneth Casson Leighton from comment #16) > ok so i forgot to say that reducing the number of instructions > by merging FP32 and FP64 would be a step too far, because what > IBM typically does is allocate separate MAJOR opcodes for each. > so the "s" and non-"s" variants have to be separated out. > > annoyingly. i'd be happy to apply that change since it makes it closer to PowerISA's naming scheme. basically RCS gets deleted and replaced with separate `s` instructions and `.` instructions with a Rc field.
https://git.libre-soc.org/?p=libreriscv.git;a=commit;h=625aacf47a091a67d9c41bfa693f7b5d5cbd42c3 commit 625aacf47a091a67d9c41bfa693f7b5d5cbd42c3 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 13:50:17 2023 -0700 fill out notes and observations I can't read the commitdiff of d827d9e11ce635d52652f8936a454319fa2ebea9, so I'm reverting and reapplying it as a set of split-up commits. commit b00624c34f66483b5e8048387ffacb2ce224246b Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 13:49:30 2023 -0700 add "Special Registers altered" sections I can't read the commitdiff of d827d9e11ce635d52652f8936a454319fa2ebea9, so I'm reverting and reapplying it as a set of split-up commits. commit 630ad1f4c065e0afae6a78eaaf6f9a4e06854edd Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 13:45:31 2023 -0700 misc grammar adjustments I can't read the commitdiff of d827d9e11ce635d52652f8936a454319fa2ebea9, so I'm reverting and reapplying it as a set of split-up commits. commit ee94bf985a85caf27808a0a40863772f5dc2f545 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 13:44:22 2023 -0700 whitespace adjustments I can't read the commitdiff of d827d9e11ce635d52652f8936a454319fa2ebea9, so I'm reverting and reapplying it as a set of split-up commits. commit 17d97bc5c43141cd7e04788deb7bf31a5f366df7 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 13:42:14 2023 -0700 re-word-wrap text I can't read the commitdiff of d827d9e11ce635d52652f8936a454319fa2ebea9, so I'm reverting and reapplying it as a set of split-up commits. commit 857a41723e52129af4f0f5871b16adb2471f29c7 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 13:29:15 2023 -0700 remove redundant text I can't read the commitdiff of d827d9e11ce635d52652f8936a454319fa2ebea9, so I'm reverting and reapplying it as a set of split-up commits. commit 3e61aff2c5b0d3ccd9968c7ae08ead0aec58f0da Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 13:26:05 2023 -0700 only indent code -- nothing else I can't read the commitdiff of d827d9e11ce635d52652f8936a454319fa2ebea9, so I'm reverting and reapplying it as a set of split-up commits. commit 537b0774bb988bcb9ff67338a29157db7d40d096 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 13:10:08 2023 -0700 Revert "whitespace cleanup on ls006, remove duplication," I can't read the commitdiff, so I'm reverting and reapplying it as a set of split-up commits. This reverts commit d827d9e11ce635d52652f8936a454319fa2ebea9.
(In reply to Jacob Lifshay from comment #18) > https://git.libre-soc.org/?p=libreriscv.git;a=commit; > h=625aacf47a091a67d9c41bfa693f7b5d5cbd42c3 thank you for doing this, really appreciated.
commit 3203275e80b4dccf3620faa0f73e2d0dcd1b64d7 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:56:51 2023 -0700 copy table changes from ls006 to int_fp_mv commit e3b729aed995b32f6a530e500a85480470f36752 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:55:18 2023 -0700 copy changes from ls006 -> int_fp_mv -- table changes are a separate commit commit 65eb9a8a1178b03346e45c9e4a667d33a9e8d0fc Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:54:35 2023 -0700 fix spacing commit ab3261ebf546e03654b517fab6051f7541fa6735 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:46:21 2023 -0700 change formatting to line up with pages better commit 1b001048a6779606561bdbac3e2b2633cf3181b7 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:45:41 2023 -0700 rewrap text to save lines commit 6d0a49899a217dd73637aa7e0473e391be4de1c3 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:44:28 2023 -0700 convert tables to be wider rather than taller commit c3207e6ea70076278957eff0b61dcca3df89f881 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:42:27 2023 -0700 partially fix FPCSR in "Special Registers altered" sections didn't yet fill in "TODO: which bits?" commit 69379f9c04592bcb17e4d8bba91c402fa0eb5ad4 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:38:55 2023 -0700 re-add empty lines before/after SetFX -- the spec has them, we should too commit 9889ee7c1c5e1faa0cd2ebbde3f2a6ebd6dc601d Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:37:57 2023 -0700 spelling fixes commit 91d8b48ca10a546db82df9a6b138d39ec807d9d5 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 14:33:39 2023 -0700 copying changes from ls006 to int_fp_mv -- indent code blocks -- nothing else
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=ef12e4a02c9c7908fad914230b3e364c527d0857 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 15:13:24 2023 -0700 add fixmes for disagreement in the cost of JavaScript ToInt32 without fcvttgw
(In reply to Jacob Lifshay from comment #17) > (In reply to Luke Kenneth Casson Leighton from comment #16) > > ok so i forgot to say that reducing the number of instructions > > by merging FP32 and FP64 would be a step too far, because what > > IBM typically does is allocate separate MAJOR opcodes for each. > > so the "s" and non-"s" variants have to be separated out. > > > > annoyingly. > > i'd be happy to apply that change since it makes it closer to PowerISA's > naming scheme. > basically RCS gets deleted and replaced with separate `s` instructions and > `.` instructions with a Rc field. Done. https://git.libre-soc.org/?p=libreriscv.git;a=history;f=openpower/sv/rfc/ls006.mdwn;hb=f13824387524bd68ce68c92562b3dc9d951f598f commit f13824387524bd68ce68c92562b3dc9d951f598f Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 18:45:30 2023 -0700 remove RCS table since it's now unused commit 29612ee9d2bd4d5977dbf68bc46ddd943aab7d20 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 18:45:11 2023 -0700 fix mnemonics commit 928a7c90f0c8a6ac938dad6477b9df6b3978c874 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 18:38:02 2023 -0700 move form tables to between mnemonic list and pseudo-code, like the spec does commit a688ccce3ac502734a7ae8e18e28c7c54081db50 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 18:36:12 2023 -0700 remove wrong mnemonics commit fc917fdaf848e3f15aece529be41228b75add4b1 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 18:28:34 2023 -0700 convert mnemonics to be code blocks, so markdown doesn't put all inst variants on one line commit 5561c3855255d17dc6d59cd036429143e352ee81 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 18:22:27 2023 -0700 change instruction section titles to match instruction mnemonics commit 46c263f1dd0ec5c5d513cae0d428341f2234abc7 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 18:15:00 2023 -0700 convert fcvttg[o] to fcvt[s]tg[o][.] commit 31f8085bae2028288a217990e2e8e337bd012a42 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 17:57:00 2023 -0700 convert fcvtfg to fcvtfg[s][.] commit 1f310803d27b2ddd3f7be4bf7ed6a6d99f5d0f04 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 17:44:57 2023 -0700 dedent code section we're keeping in fcvtfgs[.] -- nothing but dedenting commit f7f30c5ea1b46dc499ce80f0b3ca29fe8702acd1 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 17:36:34 2023 -0700 duplicate fcvt[f/t]g[o] sections in preperation for splitting out Single versions commit bc4900835fe18ad8ab37bcff74207918c3b6780e Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 17:31:27 2023 -0700 convert fmv[f/t]g to fmv[f/t]g[s][.] commit ddecc774f9bc4e9b179822901843edbbefed4986 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 17:19:12 2023 -0700 duplicate fmv[f/t]g sections in preperation for splitting out Single versions commit bf12775cd69451fb6705e6dfb13a0f957e1e8b6c Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Mar 22 17:15:50 2023 -0700 fix: fmvtg. changes CR0, not CR1
commit 0acbcae658f7571723b71bf7b742391e0302192e (HEAD -> master) Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> Date: Sat Mar 25 14:31:28 2023 +0000 update nunmber of instructions (to 8, sigh), clarify heading for each instruction explicitly saying "Double-Precision" https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=0acbcae658f7571723b71bf7b742391e0302192e
there was a link already mentioned about rust: i removed the duplicate. i want all mention of rust to be kept to the absolute bare minimum. links need to be converted to show the actual URL as text, because in a Specification it will be expected that the URLs be readable rather than as an embedded hyperlink. normally "<ref>" would be used or i mean \ref but that *may* be beyond the capability of pandoc, then again it might be a surprise to find it's possible.
https://scientificallysound.org/2021/12/28/cross-referencing-in-pandoc-and-markdown-with-x/ pandoc-xnos apparently does the job? (needs installing from source, would need to be added to devscripts, sigh)
https://git.libre-soc.org/?p=libreriscv.git;a=shortlog;h=b06a65bfa405ce17807a45f2ea9eae8bfc76122a commit b06a65bfa405ce17807a45f2ea9eae8bfc76122a Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Apr 3 18:30:43 2023 -0700 fill in FPSCR bits modified by int <-> fp conversions commit fd4449853ae9d37c81ca396d7fe7678b8f070702 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Apr 3 18:19:03 2023 -0700 resolve ToInt32 instruction count disagreement commit 4b8a4d6167c510b7edad7281df9ed74c49b6eedd Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Apr 3 18:15:25 2023 -0700 add new fields/formats for ls006 commit 86883ebe368fdf94f54396119275277f0ec0627e Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Apr 3 17:44:50 2023 -0700 sync changes from ls006 -> int_fp_mv commit 81bd38e754a37670c57958fe7fd2e77d5464d736 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Apr 3 17:37:13 2023 -0700 switch to using standard OE bit location for XO-FORM
(In reply to Jacob Lifshay from comment #26) > commit 86883ebe368fdf94f54396119275277f0ec0627e > Author: Jacob Lifshay <programmerjake@gmail.com> > Date: Mon Apr 3 17:44:50 2023 -0700 > > sync changes from ls006 -> int_fp_mv tip: in extreme cases such as ls010 i have been modifying the header of the wiki page then leaving the ls019.mdwn as a 1-page stub and using pandoc *.mdwn that way there *are* no duplicate pages and no need to "sync".
(In reply to Luke Kenneth Casson Leighton from comment #27) > (In reply to Jacob Lifshay from comment #26) > > > commit 86883ebe368fdf94f54396119275277f0ec0627e > > Author: Jacob Lifshay <programmerjake@gmail.com> > > Date: Mon Apr 3 17:44:50 2023 -0700 > > > > sync changes from ls006 -> int_fp_mv > > tip: in extreme cases such as ls010 i have been > modifying the header of the wiki page then leaving > the ls019.mdwn as a 1-page stub and using pandoc *.mdwn > > that way there *are* no duplicate pages and no need to "sync". well, they are still different enough that they should be separate pages, ls006 has all the rfc boilerplate, int_fp_mv has all of fmvis/fishmv
(In reply to Jacob Lifshay from comment #26) resolve ToInt32 instruction count disagreement > > commit 4b8a4d6167c510b7edad7281df9ed74c49b6eedd > Author: Jacob Lifshay <programmerjake@gmail.com> > Date: Mon Apr 3 18:15:25 2023 -0700 > > add new fields/formats for ls006 please use the style from fields.text which is machine-readable, the column vertical-bar positions matter example is Z23-Form 270 # 1.6.27 Z23-FORM 271 |0 |6 |11 |15 |16 |21 |23 |31 | 278 | PO | FRTp| FRAp | FRBp |RMC| XO |Rc | 279 | PO | FRT | /// | R | FRB |RMC| XO |Rc | 280 | PO | FRTp| /// | R | FRBp |RMC| XO |Rc | it is obvious that R is 1 bit, and (line 279) bits 11-14 are unused. don't use markdown table format it is inconsistent with fields.text and with every other RFC and with the Power ISA itself
(In reply to Jacob Lifshay from comment #28) > well, they are still different enough that they should be separate pages, please listen. i *made* the existing wiki pages become part of the rfc. > ls006 has all the rfc boilerplate, int_fp_mv has all of fmvis/fishmv that's precisely the split location. ls006 has all the rfc boilerplate SPLIT int_fp_mv has all of fmvis/fis pandoc ls006.mdwn int_fp_mv.mdwn look at the Makefile. saves work. avoids duplication mistakes. i am converting ls008 and ls009 tomorrow as well
(In reply to Luke Kenneth Casson Leighton from comment #29) > (In reply to Jacob Lifshay from comment #26) > > resolve ToInt32 instruction count disagreement > > > > commit 4b8a4d6167c510b7edad7281df9ed74c49b6eedd > > Author: Jacob Lifshay <programmerjake@gmail.com> > > Date: Mon Apr 3 18:15:25 2023 -0700 > > > > add new fields/formats for ls006 > > please use the style from fields.text which is > machine-readable, the column vertical-bar positions > matter ok, I can change that...I'm assuming you're done changing those sections now
> (In reply to Luke Kenneth Casson Leighton from comment #29) > ok, I can change that...I'm assuming you're done changing those sections now commit 13c991caadcc5e59f394a494c3e3d68fa483f4ff Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Apr 3 21:59:15 2023 -0700 re-narrow fcvttg asm alias table commit d5849caa777813a5cb9c91d1f56decce365c638a Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Apr 3 21:57:36 2023 -0700 convert to fields.text format
commit 56838fb55e52111b22a8f312981aaf965a8b2291 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Apr 5 20:30:03 2023 -0700 replace common sections with [[!include]] commit 2dea3984ba926b62bdc3e4b77ed928502b3972ef Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Apr 5 20:22:09 2023 -0700 add new file for common section from ls006 and int_fp_mv commit 597e46ec6c9f852d10e53892d4b42e747935ecc2 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Apr 5 20:19:19 2023 -0700 sync int_fp_move and ls006 fully in prep for section being split out into separate file
| 0-5 | 6-10 | 11-15 | 16-20 | 21-30 | 31 | Form | |-----|------|-------|-------|-------|----|--------| | PO | FRT | 0 | RB | XO | Rc | X-Form | these need removing and replacing with | PO | FRT | // | RB | XO | Rc | X-Form | please do not include suggestions within *this* RFC on new opcode encoding ideas. keep this RFC absolutely focussed please.
commit 400732dbef3d2bc81aacbdabc64933cee6de7783 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Apr 6 16:56:50 2023 -0700 change 0 bits in RA field to // for int/fp mv/cvts as luke requested https://libre-soc.org/irclog/latest.log.html#t2023-04-07T00:34:47 I'll note that I had those bits as 0 because that way it effectively has an expanded opcode field, like: mffscdrn FRT, FRB |0 |6 |11 |16 |21 |31 | | 63 | FRT | 20 | FRB | 583 | / |
Afaict this is ready for review
https://libre-soc.org/openpower/sv/int_fp_mv/moves_and_conversions/ couple of things: 1) can you remove these from sv/int_fp_mv and do the same "include" trick, it's a pain but we shouldn't have gone down the duplication route, oh well. (i have a couple to do as well, sigh) 2) can you please make fcvtstg end with "s" by renaming it to a *from* instruction "float to integer convert *from* single or something that arranges the letter "s" to be at the end. this is important from an orthogonality perspective (and ISACaller crucially relies on it).
(In reply to Luke Kenneth Casson Leighton from comment #37) > https://libre-soc.org/openpower/sv/int_fp_mv/moves_and_conversions/ > > couple of things: > > 1) can you remove these from sv/int_fp_mv and do the same "include" trick, i did that already, in the same commit as i did includification for ls006 > 2) can you please make fcvtstg end with "s" added to todo list
got some feedback: btw, https://libre-soc.org/openpower/sv/rfc/ls006/ section "3.2 Floating Move To GPR Single" might need some improved wording, as the storing of single-precision data is not really just bit extraction and sending to storage. Check the venerable Book-E "5.6.2 Floating-Point Store Instructions" for a detailed explanation what conversions take place during stfs
(In reply to Luke Kenneth Casson Leighton from comment #39) > got some feedback: > > btw, https://libre-soc.org/openpower/sv/rfc/ls006/ section "3.2 Floating > Move To GPR Single" might need some improved wording https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=d4f8c834818adc2904ee98ff13e4a70ae31e028e commit d4f8c834818adc2904ee98ff13e4a70ae31e028e Author: Jacob Lifshay <programmerjake@gmail.com> Date: Fri Apr 14 18:56:33 2023 -0700 reword fmv[f/t]gs as requested by feedback
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=9046dad33eba10697d4727db91968bf945410108 added fixes for syntax errors found while adding these instructions to the simulator commit 9046dad33eba10697d4727db91968bf945410108 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed May 3 21:55:07 2023 -0700 fix fcvt pseudocode
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=c75dd28e637f6f555d5c6116576924812b0b9f9a commit c75dd28e637f6f555d5c6116576924812b0b9f9a Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue May 16 21:53:45 2023 -0700 fix bug in fcvttg OpenPower and saturating conversion
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=bcd5313faf232137e91f4c7fa8fc9e6828000bd7 commit bcd5313faf232137e91f4c7fa8fc9e6828000bd7 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Fri Jun 16 18:23:11 2023 -0700 add notes about fmv[ft]g similarity to m[tf]vsrd
since I think we need to rename fcvt*/fmv* to be consistent with existing instructions, I propose: fmvfg -> mtfpr/mtfprd (depending if we want a new instruction anyway) fmvfgs -> mtfprs fmvtg[.] -> mffpr[.]/mffprd (depending if we want a new instruction anyway) fmvtgs[.] -> mffprs[.] fcvtfg[.] -> ctfprd[.] fcvtfgs[.] -> ctfprs[.] fcvttg[o][.] -> cffprd[o][.] note mtfprd/mffprd are just using the existing instructions but made available on SFFS when SX/TX=0, since PowerISA treats the SX/TX=0 version as a FP instruction instead of a VSX instruction. the only part that we would lose if we just used the existing instructions is Rc=1 support for fmvtg., which is not that important.
(In reply to Jacob Lifshay from comment #44) > note mtfprd/mffprd which are not real instructions they are pseudo-aliases > are just using the existing instructions existing VSX instructions that will have their own Vectorisation Prefixing > but made > available on SFFS when SX/TX=0, since PowerISA treats the SX/TX=0 version as > a FP instruction instead of a VSX instruction. no. definitely not. absolute total chaos would ensue: code would redirect down an untested hardware path. plus, the entire SV concept would become "non-orthogonal". we have pushed hard for keeping entirely separate from VSX: what you are effectively saying is to dig deep into VSX Encoding and *redirect* to a different hardware path. aside from losing the Orthogonality this will deeply complexify Multi-Issue Decode. > the only part that we would > lose if we just used the existing instructions is Rc=1 support for fmvtg., > which is not that important. which is a secondary reason to keep it
(In reply to Jacob Lifshay from comment #44) > since I think we need to rename fcvt*/fmv* to be consistent with existing > instructions, I propose: > > fmvfg -> mtfpr/mtfprd (depending if we want a new instruction anyway) > fmvfgs -> mtfprs > fmvtg[.] -> mffpr[.]/mffprd (depending if we want a new instruction anyway) > fmvtgs[.] -> mffprs[.] > fcvtfg[.] -> ctfprd[.] > fcvtfgs[.] -> ctfprs[.] > fcvttg[o][.] -> cffprd[o][.] luke responded that the renaming is fine, but we can't just reuse the existing vsx instructions (mffprd/mtfprd) https://libre-soc.org/irclog/%23libre-soc.2023-06-22.log.html#t2023-06-22T09:55:56
(In reply to Jacob Lifshay from comment #46) > (In reply to Jacob Lifshay from comment #44) > > since I think we need to rename fcvt*/fmv* to be consistent with existing > > instructions, I propose: > > > > fmvfg -> mtfpr/mtfprd (depending if we want a new instruction anyway) > > fmvfgs -> mtfprs > > fmvtg[.] -> mffpr[.]/mffprd (depending if we want a new instruction anyway) > > fmvtgs[.] -> mffprs[.] > > fcvtfg[.] -> ctfprd[.] > > fcvtfgs[.] -> ctfprs[.] > > fcvttg[o][.] -> cffprd[o][.] > > luke responded that the renaming is fine, but we can't just reuse the > existing vsx instructions (mffprd/mtfprd) > > https://libre-soc.org/irclog/%23libre-soc.2023-06-22.log.html#t2023-06-22T09: > 55:56 Did the rename, though used ctfpr/cffpr instead of ctfprd/cffprd to be consistent with m[ft]fpr and with other FP operations that use s/<nothing> instead of s/d. https://git.libre-soc.org/?p=libreriscv.git;a=shortlog;h=be089eab5a23d6f2ae4891f60a8284b24ca34648 commit be089eab5a23d6f2ae4891f60a8284b24ca34648 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Jun 22 20:20:16 2023 -0700 change instruction titles to match new names commit 1d2438c5102227f6b53b760ba77eac3d740506af Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Jun 22 20:08:48 2023 -0700 rename fmv[ft]g*/fcvt[ft]g* to m[tf]fpr*/c[tf]fpr* https://git.libre-soc.org/?p=openpower-isa.git;a=shortlog;h=47c56299f95329c52298d6109552a1f886b30dd1 commit 47c56299f95329c52298d6109552a1f886b30dd1 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Jun 22 20:10:45 2023 -0700 rename fmv[ft]g*/fcvt[ft]g* to m[tf]fpr*/c[tf]fpr* commit de103f942c8fe5f284e41125f17759e242762924 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Jun 22 19:58:04 2023 -0700 use the CSV "CR out" column to compute which mode to use for Rc=1 this works much better than trying to bodge it by checking if the instruction name meets some pattern
partially addressing https://bugs.libre-soc.org/show_bug.cgi?id=1118#c1 https://git.libre-soc.org/?p=libreriscv.git;a=shortlog;h=5e573680771f7a041d93d394003d6f9f08177a98 commit 5e573680771f7a041d93d394003d6f9f08177a98 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue Jun 27 19:08:11 2023 -0700 match v3.1B section 4.6.7.2 Floating-Point Convert To/From Integer Instructions commit 68ba72c0faebe55080cafcc8b878b39ca81efbc3 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue Jun 27 19:07:36 2023 -0700 change c[ft]fpr* instruction titles commit 04ba9d3f0ade3be5620d0cf89dbd262668de8869 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue Jun 27 18:58:48 2023 -0700 rename sections to match PowerISA v3.1B section 3.3.18 rename sections to match PowerISA v3.1B section 3.3.18 Move To/From Vector-Scalar Register Instructions commit c20a7f61310a01126862f31ba1d9d364b226cf81 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue Jun 27 18:53:32 2023 -0700 reformat markdown tables commit 50d8d707d5b37d59183891776051394ea96b78dd Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue Jun 27 18:49:30 2023 -0700 rewrite int/fp moves specification text to use style requested by luke https://bugs.libre-soc.org/show_bug.cgi?id=1118#c1
I rewrote the fp->int conversion overview section to be more like the PowerISA's style, as well as no longer using a special custom pseudocode style. I also split it out into a separate file, since I was thinking of maybe putting it in the RFC's Motivation section instead of the actual spec. wording. https://git.libre-soc.org/?p=libreriscv.git;a=shortlog;h=ad1a677bd8f17248e55201ebe2cb33176ac8717f commit ad1a677bd8f17248e55201ebe2cb33176ac8717f Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Jul 3 20:21:54 2023 -0700 update keywords to match rest of document commit 9f4b4d23f44a395e0c5766e156f2647a13f52c37 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Jul 3 20:20:55 2023 -0700 change rest of int/fp conversion docs to use new P/S/E-type naming commit c6e2d351c97c120b74e794b412e4f5b3f8a1d952 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Jul 3 20:13:09 2023 -0700 rewrite cvt_fp_to_int_overview.mdwn to be more like a specification. commit 985eed121053b544605af3adbe1de5651f61ae27 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Mon Jul 3 17:45:11 2023 -0700 extract fp->int conversion overview to separate page
nice. avoid "Kind" as it is an adverb that implies "Un-kind" should be somewhere in the document :) [`trunc_sat_u`](https://webassembly.github.io/spec/core/exec/numerics.html#op-trunc-sat-u) and [`trunc_sat_s`](https://webassembly.github.io/spec/core/exec/numerics.html#op-trunc-sat-s) sigh these all need to convert to references (see REP and CPIR done already, bear in mind any ref tags need to be global unique names) and there is a andic post-processing script in the... comparison_table which sorts out non-unique ref reuse, but the wiki is not as high a priority as the PDF.
(In reply to Luke Kenneth Casson Leighton from comment #50) > nice. avoid "Kind" as it is an adverb that implies "Un-kind" should > be somewhere in the document :) but I'm using it only as a noun, not an adverb. https://en.wiktionary.org/wiki/kind#Noun A type, race or category; a group of entities that have common characteristics such that they may be grouped together > > [`trunc_sat_u`](https://webassembly.github.io/spec/core/exec/numerics. > html#op-trunc-sat-u) > and > > [`trunc_sat_s`](https://webassembly.github.io/spec/core/exec/numerics. > html#op-trunc-sat-s) > > > sigh these all need to convert to references ok, added to todo list
(In reply to Jacob Lifshay from comment #51) > (In reply to Luke Kenneth Casson Leighton from comment #50) > > nice. avoid "Kind" as it is an adverb that implies "Un-kind" should > > be somewhere in the document :) > > but I'm using it only as a noun, not an adverb. nobody knows that and we're not prefixing the word "Kind" with "(n)" welcome to english language ambiguity :) > https://en.wiktionary.org/wiki/kind#Noun > A type, race or category; a group of entities that have common > characteristics such that they may be grouped together it's not what *you* intend it's what *other people read* when they don't know anything at all (zero context) > > sigh these all need to convert to references > > ok, added to todo list pain in the ass, isn't it? we *really* needed an "RFC Style Guide" over 2 years ago. would have saved us a lot of time and money. grrr.
(In reply to Jacob Lifshay from comment #51) > (In reply to Luke Kenneth Casson Leighton from comment #50) > > sigh these all need to convert to references > > ok, added to todo list I converted all the links to footnotes with all urls being literally present in the final pdf so you could follow them even from a printed copy. e.g. a footnote copied from the rendered ls006.fpintmv.pdf: > 3 Java float/double to long/int conversion: https://docs.oracle.com/javase/specs/jls/se16/html/jls-5.html#jls-5.1.3 https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=16d18350a918dbbd071a13b621f5111df8f97fae;hp=dafba4de190ad2b0ffb5e7ed42f436a729a79d69 commit 16d18350a918dbbd071a13b621f5111df8f97fae Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Jul 6 17:17:50 2023 -0700 links are part of footnotes commit 012a60193df5b708b462e62677319db682d1c107 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Jul 6 17:16:22 2023 -0700 convert links to footnotes
awesome, looks great. sorry it is 4:30am, very brief: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=67bbeb1fd7e4d2413c00d889c925303657a4407f the pseudocode for cffpr is really too long and needs moving to the appendix just like other instructions that e.g. use DOUBLE() or SINGLE(). it should be possible to pull in the file into the pdf by way of including the underlay directory location of openpower/isa (not openpower/isatables) and having the pandoc-plugin-program spot that. hm really we should be doing the same thing for *all* pseudocode(!)
submitted 09feb2024 as https://ftp.libre-soc.org/opf_ext_rfc/ls006.fpintmv.v2.09feb2024.pdf