ghostmansd[m] | A quick question: can we, like vanilla PPC, have optional operands? | 10:16 |
---|---|---|
ghostmansd[m] | If not, this would greatly simplify the parsing. PPC code is a gory mess in this part. | 10:20 |
lkcl | no there's no optional operands | 10:35 |
lkcl | but there are "aliases" | 10:35 |
lkcl | so there is no instruction mtlr r5 | 10:36 |
lkcl | because it is an alias for "mtspr 8, r5" (LR = SPR number 8) | 10:36 |
ghostmansd[m] | Good, so count of operands is always fixed, right? | 10:37 |
lkcl | for now, it would be reasonable to assume that aliases are not supported (or done at a later stage) | 10:37 |
lkcl | yes | 10:37 |
ghostmansd[m] | A perfect design choice! | 10:38 |
lkcl | a trick there maaaay be to perform a dumb parsing phase, working on the alias to substitute the [missing, non-optional] operands | 10:38 |
lkcl | none of the examples - anywhere - use aliases, at all. not the svp64 openpower-isa repo ones, and not the v3.0B ones either | 10:39 |
ghostmansd[m] | Well, unlike PPC, I _do_ decouple functions | 10:39 |
lkcl | joy | 10:39 |
ghostmansd[m] | So we can re-use the code which parses the registers | 10:40 |
ghostmansd[m] | Unlike they who put every single shitty bit into md_assemble | 10:40 |
lkcl | and do alias substitution | 10:40 |
ghostmansd[m] | Yep, exactly | 10:40 |
lkcl | well i'm assuming they thought that a hash-table would make it ok | 10:41 |
ghostmansd[m] | hash table is OK, it's the parsing code which sucks :-) | 10:41 |
ghostmansd[m] | The function is almost 1000 lines long | 10:42 |
lkcl | ye frickin gods | 10:44 |
ghostmansd[m] | Just in case: we _do_ have the same count of operands for sv-extended insns as non-extended have at most, right? For example, "dcbf" has at most 3 operands, so "sv.dcbf." always has 3, right? | 13:04 |
lkcl | that's a fundamental and absolute inviolate requirement | 13:05 |
ghostmansd[m] | Perfect | 13:05 |
lkcl | prefixing is fundamentally independent from the suffix | 13:05 |
lkcl | like x86 REP instruction | 13:05 |
lkcl | i broke that rule once, just to see how bad it would be | 13:05 |
lkcl | it was... bad | 13:05 |
ghostmansd[m] | :-D | 13:05 |
lkcl | that's the LD-with-RC-taking-some-of-its-bits-from-the-immediate-to-use-as-a-shift-parameter | 13:06 |
lkcl | which when i have time i will stamp on with prejudice and much glee | 13:06 |
lkcl | and relief | 13:06 |
lkcl | you asked "what's this all about" a couple days ago and i said "please ignore it" | 13:07 |
lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l355 | 13:07 |
lkcl | all of that has to die, die, die | 13:07 |
lkcl | the *right* way to do that is for it to be added to Power ISA v3.0 first | 13:08 |
ghostmansd[m] | So this will go through the committee? | 13:14 |
lkcl | it requires a proposal to be written, and submitted as an RFC. | 13:14 |
ghostmansd[m] | Aha, got it | 13:14 |
ghostmansd[m] | Thank you so much for explanation! | 13:14 |
lkcl | https://openpowerfoundation.org/groups/isa/ | 13:15 |
ghostmansd[m] | It's always great to know the details like this | 13:15 |
lkcl | yehyeh totally, gives some context | 13:15 |
lkcl | guess the size SVP64 specification? | 13:15 |
lkcl | guess how many pages | 13:16 |
lkcl | go on, have a guess :) | 13:17 |
ghostmansd[m] | Well, this must be much smaller than OpenPOWER | 15:51 |
ghostmansd[m] | (unless we have to copy that one) | 15:51 |
ghostmansd[m] | Considering how many pages there are in PPC... 1000, 1500... | 15:52 |
ghostmansd[m] | I'd bet less than 100 pages? | 15:52 |
lkcl | around 120-150. it's over 10,000 words | 16:34 |
lkcl | lkcl@fizzy:~/src/libresoc/libresoc/openpower/sv$ find . -name "*.mdwn" | xargs wc | 16:34 |
lkcl | 10962 74439 491949 total | 16:34 |
ghostmansd[m] | Still really good. | 16:41 |
ghostmansd[m] | One of things why I like C is because the specs and many books are simple | 16:41 |
ghostmansd[m] | I mean, compared to many other languages | 16:42 |
programmerjake | simple...like: "if you stray off this very-specific path everything is UB...have fun with that!" | 16:44 |
programmerjake | part of why I prefer Rust | 16:45 |
programmerjake | ...not that rust has a particularly short spec...currently the spec is not fully elaborated...so it effectively boils down to whatever stable rustc does + misc. safety fixes | 16:50 |
ghostmansd[m] | That's not the simplicity I meant | 17:03 |
ghostmansd[m] | Anyway, I feel no desire to start yet another holy war :-) | 17:04 |
ghostmansd[m] | lkcl, refactored operands parsing in svp64 binutils, looks really cool | 17:04 |
lkcl | maaagic, hm must take a look | 17:05 |
ghostmansd[m] | And now we are able to detect the exact type of each and every operand | 17:05 |
ghostmansd[m] | The next step is to drop that custom mapping for GPR/FPR/etc. | 17:05 |
* lkcl twitches, no code-comments | 17:05 | |
lkcl | ghostmansd[m], this little tick, in my eye, is twitching uncontrollably... :) | 17:06 |
ghostmansd[m] | What do you mean? :-) | 17:06 |
ghostmansd[m] | Sorry, I don't quite get what you mean by twitching :-) | 17:07 |
lkcl | no code-comments *twitch* | 17:07 |
lkcl | ah this was what i was referring to that isn't going to go in the spec | 17:07 |
lkcl | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc-svp64.c;h=a5444ff440d70a5a8c60b782eb8ee4199f982a21;hb=0c3cd699a0b3041f7f80caf49fcbb1ab03c086a2#l225 | 17:07 |
lkcl | svp64->ldst_shift - that should be removed. | 17:08 |
lkcl | sats, satu, all good... | 17:09 |
lkcl | nice! | 17:10 |
lkcl | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc-svp64.c;h=a5444ff440d70a5a8c60b782eb8ee4199f982a21;hb=0c3cd699a0b3041f7f80caf49fcbb1ab03c086a2#l770 | 17:10 |
lkcl | bit of a pig that the ld/st has to be identified in that horrible way, but hey | 17:11 |
programmerjake | > That's not the simplicity I meant | 17:11 |
programmerjake | yeah, I know, just imho it's a major flaw in the C/C++ specs... | 17:11 |
lkcl | ah. | 17:12 |
lkcl | ghostmansd[m], the bits for the "modes" are different depending on which type is detected | 17:12 |
lkcl | * normal-mode has its own set of bits | 17:13 |
lkcl | * ldst-mode has its own set | 17:13 |
lkcl | * branch-mode has another set | 17:13 |
lkcl | * cr_ops-mode another | 17:13 |
lkcl | annoyingly, for example, SZ is *not* in the same place for all those 4 modes | 17:13 |
programmerjake | one thing the assembly parser should handle at some point is `1<<r3` having spaces in it and/or different capitalization...idk if you got it to already handle that | 17:13 |
lkcl | not in the least :) | 17:14 |
lkcl | this is waaay early days | 17:14 |
ghostmansd[m] | lkcl, could you, please, refer to svp64.py with these bits? | 17:15 |
lkcl | willdo, 1 sec... | 17:15 |
ghostmansd[m] | All but recent parts were done mostly by looking at svp64.py, sometimes it's a literal translation | 17:16 |
lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;hb=HEAD#l847 | 17:16 |
ghostmansd[m] | But I could misunderstand the thing | 17:16 |
lkcl | mmmm yeah, ok, it's all good | 17:17 |
ghostmansd[m] | Ah, this | 17:17 |
ghostmansd[m] | This follows after parsing | 17:17 |
ghostmansd[m] | There's "post-parsing" stage | 17:17 |
ghostmansd[m] | 1 sec... | 17:17 |
ghostmansd[m] | svp64_canonicalize | 17:17 |
lkcl | i haven't looked at this in 6+ months so i may find, after looking at it, that i've actually been "sane and sensible" and properly matched things up | 17:17 |
lkcl | (!) | 17:17 |
lkcl | which iirc took frickin forever | 17:17 |
ghostmansd[m] | (name's dumb, I know) | 17:18 |
ghostmansd[m] | That's OK :-) | 17:18 |
ghostmansd[m] | TBH it took me damn lot of time to even recall what I did | 17:18 |
ghostmansd[m] | And it was not even close to 6+ months | 17:18 |
lkcl | :) | 17:18 |
ghostmansd[m] | I'll rebase the branch and drop or squash some commits | 17:19 |
ghostmansd[m] | Because some commits are crap, and some should be better organized | 17:19 |
ghostmansd[m] | Beware! | 17:19 |
lkcl | 2 formats that are not included yet in svp64.py - cr_ops and branches | 17:20 |
lkcl | i'm just going to add links to the top of svp64.py now... | 17:20 |
ghostmansd[m] | I think even with binutils support it'd be great to update svp64.py eventually | 17:21 |
lkcl | yehyeh | 17:22 |
ghostmansd[m] | And that'd better be you, I'm terrible at reading specs | 17:22 |
lkcl | ah, i *do* have the branches (beginnings of it, anyway) started https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;hb=HEAD#l839 | 17:22 |
ghostmansd[m] | But at least as they say even a monkey can be taught to write code, so here I am | 17:22 |
lkcl | haha | 17:23 |
lkcl | ghostmansd[m], ok there we go https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;hb=HEAD#l844 | 17:32 |
lkcl | so you can see, in both LD/ST and "normal", i did, it seems, actually go to the trouble of making sure that the bits with same names do actually line up | 17:33 |
lkcl | sz is always bit 4, dz always bit 3 | 17:34 |
lkcl | no matter if it's LD/ST-mode or Normal-Arithmetic-mode | 17:34 |
ghostmansd[m] | Out of curiosity, why did you change double with dbl? :-) | 17:51 |
lkcl | 80-char limit | 17:51 |
ghostmansd[m] | Ah, OK | 17:51 |
ghostmansd[m] | I'm somewhat more liberal in such cases :-) | 17:52 |
lkcl | this helps illustrate why | 17:52 |
lkcl | https://libre-soc.org/HDL_workflow/2020-01-24_11-56.png | 17:52 |
lkcl | i have memory-recall issues and a strange type of dyslexia | 17:54 |
lkcl | means i have to have everything that's context-related on-screen, simultaneously | 17:54 |
ghostmansd[m] | For me the effect would be contrary, I'd simply be lost :-) | 17:55 |
lkcl | jobs | grep "keyword" helps with that | 17:55 |
lkcl | "fg 120" is not uncommon :) | 17:55 |
lkcl | ps auxww | grep "vim" | wc | 17:56 |
lkcl | the record is 1540, after 300 days | 17:56 |
lkcl | something really frickin weird going on with the simulations when programs are moved to address 0xFF00_0000 | 17:58 |
lkcl | ahh damnit, st-with-update is borked | 18:07 |
lkcl | what the hell | 18:08 |
lkcl | i have a sudden urge for no good reason i can explain for fish fingers, peas, and mash potato | 18:22 |
lkcl | :) | 18:22 |
* lkcl going shopping | 18:22 | |
ghostmansd[m] | Bene sapiat! | 18:30 |
Veera[m] | lkcl: TypeError: Object (rec <unnamed> st_data_i st_data_i_ok) cannot be used as a key in value collections | 18:55 |
Veera[m] | make: *** [Makefile:63: microwatt_external_core] Error 1 | 18:55 |
Veera[m] | lkcl: What can be done | 18:56 |
lkcl | Veera[m], you have the wrong source code | 19:00 |
lkcl | pip3 has downloaded s*** | 19:00 |
lkcl | you will find nmigen 0.2 from the internet has been randomly downloaded | 19:00 |
lkcl | and installed without your consent | 19:00 |
Veera[m] | I remember nmigen being installed from pip | 19:01 |
Veera[m] | so what should be done | 19:01 |
Veera[m] | how to prevent pip from installing nmigen | 19:01 |
Veera[m] | ah. I did python setup.py develop in nmigen git source and now it compiles successfully. thanks luke! | 19:09 |
tplaten | I got the uart working on tplaten_3d_game, so I hope I will be able to run the 3d game on libre-soc on the orangecrab before Easter | 19:10 |
lkcl | tplaten, great | 20:00 |
lkcl | Veera[m], yeah i know it's annoying. we need control over the pypi packaging but it's currently cyber-squatted | 20:01 |
lkcl | meeting in 2hr (21:00 UTC) jn cesar octavius sadoon[m] toshywoshy lxo programmerjake markos anyone else who'd like to | 20:12 |
Veera[m] | lkcl: successfully compiled ls2 microwatt (hello_world) bitstream! | 20:48 |
Veera[m] | lkcl: logged on to uoregon server | 20:49 |
Veera[m] | but could not find out ls2 directory | 20:49 |
Veera[m] | neither xc3sprog binary | 20:50 |
Veera[m] | tried sudo bash; su - coriolis2; there is no src/ls2 dir | 20:50 |
lkcl | Veera: once su - coriolis2, then do "schroot -c nextpnr-xilinx" | 21:37 |
lkcl | in future, use updatedb and locate | 21:37 |
lkcl | (nextpnr-xilinx)root@silicon:/home/coriolis2/src# ls | 21:37 |
lkcl | c4m-jtag lambdasoc nmigen-soc sphinxcontrib-verilog-diagrams | 21:37 |
lkcl | ethmac ls2 nmigen-stdio tercel-qspi | 21:37 |
lkcl | gram nextpnr-xilinx nmutil uart16550 | 21:37 |
lkcl | hdl_tools nmigen openpower-isa xc3sprog | 21:38 |
lkcl | ieee754fpu nmigen-boards soc | 21:38 |
lkcl | you can see there i've run at least 3 of the dev-env-setup scripts | 21:38 |
lkcl | but, don't break that schroot :) | 21:41 |
lkcl | use it as a template to look at | 21:42 |
lkcl | when creating an entirely new one, from scratch | 21:42 |
Veera[m] | ok won't break that schroot | 21:44 |
Veera[m] | just did "schroot -c nextpnr-xilinx" and can access it | 21:45 |
lkcl | excellent | 21:49 |
lkcl | meeting cesar toshywoshy programmerjake lxo jn sadoon_albader[m octavius rsc markos | 21:50 |
lkcl | moved 1hr early, remember :) | 21:56 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!