Friday, 2021-09-03

ghostmansd-pcHolly Molly, it seems I can finally run tests on Talos05:15
ghostmansd-pcand, actually, unlike on my VM, these tests don't take forever to run05:15
ghostmansd-pcI was able to run test_pipe_caller_long.py05:17
ghostmansd-pchm, on there are still issues...05:28
ghostmansd-pc  File "/home/ghostmansd/.env/lib/python3.9/site-packages/libresoc_nmutil-0.0.1-py3.9.egg/nmutil/", line 8, in <module>05:28
ghostmansd-pc    from vcd.gtkw import GTKWSave, GTKWColor05:28
ghostmansd-pcImportError: cannot import name 'GTKWColor' from 'vcd.gtkw' (/home/ghostmansd/.env/lib/python3.9/site-packages/pyvcd-0.1.7-py3.9.egg/vcd/
ghostmansd-pcthat's from venv; if I run vanilla python3, I have the same output, with python residing in /usr/local05:28
programmerjakehmm, you have a version of pyvcd that's too old, GTKWColor first shows up in v0.2 in this commit:05:53
programmerjakeoh, you were gone when I posted a reply...05:56
programmerjakehmm, you have a version of pyvcd that's too old, GTKWColor first shows up in v0.2 in this commit:05:56
programmerjakehope that helps06:00
ghostmansdprogrammerjake: thank you! Does it need Luke's intervention, or I can install it locally?07:12
ghostmansdWith the former, perhaps both venv and system Python will work, but you never know for sure...07:13
programmerjakewith a venv (assuming it's in your home directory), your free to install whatever python stuff you please .. it won't break anyone else since they use their own venvs or the system python07:16
programmerjakeyou should be able to install it with (in the venv) `pip install pyvcd==<version>` where <version> is whatever version you want...07:19
programmerjakeyou probably want 0.2.4 which is the latest version07:19
programmerjakeso, you shouldn't need to ask luke to upgrade pyvcd in your own venv07:21
programmerjakehopefully that helps!07:21
lkclghostmansd, use python3 install --user07:27
lkclvenv will stop you from accessing the already-installed packages in ~/.local07:27
lkcland require you to re-run all of the commands that i already ran in order to get the tests to run, for you07:28
lkclprogrammerjake: venv is like chroot, it cuts you off from everything that you've done outside of the "chroot"07:29
programmerjakeyup, i know...07:29
lkclconsequently, recommending to ghostmansd to use venv forces him to go through the already-actioned install process yet again07:29
programmerjakehmm, i thought he had done that in a venv already...07:30
lkclno, it didn't work07:30
programmerjakeoh, :(07:31
lkclso i used python3 develop --user07:31
programmerjakevenv works just fine for me...07:31
programmerjakeit makes it so i can install whatever i like without having to worry about conflicting versions messing up system programs07:32
programmerjakeinstall --user still has conflicts07:33
programmerjakebut at least it's better than sudo pip install...07:33
lkclwtf nmigen 0.2 is installed??07:37
lkclf****g f*****g pip, pissing me off07:37
lkcla whole stack of things had been installed by someone running as root - by pip - which included pulling in nmigen 0.207:41
lkcli reaaaally intensely dislike pip and how it carries out unauthorised downloads without your consent07:43
programmerjakeoops...more reasons to use a venv...07:45
lkclghostmansd: ok, i've removed the f****d-up pip-installed version 0.2 of nmigen, and the libresoc-* packages that pip3 brought in without informing anybody07:45
lkcli'm not sure it would actually help, because pip3 would *still* - under the venv - pull in unauthorised downloads07:45
lkcllike, exactly as has happened in /home/ghostmansd/.env/lib/python3.9/site-packages07:47
programmerjakewe need *one* script that does the full setup process, so newbies can just run and it creates a venv, clones git repos, does the whole setup process, finally leaving you with a fully working setup. kinda like rustc's x.py07:47
lkclghostmansd: you've gone and run things in a random order, which has resulted - a second time - in pip3 going and randomly f*****g about and carrying out unauthorised downloads07:48
lkcldon't use venv07:48
lkcli repeat again: don't use venv07:49
lkclthe order of the installation of the python dependencies is CRITICAL07:49
lkcland is listed EXPLICITLY in the scripts.07:49
lkclif you run them manually - which i can tell from the results that you've been doing that - you MUST run the installs in the EXACT AND PRECISE ORDER listed in the dev-env-setup scripts07:50
lkcland in NO OTHER ORDER07:50
lkclif you try to run any of the scripts from libresoc in the wrong order, pip3 will go,07:50
lkcl"oh, you don't have one of the dependencies, let me go off randomly to get that for you, from some random version you have no idea about, and i won't ask your permission before doing so"07:51
programmerjakesorry for contributing to the confusion07:51
lkclconsequently, by running "python3 develop" in, for example, the "soc" directory, it went:07:52
lkcl* oh you don't have nmigen, let me get that for you. hmm, what version shall i install? oh, i'll get nmigen 0.2 for you07:52
lkcl* oh, what does nmigen 0.2 need? oh, that requires pyvcd 0.1.7.  let me terminate all and any possibility of upgrading that because i've installed nmigen 0.2 for you.07:53
ghostmansdlkcl: thanks for clarification, now it's clear07:53
lkcl* oh, you don't have nmutil, let me just grab that off of pypi07:53
lkclyou go07:53
lkclcd nmutil07:53
lkclpython3 install07:53
lkcland it goes07:53
lkcl"ARGH, i can't do this because it conflicts with the version already installed by pip"07:54
lkclactually it's much worse than that07:54
lkclit goes,07:54
ghostmansdHowever, in my defense, I must say: it's not clear what and how to install on Talos. On system you own, you can simply run whatever script we have in dev-env.07:54
lkcl"ARGH, i can't do this, because there's a version of nmigen already installed by pip, which conflicts with the version needed"07:54
lkclit gets worse07:54
lkclyou then cd to the nmigen git repo07:55
ghostmansdSo yes, I _assumed_ it'd be fine to follow the install from, because, well, that's what was mentioned in discussion.07:55
lkclyou get the idea07:55
ghostmansdWas there a specific order mentioned? I don't recall.07:55
lkclwelcome to pip3 hell07:55
lkcli didn't think to mention it because it's in the dev-env-setup script07:55
lkclso if you stop using the venv and just use the user-local-installed stuff which i did a few hours ago for you, it'll be fine07:56
ghostmansdOk, I'll use it, thank you!07:56
ghostmansdAgain, in case I ever need to re-do the thing, is there a clear sequence for a new developer?07:56
lkclls -altr /home/ghostmansd/.env/lib/python3.9/site-packages to see the full extent of the horror-show created by pip307:57
ghostmansdBecause currently the docs is "call lkcl, he's kind and hopefully will help you"07:57
lkclincludes nmigen-0.2 (unauthorised download)07:57
lkclnormally it would just be hdl-dev-repos-virtualenv07:58
lkclthat's kept in sync with the equivalent (system-wide) hdl-dev-repos script07:59
lkclyou can compare the two and see that they're near-identical07:59
programmerjakewell, we should add that to the docs on the wiki...first I heard of that07:59
programmerjakei just did a roll-your-own venv for my computer08:00
programmerjakeadmittedly, i started before we had dev-env-setup08:00
lkclit's been there for.... 15 months.  tobias created it08:01
lkcli've never been particularly keen on virtualenv, i lean more towards a preference for doing full chroots08:03
lkclthat's just me08:04
programmerjakei'm kinda partial to how cargo does it: versions (and sources) are declared in each project's toml file, and the code is supplied by cargo, independently of every other project. no system-wide conflict-ridden mess. too bad python went for the interpreter equivalent of dll hell08:06
lkclit's nothing to do with python08:07
lkclit's entirely pip308:07
programmerjakewell, pip is de-facto python08:07
lkclbefore pip3 went ballistic, things were explicit.08:07
lkclno, it's not.08:07
lkcl"the interpreter" != "a package used to install other packages"08:08
programmerjakewhat I meant was, for the python ecosystem, pip is the de-facto method of obtaining dependencies08:09
lkcldebian got this right. if there's more than one package to be pulled down, it prompts you unless you add the "-y" option08:09
lkclif there's just one package it just does it.08:10
lkclyes, that's true08:10
programmerjakeand python has to live with the consequences08:11
lkclfortunately - very fortunately - at least pip3 detects system-wide packages08:11
lkcli'm not impressed by some of the decisions made by the Python Software Foundation in recent years08:11
programmerjakecargo is a lot more like nix -- dependencies are taken from a key-value store and assembled together exactly how the program your compiling desires, no system-wide conflicts08:13
programmerjakeadmittedly i haven't looked at nix too closely so i could be incorrect08:14
lkcli suspect that when packages stabilise and end up being installed by distros that cargo will run into exactly the same problem faced by pip3 right now08:14
lkclthe problems come from interaction between stably-declared releases and developer versions08:15
lkclthat's really the source of the problem for pip-installed packages08:15
programmerjakeone other nice part is it will let you use multiple major versions of a dependency in the same program08:15
lkcla developer declares "my software works solely and exclusively with this version X of package Y and this version X1 of package Y1"08:16
lkclthat's exactly what pip3 allows.08:16
lkcldon't think for one second that what cargo does is "new" or hasn't been done many many times by many package-installers08:16
lkclthe problem comes when a developer wants to use latest-and-greatest-out-of-git08:17
programmerjakenope, not new, just a really good idea08:17
lkclif the declared versions in the cargo manifest happen not to match those, the developer is screwed08:17
lkcljust like - exactly like - the situation with pip3 manifests08:18
programmerjakethen, one just uses a git dependency in your toml file rather than using pip's approach of saying "i want v0.3" and installing it yourself behind pip's back08:18
lkcli know everyone (including me) keeps blaming pip3 itself, but actually the source of the problem is an interaction between stable "packaged" releases and developer versions08:18
lkclwhich *you* as the developer have to override08:19
lkcl*you* as the developer have to be the one to manually and explicitly edit that in08:19
lkclthe exact same thing is perfectly possible with pip3 manifests: it's just that nobody actually does it because it's such a pain in the ass08:20
programmerjakepip's problem is it *doesn't* have a way to say "i want the version from commit xxx of"08:20
lkclyes, it does.08:21
lkclit's just that nobody uses it - or is aware of it08:21
lkclplus, it's a pain in the ass08:21
programmerjakehmm, never seen that08:21
programmerjakewell, we should use it then...or is it hopelessly broken?08:21
lkclusing that, you have a maintenance headache at the developer level08:21
lkclit's a maintenance nightmare08:22
lkclevery single commit in one repo, we now have to update five other hash tags in pip3 manifests??08:22
lkcli don't think so08:22
lkcli'm doing 30+ commits a day on a good day.08:23
programmerjakewell, you can declare it to depend on a branch instead (at least in cargo)08:23
lkclno way in hell i'm wasting time updating pip3 manifests 30+ times a day08:23
programmerjakewell, if the dependency is "master@git.blah/repo.git", and not a commit hash, it is better08:24
programmerjakeidk if pip supports that08:25
programmerjakecargo does08:25
lkclit should do. i've never used it.08:25
lkclalways preferred to work with " develop" on the most-used (in-development) packages08:26
programmerjakethis all is why I was advocating for a monorepo...everything is guaranteed to work together (assuming we test commits). pip dependencies could then just be "../dependency/" (or however pip phrases getting something from the local fs)08:27
programmerjakewe won't have to worry about version mismatch08:28
lkclyyeh, look up freeswitch for how that turns out08:29
programmerjakelinks? google gave nothing apparently relevant for "freeswitch monorepo"08:31
lkcl100+ dependencies that they pulled in and "maintained" themselves08:31
lkclthen wondered why people complained when they failed to keep the security patches up-to-date on their "maintained" dependencies08:32
programmerjakepulling in external non-libre-soc dependencies is not what I'm advocating, i'm advocating putting all libre-soc hdl-related code in a single repo08:33
lkclgot themselves into a total nightmare situation where they *couldn't* update the dependencies with security patches, because they hadn't kept the core software up-to-date, and were critically relying on hopelessly out-of-date versions08:33
lkclyes. no.08:33
programmerjakeit worked out just fine for llvm08:34
lkcla monorepo basically declares to users, "under no circumstances should you even remotely consider using the libraries we create, for your own project"08:34
lkclyeah - we're not llvm.08:34
lkclllvm is a monolithic project08:35
lkclfor a monolithic single-purpose project ("a compiler"), a monorepo is a natural fit08:35
programmerjakeno, it doesn't...we can create mirror repos that follow subprojects of the monorepo, just like llvm08:35
lkclnmutil is not in *any way* actually related to soc, at *all*08:36
lkclit's the direct equivalent of chisel3's io library08:36
programmerjakellvm, isn't very monolithic anymore...they've grown to have a bunch of not-closely related stuff08:36
lkclchisel3's io library is very deliberately not included in chisel3 for exactly the same reasons that nmutil is not included in either nmigen *or* soc.08:37
lkclthe ieee754fpu library is, likewise, very specifically intended *not* to be something that forces people to think, psychologically, of it being "solely exclusively for use with and by libre-soc"08:38
lkclthey're designed as completely independent autonomous libraries for *general-purpose* usage08:38
lkcla monorepo psychologically prevents and prohibits people from considering that even as a possibility08:39
programmerjakewell, since they're submodules of soc.git, it means they're still kinda a monorepo with extra painful syncing steps08:39
lkclforcing contributors to have to download massive packages and hunt through tens to hundreds of thousands of lines of code just to get on tiny library that they actually want?08:39
lkclyep, i know08:40
programmerjakeas i said----git mirrors of parts of the monorepo08:40
lkclexcept because i do it all the time, it's not at all painful08:40
lkcli just run the "git update" commands naturally out of habit, without thinking about it08:40
lkclonce we hit a stable release point, everything changes.08:41
lkclwhich is why i spent some time a couple months back registering nmutil, ieee754fpu etc. etc. with pypi08:41
* lkcl tired. need to investigate a bug for ghostmansd 08:42
lkcldivw fails08:42
programmerjakewell, because you have to make sure the submodule is updated in a separate commit, and it's hard to diff across, or have synchronized commits, or have moving code make sense to git, etc, etc, etc08:42
lkcli know. git submodules are supposed to help with that, but have their own problems08:43
programmerjakeor when people forget to push their submodule commits08:44
programmerjakea monorepo solves all of those08:44
programmerjakeanyway, good luck with divw, i'm going to sleep08:45
lkclyeh me too (again) shortly08:45
ghostmansdSo for now we have two issues, right?08:50
ghostmansdone in shift and one in arith08:51
lkclghostmansd, take a peek at the "depends on" list on 671
lkcli just sorted divw08:52
lkclam re-running test_issuer.py08:52
lkclit'll be another 15 mins and i need to go lie back down08:52
lkclsrad is broken and it's not obvious at aaaalll why08:53
* lkcl will be awake again in about 4-5 hours 08:54
Las[m]lkcl: Do you know if there's any specific reason some python modules in Coriolis are in `/etc`? Are you expected to modify them as a user of the software?11:28
Las[m]Or are they supposed to be readonly?11:28
lkclinstalled in etc? ???14:01
lkclthat's definitely a FSH violation14:01
lkcli'll have to talk to Jean-Paul about that.14:02
lkcli'd never noticed before.14:02
Las[m]It's the `symbolic.cmos` modules and such14:50
lkcli will tell Jean-Paul off :)17:38
lkclit's clear that the "normal" install process is supposed to be in ~/ (homedir)17:39
lkclghostmansd, passed, last night, for the (fixed) divw17:39
lkclafter some missing brackets17:39
lkclbut srad doesn't17:40
ghostmansdSo that's was precedence issue?17:40
lkclyes, in the actual pseudocode17:40
lkclwas translated to17:40
lkclconcat(0, repeat=XLEN)/217:41
lkclwhich is of course a list divided by an integer :)17:41
lkcli fixed it by doing17:41
lkclit's actually valid from a precedence perspective, * has priority over /17:41
ghostmansdDamn :-)17:42
lkclthe srad one is not obvious *at all* what the hell is going on17:42
ghostmansdDo we have a content of registers by the time it failed?...17:43
ghostmansdI think I might reproduce it with test_caller.py17:43
lkclin the bugreport, yes.17:43
lkclyes good idea17:44
ghostmansdDoes it include initial regs?17:44
lkclor, make a test_caller_shift.py17:44
lkclactually i think the bug is "bad" enough that *any* values fail (!)17:44
ghostmansdThat's actually better for us :-)17:44
lkclcan i suggest, though, if you want to do "known" values, to simply temporarily patch-out fixedshift.mdwn17:45
lkclback to its original state17:45
lkclpatch -p1 -r17:46
lkclerrr.... hang on, it just passed17:47
lkcllet me re-run17:47
lkclha, passed, irony17:48
lkclthat may just be my fault, not running pywriter noall fixedshift17:48
lkcllet me re-run agaaaaaain17:48
lkclsorry about that :)17:49
lkclghostmansd: comparefixed is a next most likely candidate17:51
lkclcmpeqb will need a minor rewrite to use a for-loop17:51
lkclpretty much exactly the same thing as bpermd which is byte-based, isn't it?17:52
lkclbtw you starting to see why i suggested the XLEN task for you? it's necessary to go over *every* Power ISA instruction17:52
lkclwhich gives you a "hands-on" actual practical working knowledge of what's _actually_ in the ISA17:53
lkclwhoops it looks like he got disconnected from the internet, doh17:58
ghostmansdYep, got it :-)18:01
ghostmansdActually, the more I deal with it, the more I like it18:02
ghostmansdInitially it was quite frustrative, though18:02
ghostmansdDid I get it right that pywriter wasn't run after you fixed off-by-one?18:06
ghostmansdAnd the error that was in issue is caused by that?18:06
lkcllooks like it18:10 completed let me check it18:10
lkclno errors! all good18:10
lkclclosed it18:11
lkclsuggest as the next batch18:11
lkclthere's only 6 instructions, but they're quite odd18:12
lkcloh, fixedstore.mdwn as well18:12
* lkcl out for a walk18:12
ghostmansdOk, in progress now :-)18:24
ghostmansd-pclkcl: I'm still somewhat confused with fixedstore. What'd be the right change?19:05
ghostmansd-pclet's consider sth, which has `MEM(EA, 2) <- (RS)[48:63]`19:05
ghostmansd-pc1) MEM(EA, 2) <- (RS)[XLEN-16:XLEN-1]19:05
ghostmansd-pc2) MEM(EA, MIN(2, XLEN/8)) <- (RS)[48:63]19:06
ghostmansd-pc3) MEM(EA, MIN(2, XLEN/8)) <- (RS)[XLEN-16:XLEN-1]19:06
lkclon phone19:18
lkcljust MEM(EA, 2)19:18
lkclno change to mem width19:18
lkclpart of spec19:18
ghostmansd-pcOK, so only RS[XLEN] change19:22
lkclyes, correct19:28
lkclthe discussion we had on the mailing list a couple days ago19:29
lkclbasically if XLEN/8 < MEM(EA, {width}) we consider it UNDEFINED behaviour19:29
lkclLauri pointed out that it would be an extremely bad idea to "silently" change the behaviour of any of the ld operations19:30
lkcllw "magically" becomes a different width ==> ExtremelyBad(tm)19:30
programmerjakehmm, i think it might be better to load at full lw width and truncate to elwidth -- just like uint32_t -> uint8_t conversion in C19:32
programmerjakeISA-level UB should be avoided19:33
programmerjaketoo bad OpenPower is full of UB...19:34
programmerjakethey should have picked sign/zero extension for modsw, not UB extension19:35
lkclyes, that's effectively what is done19:44
lkclsigh yes19:44
lkcland then had IBM POWER9 do something completely different19:44
lkclin between those two (load at full width, truncate to dest elwidth) goes the "saturation"19:45
lkclin a very-carefully-documented specific order19:45
lkclin order to cope with possible sign-extension as well19:45
lkclwhich err.... means...19:46
lkcl* load a byte19:46
lkcl* extend it to 16-bit19:46
lkcl* then extend it *again* to 32-bit19:46
lkclsomething like that19:47
* lkcl needs to re-read the spec again
lkclright, ok, some of the LDs are arithmetic, so involve sign-extension.  that was it19:48
lkclso a good example would be... lha19:48
lkclwhich would be:19:49
lkcl... wait....19:49
lkclwhich would be....19:49
lkcl* load at 32-bit (the original 32-bit LD behaviour)19:49
lkcl* perform sign-extension to 64-bit19:50
lkcl* examine whether the 64-bit result as a *signed* integer is greater than 0x7FFF (32767) or less than 0x8000 (-32768)19:50
lkcl* perform signed-saturated truncation if it is19:51
lkclso the dw=16 tells "sats" what the saturation limits are19:51
lkclit's quite specific and quite tricky19:51
lkclhas to cover a really wide range of possibilities19:51
lkclan entire quadrant of which wasn't properly discussed / evaluated until this came up a few days ago19:52
ghostmansd-pcbtw, regarding ldst. there's a couple of either explicitly or implicitly 64-bit instructions, and some are double-word: stq, sthbrx, stwbrx, stdbrx19:52
ghostmansd-pcand also stmw, I guess19:53
ghostmansd-pcI guess we should keep these as is?19:53
ghostmansd-pctheir ld* variants we kept as is19:53
lkclyep skip the double-word ones entirely19:54
lkclwe're not doing them19:54
ghostmansd-pclmw/stmw are not double words, though, but still are implicitly 64-bit19:55
lkclthey're optional in the "Level 2" Compliance Subset (Embedded Floating-Point)19:55
lkclyeah we're definitely not doing those.19:55
lkclif you look closely you'll see those are deprecated19:55
lkclbecause they're a massive pain, great idea in 1994 when you're not doing high-performance Multi-Issue Out-of-Order superscalar designs19:56
lkclbut an absolute blasted nuisance if you are19:56
lkcleven ARM had to learn that one and deprecate their multi-register instructions19:56
lkclARM settled for a twin-LD, twin-ST19:57
kylelWell that the install nightmare is over...ready for orders19:57
lkclkylel: :)19:57
ghostmansd-pclol, ARM even introduced cmpxchg19:57
kylelOh, a few things about the venv script...19:57
ghostmansd-pcI might be non-objective, but this ll/sc is a total crap19:57
programmerjakefor the double-word atomic load/stores...we still need those since software needs 128-bit atomics19:57
ghostmansd-pccmpxchg for the win19:58
lkclkylel, yah go for it19:58
ghostmansd-pcprogrammerjake: dw-cas?19:58
ghostmansd-pcor generic 128-bit atomics?19:58
* lkcl kylel, i just added you to the dev-env-setup gitolite3 write-access list19:59
ghostmansd-pciirc most of atomics can be implemented atop of cmpxchg19:59
kylelJust minor differences about checking for sudo, creating src directory, etc.  No biggie.19:59
programmerjakein reference to above where lkcl was saying we don't need 128-bit load/stores19:59
lkclprogrammerjake: ah. you think we'll need them?20:00
programmerjakenot a reply to ll/sc vs cmpxchg20:00
* lkcl trying to find them20:00
programmerjakeyes, lots of sw depends on 128-bit atomics for stuff like wait-free linked lists20:00
ghostmansd-pclkcl: pushed xlen branch with fixedstore; before checking it, I should re-run `hdl-dev-repos`, `hdl-dev-repos-virtualenv`?20:00
lkclghostmansd-pc, ah no.20:01
lkcljust re-run pywriter noall fixedstore20:01
lkclthat should do it20:01
ghostmansd-pc> yes, lots of sw depends on 128-bit atomics for stuff like wait-free linked lists20:01
ghostmansd-pchm, do you mean doubly-linked list?20:01
lkclby using "python3 develop" you've requested that python look at the *development* directory20:01
lkclthe actual git clone checked-out source code20:01
ghostmansd-pcsingly-linked should be solved (at least in C) as Harris20:01
lkclyou *do not* need to re-run "python3 develop" multiple times20:02
ghostmansd-pclet's assume I've just ssh-ed to talos20:02
lkclif however we had used python3 ***INSTALL*** then that *would* be necessary to re-run20:02
ghostmansd-pcwhat should be next steps?20:02
programmerjakesee isa v3.1 section 3.3.4 for some reasoning20:02
ghostmansd-pc(including git)20:02
lkcland you've just git committed something from your local machine to the server?20:02
ghostmansd-pcI have it in xlen remote branch20:03
ghostmansd-pcwhich I can pull20:03
lkclok then it's just a matter of "git pull"20:03
ghostmansd-pcand even try rebasing it20:03
ghostmansd-pcso, ssh, then git pull --rebase, then
lkclgit pull --rebase20:04
ghostmansd-pc(and also pywriter)20:04
ghostmansd-pcsorry, forgot to mention20:04
lkclpywriter noall fixedstore (or whatever MDWN file was modified)20:04
lkclthen yes, run test_issuer.py20:04
lkclor if you want something shorter20:04
lkclpython3 fu/compunit/test/test_ldst_compunit.py20:04
lkclthat should be very quick20:05
ghostmansd-pc`git pull --rebase` -- only openpower-isa, or all I have in src/?20:05
lkclif there's errors, go back to editing and fix those20:05
lkclwell, given that you don't know whether anybody else has also done some commits, it maaaay be a good idea to git pull on all other repos as well20:05
programmerjakesee also the lqarx and stqcx. instructions20:05
lkclbut that's up to you to decide / evaluate20:05
lkcllqarx, that's what i wanted to search for20:05
* lkcl ngggh stressed. 128-bit operations with atomic behavoiur, streeeeess20:06
lkclwe need to check what Microwatt does, there20:07
lkclkylel, ok so you've done python, and c, and assembly-level programming20:08
lkclthis is goood.20:08
lkclwould you be happy to go through this20:08
lkclwhich ghostmansd-pc wrote a couple weeks ago?20:08
lkclit will give you an idea of how things "fit together" on the simulator side20:09
ghostmansd-pcyep, that's mine :-)20:09
ghostmansd-pcall faults are mine20:09
programmerjakethe lq and stq instructions are needed for compiling 128-bit atomic relaxed ld/st20:10
ghostmansd-pcinteresting, do we have a proper map of how C11 atomics interoperate with openpower?20:10
kylellkcl will do20:10
programmerjakesince they're cheaper than a lqarx stqcx. loop20:10
* lkcl has no clue how an elwidth ovrride would even work on lq / stq20:10
programmerjakeit won't...20:11
programmerjakeit's like asking how elwidth override works on a syscall20:11
lkclkylel, it will give you some confidence in the idea of a specification actually coming from an official source (OpenPOWER ISA v3.0B document)20:11
lkcland *compiling* it into an actual simulator20:11
lkcland some confidence in the fact that "if i modify the pseudocode, it changes the actual simulator... which... errr... isn't in python? moo?"20:12
lkclthere's a *python compiler* (!) which turns the v3.0B specification source code *INTO* python20:13
lkcland also the actual Power ISA *decoder* is in plain ASCII text file format (again, extracted from the spec, into machine-readable format)20:13
* lkcl deep breath20:13
ghostmansd-pckylel: despite how it looks, that's actually quite a nice stuff :-)20:13
ghostmansd-pcI really like the idea20:14
lkclyeah, it means we can do a c compiler and get a c code simulator "for free"20:14
lkcland there are people actively considering doing a Formal Proof (SAIL) as well20:14
kylelI was impressed by the pseudocode in the v3 manual20:14
lkcldoing a simple compiler20:14
lkclyeah, it's pretty readable and consistent20:15
lkcland it was an obvious natural step (at least to me) to ignore the warnings in the preamble, "warning, this is not intended to be executed", *make* it executable20:15
lkclthat involved adding ">u" and "<u" comparison operators (unsigned-less-than, unsigned-greater-than)20:16
ghostmansd-pc(actually it has some other differences, e.g. xor operator)20:16
ghostmansd-pcIIRC we even had these documented somewhere20:16
ghostmansd-pcI for sure recall I saw it20:17
lkclpainstakingly going through the spec (with unit tests as backup) to identify those comparators which, in the spec *wording* (in english), said, "this is a signed comparison"20:17
lkclghostmansd-pc, it's more that in the FrameMaker Source they picked a non-ASCII (scientific) symbol20:17
ghostmansd-pcwell, bitwise negation is not an easy to type as well :-)20:18
programmerjakelq demo:
lkclprogrammerjake, thx20:18
lkclprogrammerjake, can you raise a bugreport about this because, sigh, it needs properly investigating.20:18
ghostmansd-pclkcl: would it be sufficient for a lazy ass like me to execute this in src/? $(for each in ./*; do cd "$each"; git pull --rebase --recurse-submodules origin master; cd ..; done)20:19
lkcli have noooo idea for example what to do with elwidth overrides on lq / stq and it needs some thought20:19
lkclghostmansd-pc, pffh, perfect20:19
ghostmansd-pc(I don't account for errors, perhaps I'll write a script)20:19
lkcladd it to dev-env-setup :)20:19
lkcli just gave you write-perms :)20:20
* lkcl need to get up and walk about20:20
ghostmansd-pcOK, will do after tests20:20
programmerjakei'd say lq/stq don't support elwidth override20:20
lkclsitting too long20:20
lkclprogrammerjake, i'd tend to agree - we just need to document the reasons why20:20
programmerjakeuse ld/std if you want <128-bits20:21
lkclit's that it's involved in atomics, that makes it important to have20:21
* lkcl afk need to move about20:21
ghostmansd-pcprogrammerjake: so instructiomns less-than-128-bit are implicitly atomic?20:26
programmerjakeyes, if the load/stores are correctly aligned and going to normal memory...they are "relaxed" atomic20:28
ghostmansd-pcnice! any way to ensure barriers?20:31
programmerjakeyup...add lwsync or sync before or after20:33
programmerjakefor some details, see
programmerjakewell...just had fun discovering that thermal sensor #2 of 5 failed on my odroid xu4...20:35
programmerjakeit was randomly shutting down20:35
programmerjakei watched the readings and it randomly said 45 C and -25 C20:36
programmerjakei'm assuming the shutdowns are caused by it randomly saying 130 C or similar20:36
ghostmansd-pcbasically power also uses ll/sc, right?20:37
programmerjakei told linux to fake the sensor reading, always using 42 C20:38
ghostmansd-pcI mean, they name it differently, but the logic is the same20:38
programmerjakeghostmansd yes20:38
EmanuelLoos[m]Hello, have you ever considerd developing an open hardware 5G modem or do you know if such a project exists?20:38
ghostmansd-pcah, the answer for everything!20:38
programmerjakethe instructions are lqarx stqcx. and friends20:39
programmerjakeEmanuel Loos idk, sounds interesting!20:39
EmanuelLoos[m]programmerjake: The reason I am asking is that there appears to be no 4G modem usable without non-free drivers. The only non-free drivers the Librem 5 still needs are those for the modem.20:41
programmerjakeI'm aware of idk if it's open source though20:43
EmanuelLoos[m]programmerjake: Would this be useable in a smartphone?20:45
EmanuelLoos[m]programmerjake: Do you mean the software or the hardware?20:47
programmerjakeiirc it's software there, it's for software-defined-radio 4g/5g basestations20:48
programmerjakeidk what's open source if anything or everything20:49
EmanuelLoos[m]programmerjake: How good is a "software-defined-radio 4g/5g basestation" compared to a modem?20:51
programmerjakeit's the part that runs a celltower, not the part in a cellphone20:52
EmanuelLoos[m]Do you think NLNet would support developing a 5G modem too?20:53
ghostmansd-pclkcl: two good news!20:54
ghostmansd-pc1) I've finally been able to execute at least one test on talos20:54
ghostmansd-pc2) runs fine on xlen branch20:55
ghostmansd-pcbefore executing this one, I did $(git checkout xlen), please, confirm, this is sufficient :-D20:55
programmerjakethx for your hard work, ghostmansd and lkcl20:55
ghostmansd-pcah, wait, I forgot to update pywriter20:56
ghostmansd-pcone moment, will re-check20:56
ghostmansd-pcprogrammerjake: thank you too for your help!20:56
EmanuelLoos[m]programmerjake: Than I think it would be really great if that could be archived!20:57
ghostmansd-pcah, failed21:00
ghostmansd-pcanyway, at least I'm able to debug now :-)21:01
ghostmansd-pcok, 1 good news out of two, still good!21:01
ghostmansd-pcwill continue tomorrow21:01
lkclghostmansd-pc, well done21:02
lkclEmanuelLoos[m], look up the pinephone LTE modem reverse-engineering21:03
lkclyes that's the sort of thing nlnet has funded in the past (Haralde Welte's OpenBTS and reverse-engineering of Calypso chipsets)21:04
ghostmansd-pcI couldn't resist and checked what gone wrong in xlen branch21:07
ghostmansd-pcshould be fine now, pushing changes into master21:07
ghostmansd-pclkcl, could you, please, take a quick look to check whether we covered all fixedstore?21:08
ghostmansd-pcactions done: push xlen into remote; ssh talos; cd ~/src/openpower-isa; git fetch -a; git checkout xlen; git pull origin xlen --rebase; src/openpower/decoder/pseudo/; cd ~/src/soc; python3 ./src/soc/fu/compunits/test/test_ldst_compunit.py21:12
lkcllooks good, a couple of optimisations:21:14
lkclpywriter noall fixedstore21:14
lkcl(because *you* know you only modified fixedstore.mdwn)21:14
lkclthis will save several minutes of your time21:14
lkclpywriter because it's been installed into ~/.local/bin and that *should* be in the $PATH21:15
* lkcl rerunning now...21:16
lkclyaaa confirmed, all good21:16
* lkcl rerunning for about the 14th time in 3 days...21:16
EmanuelLoos[m]<lkcl> "yes that's the sort of thing..." <- Is it being developed further into free software drivers or, even better, an open hardware modem or has it been discontinued?21:34
lkclEmanuelLoos[m], this was about 8 years ago21:39
lkcland many others - full list is here
EmanuelLoos[m]So are there any open hardware modems resulting from these projects?21:48

Generated by 2.17.1 by Marius Gedminas - find it at!