see #1054 there is a table with the instructions that have been implemented and those that remain to be implemented. TODO list: <----- EDIT BELOW AND REPLACE "TODO" with "DONE" when complete * DONE - cffpr (doesn't include c[ft]fpr* aliases) * DONE - cffpro * DONE - ctfpr * DONE - ctfprs * DONE - divmod2du (needs fixing to use SFFS not POWER9) * DONE - fminmax (needs redoing) * DONE - mixmax (see comment #32) * DONE - mffpr * DONE - mffprs * DONE - mtfpr * DONE - mtfprs ---- IGNORE BELOW THIS LINE - FUTURE WORK, NEW BUG REPORT ----- Aliases that NEED DISCUSSION BEFORE AUTHORIZATION IS APPROVED * cffpr (note the lists of aliases for c[ft]fpr*: https://libre-soc.org/openpower/sv/rfc/ls006.fpintmv/) * cffpro * ctfpr * ctfprs Is in simulator but should NOT be added to binutils yet because they need to move to EXT2xx which has NOT been done in the simulator: lbzup lbzupx ldup ldupx lhaup lhaupx lhzup lhzupx lwaupx lwzup lwzupx stbup stbupx stdup stdupx sthup sthupx stwup stwupx just in openpower/isa/* mdwn files, but not otherwise implemented yet (you don't need to add them to binutils yet): ffdiv ffdivs ffmul ffmuls ffsub ffsubs Not in simulator (you don't need to add them to binutils yet): absaccs absaccu binlut crbinlut crrweird crternlogi crweirder fmv.swizzle fptstp fptstps grevlut grevluti lbzsx lbzuspx lbzusx ldbrsx ldsx lduspx ldusx lfdup lfdupsx lfdupx lfduxs lfdxs lfiwaxs lfiwzxs lfsup lfsuxs lfsxs lhasx lhauspx lhausx lhbrsx lhzsx lhzuspx lhzusx lsdupsx lsdupx lwasx lwauspx lwausx lwbrsx lwzsx lwzuspx lwzusx mcrfm mfcrweird mtcrrweird mtcrweird mv.swizzle stbsx stbuspx stbusx stdbrsx stdsx stduspx stdusx stfdup stfdupsx stfdupx stfduxs stfdxs stfiwxs stfsup stfsupsx stfsupx stfsuxs stfsxs sthbrsx sthsx sthuspx sthusx stwbrsx stwsx stwuspx stwusx
ghostman do you have a list of the scalar instructions supported? i believe this is it https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.c;h=2db4f415413ea120483e817f0a8675f3aa3e6c8c;hb=5f4e0b013934af256dff12620886355a8aa3ab3d btw an additional flag is needed 5094 #define SVP64 PPC_OPCODE_SVP64 5095 #define DRAFTSFFS PPC_OPCODE_DRAFT_SFFS and then all occurrences 5250 {"maddedu", VXA(4, 50), VXA_MASK, SVP64, PPCVLE, {RT, RA, RB, RC}}, replaced with 5250 {"maddedu", VXA(4, 50), VXA_MASK, DRAFTSFFS, PPCVLE, {RT, RA, RB, RC}}, i'll go through the list and add to optable.csv we can get a clear picture about what's needed here.
done, here's the list that needs redoing: minmax, ls013, high, 6, yes, EXT0xx, no, sv/av_opcodes, 2R1W1w, SFFS, REDO fminmax, ls013, high, 6, yes, EXT0xx, no, transcendentals, 2R1W1w, SFFS, REDO and the ones that need adding: absdu, TBD, TBD, 10, yes, TBD, no, sv/av_opcodes, 2R1W1w, SV/D, TODO absaccs, TBD, TBD, 10, yes, TBD, no, sv/av_opcodes, 3R1W1w, SV/D, TODO absaccu, TBD, TBD, 10, yes, TBD, no, sv/av_opcodes, 3R1W1w, SV/D, TODO crrweird, ls015, high, 8, yes, TBD, no, sv/cr_int_predication, 1r1W1w, SV/D, TODO mfcrweird, ls015, high, 8, yes, TBD, no, sv/cr_int_predication, 1r1W1w, SV/D, TODO mtcrrweird,ls015, high, 9, yes, TBD, no, sv/cr_int_predication, 1R1r1w, SV/D, TODO mtcrweird, ls015, high, 9, yes, TBD, no, sv/cr_int_predication, 1R1r1w, SV/D, TODO crweirder, ls015, high, 9, yes, TBD, no, sv/cr_int_predication, 2r1w, SV/D, TODO mcrfm, ls015, high, 9, yes, EXT0xx, no, sv/cr_int_predication, 2r1w, SFFS, TODO fptstp(s), TBD, high, 10, yes, EXT0xx, no, sv/fclass, 1R1w, SFFS, TODO fmvtg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fmvfg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fcvtfg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fcvttg(s), ls006, high, 9, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO dsld, ls003, high, 5, yes, EXT0xx, no, sv/biginteger, 3R2W1w, SFFS, TODO dsrd, ls003, high, 5, yes, EXT0xx, no, sv/biginteger, 3R2W1w, SFFS, TODO maddedus, ls003, high, 6, yes, EXT0xx, no, sv/biginteger, 3R2W, SFFS, TODO divmod2du, ls003, high, 6, yes, EXT0xx, no, sv/biginteger, 3R2W1w, SFFS, TODO ffadd(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffsub(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffmul(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffdiv(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO fdmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffmsub(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffnmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffnmsub(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO
I'm lost a bit between the list above and list here: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=1612a779c718fef1bec4f0384d4121119665f32e. I counted all additions (+ in patch), and got me 172 instructions. Do we intend to cover all of them in this task? Even considering that we already have some of these implemented, this is too huge task to be covered at once (even checking which we already covered and which need a flag change is a big task per se). Am I missing something? Also, a question of DRAFTFFS flag. Am I right that I need to filter instructions marked with "FFS" in "level" section of optable.csv? What do other levels mean (e.g. opt, SV/S, SV/D)? Do we need other flags?
(In reply to Dmitry Selyutin from comment #3) > I'm lost a bit between the list above and list here: > https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff; > h=1612a779c718fef1bec4f0384d4121119665f32e. > > I counted all additions (+ in patch), and got me 172 instructions. Do we > intend to cover all of them in this task? no absolutely not. i've already pre-filtered them. although it looked like i did it "quick" so it's good to ask, i did it "quick" because (a) i have been keeping an eye on this for months and (b) i'm on a deadline. > Also, a question of DRAFTFFS flag. Am I right that I need to filter > instructions marked with "FFS" in "level" section of optable.csv? no. it's literally a replace "SVP64" flag with "DRAFT_SFFS" in ppc_opc.c (because they're *all* Scalar SFFS instructions). > What do > other levels mean (e.g. opt, SV/S, SV/D)? see table key "Level" at https://libre-soc.org/openpower/sv/rfc/ls012/ more details here: https://libre-soc.org/openpower/sv/compliancy_levels/ Compliancy Levels that have been thought through from our side but have not been discussed or approved by the OPF ISA WG. > Do we need other flags? not right now.
(In reply to Luke Kenneth Casson Leighton from comment #4) > (In reply to Dmitry Selyutin from comment #3) > > I'm lost a bit between the list above and list here: > > https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff; > > h=1612a779c718fef1bec4f0384d4121119665f32e. > > > > I counted all additions (+ in patch), and got me 172 instructions. Do we > > intend to cover all of them in this task? > > no absolutely not. i've already pre-filtered them. OK, so I need to go through list at https://bugs.libre-soc.org/show_bug.cgi?id=1068#c2 and fix flags, right? More on the flags below. > although it looked > like i did it "quick" so it's good to ask, i did it "quick" because > (a) i have been keeping an eye on this for months and (b) i'm on a > deadline. Ah no, actually my suspicions were based on a simpler ground: comment here predates the comment in another task. So I suspected the more recent one is the one I should consider most. :-) https://bugs.libre-soc.org/show_bug.cgi?id=1068#c2 https://bugs.libre-soc.org/show_bug.cgi?id=1054#c3 > > Also, a question of DRAFTFFS flag. Am I right that I need to filter > > instructions marked with "FFS" in "level" section of optable.csv? > > no. it's literally a replace "SVP64" flag with "DRAFT_SFFS" in ppc_opc.c > (because they're *all* Scalar SFFS instructions). Ah, my bad. I thought that we need only consider stuff with SFFS in level column, and considered things like setvl or svstep or svremap being marked as `PPC_OPCODE_SVP64`. If not, I don't even understand when we need `PPC_OPCODE_SVP64`, other than checking that some instructions start with "sv." in asm and disassembly magically handles the prefix. Please confirm if the latter statement is correct. :-) > > Do we need other flags? > > not right now. So, if I understand correctly, -mlibresoc activates both PPC_OPCODE_SVP64 and PPC_OPCODE_DRAFT_SFFS (perhaps both should be called "draft"). PPC_OPCODE_DRAFT_SFFS can also be activated via -mdraft-sffs. Should we also have -mdraft-svp64 which activates PPC_OPCODE_DRAFT_SVP64 but not PPC_OPCODE_DRAFT_SFFS?
After sorting and checking the list, I got these entries: absaccs, TBD, TBD, 10, yes, TBD, no, sv/av_opcodes, 3R1W1w, SV/D, TODO absaccu, TBD, TBD, 10, yes, TBD, no, sv/av_opcodes, 3R1W1w, SV/D, TODO crrweird, ls015, high, 8, yes, TBD, no, sv/cr_int_predication, 1r1W1w, SV/D, TODO mfcrweird, ls015, high, 8, yes, TBD, no, sv/cr_int_predication, 1r1W1w, SV/D, TODO mtcrrweird,ls015, high, 9, yes, TBD, no, sv/cr_int_predication, 1R1r1w, SV/D, TODO mtcrweird, ls015, high, 9, yes, TBD, no, sv/cr_int_predication, 1R1r1w, SV/D, TODO crweirder, ls015, high, 9, yes, TBD, no, sv/cr_int_predication, 2r1w, SV/D, TODO mcrfm, ls015, high, 9, yes, EXT0xx, no, sv/cr_int_predication, 2r1w, SFFS, TODO fptstp(s), TBD, high, 10, yes, EXT0xx, no, sv/fclass, 1R1w, SFFS, TODO fmvtg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fmvfg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fcvtfg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fcvttg(s), ls006, high, 9, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO dsld, ls003, high, 5, yes, EXT0xx, no, sv/biginteger, 3R2W1w, SFFS, TODO dsrd, ls003, high, 5, yes, EXT0xx, no, sv/biginteger, 3R2W1w, SFFS, TODO maddedus, ls003, high, 6, yes, EXT0xx, no, sv/biginteger, 3R2W, SFFS, TODO ffadd(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffsub(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffmul(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffdiv(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO fdmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffmsub(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffnmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffnmsub(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO So, with 25 instructions, it seems to be doable in a reasonable time. :-)
fptstp(s), TBD, high, 10, yes, EXT0xx, no, sv/fclass, 1R1w, SFFS, TODO fmvtg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fmvfg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fcvtfg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO fcvttg(s), ls006, high, 9, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, TODO These don't appear to be present in openpower-isa repos. Are they some kind of aliases? ffadd(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffsub(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffmul(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO ffdiv(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, TODO fdmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffmsub(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffnmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO ffnmsub(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, TODO Shouldn't these (and also listed above) be present amongst FPTRANS_INSNS?
(In reply to Dmitry Selyutin from comment #6) > After sorting and checking the list, I got these entries: > > absaccs, TBD, TBD, 10, yes, TBD, no, sv/av_opcodes, 3R1W1w, SV/D, > TODO can you please check they are in this table as either "TODO" or "REDO"? https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/rfc/ls012/optable.csv;hb=HEAD sorry i should have mentioned that file earlier. > So, with 25 instructions, it seems to be doable in a reasonable time. :-) indeed.
(In reply to Dmitry Selyutin from comment #7) > fptstp(s), TBD, high, 10, yes, EXT0xx, no, sv/fclass, 1R1w, SFFS, TODO > fmvtg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, > TODO > fmvfg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, > TODO > fcvtfg(s), ls006, high, 10, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, > TODO > fcvttg(s), ls006, high, 9, yes, EXT0xx, no, sv/int_fp_mv, 1R1W1w, SFFS, > TODO > > These don't appear to be present in openpower-isa repos. Are they some kind > of aliases? no, rats. ok leave them off for now - jacob needs to implement them in ISACaller. let me track down an appropriate bugreport/budget for that (edit: bug #1072) > ffadd(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, > TODO > ffsub(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, > TODO > ffmul(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, > TODO > ffdiv(s), TBD, med, 10, yes, EXT2xx, no, isa/svfparith, 2R1W1w, opt, > TODO > fdmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, > TODO > ffmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, > TODO > ffmsub(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, > TODO > ffnmadd(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, > TODO > ffnmsub(s), TBD, med, 5, yes, EXT2xx, no, isa/svfparith, 3R2W1w, opt, > TODO these are not transcendentals, they are DCT and FFT butterfly instructions. > Shouldn't these (and also listed above) be present amongst FPTRANS_INSNS? no, they're "move and/or convert" instructions intended to be mandatory additions to SFFS.
(In reply to Luke Kenneth Casson Leighton from comment #8) > > can you please check they are in this table as either "TODO" or "REDO"? > https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/rfc/ls012/ > optable.csv;hb=HEAD All these instructions are here, with "TODO" in binutils section. I thought you take this list from that file, I only checked whether some entries are already handled in binutils (absdu, divmod2du) or if they are not present in openpower-isa (https://bugs.libre-soc.org/show_bug.cgi?id=1068#c7).
(In reply to Dmitry Selyutin from comment #6) > After sorting and checking the list, I got these entries: Correction: I've checked the rest in openpower-isa semi-automatically (basically checking which entries are determined by insndb and then manually inspecting the repo). Below are my findings. The list of what we have now is even shorter. Here are instructions which were identified by insndb and can be used as candidates for binutils at this stage: dsld dsrd maddedus divmod2du minmax absdu ffmsubs ffmadds ffnmsubs ffnmadds fdmadds ffadds Below is the list of missing instructions, with few comments where relevant, no comments imply there're no traces of the instruction at all: fminmax -- only mentioned in fields.text absaccs absaccu crrweird mfcrweird mtcrrweird mtcrweird crweirder mcrfm fptstp fptstps fmvtg fmvtgs fmvfg fmvfgs fcvtfg fcvtfgs fcvttg fcvttgs ffadd -- only present in svfparith.mdwn, but has no relevant CSVs ffsub -- only present in svfparith.mdwn, but has no relevant CSVs ffmul -- only present in svfparith.mdwn, but has no relevant CSVs ffmuls -- present in svfparith.mdwn and power_enums.py, but has no relevant CSVs ffdiv -- only present in svfparith.mdwn, but has no relevant CSVs ffdivs -- present in svfparith.mdwn and power_enums.py, but has no relevant CSVs fdmadd fdmadds ffmadd -- only present in comment in power_decoder2.py ffmsub ffnmadd ffnmsub
(In reply to Dmitry Selyutin from comment #11) > (In reply to Dmitry Selyutin from comment #6) > > After sorting and checking the list, I got these entries: > > The list of what we have now is even shorter. Here are instructions which > were identified by insndb and can be used as candidates for binutils at this > stage: > > dsld > dsrd > maddedus > divmod2du > minmax > absdu > ffmsubs > ffmadds > ffnmsubs > ffnmadds > fdmadds > ffadds > Already present in binutils: divmod2du absdu
Summary. At this point, I'm able to support these: dsld dsrd maddedus minmax ffmsubs ffmadds ffnmsubs ffnmadds fdmadds ffadds This narrows the scope of this task for now, until opcodes are allocated and all relevant entries are present in openpower-isa.
(In reply to Dmitry Selyutin from comment #13) > Summary. At this point, I'm able to support these: > > dsld > dsrd > maddedus Don't know about Luke, but having these big integer instructions implemented first would probably be better (for modulo arithmetic and cryptography examples).
Added 5 more instructions: dsld dsrd maddedus minmax Others are on the way: ffmsubs ffmadds ffnmsubs ffnmadds fdmadds ffadds
All instructions we have supported in openpower-isa are added into binutils with appropriate tests. Missing instructions: https://bugs.libre-soc.org/show_bug.cgi?id=1068#c11 Supported instructions: https://bugs.libre-soc.org/show_bug.cgi?id=1068#c12 Commits: https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=e25f217f597e0a5d6636393809d1d20b6feccaeb https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=2407ce0f84ed13e6a26aa9ed8b22aa743fa83c85 https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=1a29a82850b8d86a7fa10b65fa9a6f3fa562e0af https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=a95be49abd8e8c6fd6be73e080299137fb1ec302 https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=82cb420cc9c84af21c1df9f41359d4196579a570 https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=4e5d79912f8170a1b2cba8ffbd204cb5e0eab571 https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=411ad54b47e7c35de305b6c780d0b098a7bffae3 https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=aa0f4778e6d3745fc1dde9a1b634a560f3f6e921 https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=bbfbfc4773a5ac25a3995b8339496093ce8cced7 https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=c2e8d9d8dc2f84fb3473d6315480e11ea85e4909 Also now binutils support SFFS flag and new options, -mdraft-sffs and -mdraft-svp64, both are included by -mlibresoc: https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=5f2e46af4ef4222a5172e7b69c486cef3d03c2d5
Luke, two remarks: 1. Should we split this task and budget into two parts since not all instructions are covered yet due to the fact these are not present in our repos? 2. You committed some updates on CSV/mdwn part, I'd be glad if you could join this little festival of life budget-wise. :-)
(In reply to Dmitry Selyutin from comment #16) > > Also now binutils support SFFS flag and new options, -mdraft-sffs and > -mdraft-svp64, both are included by -mlibresoc: > https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff; > h=5f2e46af4ef4222a5172e7b69c486cef3d03c2d5 fantastic! like it. (In reply to Dmitry Selyutin from comment #17) > Luke, two remarks: > 1. Should we split this task and budget into two parts since not all > instructions are covered yet due to the fact these are not present in our > repos? hmm hmm ok yes. there are some other things need doing: moving eeverything to PO9 is one of them. that's a big change, has to be done all at once. > 2. You committed some updates on CSV/mdwn part, I'd be glad if you could > join this little festival of life budget-wise. :-) :) sure.
Off-topic: I had to change the nickname since budget-sync has no idea who is ghostman. But it's funny that Luke dropped these two exact letters: ghostman was exactly my nickname many years ago, until I discovered the Internet and found there already were multiple folks with this exact nickname. :-) "sd" actually stands for the combination of the first letters of my real second name and first name, just the first suffix which came to my mind when I wanted to update the nickname. A funny coincidence.
minmax / fminmax still TODO...
Just to clarify. fminmax is in TODO because not yet present in openpower-isa repo (thus there's no etalon for binutils) minmax IS done; it's just minXX/maxXX instructions need redoing (but it has not been mentioned in the task, I found it occasionally in IRC, perhaps it's mentioned somewhere else)
minmax aliases support is introduced to binutils. https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=f2cb631dd73096751e1af8e116b091ebbdb04aad Please note that, like with branches, this means that disassembly tends to prefer aliases, not the vanilla instruction, which is checked by the tests I implemented (see link above). For example, `minmax 31,0,0,0` will always be shown as `minu r31,r0,r0` by objdump, and this is intentional. Also, this is one of the rare (IIRC the first) time when I feel the task was completely underrated budget-wise. From binutils point of view, all these are distinct instructions, and it takes a lot of time to process these (2 instructions, 16 aliases, 48 tests). If we have more similar cases, I suggest that we either: a) estimate these tasks as if these instructions are distinct (because they indeed are); b) implement some mechanism inside insndb to deal with aliases based on some sort of configuration, because otherwise these things take too much time. As I understand, there's at least one more case of such aliasing, fminmax; I suspect grevlut should also have aliases. Any other victims?
(In reply to Dmitry Selyutin from comment #22) > minmax aliases support is introduced to binutils. > https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff; > h=f2cb631dd73096751e1af8e116b091ebbdb04aad manually verified, looks good!
A side note about "bring aliases support to insndb": it seems that we will have to do it anyway, or at least we will have to put all such aliases into the CSV. I'd prefer to introduce some separate configuration, perhaps ini-like, which is designed specifically for aliases. lkcl, programmerjake, what do you think?
(In reply to Dmitry Selyutin from comment #24) > A side note about "bring aliases support to insndb": it seems that we will > have to do it anyway, or at least we will have to put all such aliases into > the CSV. > lkcl, programmerjake, what do you think? please wait until the next revision of Power ISA tech ref manual is release. i cannot say more on this topic that is Confidential.
Any updates on MoU for this task?
Kind reminder... :-)
(In reply to Dmitry Selyutin from comment #26) > Any updates on MoU for this task? i need to schedule a conversation with Michiel to review the Schedule A in https://bugs.libre-soc.org/show_bug.cgi?id=961#c0 (this is because it is a EUR 100,000 grant, so they have a dedicated EU Auditor for it). let's keep questions about this on IRC?
I checked all the instructions in ls012/optable.csv against the simulator and the svp64 branch of binutils. I edited the top comment to include my results. I also noticed that divmod2du is marked in ppc-opc.c to be in POWER9, not SFFS, so that needs to be fixed. I also fixed some typos I discovered in optable.csv: commit ab5a378226a7c61eb6b0f7b836ea6772a09bca53 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Aug 3 17:16:18 2023 -0700 fix missing p in post-increment load/stores commit 2ce44491fc7ba280b7ff7bd5a5ea35282922d886 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Thu Aug 3 16:55:15 2023 -0700 rename shadd* -> sadd* in ls012/optable.csv to match ls004 Including the full opcode list here too for future reference: divmod2du (needs fixing to use SFFS not POWER9) In simulator but not binutils: cffpr cffpro ctfpr ctfprs ffdiv ffdivs ffmul ffmuls ffsub ffsubs fminmax lbzup lbzupx ldup ldupx lhaup lhaupx lhzup lhzupx lwaupx lwzup lwzupx mffpr mffprs mtfpr mtfprs stbup stbupx stdup stdupx sthup sthupx stwup stwupx Not in simulator: absaccs absaccu binlut crbinlut crrweird crternlogi crweirder fmv.swizzle fptstp fptstps grevlut grevluti lbzsx lbzuspx lbzusx ldbrsx ldsx lduspx ldusx lfdup lfdupsx lfdupx lfduxs lfdxs lfiwaxs lfiwzxs lfsup lfsuxs lfsxs lhasx lhauspx lhausx lhbrsx lhzsx lhzuspx lhzusx lsdupsx lsdupx lwasx lwauspx lwausx lwbrsx lwzsx lwzuspx lwzusx mcrfm mfcrweird mtcrrweird mtcrweird mv.swizzle stbsx stbuspx stbusx stdbrsx stdsx stduspx stdusx stfdup stfdupsx stfdupx stfduxs stfdxs stfiwxs stfsup stfsupsx stfsupx stfsuxs stfsxs sthbrsx sthsx sthuspx sthusx stwbrsx stwsx stwuspx stwusx
(In reply to Jacob Lifshay from comment #29) > I checked all the instructions in ls012/optable.csv against the simulator > and the svp64 branch of binutils. I edited the top comment to include my > results. I also noticed that divmod2du is marked in ppc-opc.c to be in > POWER9, not SFFS, so that needs to be fixed. I checked by grepping against openpower-isa.git/openpower/isa and against binutils-gdb.git/opcodes/ppc-* > > I also fixed some typos I discovered in optable.csv: forgot the link: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=ab5a378226a7c61eb6b0f7b836ea6772a09bca53;hp=b5086c72247de1a02b129fa101bbfead502edc9e > > commit ab5a378226a7c61eb6b0f7b836ea6772a09bca53 > Author: Jacob Lifshay <programmerjake@gmail.com> > Date: Thu Aug 3 17:16:18 2023 -0700 > > fix missing p in post-increment load/stores > > commit 2ce44491fc7ba280b7ff7bd5a5ea35282922d886 > Author: Jacob Lifshay <programmerjake@gmail.com> > Date: Thu Aug 3 16:55:15 2023 -0700 > > rename shadd* -> sadd* in ls012/optable.csv to match ls004
(In reply to Luke Kenneth Casson Leighton from comment #2) > done, here's the list that needs redoing: > > minmax, ls013, high, 6, yes, EXT0xx, no, sv/av_opcodes, 2R1W1w, SFFS, REDO jacob is this still the case? > fminmax, ls013, high, 6, yes, EXT0xx, no, transcendentals, 2R1W1w, SFFS, REDO that one's on the list in comment #0, i'll mark it as "redo"
(In reply to Luke Kenneth Casson Leighton from comment #31) > (In reply to Luke Kenneth Casson Leighton from comment #2) > > done, here's the list that needs redoing: > > > > minmax, ls013, high, 6, yes, EXT0xx, no, sv/av_opcodes, 2R1W1w, SFFS, REDO > > jacob is this still the case? not anymore afaict from looking at opcodes/ppc_opc.c.
I certainly remember the list was smaller when we started this task. :-) All these instructions were missing initially IIRC. List of commits already done in scope of this task: https://bugs.libre-soc.org/show_bug.cgi?id=1068#c16 https://bugs.libre-soc.org/show_bug.cgi?id=1068#c22 I'm concerned that the list of instructions keeps extending, unlike the budget. :-) If the budget can be updated or reallocated, that'd be great. I obviously consider other binutils tasks we have here; I'm looking at 1003 and 1079. Also, I'd really like to establish the list of instructions for the scope of _this_ exact task. I'd really like to avoid situation this task is postponed whenever new instruction is added into the simulator. Any ideas on how to make it work? Meanwhile I'm checking how to support TODO list, but even this one is big enough (especially considering that these might have Rc-Oe-enabled versions and/or custom operands types).
It seems that some of fptrans got commented out, most notably fmin/fmax. I see that fminmax are marked as "needs redoing". What exactly should be done here? Judging from minor_59.csv, I should drop these from binutils. What's worse, some of these occupied the same range where other instructions from TODO list should reside. The comment #33 is even more relevant than I initially thought. It seems that instructions changed a lot since we've started this task, and things keep changing.
(In reply to Dmitry Selyutin from comment #34) > It seems that some of fptrans got commented out, most notably fmin/fmax. I > see that fminmax are marked as "needs redoing". What exactly should be done > here? fmin*/fmax* have been replaced with fminmax just like min/max were replaced with minmax. so fmin*/fmax* need to have their encodings changed to be aliases of fminmax and fminmax needs to be added. > Judging from minor_59.csv, I should drop these from binutils. What's > worse, some of these occupied the same range where other instructions from > TODO list should reside. iirc those new insns are using the encodings where the old fmin*/fmax* encodings were. > The comment #33 is even more relevant than I initially thought. It seems > that instructions changed a lot since we've started this task, and things > keep changing. yeah, we should pick a cutoff and move all further changes to a new task with new budget (making sure to not lose any TODO list entries even if they're not ready for binutils yet). I'll let luke decide where that cutoff should be.
`(ffdiv|ffmul|ffsub).+` are only present in svfparith.mdwn; CSVs are not present.
(In reply to Dmitry Selyutin from comment #36) > `(ffdiv|ffmul|ffsub).+` are only present in svfparith.mdwn; CSVs are not > present. adjusted the top comment to account for that.
> I'm concerned that the list of instructions keeps extending, unlike the > budget. :-) Jacob does not have project/time-management capability and persistently fails to accept this. Please do not take Jacob's "and another thing" additional comments as IN ANY WAY authoritative. He is brilliant at technical tasks that are defined and extremely useful for helping out with research and insights, but if YOU have an assigned task YOU are in charge of it. > Also, I'd really like to establish the list of instructions for the scope of > _this_ exact task. Focus on comment #0 the short list of appx 12-15 instructions. Ignore absolutely everything else. > I'd really like to avoid situation this task is postponed > whenever new instruction is added into the simulator. or ones that have not been added yet, I removed all of those from the list that Jacob created (and edited comment #0 without authorization) > Any ideas on how to make it work? > Meanwhile I'm checking how to support TODO Click the "edit" on the comment, edit the text and put the word "TODO" in front of what needs doing. I will now edit comment #0 so you know obviously how that works. When completed edit it as DONE instead of TODO. > list, but even this one is big enough (especially considering that these > might have Rc-Oe-enabled versions and/or custom operands types). hmmm... Keep in touch how far you get. Reminder (again), this project operates on the basis of REDEFINING tasks so that they are "fair". we DO NOT expect and HAVE NEVER expected ANYONE to do more work than the fixed budget allows. If you feel that you have not been paid enough STOP WORK, raise it on IRC, and move the rest to a new bug report where we can allocate more funds LATER under another NLnet Grant. (or if urgent find a sub-sub-budget somewhere)
(In reply to Dmitry Selyutin from comment #34) > It seems that some of fptrans got commented out, most notably fmin/fmax. I > see that fminmax are marked as "needs redoing". What exactly should be done > here? Judging from minor_59. I should drop these from binutils. What's > worse, some of these occupied the same range where other instructions from > TODO list should reside. this gives you a clue as to why they were commented out from fptrans. Basically if insndb does not list them, they don't go in. This task is real simple: Sync binutils with insndb. That's all. Some good investigation by Jacob established that this leaves only 12-15 instructions difference.
elaborated on which exact c[ft]fpr* instructions have aliases (all of them, not just cffpr)
The instructions are synced: https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=323e75a0215c2b3da2d97ee6024797d04a9e1385 Due to time and budget constraints, I've put this sync into a single commit and left tests out of it. Considering the previous changes already done in the scope of this task, I hope nobody objects if other activities are performed in the scope of the new tasks. I found it extremely annoying to add aliases for minmax and fminmax (not much time, but highly error-prone). Any objections if I raise the task for introducing a special format for aliases? I remember a discussion where Luke pointed that we were not ready for aliases, but it's the second time I've added these. :-)
(In reply to Dmitry Selyutin from comment #41) > The instructions are synced: > https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff; > h=323e75a0215c2b3da2d97ee6024797d04a9e1385 > > Due to time and budget constraints, I've put this sync into a single commit > and left tests out of it. Considering the previous changes already done in > the scope of this task, I hope nobody objects if other activities are > performed in the scope of the new tasks. not at all. > I found it extremely annoying to add aliases for minmax and fminmax they weren't on the TODO list in comment #0 so should not have been added. the reason is (as you noted above) there's no unit tests... because *pypowersim* does not support aliases, therefore we cannot even test them (as part of openpower-isa unit tests). > much time, but highly error-prone). Any objections if I raise the task for > introducing a special format for aliases? none at all - please cross-reference it ("See also") to this bugreport and put it on "Future" milestone. when we come to putting in *another* NLnet Grant, the list can be reviewed and it not forgotten. also i cannot explain why but there are reasons (confidential to the ISA WG) why adding aliases should be delayed until an announcement is made by the ISA WG. (i am NOT authorized to give out OPF confidential information but i can at least say "i am not authorized but there are reasons"). > I remember a discussion where Luke > pointed that we were not ready for aliases, correct. below explains why. > but it's the second time I've > added these. :-) if they cannot be tested (no openpower-isa unit tests, rather than binutils tests) then many apologies but they need to be removed (from this patch, as they were never to be part of this task). when *another* NLnet Grant is done (which we can only do when at least one of these outstanding ones is completed) *then* we can look at: 1) define the aliases format 2) define a *database* format for them and implement them in insndb 3) add aliases in pypowersim 4) UNIT TESTS for aliased instructions in openpower-isa and FINALLY - ONLY THEN: 5) adding binutils support for the same aliases AND THEN 6) add unit tests for the same aliases in binutils AND THEN 7) run the same unit tests for openpower-isa but using binutils which is about... a minimum of... EUR 15,000 worth of additional work that is *not* accounted for in *any* of the current EUR 300,000 of NLnet grants? i trust that this is now really clear that aliases were not, shall not, cannot and will NEVER be part of the *current* scope of work within at least the next 4-6 months, until we have completed sufficient of the EUR **300,000** worth of existing outstanding uncompleted NLnet grants, to be able to put in another one? (as you can see i am able to think in terms of breaking tasks down to this level where time and budget can be allocated to them within reasonable estimates. Jacob is *not* capable of doing that: he will add "and this needs doing. and that's a good idea. and this other thing needs to be done" - in one extreme case a task allocated to him with a 10 day budget i let him get on with it for 5 *months* before reminding him that the budget was 10 days and he hadn't done *any* of what was actually required for the actual payment from NLnet - to teach him the hard lesson that he needs to learn about focus, time, scoping, and budget management.
The binutils are synced, aliases are dropped too: https://git.libre-soc.org/?p=binutils-gdb.git;a=blobdiff;f=opcodes/ppc-opc.c;h=c01f374c0dfb6dfa9c60c9da71ebf4977d677f2f;hp=e2e141bf1e12915e79ac1905ff0d61398ce510ee;hb=e7bb4e1e6a96909ffe3caf466d2f23afb99aee01;hpb=77725ba0fd9a65117497684b0ae6845a9f8d9f5f I believe this puts an end to this task. Any objections?
(In reply to Dmitry Selyutin from comment #43) > I believe this puts an end to this task. Any objections? awesome. none from me. will ping nlnet again.