| lkcl | ghostmansd, i found the pseudocode for DPD_TO_BCD and its inverse in the appendix, and noted | 11:21 |
|---|---|---|
| lkcl | it here https://bugs.libre-soc.org/show_bug.cgi?id=656#c1 | 11:21 |
| lkcl | it'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 wxie | 15:39 | |
| ghostmansd-pc | it took me a while to understand where I break test_power_decoder.py upon adding new instruction :-) | 18:19 |
| ghostmansd-pc | but I really like the way how power_enums.py is descriptive | 18:19 |
| lkcl | oh, good. that's a nice surprise | 19:12 |
| ghostmansd-pc | lkcl: 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 |
| lkcl | about 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 |
| lkcl | and yes, the notation is described iiin... | 19:19 |
| lkcl | section 1.3.2 | 19:19 |
| lkcl | page 4, v3.0B | 19:19 |
| ghostmansd-pc | yep, that's what I'm checking now | 19:20 |
| ghostmansd-pc | but thanks for the tip :-) | 19:20 |
| lkcl | :) | 19:20 |
| lkcl | there'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-pc | holly molly, does 4xi simply mean 4*i? | 19:25 |
| lkcl | let me take a look | 19:26 |
| lkcl | in the spec, yes. | 19:26 |
| ghostmansd-pc | that's almost for sure, given the code I observe in bcd.mdwn | 19:26 |
| lkcl | we converted x to * because that's standard for pretty much every programming language | 19:27 |
| richardwilbur[m] | probably. One BCD digit is usually coded in 4 bits. | 19:27 |
| ghostmansd-pc | yes, for sure | 19:27 |
| ghostmansd-pc | and that's what I'd have expected | 19:27 |
| ghostmansd-pc | but hey, they have bits swapped, why not have x instead of * | 19:27 |
| ghostmansd-pc | and this one's complement, ¬ | 19:28 |
| ghostmansd-pc | how am I supposed to enter it w/o copy-paste? | 19:28 |
| ghostmansd-pc | :-D | 19:28 |
| lkcl | you don't. | 19:28 |
| ghostmansd-pc | I saw it in both specs and mdwn | 19:29 |
| lkcl | yes. so the conversion is already done | 19:29 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/bcd.mdwn;hb=HEAD | 19:29 |
| lkcl | that is the code that needs unit tests for it. | 19:29 |
| lkcl | it does *not* need quotes converting quotes | 19:30 |
| lkcl | it does not need altering (unless there is a syntax error or a program error, detected by running a unit test) | 19:30 |
| ghostmansd-pc | ok, that's good news | 19:30 |
| lkcl | ah, that's not quite correct. | 19:30 |
| lkcl | carry_out is a non-existent function | 19:30 |
| ghostmansd-pc | but, at the same time, bug 656 mentions that I need to change the pseudocode :-) | 19:31 |
| ghostmansd-pc | yep, exactly | 19:31 |
| lkcl | yes, to remove the function carry_out | 19:31 |
| ghostmansd-pc | OK, got it | 19:31 |
| lkcl | yes, forgot about that. am in the middle of something complicated | 19:31 |
| ghostmansd-pc | that's OK, sorry for distracting | 19:31 |
| ghostmansd-pc | it took me some time to realize || is a concatenation; I somehow missed it in specs, and had to find it in parser.py | 20:48 |
| ghostmansd-pc | it 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 |
| lkcl | it means "get the carry out bit from the addition of bit length N" | 21:15 |
| lkcl | so it is critically dependent on the *length of the input* | 21:16 |
| programmerjake | that formula in 656 is incorrect, since it also adds in the sum bits rather than giving only the carry bits | 21:16 |
| lkcl | not "get the carry out from a 64 bit add" | 21:16 |
| lkcl | "in 656"? | 21:16 |
| lkcl | where is "656"? | 21:16 |
| programmerjake | bug 656 | 21:17 |
| lkcl | ah bug 656 | 21:17 |
| * programmerjake < https://libera.ems.host/_matrix/media/r0/download/libera.chat/50d6be014909f24dde24c88f96cb3e47c5362134/message.txt > | 21:17 | |
| lkcl | programmerjake: you sent the following message: | 21:17 |
| lkcl | "programmerjake < https://libera.ems.host/_matrix/media/r0/download/libera.chat/50d6be014909f24dde24c88f96cb3e47c5362134/message.txt >" | 21:17 |
| lkcl | can you send the text not a link to something that is external to the libre-soc server please? | 21:18 |
| programmerjake | ah, I pasted a too-long message... | 21:18 |
| lkcl | the pseudo-code from https://bugs.libre-soc.org/show_bug.cgi?id=656#c1 is a direct copy of the pseudo-code from v3.0B | 21:18 |
| programmerjake | here it is again: | 21:18 |
| programmerjake | this formula is incorrect: | 21:18 |
| lkcl | if it's incorrect, it means the SPECIFICATION is incorrect | 21:19 |
| programmerjake | temp <- (0b0 || RA) + (0b0 || RB) | 21:19 |
| programmerjake | dc[16] <- [0]*16 | 21:19 |
| programmerjake | do i = 0 to 15 | 21:19 |
| programmerjake | dc[i] <- temp[4*i] | 21:19 |
| lkcl | or... 1 sec... need to check it line-by-line against p111 | 21:20 |
| programmerjake | no, the specification is correct, it's lkcl's reinterpretation that's incorrect as-given | 21:20 |
| lkcl | reinterpretation? | 21:20 |
| lkcl | i really don't understand | 21:20 |
| lkcl | what words in exactly which location are incorrect compared to what? | 21:21 |
| programmerjake | in https://bugs.libre-soc.org/show_bug.cgi?id=656#c0 | 21:21 |
| lkcl | ok, 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 |
| programmerjake | the part directly under will need to be changed to something like: | 21:22 |
| programmerjake | "will need to be changed to something like:" | 21:22 |
| lkcl | right, got it | 21:22 |
| programmerjake | the part directly above is correct afaict, it's copied from the spec | 21:22 |
| richardwilbur[m] | dc[16] = [0]*16 looks like it zeros 16 bits of dc | 21:23 |
| lkcl | yep got it | 21:23 |
| programmerjake | I'll write a comment with my suggested pseudocode | 21:23 |
| lkcl | it's going to be something like... | 21:23 |
| lkcl | inside the loop... | 21:23 |
| lkcl | temp <- (0b0 || RA[4*i:63] + (0b0 || RB[4*i:63} | 21:23 |
| lkcl | dc[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 |
| lkcl | that looks better | 21:24 |
| lkcl | ghostmansd-pc: yes, "||" means "concatenate". in some order that i couldn't tell you what it is because i get order-dyslexic | 21: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 notations | 21:31 |
| programmerjake | iirc 0b101 || 0b010 = 0b101010 | 21:36 |
| programmerjake | do 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 |
| programmerjake | just give up now, openpower's spec is their own special sauce, just like them deciding to use msb0 | 21:43 |
| richardwilbur[m] | Good point. | 21:44 |
| programmerjake | :P | 21:44 |
| programmerjake | lkcl & others, meeting in 15min | 21:45 |
| ghostmansd | Can someone confirm that I understand the code correctly? | 21:59 |
| ghostmansd | 1. Start with {carry} set to 0. | 21:59 |
| ghostmansd | 2. Get next 4 bits from RA and RB, prepend a 0 to both. | 21:59 |
| ghostmansd | 3. Repeatedly add 3 5-bit chunks: {SUM} <- 0b0{RA_4bit_slice} + 0b0{RB_4bit_slice} + 0b0000{carry}. | 21:59 |
| ghostmansd | If so, why carry ends up at SUM[0]? | 22:02 |
| programmerjake | because the power spec numbers bits from 0 at the msb, not the lsb | 22:02 |
| ghostmansd | Pardon my ignorance, I've never worked with gates that much. | 22:03 |
| programmerjake | yes, that's correct | 22:03 |
| ghostmansd | Ah, Ok. So, for others, it'd have been [5]? | 22:03 |
| programmerjake | it's because IBM's weird, lots of others use lsb0 | 22:03 |
| ghostmansd | *[4] | 22:03 |
| programmerjake | yes | 22:03 |
| programmerjake | nmigen uses lsb0 | 22:04 |
| ghostmansd | Ah, ok, I think I finally got it. Thank you so much! | 22:04 |
| programmerjake | yw | 22:04 |
| lkcl | ghostmansd, excellent | 22:04 |
| ghostmansd | That's really weird :-) | 22:04 |
| ghostmansd | Feels kinda mine field | 22:05 |
| richardwilbur[m] | Do we have any adaptations for nmigen to work with msb0? | 22:06 |
| programmerjake | richard.wilbur yes, SelectableInt does the endian swapping for us: | 23:46 |
| programmerjake | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/selectable_int.py;h=5e2c0fe8b38e77160486d69f37bb1c5257048510;hb=HEAD | 23:46 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!