| Summary: | create IEEE754 FP Pipelines and decoder for TestIssuer | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Luke Kenneth Casson Leighton <lkcl> |
| Component: | Source Code | Assignee: | Luke Kenneth Casson Leighton <lkcl> |
| Status: | IN_PROGRESS --- | ||
| Severity: | enhancement | CC: | andy.miroshnikov, libre-soc-bugs, programmerjake, toshaan |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.libre-soc.org/show_bug.cgi?id=961 | ||
| NLnet milestone: | Future | total budget (EUR) for completion of task and all subtasks: | 40000 |
| budget (EUR) for this task, excluding subtasks' budget: | 40000 | parent task for budget allocation: | 487 |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: | ||
| Bug Depends on: | 1134, 1136, 1137 | ||
| Bug Blocks: | 1072 | ||
|
Description
Luke Kenneth Casson Leighton
2023-03-15 16:42:14 GMT
(In reply to Luke Kenneth Casson Leighton from bug #1072 comment #8) > (In reply to Jacob Lifshay from bug #1072 comment #7) > > > all I need is just the register with accessible fields, > > copy the style here > https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/ > decoder/isa/svstate.py;hb=HEAD Done, though I may have gone a little overboard -- I added a parser that parses the fields from the doc comment to ensure they always match. One benefit is it can probably be easily adapted to whatever Latex table thing has the field definitions whenever the OpenPower Foundation releases the spec source. https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=bb7069cee706f7fbc75dc7cafec3afe19cd87e02;hp=c8b2c5d2c984cc444880187679c2a9589bae0526 commit bb7069cee706f7fbc75dc7cafec3afe19cd87e02 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Fri May 5 20:38:22 2023 -0700 fix fpscr table parser error reporting commit bef52a38023bfce850174a3156d61170f767dd01 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Fri May 5 20:34:18 2023 -0700 add FPSCRState and FPSCRRecord and a FPSCR smoke-test > > i will followup by adding it to ISACaller. Thanks! (In reply to Jacob Lifshay from comment #1) > https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff; > h=bb7069cee706f7fbc75dc7cafec3afe19cd87e02; > hp=c8b2c5d2c984cc444880187679c2a9589bae0526 + + @property + def DRN(self): + return self.fsi['DRN'].asint(msb0=True) + + @DRN.setter + def DRN(self, value): + self.fsi['DRN'].eq(value) + please remove all of those and replace them with dynamic functions added within the for-loop. there are far too many and you should have immediately red-flagged the fact that they are a regular pattern (60+ identical duplications of the above lines with different 'DRN') python is not rust or java. use a simple override on __getattr__ and __setattr__ do not waste time creating metaclasses (or override __dir__) https://amir.rachum.com/python-dynamic-attributes/ we do not want complex concepts nor unintelligable code nor vast quantities of unmaintainable code. (In reply to Luke Kenneth Casson Leighton from comment #2) > please remove all of those and replace them with > dynamic functions added within the for-loop. I put them in there because that's what you did for SVSHAPE https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/svshape.py;hb=d40763cd6e186ad9b17ce6f974a38b4c4877965e I can remove them if you like... I adjusted the costs for different tasks, and figured out what would fit in our EUR 8000 budget (it ended up excluding all Libre-SOC instructions, so I think some of those should just be moved to #1026 where we explicitly have a budget for Libre-SOC instructions) I picked: * add FPSCR and rounding-mode definitions to ieee754fpu already done * add FPSCR and FP registers and dependency-tracking to soc.git needed for everything else * add PowerISA SINGLE/DOUBLE conversion functions needed for nearly everything else * add FP loads to soc.git we need a way to get data in/out of FP registers and loads/stores are what compilers currently use (they don't support m[ft]fpr yet) * add FP stores to soc.git same as FP loads reasoning * FP move/sign-bit-manipulation data in registers needs to move around * FP add/sub common and fits in budget * FP select exactly fits in EUR 400 left over from everything else * FPSCR manipulation we need a way to get data in/out of FPSCR (In reply to Jacob Lifshay from comment #3) > (In reply to Luke Kenneth Casson Leighton from comment #2) > > please remove all of those and replace them with > > dynamic functions added within the for-loop. > > I put them in there because that's what you did for SVSHAPE yes but not 64 individual bits resulting in 250+ lines of duplicated code easily autogenerated. > I can remove them if you like... no it's too late now, done and a waste of time removing them, despite being a maintenance nightmare. to be honest these should all be done by insndb, which is a big enough task to justify its own budget, and autogenerating nmigen Record-derivatives as well. (In reply to Jacob Lifshay from comment #4) > I adjusted the costs for different tasks, and figured out what would fit in > our EUR 8000 budget (it ended up excluding all Libre-SOC instructions, so I > think some of those should just be moved to #1026 where we explicitly have a > budget for Libre-SOC instructions) not sure yet. see how it goes. > I picked: .... it is a good start, gives the general idea of cost, but is missing preparation (please find where i described it already) and regfile profile analysis and documentation. also adding regfiles, and prep code to initialise then extract them in the TestAPI. and adding config params, and adding TestIssuer options, all the way to Makefile to compile with or without FP. > * add FP loads to soc.git > we need a way to get data in/out of FP registers ignore LD/ST initially and have the unit tests pre-arrange values in regs. i had to add that for GPRs, and so adding the ability to up!oad into FPRs prior to starting the nmigen sim is *another* task on the list. please follow the following incremental strategy as top-level bugs: * add FPR regfile **ONLY** plus do the pipeline reg allocation analysis. grep all code for "IntRegs" and duplicate all sections, then document the proposed pipeline reg allocation. - fneg will be in 1R1W (plus FPSCR plus CR1, read and write) - fmac in 3R1W (plus FPSCR CR1) - fadd *also* consider in 3R1W but with mul as "no input". - fld/fst as another (bear in mind these are special-case) * do the 1in1out as one bug "group" * do 3r1w as another * do LD/ST as another * add FPSCR and CR1 to all pipelines *as a totally separate set of tasks* with their own toplevel budget. reason: look in common_input and output_stage.py, the same can be done for CR1 / FPSCR. FPSCR regfile can copy XERRegs style. this will give a coarse granularity that NLnet will be happier with, and is a safer incremental approach. i did think of another way (another subdivision) but i can't remember it
this morning. oh yes!
* pipeline (+tests)
* CompUnit (+tests using classes as used in test_caller_*)
* FunctionUnit (+tests using same classes)
* Core integration (test_core.py - needs FP option)
* TestIssuer integration (test_issuer.py - needs option(s) plural)
the *exact* same unit tests - many of which have already been written
for use by test_caller*.py - can if generalised be used the entire way,
*four* new (additional) times.
i got test_core.py up and running again last time i looked at this
(when doing the InOrder core).
|