| ghostmansd[m] | It striked me today that ff/pr and dm/sm/m share same predicates so I can unify some code together. Actually, I must check than only CR predicates are allowed in ff/or (plus RC1/~RC1, but this is yet another story). | 07:32 |
|---|---|---|
| ghostmansd[m] | Actually this works like this: allow everything but RC1/~RC1 for dm/sm/m, and allow only CRs/RC1/~RC1 for ff/pr. | 07:42 |
| ghostmansd[m] | So I encoded all this information into one big table. | 07:42 |
| ghostmansd[m] | So I ended up with 16 insertions and 113 deletions in patch. Not bad. | 07:43 |
| ghostmansd[m] | Also fixed an infinite recursion in expr parser I introduced. If you define md_operand routine (and we did it for handling vector * notation), you have to be damn careful. | 07:48 |
| lkcl | ff and pr are modes, they do not take arguments. | 10:53 |
| lkcl | wait... ff yes, takes the same predicate-mode bits | 10:57 |
| * lkcl checking pr | 10:57 | |
| lkcl | 11invCR-bitRc=1: pred-result CR sel | 10:58 |
| lkcl | yes that takes the same predicate-mode bits as well | 10:59 |
| lkcl | sorry! | 10:59 |
| lkcl | 01invCR-bitRc=1: ffirst CR sel | 10:59 |
| lkcl | for fail-first | 10:59 |
| lkcl | https://libre-soc.org/openpower/sv/normal/ | 10:59 |
| lkcl | The Mode table for Arithmetic and Logical operations is laid out as follows: | 10:59 |
| lkcl | 0-123 4description | 10:59 |
| lkcl | 01invCR-bitRc=1: ffirst CR sel | 10:59 |
| lkcl | 01invVLi RC1Rc=0: ffirst z/nonz | 11:00 |
| lkcl | 11invCR-bitRc=1: pred-result CR sel | 11:00 |
| lkcl | 11invzz RC1Rc=0: pred-result z/nonz | 11:00 |
| lkcl | yes. interesting. they do indeed use the same so/ns/eq/ne/..../gt/ge | 11:01 |
| lkcl | my memory's hosed. | 11:03 |
| lkcl | and i'm not sure i've got test_caller unit tests yet for fail-first or predicate-result so it's not stuck in my long-term memory | 11:04 |
| lkcl | ghostmansd[m], i had to rename RS in svindex to SVG to specifically avoid it getting detected and processed as a GPR | 11:49 |
| lkcl | the position does not change the size does not change nothing changes except the name. | 11:49 |
| ghostmansd[m] | lkcl, ack; will update it in binutils | 12:55 |
| lkcl | thx. otherwise it gets treated as a register source field, which is bad | 12:59 |
| lkcl | even the fact that it's called "RS" confuses ISACaller and the parser | 12:59 |
| ghostmansd[m] | For binutils it'll also do since RS sets GPR register flag, and that one's later being checked. | 15:41 |
| lkcl | ah yeah | 16:20 |
| ghostmansd[m] | So, a simple numeric field within the same bit range as RS, right? | 17:03 |
| lkcl | yes 5-bits although strictly speaking it will be <<2. | 17:25 |
| lkcl | so numbers 0 4 8 12 16 .... 124 | 17:25 |
| lkcl | but i'm not quite ready for that yet | 17:26 |
| lkcl | so just a numeric field 0-31 is fine for now | 17:27 |
| ghostmansd[m] | Should I put it on the review on mailing list, or it's a bit early yet? | 19:43 |
| ghostmansd[m] | Because there's already svindex patch, but, if you feel svindex might change soon again, I can postpone it and keep it local | 19:43 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!