while writing the 512x256-bit divmod algorithm for bug #1044, I discovered mcrxrx wasn't implemented properly, so, since it's pretty simple, I'm just implementing it and writing a unit test, since I want to use it. mcrxr is likewise not implemented properly, however it isn't part of PowerISA v3.1B, that encoding is marked reserved, so I'm just leaving it.
https://git.libre-soc.org/?p=openpower-isa.git;a=shortlog;h=37bb1fe61b26ed4957227af4224c4aeb4281624c commit 37bb1fe61b26ed4957227af4224c4aeb4281624c Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue Sep 26 20:34:39 2023 -0700 add unit test for mcrxrx commit 5a0517bba06e6b9fe62a435b3d0f067e36c2d120 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue Sep 26 20:34:25 2023 -0700 fix mcrxrx commit 4e1b994d20e3ae3a7db4491a17a762671c77a266 Author: Jacob Lifshay <programmerjake@gmail.com> Date: Tue Sep 26 20:28:16 2023 -0700 fix concat when the first argument is a FieldSelectableInt
(In reply to Jacob Lifshay from comment #0) > while writing the 512x256-bit divmod algorithm for bug #1044, I discovered > mcrxrx wasn't implemented properly, so, since it's pretty simple, I'm just > implementing it and writing a unit test, fantastic. > since I want to use it. ahh what for? can you put something about it on the mailing list and as usual crossref to bugreport(s) i have a sneaking suspicion you should be using sv.cr* and/or other svp64 operations, and it needs proper discussion. don't stop on bug #1044 as it will help illustrate by way of example if you explain what you are planning on doing with it. also the rules involving Vectorized full-CR operations are set but *not* implemented yet. another one on the massive TODO list, sigh. > mcrxr is likewise not implemented properly, however it isn't part of > PowerISA v3.1B, that encoding is marked reserved, so I'm just leaving it. can you please implement it anyway if it is part of v3.0 and not marked "reserved". investigations can be carried out later, we need to ensure that binutils and gcc have recognised it. otherwise we get
(In reply to Luke Kenneth Casson Leighton from comment #2) > (In reply to Jacob Lifshay from comment #0) > > mcrxr is likewise not implemented properly, however it isn't part of > > PowerISA v3.1B, that encoding is marked reserved, so I'm just leaving it. > > can you please implement it anyway if it is part of v3.0 and not marked > "reserved". investigations can be carried out later, we need to ensure > that binutils and gcc have recognised it. otherwise we get it's marked "reserved" on v3.0B, I didn't see a v3.0 on openpower.foundation the encoding is 1000000000 on EXT031 iirc I'm guessing you copied it from Microwatt when you made the CSVs, Microwatt as of f5e06c2d4 doesn't have it (anymore?).
(In reply to Jacob Lifshay from comment #3) > it's marked "reserved" on v3.0B, I didn't see a v3.0 on openpower.foundation > > the encoding is 1000000000 on EXT031 iirc okaaay. > I'm guessing you copied it from Microwatt when you made the CSVs, Microwatt > as of f5e06c2d4 doesn't have it (anymore?). can you check the verilator branch real quick? that's the one that is libresoc-compatible. i need time to recall some things from my long-term memory.
found it. you likely want sv.mcrf 125 # Move Condition Register Field 126 127 XL-Form 128 129 * mcrf BF,BFA but it needs checking/implementing under bug #1176 discuss on mailing list ok?
(In reply to Luke Kenneth Casson Leighton from comment #4) > > I'm guessing you copied it from Microwatt when you made the CSVs, Microwatt > > as of f5e06c2d4 doesn't have it (anymore?). > > can you check the verilator branch real quick? that's the one that is > libresoc-compatible. i need time to recall some things from my long-term > memory. no mcrxr there.
(In reply to Luke Kenneth Casson Leighton from comment #5) > found it. you likely want sv.mcrf > > 125 # Move Condition Register Field > 126 > 127 XL-Form > 128 > 129 * mcrf BF,BFA That's not what I want, what I want is to branch if CA is set/clear. no matter how much you move CRs around, you still need an insn that reads CA, not the CRs.
78 # Move to CR from XER Extended 79 80 X-Form 81 82 * mcrxrx BF 83 84 Pseudo-code: 85 86 CR[4*BF+32:4*BF+35] <- XER[OV] || XER[OV32] || XER[CA] || XER[CA32] ahhh i think i know what you're planning :)
(In reply to Jacob Lifshay from comment #7) > > That's not what I want, what I want is to branch if CA is set/clear. no > matter how much you move CRs around, you still need an insn that reads CA, > not the CRs. yep i totally grok it. very cool :) looking forward to seeing what you come up with in bug #1044