| programmerjake | lkcl: saw the llvm rfc, looks nice, though you forgot to include any links to svp64 docs | 01:43 |
|---|---|---|
| lkcl | programmerjake, yeh good point. if there's followups i can post them then | 09:46 |
| jn | Linus Tech Tips got excited about laptop repairability and modularity: https://www.youtube.com/watch?v=0rkTgPt3M4k - not like EOMA68, but a small step in the direction | 11:35 |
| lkcl | jn: yes, the concept is kinda sinking in, finally | 13:08 |
| lkcl | MaciejPijanowski: btw apologies for making assumptions with the NLnet grant, i was running out of time to get it in. the tasks on the final MoU do not have to be exactly 100% what is on the application (some can be removed, but new ones cannot be added) | 13:13 |
| lkcl | there is plenty of time to discuss, plus (hello ghostmansd) for dmitry we can run things under the existing Grants for the next couple of months. | 13:14 |
| lkcl | then assuming it's approved the new Grant takes over, at a higher base rate. better for you :) | 13:14 |
| ghostmansd-pc | I wonder if we have a way to drop a comment in the pseudocode? | 16:09 |
| ghostmansd-pc | I'm now working on cbcdtd/cdtbcd, and I'd like to preserve the original notation from the specs at least in comments | 16:10 |
| ghostmansd-pc | Hm, if I use <!-- some comment --> in pseudocode, I'm doomed, right? | 16:23 |
| lkcl | ghostmansd-pc, yes. it has to be a single line | 16:23 |
| lkcl | not | 16:23 |
| lkcl | <!-- some comment | 16:23 |
| lkcl | --> | 16:23 |
| lkcl | also supported is python "#" comment in the pseudocode itself | 16:24 |
| lkcl | but do not put it at the end of a line | 16:24 |
| lkcl | and do not include line-breaks either | 16:24 |
| ghostmansd-pc | Ah, really? I couldn't find it in parser. | 16:24 |
| lkcl | it's in the lexer. | 16:24 |
| lkcl | it is reasonably standard for the lexer to be where comments are converted (and in some cases stripped out entirely) | 16:25 |
| ghostmansd-pc | Ah, OK, I wasn't aware that not all code is in pseudo/parser.py. I haven't checked the whole directory, my bad. :-( | 16:25 |
| lkcl | because, otherwise, how would the BNF / LALR parser code? | 16:25 |
| lkcl | cope | 16:25 |
| lkcl | it would have to be like: | 16:25 |
| lkcl | token comment token comment token | | 16:25 |
| lkcl | token token comment token | | 16:26 |
| lkcl | token comment token token | | 16:26 |
| lkcl | token token token | 16:26 |
| lkcl | an N^2 proliferation of BNF syntax entries! | 16:26 |
| lkcl | so, it is standard practice for the _lexer_ to remove comments. | 16:26 |
| ghostmansd-pc | yep, I understand | 16:27 |
| ghostmansd-pc | I mean, I wasn't aware of the fact that lexer is decoupled in our code | 16:27 |
| lkcl | feel free to ask anything like that, rather than spend time yourself then, after several hours, only then ask | 16:27 |
| ghostmansd-pc | I haven't spent several hours on that yet :-) | 16:27 |
| lkcl | :) | 16:27 |
| lkcl | i was lucky in that one of my lecture courses at Imperial College was in compilers. 1989? | 16:28 |
| ghostmansd-pc | in fact, I quickly surrendered and used <!-- --> for now, but I'll switch to # | 16:28 |
| lkcl | :) | 16:28 |
| lkcl | actually, <--- .... --> will work just as well, but note that <!-- --> gets stripped by pagereader.py | 16:29 |
| lkcl | whereas "# ...." actually gets passed through to the lexer | 16:29 |
| lkcl | "# ...." we would expect to submit upstream to the OpenPOWER ISA WG (first submitting "#" as an addition to the notation to Section 1.3.2) | 16:30 |
| lkcl | sigh :) | 16:30 |
| ghostmansd-pc | A quick question. We are going to introduce helpers for bcd/dpd conversion, if I get that correct, and use those (i.e. pseudocode won't be changed, right?). Why hadn't we created something for carry_out? | 16:32 |
| lkcl | introduce is slightly too strong a word... "use the existing pseudocode from the spec Appendix B.1 and B.2" | 16:33 |
| lkcl | carry_out, ok, so the way that SelectableInt works is to very strictly respect the bitwidth of the operations | 16:33 |
| lkcl | so SelectableInt.__add__ goes to some lengths to (a) check its input arguments as having the same bitwidth and (b) return a result that has the exact same bitwidth | 16:34 |
| lkcl | how, then, when carry_out *SPECIFICALLY* returns the bit in position "LENGTH+1", could carry_out obtain that information? | 16:35 |
| lkcl | SelectableInt.__add__ *specifically* returns a result that does *NOT* contain "1 bit more than the result of the addition" | 16:35 |
| lkcl | it returns, "EXACTLY the length of the sum" | 16:35 |
| lkcl | not "EXACTLY the length of the sum plus one extra bit aka carry-bit" | 16:36 |
| lkcl | in theory we could take the last bit and drop it into the SelectableInt as a hidden return result | 16:36 |
| lkcl | i hate hidden return results - they're a sign of desperate "last resort" | 16:36 |
| ghostmansd-pc | Yes, but helper could be done in terms of SelectableInt.__add__, couldn't it? | 16:37 |
| lkcl | are you using an irc client that strips out underscores and replaces them with spaces, by any chance? | 16:37 |
| lkcl | ok so if SelectableInt.__add__ returns a result that has one more bit than is "necessary" | 16:38 |
| lkcl | then when that is passed to other operations, it will **FAIL**, won't it? | 16:38 |
| ghostmansd-pc | hm, shouldn't be, I see `__add__` | 16:38 |
| lkcl | why? | 16:38 |
| lkcl | darn it must be hexchat. sigh | 16:38 |
| lkcl | operations NOT involving carry will FAIL.... | 16:38 |
| lkcl | because when the add result is used in subsequent operations, its length will be "LENGTH+1" | 16:39 |
| lkcl | that will get checked by the next operation to use that result, won't it? | 16:39 |
| lkcl | and that operation will go, "argh, this is one bit too long, i am going to terminate this operation, catastrophically, because there is a hard error in the pseudocode" | 16:40 |
| lkcl | yes? | 16:40 |
| ghostmansd-pc | def carry_out(RA, RB, i): | 16:41 |
| ghostmansd-pc | val = (0b0 || RA[4*i:63]) + (0b0 || RB[4*i:63]) # via concat and whatever magic | 16:41 |
| ghostmansd-pc | return val[0] | 16:41 |
| ghostmansd-pc | Couldn't helpers.py contain something like this? | 16:41 |
| lkcl | ahh ok yes, that would work | 16:41 |
| lkcl | except for the i | 16:41 |
| ghostmansd-pc | yep, sorry for confusion | 16:41 |
| lkcl | i like it. | 16:41 |
| ghostmansd-pc | the reason I'm asking is because we actually changed the pseudocode | 16:42 |
| lkcl | i mean, it's totally wasteful in terms of resources, to do it that way... oh wait... hang on.... | 16:42 |
| lkcl | carry_out in the pseudocode only takes one argument | 16:42 |
| lkcl | look again closely | 16:42 |
| ghostmansd-pc | and I assumed changing the pseudocode is the least we'd like to do | 16:42 |
| lkcl | v3.0B p113 | 16:42 |
| ghostmansd-pc | Yes, I know | 16:42 |
| ghostmansd-pc | we can't be word-to-word with spec | 16:43 |
| ghostmansd-pc | but at least function name would be the same | 16:43 |
| lkcl | what you've proposed is *still* a change to the spec | 16:43 |
| ghostmansd-pc | :-D | 16:43 |
| ghostmansd-pc | fair enough | 16:43 |
| lkcl | the only way to "respect" the spec is a horrible one. | 16:43 |
| ghostmansd-pc | but still it's visually closer to what it had :-) | 16:43 |
| lkcl | to have SelectableInt.__add__ actually store bit LENGTH+1 inside a "hidden variable" SelectableInt.carry | 16:44 |
| lkcl | the function carry_out simply takes a copy of that variable: | 16:44 |
| lkcl | def carry_out(val): return SelectableInt(val.carry, 1) | 16:44 |
| lkcl | which is... "hidden results". | 16:44 |
| ghostmansd-pc | Hm. Ugly, because it changes an internal state. | 16:44 |
| lkcl | yes. the "last resort" method | 16:45 |
| lkcl | i feel it's just much better to go "screw it" and remove carry_out. | 16:45 |
| lkcl | i did that elsewhere, in the FP helpers. | 16:45 |
| lkcl | p778 v3.0B | 16:45 |
| ghostmansd-pc | OK, let's keep it as is | 16:46 |
| ghostmansd-pc | things would have been simpler if they had some operator instead of + | 16:46 |
| ghostmansd-pc | to mean exactly "+ with carry out" | 16:46 |
| lkcl | sigh, i know | 16:46 |
| ghostmansd-pc | OK, sorry for distraction | 16:47 |
| lkcl | the entire pseudocode was never intended to be executable, more an "aide-memoire" | 16:47 |
| lkcl | hey no problem | 16:47 |
| lkcl | you saw this btw? https://bugs.libre-soc.org/show_bug.cgi?id=656#c15 | 16:47 |
| ghostmansd-pc | and thank you again for your help :-) | 16:47 |
| ghostmansd-pc | yep, I even fixed it and mentioned this comment :-) | 16:47 |
| lkcl | awesome | 16:47 |
| ghostmansd-pc | I forgot to reply in the task, but I replied in the repo | 16:48 |
| lkcl | i use git in rebase mode, i can't do "git pull" at the moment i have some outstanding uncommitted diffs | 16:48 |
| lkcl | the more cross-refs the better, it's not a hard rule though | 16:48 |
| lkcl | iDCT is doing my head in :) | 16:49 |
| ghostmansd-pc | I usually use $(git pull --rebase) | 16:50 |
| ghostmansd-pc | but yes, this assumes either committed or stashed stuff | 16:51 |
| lkcl | rebase fails when there's uncommitted (unstashed) working modifications | 16:51 |
| lkcl | yes. | 16:51 |
| ghostmansd-pc | why not stash? | 16:51 |
| lkcl | because it disrupts vim file notification | 16:51 |
| lkcl | and i run with hundreds of vim sessions, backgrounding them and jumping between them, multiple xterms | 16:52 |
| lkcl | "jobs | wc" returning a count of 150 is not uncommon for me | 16:52 |
| lkcl | ghostmansd-pc, index 5af6b66..63c42b2 100644 | 17:27 |
| lkcl | looks grat | 17:27 |
| ghostmansd-pc | thanks! | 17:37 |
| ghostmansd-pc | do we have some way to convert things like [0,1,0,1] to 4-bit selectable int? | 17:37 |
| ghostmansd-pc | I mean, I for sure can convert list of bits to an integer and then feed selectable int with it | 17:39 |
| ghostmansd-pc | but perhaps this task is quite common, and we have some wrapper or whatever | 17:39 |
| lkcl | errr... let me think... | 17:40 |
| lkcl | is this inside the pseudocode? | 17:40 |
| lkcl | because 0bNNNNNN syntax is supported. | 17:41 |
| lkcl | so you would write [0,1,0,1] as simply 0b0101 | 17:41 |
| lkcl | and the compiler goes, "oh, this is 4 bits, let me create a SelectableInt of width 4 for you" | 17:42 |
| lkcl | i have to ask, why you would need that? | 17:43 |
| lkcl | the only reason i can think of is if you've misunderstood what the task is, with respect to BCD_TO_DPD | 17:44 |
| lkcl | the task there is *literally* to insert the text from the v3.0B specification into a .mdwn file | 17:44 |
| lkcl | NOT | 17:44 |
| lkcl | "take the pseudocode from BCD_TO_DPD and convert it *BY HAND* to python" | 17:45 |
| lkcl | if, rather, you are thinking, "converting [0,1,0,1] to 4-bit selectable int is a common task in the pseudocode", this makes no sense | 17:45 |
| lkcl | because the pseudocode does not support python lists or lists of any kind | 17:46 |
| lkcl | so that can't be it | 17:46 |
| lkcl | select_concat expects SelectableInts. because it has to know the bit-width. | 17:47 |
| lkcl | [SelectableInt(0, 1), SelectableInt(1, 1), SelectableInt(0, 1), SelectableInt(1, 1)] you would just call select_concat | 17:47 |
| lkcl | but the more important question is: *why* do you think it is necessary? what task are you doing where it is being considered? | 17:48 |
| ghostmansd-pc | aaah | 17:53 |
| ghostmansd-pc | I thought that we introduce a helper in Python which exactly does this: "take the pseudocode from BCD_TO_DPD and convert it *BY HAND* to python" | 17:54 |
| ghostmansd-pc | do you mean that I should _expand_ BCD_TO_DPD in pseudocode? | 17:55 |
| ghostmansd-pc | I intended to introduce `def BCD_TO_DPD(BCD)`, which _always_ acts upon 3-digit BCD | 17:56 |
| ghostmansd-pc | and `def DPD_TO_BCD(DPD)`, which _always_ acts upon 10-bit BCD | 17:57 |
| ghostmansd-pc | and I assumed these would be called directly by pseudocode, and both will return selectable int (10-bit and 12-bit respectively) | 17:58 |
| ghostmansd-pc | I'm confused. The task description talks of editing helpers.py; another comment mentions that I need to edit pseudocode. I don't quite get which way we should follow. | 18:15 |
| ghostmansd | FWIW, the code I meant to use is at bug-656 branch | 18:26 |
| ghostmansd | I haven't checked whether it works; that's just WIP. I thought I can check and rebase it before pushing to master after writing tests (and checking those which already exist). | 18:29 |
| lkcl | no, definitely not: i would have said, "convert the BCD_TO_DPD function to python, by hand" if that was the case | 18:37 |
| lkcl | but, what would be the point? the compiler does the job already, so why would we repeat - by hand - what the compiler will do with better success? | 18:37 |
| lkcl | and, in the process, defeat the purpose of the exercise of having a compiler which can convert the exact same code to c, later? | 18:38 |
| lkcl | if the pseudocode is converted by hand to python (with errors), then later, the exact same work has to be done (by hand) converting to c, doesn't it? | 18:38 |
| lkcl | why would we punish ourselves with such extra work? | 18:38 |
| lkcl | no, i mean, LITERALLY copy - line-for-line, byte-for-byte, the pseudocode text from the Specification | 18:39 |
| lkcl | and place it - line-for-line, byte-for-byte, into a .mdwn file. | 18:39 |
| lkcl | i gave an example of where this has been done already | 18:39 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isafunctions/fpfromint.mdwn;hb=HEAD | 18:40 |
| lkcl | so, LITERALLY put, DIRECTLY into openpower/isafunctions/bcd.mdwn, the following contents: | 18:40 |
| lkcl | def BCD_TO_DPD(value): | 18:42 |
| lkcl | p = (f & a & i & ¬e) | (j & a & ¬i) | (b & ¬a) | 18:43 |
| lkcl | .... | 18:43 |
| lkcl | ..... | 18:43 |
| lkcl | now the only question is, what the bloody hell did IBM mean "3 bit decimal value as input" | 18:43 |
| lkcl | ah that's explained at the top of the page | 18:45 |
| lkcl | i'll continue in the bugreport | 18:45 |
| ghostmansd | Not 3 bit, 3-digit | 18:48 |
| ghostmansd | Thus 12 bits | 18:48 |
| ghostmansd | One digit in BCD is 4 bits | 18:48 |
| ghostmansd | I'll check fpfromint | 18:49 |
| ghostmansd | Thanks for tip | 18:49 |
| ghostmansd | As is it cannot be used, by the very minimum I'll have to write some bolierplate code for a,b,c,d... variables. | 18:51 |
| lkcl | yes. i just went through that in the latest comment | 18:53 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=656#c17 | 18:54 |
| lkcl | if you believe it should be the other way round, i'm happy with that. i usually get these things wrong. | 18:54 |
| ghostmansd | Well, I'm new to code base, so obviously you know better. I simply saw "add these to helpers.py", then checked helpers.py and found that it contains wrappers for some functions. By that point, I assumed this is the flow we need. | 18:57 |
| ghostmansd | Also we discussed that we'd like to avoid touching pseudocode, and this made me even more confident. :-) | 18:57 |
| lkcl | new to the insanity known as "IBM MSB0 order", more like, sigh | 18:58 |
| lkcl | so by "add to helpers.py", i meant, "add an import which makes the results of the compiler output - the function which is created by the compiler - available to ISACaller". | 18:59 |
| lkcl | that means that the function op_cdtbcd (which will be created by *another* run of the compiler), will need to have, at the top, the following code: | 19:00 |
| lkcl | "from openpower.decodeer.isafunctions.bcd import DPD_TO_BCD, BCD_TO_DPD" | 19:00 |
| lkcl | (because i hate wildcard imports with a vengeance) | 19:01 |
| lkcl | and because pywriter.py is responsible for writing out the op_cdtbcd function (when compiling openpower/isa/bcd.mdwn into openpower/pseudo/isa/bcd.py) | 19:02 |
| lkcl | that import statement has to go into the template in pywriter.py | 19:02 |
| lkcl | line 33 would do | 19:03 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/pseudo/pywriter.py;hb=HEAD#l33 | 19:03 |
| lkcl | it's a simple - but quite long - logical progression. | 19:03 |
| lkcl | * cddbcd pseudocode needs a function, DPD_TO_BCD. how do we get that function? | 19:03 |
| lkcl | A: auto-generate the function | 19:04 |
| lkcl | * yes, but how does it get to call it? | 19:04 |
| lkcl | A: it has to be imported | 19:04 |
| lkcl | * yes, but how does it know where to import it from? | 19:04 |
| lkcl | A: it doesn't - pywriter.py's header has to explicitly list it | 19:04 |
| lkcl | * ok, but who is creating the function, DPD_TO_BCD? | 19:05 |
| lkcl | A: the compiler, through running pyfnwriter | 19:05 |
| lkcl | * ok, but where does that output the function? | 19:05 |
| lkcl | A: into openpower/decoder/isafunctions/bcd.py | 19:05 |
| lkcl | and from there you go back up the chain. | 19:06 |
| lkcl | * openpower/isafunctions/bcd.mdwn contains a PSEUDOCODE definition of BCD_TO_DPD | 19:06 |
| lkcl | * pyfnwriter GENERATES AUTOMATICALLY openpower/decoder/isafunctions/bcd.py containing a ***PYTHON*** compiled version of BCD_TO_DPD | 19:07 |
| lkcl | * pywriter needs to create code **EXPLICITLY IMPORTING** that function | 19:07 |
| lkcl | * pywriter then outputs a header at the top of openpower/decoder/isa/bcd.py containing the import | 19:08 |
| lkcl | and thus, when op_cdtbcd is executed, the function BCD_TO_DPD is available. | 19:08 |
| lkcl | this is exactly how it is done with the INT2FP function which you can see at line 44 | 19:09 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/pseudo/pywriter.py;hb=HEAD#l44 | 19:09 |
| ghostmansd | Ok, got it | 19:09 |
| lkcl | cool. | 19:09 |
| lkcl | then, when it comes to the pseudocode-to-c compiler, we do not have to waste time or effort duplicating INT2FP, or BCD_TO_DPD by hand-writing those functions in c. | 19:10 |
| lkcl | just... compile, and done. | 19:10 |
| ghostmansd | Feels like microcode, BTW | 19:10 |
| lkcl | yes :) | 19:10 |
| ghostmansd | What I had in mind is closer to intrinsic, but I can see the benefits of this approach | 19:11 |
| ghostmansd | I'll update it | 19:11 |
| ghostmansd | That's why it's in branch :-) | 19:11 |
| lkcl | btw, i hate branches. | 19:11 |
| ghostmansd | Why so? | 19:11 |
| lkcl | every time i have got involved with branches, the code has been utterly wasted. | 19:11 |
| lkcl | in a couple of cases, literally years of work | 19:12 |
| ghostmansd | :-D | 19:12 |
| ghostmansd | Well, I prefer branches to couple of patches for sharing the work | 19:12 |
| ghostmansd | But I guess it's a matter of personal nasal daemons | 19:12 |
| ghostmansd | Mine are OK with branches, but, if you really don't want to deal with it, I'll send patches, this is fine | 19:13 |
| lkcl | they've generally made me very nervous, i prefer work in master branch. | 19:13 |
| lkcl | patches are a bit "yuck" | 19:14 |
| lkcl | typically, work that's "unused elsewhere" (like this is) is perfectly fine to drop into the master branch | 19:14 |
| lkcl | but, here, i can see the benefits | 19:14 |
| lkcl | because it doesn't put you under pressure to run 30 minutes unit tests | 19:14 |
| lkcl | before every commit | 19:15 |
| lkcl | you could run a comprehensive set of unit tests before doing a merge. which would work well. | 19:15 |
| lkcl | btw i also made the mistake of hand-converting one of the FP functions to python. | 19:16 |
| lkcl | i had completed it 100%, written the unit tests, then went, "arggggh what the hell am i doing??" :) | 19:16 |
| lkcl | here: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/helpers.py;h=ba665cb7b6f2e09d20a92384154d465317caf37f;hb=36521aff5e546543f84c42529f8fec9909ecae00#l232 | 19:17 |
| lkcl | and the SINGLE function as well. | 19:17 |
| * lkcl face-palm | 19:17 | |
| lkcl | they were a pain in the ass, as well. python range-end is +1 compared to IBM pseudocode. | 19:18 |
| lkcl | i know - i'll convert them, now, so you can see what i do. | 19:18 |
| lkcl | then, you'll see some patches which you can track. | 19:18 |
| lkcl | and do the same thing for BCD_2_DPD | 19:19 |
| ghostmansd | Ok, looks fair :-) | 19:22 |
| ghostmansd-pc | Should I insert the pseudocode directly before these `do i = 0 to 1` lines? | 19:29 |
| ghostmansd-pc | I'm a bit worried about how it's generated. | 19:30 |
| ghostmansd-pc | Won't the functions I introduce end up inside the instruction wrapper? | 19:30 |
| ghostmansd-pc | both fpfromint and double2single have no instructions inside | 19:31 |
| ghostmansd-pc | Ah, it looks like this should be not in pseudocode section, but separately, outside of instructions. | 19:31 |
| lkcl | ehn? que? | 19:36 |
| lkcl | correct, they are not instructions, they are... yes, that's why they're called helper functions | 19:37 |
| lkcl | ok now have to test the new SINGLE auto-generated function... hmmm.... that means recompiling the fpload.mdwn... | 19:40 |
| lkcl | ... | 19:41 |
| lkcl | .... | 19:41 |
| lkcl | aaand ehhhn, wark-wark, decoder/isa/test_caller_fp.py failed. | 19:41 |
| lkcl | i know why. forgot to create FRT (the return result) | 19:42 |
| lkcl | i'm an idiot. i just typed in the pseudocode for DOUBLE and called it SINGLE | 19:45 |
| lkcl | pass. awesome. | 19:45 |
| lkcl | MP3 audio unit test... pass | 19:47 |
| lkcl | DCT tests... one of which has a LD which uses DOUBLE.. pass | 19:48 |
| lkcl | FFT.... pass | 19:48 |
| lkcl | ok all good, committing | 19:48 |
| ghostmansd-pc | AssertionError: line with -Form expected def BCD_TO_DPD( BCD ): | 19:49 |
| ghostmansd-pc | it's barking at me, but why? | 19:50 |
| ghostmansd-pc | I tried adding the `def BCD_TO_DPD( BCD ):` along with its code in the beginning of bcd.mdwn | 19:51 |
| lkcl | commit it let me take a look | 19:53 |
| ghostmansd-pc | same if I add INT2FP from fpfromint | 19:53 |
| ghostmansd-pc | OK, will commit | 19:53 |
| ghostmansd-pc | wait a moment, this will break pywriter; is it acceptible? | 19:56 |
| ghostmansd-pc | I mean, if I commit as is | 19:57 |
| ghostmansd-pc | hm, it looks like I must create a separate mdwn, not place in bcd.mdwn | 20:01 |
| ghostmansd-pc | aha, it must be in some mdwn in isafunctions, it seems | 20:03 |
| lkcl | yes, you have to add it in... yes, that's what i wrote | 20:03 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=656#c1 | 20:03 |
| lkcl | after removing the silliness of *yet another* non-ASCII symbol for "¬" | 20:04 |
| lkcl | being used, those will need to go into openpower/isafunctions/bcd.mdwn, | 20:04 |
| lkcl | not | 20:04 |
| lkcl | openpower/isa/bcd.mdwn | 20:04 |
| lkcl | isafunctions is helper functions | 20:04 |
| lkcl | isa is actual instructions | 20:04 |
| lkcl | comment 18 is the patches i just did https://bugs.libre-soc.org/show_bug.cgi?id=656#c18 | 20:04 |
| lkcl | yes it's extremely weird, to consider actually taking lines from a processor specification and treating them as if they were executable source code | 20:06 |
| lkcl | but this way, it actually checks that the specification itself is correct. | 20:06 |
| lkcl | and yes, we have found mistakes | 20:06 |
| lkcl | might as well re-run the main unit tests just to make absolutely sure | 20:10 |
| lkcl | not that there's anything related to FP in them | 20:10 |
| ghostmansd-pc | mmm, nice | 20:20 |
| ghostmansd-pc | return concat(a, b, c, d, e, f, g, h, i, j, k, m) | 20:20 |
| ghostmansd-pc | mostly what I did, lol, but this time automatically and free :-) | 20:20 |
| ghostmansd-pc | OK, I checked that pyfnwriter is OK, pywriter is OK with `noall bcd`, and now wait for the whole pywriter to complete | 20:23 |
| ghostmansd-pc | the latter takes a while; cannot it be run in parallel, if I run it w/o args? | 20:25 |
| ghostmansd-pc | ah, OK, it's completed; after this I also checked test_caller.py (though I guess there's nothing to be called, since there are no tests yet) | 20:26 |
| ghostmansd-pc | ...anything else before I push? | 20:27 |
| lkcl | go for it | 20:40 |
| lkcl | i very rarely do the full pywriter. yes it could be, it's just usually run so rarely that i haven't made it parallel | 20:40 |
| lkcl | i added the noall option for incremental development | 20:41 |
| lkcl | looks good | 20:42 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=479e354d6c7e75e0321db39c4a76745bc0a35567 | 20:42 |
| lkcl | and this https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=c7fecbff307f5d4fed929d65fec35183c140040b | 20:42 |
| lkcl | of course, sigh, i cannot guess or advise which way round return a || b || c ... will do, MSB0 or LSB0 order | 20:43 |
| lkcl | reaallly need that documented in the concat function, sigh | 20:43 |
| lkcl | empty lines are tolerated by pyfnwriter? huh, that's a surprise. pywriter they're not | 20:47 |
| ghostmansd | I must also mention that thing dropped my lovely parentheses I added. | 20:47 |
| lkcl | shaaaame | 20:48 |
| lkcl | :) | 20:48 |
| lkcl | actually that may be a problem that needs resolving, due to operator precedenc | 20:48 |
| ghostmansd | so `((a & b) | (c & d))` got turned into `a & b | c & d` | 20:48 |
| lkcl | e | 20:48 |
| ghostmansd | And no, please, don't tell me it's obvious, because it's not | 20:49 |
| lkcl | that will need sorting, by getting the compiler to output brackets manually, around expressions | 20:49 |
| ghostmansd | That's actually bad, I love being explicit | 20:49 |
| lkcl | because yes, it's not obvious | 20:49 |
| lkcl | so, next would be unit tests, to make sure that the code is functionally correct. | 20:50 |
| ghostmansd | And lovely parentheses were the way for my explicitness | 20:50 |
| ghostmansd | That rug really tied the room together | 20:50 |
| lkcl | the most obvious "simple" test is, the two instructions back-to-back | 20:50 |
| lkcl | yehyeh | 20:50 |
| ghostmansd | Yes | 20:50 |
| ghostmansd | Also they have some examples | 20:51 |
| lkcl | but parenths are important because the pseudocode operator precedence rules may actually be different from python's. | 20:51 |
| ghostmansd | IIRC numbers 1..999? | 20:51 |
| lkcl | which can be "fixed" by always outputting brackets around everything. | 20:51 |
| lkcl | 0..999 | 20:51 |
| ghostmansd | I recall I saw some big table with conversion results, 0..999 | 20:51 |
| ghostmansd | Yep | 20:51 |
| lkcl | yes. | 20:51 |
| lkcl | there are 24 combinations missing, the other way round | 20:52 |
| lkcl | p788 | 20:52 |
| ghostmansd | I'll think about how to do the tests. Both vice versa conversion and known results are good. | 20:52 |
| lkcl | there's 2+ ways to do them | 20:52 |
| ghostmansd | As for addg6s, I'm not sure, have to think more | 20:52 |
| lkcl | (1) write some code in python which does the same conversion (but do it "the obvious way" if you know what i mean) | 20:52 |
| lkcl | (2) just extract that table, cut/paste style, blat it into the code, and run through *all* combinations! | 20:53 |
| lkcl | yeah, no idea even what it's for. | 20:53 |
| lkcl | that one, best bet is to run against qemu. | 20:53 |
| lkcl | and hope that qemu is actually right | 20:53 |
| ghostmansd | Will check next week. Not sure when exactly, I suspect there will be a plethora of other things until I can allocate time. | 20:54 |
| ghostmansd | Most likely weekends. | 20:55 |
| lkcl | no problem | 20:55 |
| lkcl | good progress | 20:55 |
| ghostmansd | Thank you for your help and patience | 20:55 |
| ghostmansd | I may be tough sometimes, lol | 20:55 |
| ghostmansd | Sorry for that | 20:55 |
| lkcl | not a problem | 20:55 |
| lkcl | it's a new project, go figure | 20:56 |
| ghostmansd | This addg6s is tricky. I understand what happens on the bit level, but still have no idea how and why someone might opt to use it. | 21:02 |
| lkcl | pffh, likewise :) | 21:02 |
| lkcl | all these three should never have been made mandatory part of the Base Compliancy Level | 21:02 |
| lkcl | they should have been optional as part of Decimal FP | 21:02 |
| lkcl | where, for large Banking Applications, IBM would need them to sustain high-performance | 21:03 |
| lkcl | as part of a COBOL compiler, most likely | 21:03 |
| ghostmansd | IIRC AMD dropped BCD instructions | 21:03 |
| lkcl | probably because they lost all Banking contracts to IBM | 21:04 |
| ghostmansd | There was some similar stuff in x86, if I'm not mistaken | 21:04 |
| lkcl | yeah i vaguely remember that. early 1990s? | 21:04 |
| lkcl | i mean, back then, it *really mattered* | 21:05 |
| ghostmansd | I think it was upon 64 bit transition | 21:05 |
| ghostmansd | Can hardly imagine where it's needed except for telecom | 21:05 |
| lkcl | if your ASCII number conversion was slow, it made your terminal slow | 21:05 |
| lkcl | but for Banking, they have such vast number of ASCII documents with numbers in them, it really matters | 21:06 |
| ghostmansd | I think we have a winner here | 21:06 |
| ghostmansd | https://www.felixcloutier.com/x86/aam | 21:06 |
| lkcl | eurrgh! :) | 21:06 |
| ghostmansd | But addg6s is a close competitor | 21:07 |
| lkcl | interesting | 21:07 |
| ghostmansd | Still they at least managed to get rid of this upon 64-bit transition | 21:07 |
| ghostmansd | I guess we don't have this opportunity | 21:08 |
| ghostmansd | :-D | 21:08 |
| lkcl | nnope :) | 21:08 |
| lkcl | but i think it would be good to make a recommendation to the (new ISA WG) to move these to optional | 21:09 |
| ghostmansd | Yep, totally agree | 21:12 |
| ghostmansd | Regarding the task you asked to check, about cavatools. I'm not the decision maker, but, as long as it's as interesting as previous tasks, I'm in. Just please keep in mind time constraints. | 21:12 |
| lkcl | time/cost in this case. | 21:13 |
| lkcl | i had to put in the extra tasks because whilst they can be removed, they can't be added, once it's gone through 3rd party External Audit | 21:14 |
| lkcl | NLnet have independent audits of proposals. | 21:14 |
| ghostmansd | Ok then | 21:15 |
| ghostmansd | I'll create the team member page on the next iteration | 21:15 |
| lkcl | ack | 21:16 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!