| Veera[m] | programmerjake: What is the procedure to git pul repos | 01:32 |
|---|---|---|
| Veera[m] | python3 setup.py develop should be rerun? | 01:33 |
| Veera[m] | for openpower-isa: are these to be rerun: make svanalysis make pywriter make pyfnwriter | 01:34 |
| programmerjake | the process I use isn't necessarily the best one...I git pull all repos then run the make commands in openpower-isa.git's readme | 01:34 |
| programmerjake | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=README.md;h=708b81e2d4fb1f91e9311dc9ef58fcb12ad09e6a;hb=HEAD | 01:35 |
| programmerjake | setup.py only rarely needs to be rerun | 01:35 |
| programmerjake | @lkcl likely uses a different process | 01:36 |
| Veera[m] | I just made new clones and setup again as per hdl-dev-repos and it is working | 01:36 |
| programmerjake | that works, but is really slow | 01:37 |
| Veera[m] | yes | 01:38 |
| Veera[m] | lst = [f"subf 3, 1, 2"]... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ce6a6921e01609ec25be1b976e1c4249111e5e0c) | 01:50 |
| Veera[m] | I think e.intregs[3] should be -0x670e65d9e273943e | 01:51 |
| Veera[m] | In python3 prompt I ran hex(~0x833652d96c7c0058+0x1c27ecff8a086c1a+1) | 01:52 |
| Veera[m] | I beforehand tell that am weak in binary arithmetic | 01:54 |
| programmerjake | well, actually the answer in the source is correct, the 0x98f... value is interpreting the 64-bit register value as an unsigned integer, the -0x670... value is interpreting it as signed. you get the unsigned value by masking out bits above bit 63: -0x670... & (2 ** 64 - 1) == 0x98f... | 01:57 |
| programmerjake | bit 63 in lsb0 form | 01:59 |
| Veera[m] | Thanks for explaining, i will find and learn it. | 02:00 |
| programmerjake | https://en.wikipedia.org/wiki/Two%27s_complement | 02:01 |
| programmerjake | basically all modern computers use two's complement as the representation of signed integers | 02:02 |
| programmerjake | python takes the approach of conceptually having two's complement but extending it to an infinite number of bits, that way the programmer never has to worry about python integers overflowing | 02:04 |
| programmerjake | hopefully you found that useful and not just repeating what you already knew | 02:08 |
| Veera[m] | got it. it's print the signed value as unsigned value in hex. | 02:31 |
| Veera[m] | Add expected state to case_addze for addze in alu_cases unit test | 05:44 |
| Veera[m] | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=ce665ff472f07bce2da662c79a275597dbf56999 | 05:44 |
| Veera[m] | Is the code format and placement ok? | 05:45 |
| Veera[m] | Also removed a non-use code line: self.add_case(Program(lst, bigendian), initial_regs) | 05:45 |
| Veera[m] | I think Kyle has not updated CR fixes yet | 05:46 |
| Veera[m] | Rest of cases depend on it, except some xer lines cases. | 05:47 |
| Veera[m] | What is initial_sprs in: self.add_case(Program(lst, bigendian), initial_regs, initial_sprs) | 05:49 |
| Chips4Makers[m] | @lkcl: I'm afraid typing annotations is another thing we'll have to agree to disagree on. I am using an editor that does the type checking when typing the code and it has tremendously increased my productivity. For me there is no way back and all new code I write is with type annotations. | 09:01 |
| programmerjake | yup, that's a major part of why I like using pyls and type annotations | 09:06 |
| programmerjake | Veera initial_sprs is the initial values of the PowerPC special-purpose registers, that's where CR, XER, and similar are | 09:10 |
| lkcl | Veera[m], you should never have to re-run "python3 setup.py develop", that's the whole point | 09:11 |
| Veera[m] | programmerjake: ok. do you know how to put expected=e in such case? | 09:11 |
| lkcl | only when the markdown or csv files change do you need to re-run make svanalysis etc. | 09:12 |
| Veera[m] | lkcl: ok. I will never run python3 setup develop | 09:12 |
| lkcl | which is also quite rare | 09:12 |
| lkcl | but will (and does) happen | 09:12 |
| lkcl | Veera[m], try not to drop too long messages into matrix. this is what happened: | 09:13 |
| lkcl | <Veera[m]> lst = [f"subf 3, 1, 2"]... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ce6a6921e01609ec25be1b976e1c4249111e5e0c) | 09:13 |
| programmerjake | Veera idk off the top of my head, lkcl should know, i'll let him answer | 09:13 |
| * lkcl catching up | 09:13 | |
| lkcl | it is also completely unnecessary to re-clone everything. | 09:14 |
| lkcl | this again you should never need to do | 09:14 |
| Veera[m] | yep. followed. | 09:15 |
| lkcl | "<Veera[m]> Is the code format and placement ok?" | 09:16 |
| lkcl | if it runs, and passes, and produces no errors (syntax or otherwise) it's fine | 09:16 |
| Veera[m] | yes. it runs and passes. I am waiting for fix in CR print values? | 09:19 |
| Veera[m] | def case_addme_ca_0(self): I do not know how to put expected state and values! | 09:20 |
| * lkcl hmmm | 09:21 | |
| lkcl | try it anyway. try case_cmp and see how it goes | 09:21 |
| lkcl | don't worry about what values come out, but... oh i know what: from the "dump" put that actually in the source, but commented-out | 09:23 |
| Veera[m] | It is still failing in case_1_regression "add." test and run | 09:23 |
| lkcl | so to reiterate: if it is failing, then your immediate reaction should always always always, without fail, alter the program so that it does succeed | 09:24 |
| Veera[m] | Actually CR assertions fail | 09:24 |
| lkcl | ok | 09:24 |
| lkcl | then leave the "failed" version in as commented-out code | 09:24 |
| lkcl | and alter the value so that it does succeed | 09:24 |
| lkcl | then | 09:24 |
| lkcl | we can compare the two | 09:24 |
| Veera[m] | lkcl: I am too new to this. | 09:24 |
| lkcl | again, to reiterate: we know that these unit tests are correct | 09:25 |
| Veera[m] | So I cannot alter the required program! | 09:25 |
| lkcl | because the HDL has already been compared against the Simulator, and against qemu | 09:25 |
| lkcl | cannot alter the required program? | 09:25 |
| lkcl | i don't understand | 09:26 |
| lkcl | can you commit what you have and git push it, i will take a look | 09:26 |
| Veera[m] | https://bugs.libre-soc.org/show_bug.cgi?id=730#c23 this bug has not been fixed till now | 09:26 |
| lkcl | Veera[m], ignore that - let's investigate | 09:27 |
| lkcl | pelase commit what you have so i can take a look | 09:27 |
| lkcl | hmmm /tmp/expected/alu_cases/case_1_regression only has 3 lines when there are 6 tests, hmmm | 09:32 |
| lkcl | ohh it's overwriting | 09:32 |
| Veera[m] | def case_1_regression(self):... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a9820b35efcc7109188556e55b97f702f464718e) | 09:33 |
| Veera[m] | cr assertion fails | 09:33 |
| lkcl | Veera: again, that's too long a message so it has gone to a matrix off-site system | 09:34 |
| Veera[m] | cr0 = 0 but 0x8 | 09:34 |
| lkcl | <Veera[m]> def case_1_regression(self):... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a9820b35efcc7109188556e55b97f702f464718e) | 09:34 |
| lkcl | ok i'll add that and try it | 09:34 |
| Veera[m] | lkcl: sorry | 09:34 |
| Veera[m] | lkcl: so how to put these kind of lengthy msgs | 09:35 |
| lkcl | although it is a pain, paste them only a few lines at a time | 09:35 |
| lkcl | maximum of about... 4 | 09:35 |
| lkcl | but be careful of IRC flooding | 09:35 |
| Veera[m] | if some one posts in between there will be break | 09:35 |
| lkcl | not a problem | 09:35 |
| Veera[m] | max 4: ok | 09:35 |
| lkcl | or, just commit it (as i asked) | 09:36 |
| lkcl | it's rare to commit code that doesn't pass tests | 09:36 |
| lkcl | but ok | 09:36 |
| lkcl | because the tests are there to show errors | 09:37 |
| lkcl | okaaay so now we have an unexpected value, i'm committing that | 09:38 |
| lkcl | with a comment to say "it's being investigated" | 09:38 |
| lkcl | Veera[m], do git pull | 09:41 |
| lkcl | commit 619081e1678d309228a758ba52cfeba22705095c | 09:41 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=619081e1678d309228a758ba52cfeba22705095c | 09:41 |
| Veera[m] | saw the change(diff) | 09:45 |
| lkcl | did you run it? | 09:45 |
| Veera[m] | I had already run it in morning. If I run it will produce same error. | 09:46 |
| Veera[m] | Or have you made it work! | 09:46 |
| lkcl | why do you believe that? | 09:46 |
| lkcl | i am walking you through the process, so there may be some differences, yes? | 09:47 |
| lkcl | i was not awake in your morning-time :) | 09:47 |
| lkcl | there will now be a difference between what you wrote in your morning-time, and what i just committed | 09:48 |
| lkcl | and i would like to walk you through it, which i can't do if you don't run it :) | 09:48 |
| lkcl | because you won't be able to see for yourself the differences in the output | 09:48 |
| lkcl | between what you ran a few hours ago, and the results that are created by what i just committed | 09:49 |
| lkcl | so please do a git pull and re-run the test | 09:49 |
| lkcl | what results did you get? | 09:52 |
| lkcl | it should be a lot shorter / quicker to run | 09:53 |
| lkcl | (you only have to do "git pull" on openpower-isa | 09:53 |
| lkcl | no other commands need to be run | 09:53 |
| lkcl | except to run the test itself of course | 09:53 |
| Veera[m] | ok it passes. | 09:53 |
| lkcl | python3 simple/test/test_issuer.py nosvp64 alu >& /tmp/f1 | 09:53 |
| Veera[m] | you put e.crregs[0] = 0x0 | 09:55 |
| Veera[m] | but with "add." opcode CR0 != 0 | 09:55 |
| lkcl | yes. sooOooo... | 09:56 |
| Veera[m] | the previuosly run expected state CR0 == 0x8 is correct | 09:56 |
| lkcl | it looks like... the CRs are not being properly outputted | 09:57 |
| lkcl | i need to check the Asserts | 09:57 |
| Veera[m] | That's what i am trying to say | 09:58 |
| lkcl | i'm going to put the log in a loop first | 09:58 |
| lkcl | then the asserts | 09:58 |
| lkcl | for i, (self.crregs, s2.crregs) in enumerate( | 09:58 |
| lkcl | zip(self.crregs, s2.crregs)): | 09:58 |
| lkcl | log("asserting...cr", i, self.crregs, s2.crregs) | 09:58 |
| lkcl | *then* asserts | 09:58 |
| Veera[m] | And previous bug:730 comment 23 | 09:58 |
| lkcl | so that the asserts don't stop the entire log output from happening | 09:59 |
| lkcl | then we can see the numbering | 09:59 |
| lkcl | ok there's something weird going on | 10:01 |
| lkcl | ok i know what it is | 10:03 |
| lkcl | kylel, you had this: | 10:04 |
| lkcl | for i, (self.crreg, self.crreg2) in enumerate(self.crreg, self.crreg2) | 10:05 |
| lkcl | which will enumerate as expected, but destroy - overwrite self.crreg and self.crreg2 in the proces | 10:05 |
| lkcl | likewise for intregs | 10:05 |
| lkcl | ahhh noooow we have what i was thinking would happe | 10:06 |
| lkcl | asserting...cr 0 0 8 | 10:06 |
| lkcl | asserting...cr 1 0 0 | 10:06 |
| lkcl | asserting...cr 2 0 0 | 10:06 |
| lkcl | asserting...cr 3 0 0 | 10:06 |
| lkcl | asserting...cr 4 0 0 | 10:06 |
| lkcl | asserting...cr 5 0 0 | 10:06 |
| lkcl | asserting...cr 6 0 0 | 10:06 |
| lkcl | asserting...cr 7 8 0 | 10:06 |
| lkcl | haaa :) | 10:06 |
| lkcl | Veera[m], okaaay try now. git pull | 10:08 |
| Veera[m] | trying | 10:08 |
| lkcl | Veera[m], see how the number for the CR field is 76543210 not 01234567? | 10:08 |
| lkcl | but there was a 2nd error masking the 1st error | 10:09 |
| lkcl | hmmmm... | 10:13 |
| lkcl | arrrgh | 10:14 |
| Veera[m] | asserting...cr 7 8 0 -- why value 8 and 0 | 10:14 |
| Veera[m] | test passes though | 10:15 |
| lkcl | ngggh ok, so the regs returned by HDLState.get_crregs() is inverted | 10:16 |
| lkcl | it didn't have the 7- | 10:16 |
| lkcl | 7-i | 10:16 |
| lkcl | sigh | 10:16 |
| lkcl | frickin Power ISA :) | 10:16 |
| lkcl | def get_crregs(self): | 10:17 |
| lkcl | self.crregs = [] | 10:17 |
| lkcl | for i in range(8): | 10:17 |
| lkcl | rval = yield self.core.regs.cr.regs[7-i].reg | 10:17 |
| lkcl | in soc/simple/test/teststate.py | 10:17 |
| lkcl | gaaah! | 10:18 |
| kylel | lkcl, ugh, sorry about that | 10:20 |
| lkcl | it's only driving me slightly nuts. like it does every time dealing with this :) | 10:21 |
| kylel | only slightly? ;-) | 10:21 |
| lkcl | 5 months tracking down numbering-order bugs, it's no surprise everyone else has the same problem | 10:24 |
| * cesar is looking for the right Pipeline/Handshake class to use. | 10:25 | |
| lkcl | cesar: i'd suggest just using direct for now, but if you do want to use one, use SimpleHandshake | 10:26 |
| lkcl | if you'd like to do "direct", see how things are set up in core.py, now | 10:26 |
| lkcl | it's pretty close to how things are in TestIssuer already | 10:26 |
| kylel | in hindsight I should have asked more questions way back when doing it by borrowing parts of the original code because it always struck me as odd instead of treating it as some sort of magical black box. live and learn. | 10:28 |
| lkcl | oh you actually changed the numbering from what it was? | 10:29 |
| lkcl | Veera[m], ok all done | 10:30 |
| lkcl | git pull on openpower-isa _and_ soc this time | 10:30 |
| Veera[m] | did you changed cse to case for all the tests | 10:31 |
| Veera[m] | trying what you said | 10:31 |
| lkcl | yes, to save time | 10:34 |
| cesar | lkcl: I'd rather use "direct" (derive straight from ControlBase), and do my own valid/ready handshake. Thanks! | 10:34 |
| lkcl | cesar, yehyeh, that's what i do in core.py :) | 10:35 |
| lkcl | do try to keep to the StageAPI though, by adding ispec() and ospec() functions | 10:35 |
| cesar | Sure. | 10:35 |
| lkcl | this will "force" a need to create Input and Output data structures | 10:35 |
| lkcl | whiiiich of couuurse, you can then use the output data struct from the previous as the exact same input data struct for next | 10:36 |
| lkcl | which is the whole point of the Stage API :) | 10:36 |
| Veera[m] | lkcl: test working perfect | 10:36 |
| lkcl | Veera[m], kylel, hooraaay | 10:37 |
| Veera[m] | lkcl: is there any simple way to revert def cse_ to def case_ | 10:37 |
| lkcl | Veera[m], if you use vi: ":%s/def cse_/def case_/g" | 10:38 |
| lkcl | i've done it and committed it already | 10:38 |
| lkcl | git pull | 10:38 |
| lkcl | you can do the opposite of course as well | 10:38 |
| Veera[m] | saw it | 10:40 |
| lkcl | ok now i need something to drink, and to try to get rid of this massive headache | 10:40 |
| lkcl | back later | 10:40 |
| Veera[m] | is there a reason why register values are printed in decimal value! | 10:40 |
| lkcl | no :) | 10:47 |
| lkcl | # pc and intregs | 10:47 |
| lkcl | sout.write("%se = ExpectedState(pc=%d)\n" % (lindent, state.pc)) | 10:47 |
| lkcl | change that to "pc=0x%x" | 10:48 |
| lkcl | this is correct msg = "%se.crregs[%d] = 0x%x\n" | 10:48 |
| lkcl | oh wait... do you mean in the assertions? | 10:48 |
| lkcl | self.dut.assertEqual(intreg, intreg2, | 10:49 |
| lkcl | "int reg %d (%s) not equal (%s) %s. got %x expected %x" % | 10:49 |
| lkcl | the python unit test code - the function assertEqual - will automatically print out the values it is comparing if they are different | 10:49 |
| lkcl | it does so.... in decimal | 10:49 |
| lkcl | because that's no so useful, we have added a debug printout line, which _does_ print out in hexadecimal | 10:50 |
| lkcl | got %x expected %x | 10:50 |
| lkcl | but | 10:50 |
| lkcl | you can't disable the default behaviour of assertEqual | 10:50 |
| lkcl | so you get both | 10:50 |
| Veera[m] | lkcl: def case_addme_ca_0(self): how to put expected=e in it! | 10:56 |
| lkcl | MaciejPijanowski, ghostmansd[m], ping, you saw the NLnet cavatools port is approved? | 10:57 |
| lkcl | Veera[m], ahh that one will be fun | 10:57 |
| lkcl | probably something like... oh i know | 10:59 |
| lkcl | addme_e = ExpectedState(...) | 11:00 |
| lkcl | addme__e = ExpectedState(...) | 11:00 |
| lkcl | admeo = ExpectedState(...) | 11:00 |
| lkcl | addmeo_ = ... | 11:00 |
| lkcl | 1 sec let me do a demo | 11:01 |
| ghostmansd[m] | lkcl: Hi, yes, I'm reading it now. I'll be able to deal with it at the end of this month (likely circa November 23). | 11:03 |
| lkcl | ghostmansd[m], star | 11:04 |
| ghostmansd[m] | And for sure no sooner than I get something from NLnet. :-) | 11:04 |
| lkcl | :) | 11:04 |
| lkcl | yes. sigh | 11:04 |
| lkcl | Veera[m], done, git pull | 11:30 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=fbd1e710462a99360805a8d0c7299e77cc627365 | 11:30 |
| lkcl | so you can copy that style for case_addme_ca_1 | 11:30 |
| lkcl | by looking at /tmp/expected/alu_cases/case_addme_ca_1.py | 11:31 |
| lkcl | and going, "hmm that expected state produced that value, so put that inside the "if" statement..." | 11:31 |
| lkcl | i put in some comments so you can see how it works | 11:32 |
| lkcl | also if you do: | 11:32 |
| lkcl | diff -u /tmp/expected/alu_cases/case_addme_ca_0.py | 11:32 |
| lkcl | /tmp/expected/alu_cases/case_addme_ca_1.py | 11:32 |
| lkcl | you should be able to much easily guage what to do | 11:33 |
| lkcl | but yes, e.crregs[7] = 0x4 is, i think, correct! | 11:34 |
| lkcl | or... errr... | 11:34 |
| lkcl | probably not, actually | 11:34 |
| lkcl | that's sticky overflow | 11:35 |
| lkcl | which should go into CR0.SO | 11:35 |
| kylel | lkcl, You want me to run it through qemu? | 12:39 |
| lkcl | kylel, i got disconnected, luckily i saw the opf chat. yes good idea | 16:28 |
| lkcl | although, there's actually no guarantee that qemu has this right! | 16:45 |
| kylel | lkcl... | 18:46 |
| kylel | using addme. with 0x7ffffffff | 18:47 |
| kylel | cr: 0b1000000000000000000000000000000 | 18:49 |
| kylel | big endian, shows 4 | 18:49 |
| kylel | in cr7 | 18:50 |
| kylel | or then it could be cr0 because reversed? | 18:53 |
| kylel | lol, ugh | 18:54 |
| kylel | ok, verified bit ordering using case_cmp2 which should modify cr2 | 19:10 |
| kylel | that one is: 0b1000000000000000000000 | 19:11 |
| kylel | so indeed, cr0...cr7 order from qemu | 19:12 |
| lkcl | so it is CR0.SO that's being set, not CR7.SO | 21:07 |
| kylel | appears that way | 21:32 |
| Veera[m] | lkcl: hey how much money you are setting for this bug | 21:41 |
| lkcl | Veera[m], depends roughly on how long it takes. i'll work it out as we go along, then you tell me if it's ok? | 21:42 |
| Veera[m] | lkcl: let's see | 21:43 |
| Veera[m] | lkcl: running def case_addme_ca_0(self) for "addmeo." : /tmp/expected/alu_cases/case_addme_ca_0.py: does not shows e.crregs[0] = 0x4 | 22:59 |
| lkcl | Veera[m], kylel added a test that, once an expected case is added, it no longer gets entered into /tmp/expected | 23:04 |
| Veera[m] | got it. So i was looking at old one!!! | 23:17 |
| Veera[m] | reran it - it showing correctly | 23:17 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!