Wednesday, 2021-07-28

lkclghostmansd, i found the pseudocode for DPD_TO_BCD and its inverse in the appendix, and noted11:21
lkclit here
lkclit's probably best to do addg6s first because that one _doesn't_ need the BCD_TO_DPD function(s)11:21
*** xws is now known as wxie15:39
ghostmansd-pcit took me a while to understand where I break upon adding new instruction :-)18:19
ghostmansd-pcbut I really like the way how is descriptive18:19
lkcloh, good. that's a nice surprise19:12
ghostmansd-pclkcl: I don't quite get the meaning of addg6s/cdtbcd/cbcdtd. First of all, I don't quite get the notation (e.g. what's bit position 4xn and things like 4(dc0)), but I think convention chapter should cover it. Second, I'll need some pointers on BCD (any good docs?).19:18
lkclabout BCD: literally, your guess is as good as mine. no, really.  i mean, the last time i dealt with it was i think... 1979? on the Commodore PET 3032?19:18
lkcland yes, the notation is described iiin...19:19
lkclsection 1.3.219:19
lkclpage 4, v3.0B19:19
ghostmansd-pcyep, that's what I'm checking now19:20
ghostmansd-pcbut thanks for the tip :-)19:20
lkclthere's a wiki page somewhere describing some of the additions like "<u" which is "unsigned less-than"19:21
richardwilbur[m]In my experience, the particulars of the BCD algorithms depend to a great extent on the details of the representation.19:25
ghostmansd-pcholly molly, does 4xi simply mean 4*i?19:25
lkcllet me take a look19:26
lkclin the spec, yes.19:26
ghostmansd-pcthat's almost for sure, given the code I observe in bcd.mdwn19:26
lkclwe converted x to * because that's standard for pretty much every programming language19:27
richardwilbur[m]probably.  One BCD digit is usually coded in 4 bits.19:27
ghostmansd-pcyes, for sure19:27
ghostmansd-pcand that's what I'd have expected19:27
ghostmansd-pcbut hey, they have bits swapped, why not have x instead of *19:27
ghostmansd-pcand this one's complement, ¬19:28
ghostmansd-pchow am I supposed to enter it w/o copy-paste?19:28
lkclyou don't.19:28
ghostmansd-pcI saw it in both specs and mdwn19:29
lkclyes.  so the conversion is already done19:29
lkclthat is the code that needs unit tests for it.19:29
lkclit does *not* need quotes converting quotes19:30
lkclit does not need altering (unless there is a syntax error or a program error, detected by running a unit test)19:30
ghostmansd-pcok, that's good news19:30
lkclah, that's not quite correct.19:30
lkclcarry_out is a non-existent function19:30
ghostmansd-pcbut, at the same time, bug 656 mentions that I need to change the pseudocode :-)19:31
ghostmansd-pcyep, exactly19:31
lkclyes, to remove the function carry_out19:31
ghostmansd-pcOK, got it19:31
lkclyes, forgot about that. am in the middle of something complicated19:31
ghostmansd-pcthat's OK, sorry for distracting19:31
ghostmansd-pcit took me some time to realize || is a concatenation; I somehow missed it in specs, and had to find it in parser.py20:48
ghostmansd-pcit appears to me that carry_out(RA4xi:63 + RB4xi:63) means the following: add two numbers with carry as if they were 64bit/60bit/56bit/etc. Would the formula suggested in bug 656 work then?20:53
lkclit means "get the carry out bit from the addition of bit length N"21:15
lkclso it is critically dependent on the *length of the input*21:16
programmerjakethat formula in 656 is incorrect, since it also adds in the sum bits rather than giving only the carry bits21:16
lkclnot "get the carry out from a 64 bit add"21:16
lkcl"in 656"?21:16
lkclwhere is "656"?21:16
programmerjakebug 65621:17
lkclah bug 65621:17
* programmerjake < >21:17
lkclprogrammerjake: you sent the following message:21:17
lkcl"programmerjake  < >"21:17
lkclcan you send the text not a link to something that is external to the libre-soc server please?21:18
programmerjakeah, I pasted a too-long message...21:18
lkclthe pseudo-code from is a direct copy of the pseudo-code from v3.0B21:18
programmerjakehere it is again:21:18
programmerjakethis formula is incorrect:21:18
lkclif it's incorrect, it means the SPECIFICATION is incorrect21:19
programmerjaketemp <- (0b0 || RA) + (0b0 || RB)21:19
programmerjake   dc[16] <- [0]*1621:19
programmerjake   do i = 0 to 1521:19
programmerjake       dc[i] <- temp[4*i]21:19
lkclor... 1 sec... need to check it line-by-line against p11121:20
programmerjakeno, the specification is correct, it's lkcl's reinterpretation that's incorrect as-given21:20
lkcli really don't understand21:20
lkclwhat words in exactly which location are incorrect compared to what?21:21
lkclok, comment 0, not comment 1 (the pseudocode from v3.0B Appendix)21:21
richardwilbur[m]That looks like harvesting carry bits from the sum of 16-digit BCD numbers.  There’s an ambiguity of notation.21:21
programmerjakethe part directly under will need to be changed to something like:21:22
programmerjake"will need to be changed to something like:"21:22
lkclright, got it21:22
programmerjakethe part directly above is correct afaict, it's copied from the spec21:22
richardwilbur[m]dc[16] = [0]*16 looks like it zeros 16 bits of dc21:23
lkclyep got it21:23
programmerjakeI'll write a comment with my suggested pseudocode21:23
lkclit's going to be something like...21:23
lkclinside the loop...21:23
lkcltemp <- (0b0 || RA[4*i:63] + (0b0 || RB[4*i:63}21:23
lkcldc[i] <- temp[0]21:24
richardwilbur[m]whereas dc[i] seems to be assigning to bit i of dc, as opposed to i bits of dc.21:24
lkclthat looks better21:24
lkclghostmansd-pc: yes, "||" means "concatenate". in some order that i couldn't tell you what it is because i get order-dyslexic21:25
ghostmansd-pc[sigh] this discussion caught me upon writing half-adder and full-adder, I guess I have to spend more time getting used to these notations21:31
programmerjakeiirc 0b101 || 0b010 = 0b10101021:36
programmerjakedo note that nmigen's Cat is the opposite order (lsb first)21:38
richardwilbur[m]I would be less surprised if ‘||’ actually meant bit-wise or.  Otherwise we’ve got variable bit length output, albeit with the top bit cleared (or bottom bit, depending on endianness).21:39
richardwilbur[m]If it is ‘or’ then it would seem 0b0 gives a clear backdrop for the whole data size.21:43
programmerjakejust give up now, openpower's spec is their own special sauce, just like them deciding to use msb021:43
richardwilbur[m]Good point.21:44
programmerjakelkcl & others, meeting in 15min21:45
ghostmansdCan someone confirm that I understand the code correctly?21:59
ghostmansd1. Start with {carry} set to 0.21:59
ghostmansd2. Get next 4 bits from RA and RB, prepend a 0 to both.21:59
ghostmansd3. Repeatedly add 3 5-bit chunks: {SUM} <- 0b0{RA_4bit_slice} + 0b0{RB_4bit_slice} + 0b0000{carry}.21:59
ghostmansdIf so, why carry ends up at SUM[0]?22:02
programmerjakebecause the power spec numbers bits from 0 at the msb, not the lsb22:02
ghostmansdPardon my ignorance, I've never worked with gates that much.22:03
programmerjakeyes, that's correct22:03
ghostmansdAh, Ok. So, for others, it'd have been [5]?22:03
programmerjakeit's because IBM's weird, lots of others use lsb022:03
programmerjakenmigen uses lsb022:04
ghostmansdAh, ok, I think I finally got it. Thank you so much!22:04
lkclghostmansd, excellent22:04
ghostmansdThat's really weird :-)22:04
ghostmansdFeels kinda mine field22:05
richardwilbur[m]Do we have any adaptations for nmigen to work with msb0?22:06
programmerjakerichard.wilbur yes, SelectableInt does the endian swapping for us:23:46

Generated by 2.17.1 by Marius Gedminas - find it at!