when LDST DDFF VLi was added and Pred-result removed (bug #1063) it allowed VLi to be promoted. two key updates are to sort out Normal VLi and crops VLi, which should move to the same Mode[0] bit for consistency. * TODO spec * TODO power decoder (sv rm extra) * TODO ISACaller unit tests * TODO power insndb * TODO binutils update actual table changes: note swapping of RG into new locations cr_ops 77 |6 | 7 |19:20|21 | 22:23 | description | 78 |--|---|-----|---|---------|------------------| 79 |/ | / |0 0 |RG | dz sz | simple mode | 80 |/ | / |1 0 |RG | dz sz | scalar reduce mode (mapreduce) | 81 |zz|SNZ|VLI 1|inv| CR-bit | Ffirst 3-bit mode | 82 |/ |SNZ|VLI 1|inv| dz sz | Ffirst 5-bit mode (implies CR-bit from result)| arithmetic/normal 50 | 0-1 | 2 | 3 4 | description | 51 | ------ | --- |---------|-------------------------- | 52 | 0 0 | 0 | dz sz | simple mode | 53 | 0 0 | 1 | RG 0 | scalar reduce mode (mapreduce) | 54 | 0 0 | 1 | / 1 | reserved | 55 | 1 0 | N | dz sz | sat mode: N=0/1 u/s | 56 | VLi 1 | inv | CR-bit | Rc=1: ffirst CR sel | 57 | VLi 1 | inv | zz RC1 | Rc=0: ffirst z/nonz | LD/ST-imm | 0 | 1 | 2 | 3 4 | description | |---|---| --- |---------|--------------------------- | |els| 0 | PI | zz LF | post-increment and Fault-First | |VLi| 1 | inv | CR-bit | ffirst CR sel | LD/ST-idx | 0 | 1 | 2 | 3 4 | description | |---|---| --- |---------|--------------------------- | |els| 0 | PI | zz SEA | simple mode | |VLi| 1 | inv | CR-bit | ffirst CR sel |
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=4e35f44f057adc516b137b03a29f0a476e097dc3 -| 0-1 | 2 | 3 4 | description | -| --- | --- |---------|-------------------------- | -| 00 | 0 | dz sz | simple mode | -| 00 | 1 | 0 RG | scalar reduce mode (mapreduce) | -| 00 | 1 | 1 / | reserved | -| 01 | inv | CR-bit | Rc=1: ffirst CR sel | -| 01 | inv | VLi RC1 | Rc=0: ffirst z/nonz | -| 10 | N | dz sz | sat mode: N=0/1 u/s | -| 11 | / | / / | reserved | +| 0-1 | 2 | 3 4 | description | +| ------ | --- |---------|-------------------------- | +| 0 0 | 0 | dz sz | simple mode | +| 0 0 | 1 | 0 RG | scalar reduce mode (mapreduce) | +| 0 0 | 1 | 1 / | reserved | +| 1 0 | N | dz sz | sat mode: N=0/1 u/s | +| VLi 1 | inv | CR-bit | Rc=1: ffirst CR sel | +| VLi 1 | inv | zz RC1 | Rc=0: ffirst z/nonz |
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=f3cfeda33bb90b218f6e7e8995553d4b0ceb044f RG and VLi move to bit 19 (Mode[0]) for consistency |6 | 7 |19:20|21 | 22:23 | description | |--|---|-----|---|---------|------------------| -|/ | / |0 RG | 0 | dz sz | simple mode | -|/ | / |0 RG | 1 | dz sz | scalar reduce mode (mapreduce) | -|zz|SNZ|1 VLI|inv| CR-bit | Ffirst 3-bit mode | -|/ |SNZ|1 VLI|inv| dz sz | Ffirst 5-bit mode (implies CR-bit from result) | +|/ | / |RG 0 | 0 | dz sz | simple mode | +|/ | / |RG 0 | 1 | dz sz | scalar reduce mode (mapreduce) | +|zz|SNZ|VLI 1|inv| CR-bit | Ffirst 3-bit mode | +|/ |SNZ|VLI 1|inv| dz sz | Ffirst 5-bit mode (implies CR-bit from result) |
CRops RG bit moved to 21 https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=cf79307700c7c83e78e861ccea01ba6b56ad1d8d
CROps VLi now in Mode[0], ff-selection is Mode[1] https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=8508b484f13ccf05916fa684f5a1bc47ad6196ad
darn it, the extra 2 bits re-using RM[6-7] for extending EXTRA2 to EXTRA3 in LD/ST-Update-Indexed for linked-list walking means that saturate no longer works. see bug #1047 124 | 0 | 1 | 2 | 3 4 | description | 125 |---|---| --- |---------|--------------------------- | 126 |els| 0 | PI | zz LF | post-increment and Fault-First | 127 |VLi| 1 | inv | CR-bit | ffirst CR sel |
(In reply to Luke Kenneth Casson Leighton from comment #5) > > 124 | 0 | 1 | 2 | 3 4 | description | > 125 |---|---| --- |---------|--------------------------- | > 126 |els| 0 | PI | zz LF | post-increment and Fault-First | > 127 |VLi| 1 | inv | CR-bit | ffirst CR sel | ok that's now sorted https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=2b73791a97be3ad0ed801b603659a323d50d21bf
https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=d39798d735c74e9b4cd2fd0c571ef231d482fb6b added post-increment mode to LD/ST-idx which was missing.
adding smask_extra332 to insndb: https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=9c0b57a next stage is to re-classify LD/ST-IDX
Until this is submitted, I suggest to drop this task for now and reallocate its budget somewhere else. Until we have a way to generate the fields for everything, including FFirst, this going to be a maintenance hell.
(In reply to Dmitry Selyutin from comment #9) > Until this is submitted, I suggest to drop this task for now and reallocate > its budget somewhere else. Until we have a way to generate the fields for > everything, including FFirst, this going to be a maintenance hell. unfortunately it can't be dropped, it's a critical part of the SVP64 specification. fortunately there are at least 18 months in which to get this task done.
(In reply to Luke Kenneth Casson Leighton from comment #10) > unfortunately it can't be dropped, it's a critical part of the SVP64 > specification. fortunately there are at least 18 months in which to get this > task done. > (In reply to Dmitry Selyutin from comment #9) > > for now > > Until we have a way to generate the fields Probably there's a misunderstanding. I don't suggest to drop this task forever. I understand this is required; my point is, maintaining it before we get all fields generated, is going to be a difficult task, and rather a useless one. And fields generation is impossible to be included in this MoU: we don't have a budget for that in scope of this MoU. So, my idea is, I'd like to postpone complex binutils modifications, generate the fields for libopid and keep the code there. And only then switch binutils to use the generated code from libopid. I'm fine with reallocating the budget to other tasks, not necessarily mine, that's what I was trying to express.
I promise I'll get to https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005633.html in the end of this week (holidays) to sort out everything I posted there.
(In reply to Dmitry Selyutin from comment #11) > So, my idea is, I'd like to postpone complex binutils modifications, > generate the fields for libopid and keep the code there. And only then > switch binutils to use the generated code from libopid. I'm fine with > reallocating the budget to other tasks, not necessarily mine, that's what I > was trying to express. ahh ok. *libopid* needs extra budget to include SVP64. ok i see. rrright. then can you cross-ref to here a "do svp64 in libopid" bug and it can be added as one of the potential "to be requested as part of 25% increase to OPF ISA WG MoU"? in which case yes *moving* this task to there or just subsuming it, would be a good idea.
(In reply to Luke Kenneth Casson Leighton from comment #13) > > in which case yes *moving* this task to there or just subsuming it, > would be a good idea. rright. ok. i had a bit of a think about this, and libopid does not yet have funding. it is a fantastic idea, i wish we had thought of it earlier but the base on which it stands (revision 2) is not stable. there is a computing adage "always plan for 3 revisions because that's what you end up doing anyway". revision 1, you don't know what you want, and you don't know how to do it. revision 2, you *do* know what you want, but don't know how to do it. revision 3, you *do* know what you want, *and* you know how to do it. libopid is phase 3 but we have not received any grant money to do the conversion of the ENTIRE CODEBASE over to it. this will need assessing and properly specifying as it is a LOT of work. revision 2 is where we are at and it *has* to be stabilised and completed before we can justify either VC investment, presenting to customers, presenting to the OPF ISA WG, or going to NLnet for further grant funding. as this feature is (DD FFirst) is absolutely critical to SV64 it has to be completed as a "phase 2" development.