| ghostmansd[m] | I have to admit, the new site for RFPs is ass-kicking | 07:33 |
|---|---|---|
| ghostmansd[m] | lkcl, what's the state of bug 884? Should we submit RFPs? | 07:43 |
| lkcl | yes go for it | 11:40 |
| lkcl | took a lot of work i had to do a json format | 11:41 |
| lkcl | be careful though, don't submit RFPs for work that's not completed yet. | 11:42 |
| ghostmansd | lkcl, could you remind me the whole deal with svindex update? | 12:49 |
| ghostmansd | I see that we switched from RS to SVG in SVI form. | 12:51 |
| ghostmansd | I see that we still pass GPR, exactly as we do in RS. openpower/isa/simplev.mdwn doesn't ring a bell either. | 12:53 |
| ghostmansd | It looks like a duck, and even the quacking is somewhat familiar. | 12:58 |
| ghostmansd | https://libre-soc.org/irclog/%23libre-soc.2022-07-10.log.html#t2022-07-10T11:49:24 | 13:43 |
| ghostmansd | > ghostmansd[m], i had to rename RS in svindex to SVG to specifically avoid it getting detected and processed as a GPR | 13:43 |
| ghostmansd | I don't quite get, it's still documented as GPR in fields.text. | 13:43 |
| ghostmansd | Anyway, I updated pysvp64asm, and will also introduce an alias for binutils (#define SVG RS). | 13:44 |
| lkcl | lkcl> one thing i haven't mentinoed (yet) is that there's a new Pack/Unpack mode. sv_analysis and sv_binutils have to take that into account but i don't want to get into discussing that with you or begin adding it until everything else has stabilised. | 13:53 |
| lkcl | ghostmansd, gimme a sec to catch up on svindex. | 13:54 |
| ghostmansd[m] | Sure, no rush | 13:54 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=867 | 13:54 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=885 | 13:55 |
| lkcl | +SVI-Form | 13:55 |
| lkcl | + | 13:55 |
| lkcl | +* svindex RS,rmm,SVd,ew,yz,mr,sk | 13:55 |
| lkcl | old version | 13:56 |
| lkcl | new version | 13:56 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/simplev.mdwn;hb=HEAD | 13:56 |
| lkcl | 270 SVI-Form | 13:56 |
| lkcl | 271 | 13:56 |
| lkcl | 272 * svindex SVG,rmm,SVd,ew,yx,mr,sk | 13:56 |
| lkcl | right. | 13:56 |
| lkcl | i know what it is. | 13:56 |
| lkcl | if you use a register (RS,RA,RB,RC,RT) then that gets the register lookups to kick in | 13:57 |
| lkcl | if you use "RS", it means "go get the CONTENTS from the GPR, GPR(RS)" | 13:57 |
| lkcl | this is ***NOT*** what is required for svindex | 13:57 |
| lkcl | svindex you must perform a vector lookup *starting* from RS | 13:58 |
| lkcl | the normal vector loop is | 13:58 |
| lkcl | for i = 0 to VL-1: | 13:59 |
| lkcl | GPR(RT+i) = GPR(RA+i) + GPR(RB+i) | 13:59 |
| ghostmansd[m] | Is it possible to code "svindex %r1, ..."? | 13:59 |
| lkcl | hmmm.... i wouldn't recommend it for now. | 13:59 |
| lkcl | it's offset/shifted in a slightly complicated way because there are only 5 bits | 14:00 |
| lkcl | so i'd just leave it as an integer 0-31 for now | 14:00 |
| lkcl | continuing... | 14:00 |
| lkcl | the normal vector loop blah blah | 14:00 |
| lkcl | whereas the svindex loop is: | 14:00 |
| lkcl | for i = 0 to VL-1: | 14:01 |
| lkcl | GPR(RT+GPR(SVG+i)) = GPR(RA+GPR(SVG+i)) + GPR(RB+GPR(SVG+i)) | 14:01 |
| lkcl | actually because there are 128 GPRs, it's more like | 14:01 |
| lkcl | GPR(RT+GPR(SVG<<4+i)) = GPR(RA+GPR(SVG<<4+i)) + GPR(RB+GPR(SVG<<4+i)) | 14:02 |
| lkcl | sorry | 14:02 |
| lkcl | GPR(RT+GPR(SVG<<2+i)) = GPR(RA+GPR(SVG<<2+i)) + GPR(RB+GPR(SVG<<2+i)) | 14:02 |
| ghostmansd | Looks like this isn't GPR at all then. | 14:02 |
| ghostmansd | But a simple integer. | 14:02 |
| lkcl | basically... correct | 14:02 |
| ghostmansd | Field used to specify a GPR to be used as a | 14:02 |
| ghostmansd | source for indexing. | 14:02 |
| lkcl | yes. | 14:02 |
| ghostmansd | This is fields.text opinion, though. | 14:02 |
| ghostmansd | This is really confusing :-) | 14:02 |
| lkcl | although the confusion comes when you realise that that indexing is in fact into the GPR | 14:03 |
| ghostmansd | Yes, but the way GPR's indexed is different. | 14:03 |
| lkcl | yes. it helps to do an FP operation | 14:03 |
| lkcl | for i = 0 to VL-1: | 14:03 |
| lkcl | FPR(FRT+GPR(SVG<<2+i)) = FPR(FRA+GPR(SVG<<2+i)) + FPR(FRB+GPR(SVG<<2+i)) | 14:04 |
| ghostmansd | Hm. OK, but still this is not a register, right? So no need to mark it as PPC_OPERAND_GPR to let others do %r1, %r25, etc. | 14:04 |
| ghostmansd | Only simple integers, 1, 25, etc. | 14:04 |
| lkcl | correct. | 14:04 |
| lkcl | no, don't mark it as a PPC_OPERAND_GPR | 14:04 |
| ghostmansd | OK then :-) | 14:04 |
| lkcl | macro substitution and arithmetic expressions are still possible, though, right? | 14:05 |
| lkcl | .set SVG_OFFSET 5 | 14:05 |
| lkcl | svindex SVG_OFFSET*2, blah, blah | 14:05 |
| lkcl | ? | 14:05 |
| * lkcl afk was in the middle of a looong reply to jacob bachmeyer | 14:06 | |
| ghostmansd | Let me check for stull like SVG_OFFSET * 2 | 14:06 |
| ghostmansd | Should work, yes | 14:07 |
| ghostmansd | lkcl, the following works: | 14:50 |
| ghostmansd | .set IMM, 55 | 14:50 |
| ghostmansd | sv.addi %r3, %r1, IMM*5-1 | 14:50 |
| lkcl | hoorah | 15:18 |
| lkcl | yes i'd expect that to. | 15:18 |
| lkcl | ghostmansd[m] you're now on 2019-10-031 | 17:34 |
| ghostmansd[m] | Cool, thanks! | 17:35 |
| lkcl | toshywoshy, ping, mattermost is behind (about 3 hours) | 17:36 |
| ghostmansd | Heck, somehow the commit which added ff/pr squashed multiple others (mr, mrr, crm, svm, etc.). Spent quite a bit splitting it again. :-) | 20:25 |
| ghostmansd | For now we have 34 commits. | 20:29 |
| ghostmansd | 19 files changed, 12631 insertions(+), 44 deletions(-) | 20:29 |
| ghostmansd | 10520 for the generated stuff. It will decrease soon, though: I'll remove one register table for CRs (Alan changed the logic a bit recently, so that one became redundant). | 20:30 |
| ghostmansd | We almost haven't touched vanilla PPC, by the way. I made a huge effort to avoid it. Perhaps we can do even more. | 20:31 |
| ghostmansd | gas/config/tc-ppc.c | 215 +++- | 20:31 |
| ghostmansd | gas/config/tc-ppc.h | 19 +- | 20:31 |
| lkcl | ghostmansd[m], doh. | 22:09 |
| lkcl | yeah avoiding tc-ppc.c is adviseable, the history behind it is significant and it would freak people out to start hacking on it significantly. | 22:10 |
| lkcl | alan on the other hand can get away with it | 22:10 |
| lkcl | ghostmansd[m], please do keep the bugtracker database up-to-date. | 22:12 |
| lkcl | please don't submit RFPs without also immediately updating the "submitted=" date | 22:12 |
| lkcl | oh er you have. or i did. i forget. dang | 22:13 |
| lkcl | only 2 hours ago and i'd forgotten already. dang. | 22:14 |
| * lkcl melted brain | 22:14 | |
| octavius | lkcl.... YES! | 23:10 |
| octavius | ...the docs are compiling | 23:10 |
| octavius | I'll pull in the changes now | 23:11 |
| lkcl | octavius, hooorah | 23:33 |
| lkcl | you found an appropriate version of saxon / libxslt / whatever? | 23:33 |
| octavius | Yeah, the original makefile for some reason calls the saxon9 jar file, whereas instead you can call saxonb-xslt directly | 23:34 |
| octavius | (saxon is the original v6.5.5, 1.0 only, saxonb is v9+ 2.0/3.0 support) | 23:35 |
| lkcl | urrr... | 23:40 |
| lkcl | nice find. frustrating but good to find. | 23:40 |
| octavius | After enough practice (and you drilling to 'grep' and learn myself), finally getting the hang of it XD | 23:41 |
| octavius | Now just need to figure out how to source the env vars as root, probably no clean way to do it? | 23:43 |
| octavius | Ah yeah, I can just call bash | 23:45 |
| octavius | and that should reload the .bashrc | 23:45 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!