| lkcl | ghostmansd, installed "apt-get install python", why the hell it wasn't already there i have no idea | 01:35 |
|---|---|---|
| lkcl | also it's extremely important - critically important - not to do *anything* other than the XLEN change | 01:36 |
| lkcl | no helpers, no extra routines, absolutely nothing. | 01:37 |
| lkcl | just | 01:37 |
| lkcl | XLEN | 01:37 |
| lkcl | nothing | 01:37 |
| lkcl | else | 01:37 |
| lkcl | explained why, here https://bugs.libre-soc.org/show_bug.cgi?id=671#c52 | 01:37 |
| toshywoshy | sorry my mistake, we have some new channels linked to working groups which are invite only, the main channel is free/open/libre | 02:00 |
| toshywoshy | I am correcting the channel mode | 02:00 |
| toshywoshy | ok, the channel should be back to normal | 02:08 |
| programmerjake | lkcl ghostmansd I tested test_pipe_caller_long.py on my system, and it never used more than 3-400MB of ram, so I have no clue how your getting 4GB...maybe you used nose or similar to run 10 copies in parallel? | 05:48 |
| programmerjake | only thing I can think of that would hit a 4GB ram limit pretty easily is *building* power-instruction-analyzer with a highly multi-core system...running 12 instances of rustc at once is entirely expected to need a bit of ram | 05:51 |
| programmerjake | sorry that doesn't help much... | 06:13 |
| programmerjake | lkcl if you can reproduce the ram usage, can you rebuild power-instruction-analyzer in debug mode (temporarily remove --release from pia's install script in pia's git repo), then run the test under valgrind massif? thanks! | 06:19 |
| programmerjake | if you like, upload valgrind's output file to jacob-build-server, that way you won't have to worry about server disk space | 06:22 |
| ghostmansd | What about adding extra variables? | 07:54 |
| ghostmansd | If we don't add new routines or helpers, can we add variables? | 07:55 |
| programmerjake | if the variables are local variables I think it's probably fine, since someone reading the spec wouldn't have to reference some other page of the pdf to figure out what it means...iirc I did that to the div/mod pseudocode | 08:17 |
| programmerjake | if they're external variables, we should avoid that as much as possible imho | 08:18 |
| programmerjake | external/global variables | 08:19 |
| ghostmansd | Ok, got it. I suggest to move to it in the next iteration, concentrating on mechanical replacements for now. | 08:41 |
| ghostmansd | I don't get why having a variable which equals XLEN/2 in multiple places is better than having a global HALF_XLEN, but OK. | 08:42 |
| ghostmansd | Perhaps it's better because spec readers won't have to dig what the heck HALF_XLEN is, though the name seems to be quite self-explanatory. | 08:43 |
| ghostmansd | So far, there are several things which are used extremely often: | 08:52 |
| ghostmansd | XLEN_WORD_LO := 0:((XLEN/2)-1) | 08:52 |
| ghostmansd | XLEN_WORD_HI := (XLEN/2):XLEN-1 | 08:52 |
| ghostmansd | XLEN_DOUBLE := XLEN*2 | 08:52 |
| ghostmansd-pc | programmerjake: I tried running $(python3 src/soc/fu/mul/test/test_pipe_caller_long.py) on talos, but end up with "ModuleNotFoundError: No module named 'soc'". Did I miss some step? | 08:53 |
| ghostmansd-pc | (I only executed (dev-env-setup/hdl-dev-repos-virtualenv) so far, I lack administrative privileges on talos, so I'm kinda unsure what steps must be done there on my side. | 08:54 |
| programmerjake | seems like you missed running `python3 setup.py develop` in soc/ | 09:03 |
| programmerjake | ...that should be in the scripts though... | 09:04 |
| lkcl | ghostmansd, yes new variables is perfect... but only in the pseudocode itself. repeated multiple times is also perfectly fine see... | 10:56 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=671#c50 | 10:56 |
| lkcl | e = XLEN/2-1 | 10:57 |
| lkcl | do i = 0 to 1 | 10:57 |
| lkcl | s = i*XLEN/2 | 10:57 |
| lkcl | keep them *short* | 10:57 |
| lkcl | if those are added to the namespace, we have to provide, as described in comment 50, a full, complete, absolute and documented justification and explanation | 10:57 |
| lkcl | followed by a formal Request For Change submission to the OpenPOWER FOundation ISA WG | 10:58 |
| lkcl | we're going to get hammered by questions | 10:58 |
| lkcl | what's this for | 10:58 |
| lkcl | what's this for | 10:58 |
| lkcl | what's the justification for this | 10:58 |
| lkcl | what's this for | 10:58 |
| lkcl | what's this for | 10:58 |
| lkcl | the less changes the less questions asked | 10:59 |
| lkcl | ghostmansd: yes, because readers of the spec, as explained here https://bugs.libre-soc.org/show_bug.cgi?id=671#c21 | 11:00 |
| lkcl | which you can see links to additional IRC logs | 11:00 |
| lkcl | the other thing is: i've done these kinds of massive code-morphs before (for many years) | 11:45 |
| lkcl | i learned the lesson the hard way that the changes need to be done in "stratification layers" | 11:45 |
| lkcl | toshywoshy: thanks :) | 11:51 |
| Las[m] | lkcl: Does working an ASIC as described on https://libre-soc.org/HDL_workflow/coriolis2/ actually work? | 12:46 |
| Las[m] | Is this the "final step" of the building process for the SoC? | 12:46 |
| lkcl | Las[m], yes | 12:47 |
| lkcl | pretty much | 12:47 |
| Las[m] | Thanks, I'll aim to get this working then | 12:47 |
| lkcl | that'd be really good | 12:47 |
| lkcl | were you able to run the alliance-check-toolkit "go.sh" tests? | 12:48 |
| Las[m] | Nope, not yet. | 12:48 |
| lkcl | some of those are known not to pass, but don't worry about them | 12:48 |
| Las[m] | lkcl: It's not immediately obvious to me how the code from the `soc` repository is used here | 12:48 |
| lkcl | they shouldn't consume vast resources, unlike ls180 | 12:48 |
| lkcl | as far as coriolis2 running with the soclayout repository contents, it isn't. | 12:49 |
| lkcl | the chain is: | 12:49 |
| lkcl | base-level dependencies nmigen yosys etc. | 12:49 |
| lkcl | soc dependencies: nmutil c4m-jtag ieee754fpu etc. | 12:50 |
| lkcl | *ASIC* dependencies for turning nmigen HDL into verilog, linked with some peripherals: litex soc pinmux | 12:50 |
| lkcl | ASIC dependencies for creating GDS-II files: FlexLib-FreePDK45, nsxlib, and soclayout | 12:51 |
| lkcl | where the output from "ASIC dependencies" was committed as PRE-BUILT and complete verilog into soclayout | 12:52 |
| Las[m] | ahhh | 12:52 |
| lkcl | it's a LARGE chain | 12:52 |
| lkcl | each step in the chain increases the size of the files by literally an order of magnitude | 12:52 |
| Las[m] | So I actually shouldn't depend on the soclayout repository if possible, since it's just the committed build output of another process | 12:52 |
| lkcl | but the key that you may be missing is that the... yes, exactly | 12:53 |
| lkcl | there is no need to package soclayout, but *other people* will want to git clone it in order to build it.... with the nix-packaged-coriolis2 | 12:53 |
| lkcl | however given that alliance-check-toolkit is an actual test suite (as well as containing nsxlib Cell Libraries) it would be sensible to package that | 12:54 |
| lkcl | arg i forgot, sorry, FlexLib-FreePDK45 should be on the list of nix-packages | 12:54 |
| lkcl | because it's a dependency of soclayout | 12:54 |
| lkcl | this is one of the releases https://gitlab.com/Chips4Makers/c4m-pdk-freepdk45/-/releases | 12:55 |
| Las[m] | Thanks. | 12:55 |
| * lkcl thinks.... | 12:56 | |
| lkcl | yep. | 12:56 |
| lkcl | if you wanted to actually try soclayout ls180 building, for god's sake don't do it on a machine with anything less than 32 GB of RAM, and don't for goodness sake try to run it in a qemu or other type of VM | 12:57 |
| lkcl | not unless you want to stress-test your hardware :) | 12:57 |
| Las[m] | Yeah I'll keep that in mind. This is a huge process honestly, but hopefully by packaging it in Nix it will become easier to build for the average layman user. | 12:59 |
| lkcl | Las[m], btw, if you examine alliance-check-toolkit go.sh you should be able to track down one single "Makefile" to try out | 13:00 |
| lkcl | yehyeh, it's a massive project, only going to get bigger | 13:00 |
| lkcl | VLSI development has been one of the top supercomputer uses since the 1980s. | 13:00 |
| lkcl | programmerjake: the idea was to not run (at all) an external unauthorised uncontrolled script, and to have the actual commands explicitly in dev-env-setup | 13:36 |
| lkcl | i've removed the use of the completely uncontrolled repository (debian salsa) which should never have been in there in the first place | 13:37 |
| lkcl | (i didn't realise it was) | 13:37 |
| lkcl | and i've taken a copy of the uncontrolled external script and placed its contents explicitly into dev-env-setup | 13:37 |
| lkcl | if debian salsa ever got hacked, it's completely outside of our control and we can do absolutely nothing about it | 13:38 |
| lkcl | or if it gets taken offline | 13:38 |
| lkcl | or if the account is terminated | 13:38 |
| lkcl | this is what i expected the script to look like | 13:39 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=commitdiff;h=63eab39255b833c09dd764d37b7e2570a057755d | 13:39 |
| lkcl | not | 13:39 |
| lkcl | "run a completely external script from an uncontrolled source" | 13:39 |
| lkcl | please can you check its contents and make sure that it's functional | 13:39 |
| lkcl | i've a version of pia that is functional here and i don't want to replace it in case it breaks. | 13:40 |
| *** farosas_ is now known as farosas | 15:22 | |
| programmerjake | lkcl: yeah, that looks correct...you can copy the old .so file and reinstall it if pia is broken...though it works just fine on my system | 17:46 |
| programmerjake | could also copy the old wheel, that will probably be more reliable | 18:25 |
| lkcl | ok that's good to know | 19:00 |
| lkcl | ghostmansd, ^ the pia install script in dev-env-setup should be fine, as always do check you're happy with the contents before running it | 19:01 |
| lkcl | (the reason programmerjake i copied the contents into dev-env-setup, you can see how "easy" it was to say that statement?) | 19:02 |
| lkcl | (if it was an external script, i couldn't say that. i'd have to say, "first, get dev-env-setup. then, get this external untrusted script manually by cloning an arbitrary repo. then, check both, and *only then* run the first one") | 19:03 |
| lkcl | toshywoshy, openpowerbot went to sleep again on us, last week, and i didn't notice :) | 19:10 |
| lkcl | interestingly it's logged in to both IRC channels, just not communicating back to mattermost | 19:10 |
| programmerjake | well, technically debian salsa is far from the only "external" source, there's pip, github (nmigen and others), rustup, crates.io, etc. | 19:13 |
| programmerjake | the difference is that we actually control the Kazan organization on Debian salsa, whereas we don't control most of the others | 19:14 |
| lkcl | i know. the less of that the better. debian's packaging is ring-of-trust protected, so can be trusted not to have been compromised. the rest (including salsa) cannot. | 19:15 |
| lkcl | unfortunately after taking a close look at nix last week, it's a single-point-of-failure team using a single github account and zero GPG-signing of any kind | 19:16 |
| lkcl | symbiflow's standard install scripts introduce conda *and* "wget xyz.google.com | bash" (!!!!) | 19:17 |
| lkcl | i've assigned Veera[m] the task of creating a dev-env-setup script which most definitely doesn't do any of that | 19:18 |
| lkcl | ghostmansd, programmerjake: after the XLEN addition is done 100% we'll close that bugreport (it's single-purpose and has got up to 50 comments in a veery short timeframe) | 19:43 |
| lkcl | and then move on to an "evaluation" phase | 19:44 |
| programmerjake | k | 19:44 |
| ghostmansd | You mean task 671? | 19:44 |
| lkcl | yes | 19:46 |
| ghostmansd | lkcl: can I update pia-install with actual rust downloading? | 19:46 |
| ghostmansd | "rustup not found" | 19:46 |
| lkcl | ghostmansd: ask programmerjake about that one | 19:46 |
| ghostmansd | programmerjake? :-) | 19:47 |
| ghostmansd | I mean, I see the disclaimer is shown by the script | 19:47 |
| ghostmansd | By why not download directly? | 19:47 |
| ghostmansd | FWIW, does it need root permissions? | 19:48 |
| ghostmansd | I'm downloading it now, but not sure whether I can install it :-) | 19:49 |
| programmerjake | the reason to get rustup instead of downloading rustc directly is that it makes it easy to follow upstream rust -- needed since power-instruction-analyzer depends on some very new features | 19:51 |
| ghostmansd | lkcl: I don't see divXXX patches in master... Did you push them? | 19:52 |
| programmerjake | in fact, it will shortly depend on a feature in rustc I wrote that will land in upstream rustc any hour now... | 19:52 |
| programmerjake | https://github.com/rust-lang/rust/pull/88350 | 19:52 |
| programmerjake | it's currently in rustc's auto-build/merge queue: https://bors.rust-lang.org/queue/rust | 19:54 |
| ghostmansd | lkcl: never mind, got lost on the way to the lake | 19:54 |
| ghostmansd | lkcl: I pushed popcntw into master, looks nice | 19:55 |
| ghostmansd | thanks for updating it, I think I'll go after others once all are updated for XLEN | 19:56 |
| ghostmansd | Ah, ok, already pushed | 19:57 |
| ghostmansd | Ok, I kinda get why you dislike branches, lol | 19:57 |
| ghostmansd | It looks like all is moved from xlen branch, right? | 19:59 |
| ghostmansd | BCD: should we deal with "as many 12 bits which can fit"? | 20:00 |
| programmerjake | I think elwidth=8 bcd<->dpd should be an illegal instruction | 20:05 |
| mikolajw | lkcl: this looks like a good starter bug, may I assign it to myself?: https://bugs.libre-soc.org/show_bug.cgi?id=665 | 20:07 |
| ghostmansd-pc | programmerjake: yes, quite likely, but tibetan monastery is also an option, as we discussed :-) | 20:11 |
| ghostmansd-pc | lkcl: pia-install "/usr/bin/python3: No module named pip" | 20:11 |
| ghostmansd-pc | lkcl: what is mode_is_64bit and how should it look in the future? | 20:12 |
| lkcl | mode_is_64bit is the contents of MSR.64b field | 20:15 |
| lkcl | mikolajw, sure, that'd be great, that one. it's quite involved, but ultimately quite simple | 20:16 |
| lkcl | the actual syntax output needed is a ridiculously short subset of c | 20:16 |
| lkcl | one thing: don't worry about anything over 64 bit in size, but plan for it as a possibility by using a #define, and macros... i'll outline it on the bugreport | 20:17 |
| ghostmansd-pc | say we have this: `if (mode_is_64bit) then M <- 0 else M <- 32`. M is then used upon indexing. | 20:19 |
| ghostmansd-pc | branch.mdwn | 20:20 |
| lkcl | yes. | 20:20 |
| lkcl | ah don't touch branches | 20:20 |
| programmerjake | <ghostmansd-pc> "lkcl: pia-install "/usr/bin/..." <- wow, no pip?! did you install the python3-pip package? | 20:20 |
| lkcl | all branches will not be subject to elwidth overrides | 20:20 |
| ghostmansd-pc | lkcl: aha, OK | 20:20 |
| lkcl | something really weird is going on with the talos2 workstation | 20:20 |
| lkcl | i'll deal with that. | 20:21 |
| lkcl | have to back down to debian/stable first | 20:21 |
| ghostmansd-pc | lkcl: you do run tests on talos, right? I mean, I'm not the first one? | 20:21 |
| programmerjake | I think we should just leave the talos2 at debian stable... | 20:21 |
| lkcl | frickin frickin frick. | 20:22 |
| lkcl | programmerjake, that's not possible | 20:22 |
| ghostmansd-pc | all I need is some quiet and simple place to check tests | 20:22 |
| programmerjake | makes installing new packages waay easier since you don't have to worry about replacing libc and a whole pile of other junk | 20:22 |
| lkcl | programmerjake: i know. too late. | 20:23 |
| lkcl | ghostmansd-pc: on a shared server, this isn't always how we want it to be | 20:23 |
| programmerjake | maybe just reinstall debian? | 20:23 |
| lkcl | ghostmansd-pc, you'll need to install pip3 locally from source | 20:23 |
| lkcl | no, it was a massive hassle last time | 20:23 |
| lkcl | the machine's *remotely* booted | 20:23 |
| programmerjake | you can use ensurepip, which comes with python by default | 20:23 |
| ghostmansd-pc | lkcl: SRR and MSR, do they need to be adopted (system.mdwn)? | 20:23 |
| lkcl | the only possible way i could get any OS of any kind installed was to upload a netboot "latest" ISO image.... *over a network connection*... to the back-end KVM management console | 20:24 |
| lkcl | ghostmansd-pc: no | 20:24 |
| ghostmansd-pc | ok, that's what I thought | 20:24 |
| lkcl | fixedshift.mdwn needs doing | 20:24 |
| lkcl | fixedstore.mdwn needs doing | 20:25 |
| ghostmansd-pc | bcd.mdwn? | 20:25 |
| lkcl | yes | 20:25 |
| lkcl | hilariously | 20:25 |
| programmerjake | ghostmansd a better alternative might be to just create a virtualenv and install libre-soc's python stuff in there, use the venv python module to do that | 20:25 |
| ghostmansd-pc | do we have some scripts intended to be used on talos for a new developer? | 20:26 |
| ghostmansd-pc | I already went through the process on debian VM, but I had admin permissions there | 20:26 |
| lkcl | virtualenv installed | 20:27 |
| lkcl | ghostmansd-pc, well, you do, but i'd prefer if you didn't use them unless absolutely absolutely necessary. | 20:27 |
| programmerjake | lkcl: use the venv module, it works better... | 20:27 |
| lkcl | programmerjake: ack. | 20:28 |
| programmerjake | python3 -m venv .... | 20:28 |
| ghostmansd-pc | I'm OK with whatever alternative plan we have | 20:28 |
| ghostmansd-pc | all I need is: | 20:29 |
| ghostmansd-pc | 1) being able to pull the code into soc and openpower-isa (plus checkout branches) | 20:29 |
| ghostmansd-pc | 2) running tests which are present in both | 20:29 |
| lkcl | ghostmansd-pc, this is a completely untested codepath. | 20:29 |
| lkcl | actually... it's not | 20:29 |
| ghostmansd-pc | ideally I'd think of some jenkins or whatever, but I'd be happy even if I have to run it manually | 20:29 |
| lkcl | tobias has a TALOS-II workstation at home | 20:29 |
| programmerjake | we will need to fix the talos's apt eventually, since I'll need clang which iirc requires updating libc6 to install by default | 20:30 |
| lkcl | well, the chroot dev-env-setup script _should_ work | 20:31 |
| ghostmansd-pc | For now, I'll proceed with fixedshift.mdwn, but anyway, being able to test is extremely important to me. I don't want lkcl or anyone else doing all tests for me. | 20:31 |
| lkcl | i've stopped it from editing //etc/fstab | 20:31 |
| programmerjake | ghostmansd-pc: iirc we have gitlab ci setup instead of jenkins, we're stalled on finishing off the setup though | 20:31 |
| lkcl | ghostmansd-pc, bear in mind i have to review and run the unit tests every single time. | 20:31 |
| lkcl | programmerjake: there's nothing stopping that from going ahead | 20:32 |
| programmerjake | umm, iirc there was some email redirecting stuff and git storage issues... | 20:32 |
| lkcl | no, no email redirection involved. | 20:33 |
| ghostmansd-pc | lkcl: yes, that's what I'm talking about as well. Ideally I'd commit the code in the branch, pull it on talos, test it and merge into master. | 20:33 |
| lkcl | i explained in the bugreport: you can use 10.6.0.1 as an SMTP gateway and install ssmtpd. | 20:33 |
| lkcl | ghostmansd-pc, ack. | 20:33 |
| ghostmansd-pc | This way I'd not bother anyone. Anyway, setting the environment is, well, problematic. :-) | 20:34 |
| lkcl | ohh yeah, i have no frickin idea why ssh-agent won't play nice. | 20:34 |
| lkcl | the "workaround" is to use rsync *back* to your local machine (sigh) | 20:34 |
| lkcl | rsync -HPavz | 20:34 |
| ghostmansd-pc | Neither me. But hey, I'm OK with push/pull on both sides, or rsync, or even scp for poor man's needs. | 20:35 |
| lkcl | i've followed all the tutorials on ssh-agent. | 20:35 |
| lkcl | script it, then it's mundane / rote | 20:35 |
| ghostmansd-pc | Virtually _any_ option to be able test is better than nothing. | 20:35 |
| lkcl | added the relevant thing on the server, added the relevant thing on the client configs. sigh | 20:35 |
| ghostmansd-pc | *to be able to test | 20:35 |
| ghostmansd-pc | Well, I also added options to ssh config, and still no luck. But hey, this is not that much of a problem. The real problem is environment. Ideally we should come up with some dev-env-setup-for-talos equivalent. | 20:37 |
| ghostmansd-pc | Perhaps a similar HDL workflow page. | 20:38 |
| ghostmansd-pc | CI is better, though, as long as it supports branches. | 20:38 |
| lkcl | ideally there should be "if grep /etc/debian_setup ppc64" or something | 20:39 |
| ghostmansd-pc | lkcl: I'm not touching MASK32, ROTL32 and others, as we discussed. | 20:39 |
| ghostmansd-pc | Still I think at least renaming these would be unavoidable. | 20:40 |
| lkcl | nope, not at this point | 20:40 |
| ghostmansd-pc | No, I don't mean now. | 20:40 |
| ghostmansd-pc | I mean, eventually. | 20:40 |
| lkcl | ngggh yeah | 20:40 |
| lkcl | yehyeh got it | 20:40 |
| lkcl | two possibilities there: change their meaning for SVP64 (which gets hellishly confusing) or change their name | 20:41 |
| lkcl | that's what will require some justification and discussion. all of which will need to be documented as part of an official ISA Spec Request for Change | 20:41 |
| ghostmansd-pc | the name change is the best option imho; like EXTS, there might be ROTL et al. | 20:43 |
| ghostmansd-pc | lkcl: rlwnm is an interesting one; should `n` always be 4 bits? | 20:45 |
| ghostmansd-pc | BTW, in specs we have not ROTL32, but ROTL + 32 in lowercase | 20:46 |
| ghostmansd-pc | so it's kinda _simpler_ to change, I think; it basically tells not to use ROTL32(arg), but ROTL(32, arg)... | 20:47 |
| lkcl | ghostmansd-pc, 1 sec let me take a look. that's 2 questions | 20:47 |
| ghostmansd-pc | page 100 in rev. C | 20:47 |
| lkcl | ha, got it | 20:47 |
| lkcl | 63-59+1 | 20:48 |
| lkcl | 5 bits | 20:48 |
| lkcl | you forgot the +1, counting inclusive | 20:48 |
| lkcl | ahh i see how it ended up ROTL32, it's because cut/paste from pdftotxt that was a subscript :) | 20:48 |
| lkcl | doh | 20:48 |
| lkcl | yes, absolutely, go for it, make it ROTL(width, input, rotamount) | 20:49 |
| ghostmansd-pc | you mean, adjusting helpers? | 20:49 |
| lkcl | that's actually a bug in the pseudocode | 20:49 |
| lkcl | yes. | 20:49 |
| lkcl | 1 sec... where's section 1.3.2.... | 20:49 |
| lkcl | chapter 1, p7 | 20:50 |
| lkcl | ahno. | 20:50 |
| ghostmansd-pc | that said... we have EXT64 as function in both spec and mdwn | 20:50 |
| lkcl | right. | 20:50 |
| lkcl | they do actually have ROTLsubscript32 and ROTLsubscript32 | 20:50 |
| lkcl | so leave those for now as ROTL32 and ROTL64 | 20:50 |
| lkcl | yes, that _was_ unavoidable | 20:51 |
| ghostmansd-pc | why haven't they used EXTS? it looks like it should do the trick? | 20:51 |
| lkcl | because for EXTS64, that specifies the *source* width (if i recall correctly) | 20:51 |
| ghostmansd-pc | I mean, it'd just propagated the sign, wouldn't it? | 20:51 |
| lkcl | EXTS _should_ behave by detecting the source and dest width | 20:51 |
| lkcl | as in: "take the MSB of the source at the width of the source and jam it up in all the upper bits" | 20:52 |
| lkcl | however... ahh, p108 v3.0B | 20:52 |
| lkcl | they used something that's just simply not listed in the spec | 20:53 |
| lkcl | so it got added despite not being listed on p7 v3.0C | 20:53 |
| lkcl | sorry p108 v3.0C | 20:53 |
| ghostmansd-pc | OK, I'll keep ROTL32 as is for now | 20:54 |
| ghostmansd-pc | yet another question: is our parser case-insensitive? | 20:54 |
| ghostmansd-pc | * rldicl RA,RS,SH,MB (Rc=0) | 20:55 |
| ghostmansd-pc | b <- mb[5] || mb[0:4] | 20:55 |
| lkcl | no it is not. | 20:55 |
| lkcl | those are DEFINITELY different fields. see section 1.7 | 20:56 |
| lkcl | p16-22 | 20:56 |
| lkcl | and also fields.txt | 20:56 |
| ghostmansd-pc | ah, OK | 20:56 |
| ghostmansd-pc | this won't be changed | 20:57 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/fields.text;h=f1ba11efb1372c13d1a24337ccd9f53bd0003c74;hb=970dc264166ef3ed184ae60fbe91d43d9c4d350e | 20:57 |
| lkcl | noooo definitely not | 20:57 |
| ghostmansd-pc | OK, got it | 20:57 |
| lkcl | basically in the upgrade some time around 2000 from 32-bit to 64-bit | 20:57 |
| lkcl | they realised they had to shoe-horn an extra bit in somehow | 20:58 |
| lkcl | so the field named "SH" is 6 bits... | 20:58 |
| lkcl | but it's *constructed* from the contents of bits 16-20 and bit 30 | 20:58 |
| lkcl | and that field is called "sh" | 20:59 |
| lkcl | so it's "SH" in the assembler but "sh" in the bitfields | 20:59 |
| lkcl | yeah, i know :) | 20:59 |
| lkcl | PowerDecoder actually successfully takes care of that for you | 20:59 |
| lkcl | but in this particular case, for some bizarre unknown reason, the spec writers wanted "n" spelled out | 21:00 |
| lkcl | probably because people kept constructing it wrong | 21:00 |
| ghostmansd-pc | I don't quite get it | 21:03 |
| ghostmansd-pc | I mean, I understand SH/sh, and MB/mb | 21:03 |
| lkcl | but look at the bit-order, how they're constructed | 21:04 |
| ghostmansd-pc | But this: (RB)[59:63], in rlwnm | 21:04 |
| lkcl | can _you_ remember which one is MSB0? | 21:04 |
| ghostmansd-pc | should this be converted? and, if yes, should it depend on XLEN? | 21:04 |
| lkcl | yes. | 21:04 |
| lkcl | at least n <- RB(XLEN-5:XLEN-1) | 21:05 |
| ghostmansd-pc | and what the dependency would be? does n scales appropriately? | 21:05 |
| lkcl | when we do actual XLEN=32-bit that'll... | 21:06 |
| lkcl | actually because it's a ROTL it doesn't technically matter if it's rotated "multiple times" | 21:06 |
| lkcl | if n (the number) is 31 | 21:06 |
| lkcl | and the elwidth is 8 | 21:06 |
| lkcl | the *actual* rotation would be only 7 | 21:06 |
| lkcl | i.e. 31 MODULO 8 | 21:06 |
| lkcl | but let's not dwell on that quite just yet | 21:07 |
| lkcl | do make a mental note, though | 21:07 |
| ghostmansd-pc | the specs talk of low-order 32 bits | 21:07 |
| ghostmansd-pc | so if it's _always_ low-order 32 bits, that's OK | 21:08 |
| ghostmansd-pc | I mean RB(XLEN-5:XLEN-1) would be OK | 21:08 |
| lkcl | yes. this will be another one that will need to be redefined as "low-order half-of-the-register-width" | 21:08 |
| lkcl | ghostmansd-pc: that's what i just went through. | 21:08 |
| ghostmansd-pc | so this "32 bits" again implies "32 since 64 in register, feel free to adjust"? | 21:09 |
| lkcl | ROTL32, if "re-tasked" to perform ROTL8, would not actually care if its input shift-amount was 7, 15, 2*8+7, 3*8+7, 4*8+7 .... | 21:09 |
| lkcl | yes... but not in the "official" spec. | 21:09 |
| lkcl | the behaviour when XLEN=64 must be "exactly the behaviour of Official Power ISA v3.0B" | 21:09 |
| lkcl | the behaviour when XLEN=32/16/8 has to be, "as *WE* define it, in such a way that it's not completely insane" | 21:10 |
| lkcl | (or totally useless) | 21:10 |
| ghostmansd-pc | OK, got it | 21:10 |
| ghostmansd-pc | but what should we do for now? should we define it already? | 21:10 |
| lkcl | it's a subtle difference | 21:10 |
| ghostmansd-pc | or let's for now stick to 32? | 21:10 |
| ghostmansd-pc | doh, 5 | 21:11 |
| lkcl | yes. | 21:11 |
| ghostmansd-pc | well, you know what I mean | 21:11 |
| lkcl | that's explained above (twice) | 21:11 |
| lkcl | n will always remain at RB(XLEN-5:XLEN-1) | 21:11 |
| lkcl | because of special properties of ROTATE | 21:11 |
| lkcl | the bits are being *ROTATED* here | 21:12 |
| lkcl | if the rotate hardware is 8 bits wied | 21:12 |
| lkcl | and you try to rotate 7 times | 21:12 |
| lkcl | it's identical - absolutely identical - to rotating 7+8 times | 21:12 |
| lkcl | or 7+8*2 times | 21:12 |
| lkcl | or 7+8*3 times | 21:12 |
| ghostmansd-pc | you mean that we will change the ROTL only? | 21:12 |
| lkcl | yes. | 21:12 |
| ghostmansd-pc | but this is still confusing as hell | 21:12 |
| lkcl | ok let's go through it | 21:13 |
| lkcl | let's define XLEN=8 | 21:13 |
| ghostmansd-pc | no, I understand what you mean | 21:13 |
| lkcl | ROTL will then be an 8-bit rotate | 21:13 |
| ghostmansd-pc | I'm talking of different thing | 21:13 |
| lkcl | ... ok | 21:13 |
| lkcl | go on | 21:13 |
| lkcl | important to establish the discrepancy in understanding here | 21:13 |
| ghostmansd-pc | if `n` is (2 ^ appropriate_power), this is cleaner | 21:14 |
| lkcl | ah, yes. | 21:14 |
| ghostmansd-pc | that's what I mean | 21:14 |
| lkcl | but if you think through the pseudocode, it would require a batch of extra code | 21:14 |
| ghostmansd-pc | I mean, I understand it'd work regardless due to ROTATE | 21:14 |
| lkcl | and i was thinking ahead of the possibility of being hit by massive amounts of questions | 21:15 |
| ghostmansd-pc | but still having an appropriate power of 2 looks a _bit_ cleaner | 21:15 |
| lkcl | what does this do | 21:15 |
| lkcl | why was this change made | 21:15 |
| lkcl | etc. etc. | 21:15 |
| lkcl | and if we can minimise the *changes* to the spec - even if they're "confusing" - i am predicting we'll have an easier time | 21:15 |
| ghostmansd-pc | if I'd read the spec, I'd find this highly confusing :-) | 21:16 |
| lkcl | i am thinking "Politics Of People Behind The OPF ISA WG" | 21:16 |
| lkcl | as in: we have been warned (in advance) that there are some people who believe that we are trying to play stupid political games | 21:16 |
| ghostmansd-pc | because a power of two makes things clearer, it's just "since XLEN=64, you take as many bits as XLEN/2 takes" | 21:17 |
| lkcl | yehyeh | 21:17 |
| ghostmansd-pc | yehyeh | 21:17 |
| lkcl | lol | 21:17 |
| ghostmansd-pc | "and get 32" | 21:17 |
| lkcl | i had to add pseudocode that did log2(N) | 21:17 |
| lkcl | it's not pretty | 21:17 |
| ghostmansd-pc | OK, for now I've pushed some simple fixedshift.mdwn changes into xlen | 21:18 |
| lkcl | excellent | 21:18 |
| ghostmansd-pc | I hope to continue tomorrow | 21:18 |
| ghostmansd-pc | bb | 21:18 |
| lkcl | ack. thx ghostmansd-pc | 21:18 |
| lkcl | ok all the fixedshift.mdwn cut over | 21:28 |
| lkcl | rest. | 21:28 |
| lkcl | meeting 40 mins | 21:28 |
| lkcl | test_issuer.py running for the 9th time in 2 days... :) | 21:28 |
| programmerjake | isn't the meeting in 1h8m and not 8m? | 21:52 |
| lkcl | yes, doh | 22:07 |
| programmerjake | meeting in 10min | 22:50 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!