Veera[m] | lkcl: Can you point me to dfu-uitl source code uri? | 01:46 |
---|---|---|
Veera[m] | eh. dfu-util! | 01:46 |
programmerjake | i just used `apt install dfu-util` | 01:48 |
programmerjake | source here: https://packages.debian.org/source/bullseye/dfu-util | 01:48 |
programmerjake | http://dfu-util.sourceforge.net/ | 01:49 |
programmerjake | https://sourceforge.net/p/dfu-util/dfu-util/ci/master/tree/ | 01:49 |
Veera[m] | <programmerjake> "source here: https://packages...." <- this I found out myself | 02:01 |
Veera[m] | programmerjake: Are you using fpga boards. If so dfu-util is needed for which one. Or lkcl may give the correct answer? | 02:02 |
programmerjake | i used dfu-util for the orangecrab, idk about other fpga boards | 02:03 |
programmerjake | iirc you need a different one for xilinx fpgas | 02:04 |
Veera[m] | ok. | 02:17 |
markos | lkcl, can predicates take negative values? Error: operand out of range (0x000000000000aaaa is not between 0xffffffffffff8000 and 0x0000000000007fff) | 10:59 |
markos | argh | 11:00 |
markos | that's the li instruction not the predicate | 11:00 |
markos | lol | 11:00 |
markos | nevermind | 11:00 |
lkcl | markos :) | 11:00 |
markos | rubber duck debugging | 11:00 |
markos | been struggling at this since yesterday and it became obvious just when I pasted it | 11:01 |
lkcl | been there. once written out, just asking the question is enough | 11:01 |
markos | always funny when this happens | 11:01 |
lkcl | predicates can never be considered negative, they're individual bits that "happen to be in a scalar integer" | 11:02 |
lkcl | i'm assuming you're using sv.op/sm=r3 or something | 11:02 |
markos | sv.fadds/mrr/m=r30 11.v, 11.v, 9.v | 11:03 |
markos | the predicate mask needs to be 0b1010101010101010 but apparently I can't use li for it and need to use lwz | 11:03 |
markos | apart from that it works fine until the last element | 11:04 |
markos | originally it was 0b10101010101010 but it missed the last element | 11:04 |
markos | I've been checking the dump and the pypowersim output | 11:04 |
lkcl | urgh because it's over 16 bits, bleh. | 11:05 |
lkcl | ha, you should be able to use one of grevlut to do that, when we have it! | 11:05 |
lkcl | RARBimmivresult | 11:06 |
lkcl | 0x555..0b100b0110110000x111111... | 11:06 |
lkcl | 0x555..0b1100b0110110000x010101... | 11:06 |
markos | I'll just load the mask for now :) | 11:06 |
lkcl | yes, it's on the list... oh hang on, that's 01010101 not 10101010, but i remember seeing it in the pseudocode | 11:06 |
lkcl | yeah | 11:06 |
lkcl | have to get round to implementing grevlut | 11:07 |
markos | lkcl, the powersim output is quite rich, what do I look for wrt to predicate masks? | 11:59 |
lkcl | markos, 1 sec... | 11:59 |
lkcl | if there's nothing saying "predicate" then it should be added! | 11:59 |
lkcl | clue: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=804da2a43cc5d95ab09de2a4cacbe1eac6a7501d;hb=0d37dbf9e4dbf100237f1353de19886fe5386cc8#l332 | 12:00 |
lkcl | get_predint | 12:00 |
lkcl | found it | 12:00 |
lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=804da2a43cc5d95ab09de2a4cacbe1eac6a7501d;hb=0d37dbf9e4dbf100237f1353de19886fe5386cc8#l1757 | 12:00 |
lkcl | pred_sz and | 12:01 |
lkcl | pred_dz | 12:01 |
lkcl | sorry | 12:01 |
markos | source and destination? | 12:01 |
lkcl | srcmask and | 12:01 |
lkcl | dstmask | 12:01 |
markos | ok | 12:01 |
lkcl | which you can see will be errr srcmask = dstmask = 0xffff_ffff_ffff_ffff | 12:02 |
lkcl | that should be 64-bit | 12:02 |
lkcl | when there's no predicate mask given it is *as if* the predicate mask is all 1s | 12:02 |
lkcl | is that right? | 12:03 |
lkcl | 0xffff_ffff_ffff_ffff>>63 | 12:04 |
lkcl | 1 | 12:04 |
lkcl | yep it's already 64-bit. ok, whew :) | 12:04 |
markos | finally | 12:15 |
markos | worked | 12:15 |
markos | now to the next instructions | 12:15 |
markos | I'll commit today this part | 12:15 |
markos | sending you my ssh key asap | 12:15 |
lkcl | markos, star. i'm getting disconnected regularly here btw, due to a storm (high winds) | 14:43 |
ghostmansd | lkcl, am I right that thing called `imm` and `immed` at e.g. decode_imm is always a 16-bit immediate? | 16:50 |
ghostmansd | e.g. decode_imm() at https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l144 | 16:50 |
ghostmansd | and, as a better example, https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l373 | 16:50 |
ghostmansd | I'm asking because I'm thinking of adding some relevant checks into binutils, but these checks are not in Python, so I'm kinda unsure | 16:51 |
ghostmansd | I tried searching ikiwiki, but "immediate" yields many not-so-relevant hits, so I decided it'd be best to ask directly :-) | 16:52 |
ghostmansd | also, whilst we're here: at stuff like `sv.stw 5.v, 4(1.v)`, 5 and 1 designate the register id if I get the code correctly; in Power ISA, it's stated we have 32 GPRs/FPRs/VRs, should I check for 0..31 range as well when I decode 5/1? | 16:58 |
lkcl | ghostmansd, ahh some of them are 14-bit, some signed, some unsigned, it's down to the individual instruction | 18:10 |
lkcl | 1 sec | 18:10 |
lkcl | ok so i *think* i'm right in saying that you simply have to *identify* that the field *is* an immediate | 18:11 |
lkcl | then use that to reconstruct the v3.0B opcode later, using the immediate "as-is" | 18:12 |
lkcl | SVP64 *extends* register numbers to 128. (0..127) | 18:15 |
lkcl | that's what get_extra_gpr() is all about (and get_extra_cr3bit()) | 18:16 |
lkcl | so you must most definitely *not* check 5/1 against a range 0..31 | 18:16 |
lkcl | but instead check to see if there is enough space in the EXTRA2/3 plus the 5-bit of RA/RB/RT/RC to fit the number | 18:17 |
lkcl | that's what... | 18:17 |
lkcl | this is about: | 18:17 |
lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=65aa1768fc2cff1a615bbd27c33babdb1a96099b;hb=de70844521d6b6e88e380c729f8384971803454d#l485 | 18:17 |
lkcl | for INTs and FPRs, EXTRA3 has enough bits | 18:18 |
lkcl | EXTRA3[2] is "scalar/vector" | 18:19 |
lkcl | EXTRA[0:2] is 2-bits, plus 5 from the v3.0B RA/RB/RT/RC that makes 7 bits | 18:19 |
lkcl | but for EXTRA2 you can't fit it | 18:19 |
lkcl | EXTRA2[1] is "scalar/vector" | 18:19 |
lkcl | that's only 1 bit | 18:19 |
lkcl | so for scalar, the register number is encoded: | 18:20 |
lkcl | * bit 7 is zero | 18:20 |
lkcl | bit 6 is EXTRA2[0] | 18:20 |
lkcl | sorry | 18:20 |
lkcl | bit 6 is zero | 18:20 |
lkcl | bit 5 is EXTRA2[0] | 18:20 |
lkcl | bit 4..0 goes into the RT/RA/RB/RC field of the v3.0B opcode | 18:21 |
lkcl | and for vector it is | 18:21 |
lkcl | * bit 6 is 1 | 18:21 |
lkcl | bits 5..1 go into the RT/RA/RB/RC field of v3.0B opcode | 18:21 |
lkcl | bit 0 is zero | 18:21 |
lkcl | for EXTRA2 that gives a range of 0..63 for scalar regnums, and a range of 0,2,4,6,8,10....,124,126 for vector regnums | 18:22 |
ghostmansd[m] | Ah, OK, now it's clear, will drop 0..31 checks :-) | 18:31 |
ghostmansd[m] | Thanks for help! | 18:32 |
markos | lkcl, fyi, 1bitsquared.de just shipped the hyperram pmod so I guess they're in stock in the EU store again? | 19:17 |
programmerjake | ghostmansd[m]: also openpower v3.1 prefixed instructions can have larger than 16-bit immediates (paddi can have 33-bits, icr what size the v3.1 prefixed load/stores support, though 33-bits is a good guess). none of the v3.1 prefixed imstructions can be svp64 instructions though, since we want to avoid 96-bit instructions with 2 separate prefixes. | 20:32 |
lkcl | markos, ah that's good | 20:42 |
lkcl | programmerjake, there maaay be a way round that, by using the route described in ZOLC, which would separate the prefix from the suffix and have a *third* L1 Cache for it | 20:43 |
programmerjake | zolc? abbreviation expansion please | 20:46 |
lkcl | https://www.researchgate.net/publication/224647569_A_portable_specification_of_zero-overhead_looping_control_hardware_applied_to_embedded_processors | 21:02 |
programmerjake | ah | 21:03 |
lkcl | so the idea floating around my head is: like the Borg, adopt ZOLC and use it to "apply" 32-bit prefixes to ranges of 32-bit instructions. | 21:04 |
lkcl | and/or register maps | 21:04 |
lkcl | this would be one hell of a lot of work, like, a maaajor upgrade to SVP64 | 21:05 |
programmerjake | iirc we dropped that as too complex -- iirc it was part of our 16-bit instruction set proposal | 21:05 |
lkcl | yes. then i realised that ZOLC has already done it, and that REMAP is remarkably similar to ZOLC | 21:06 |
lkcl | both even have the same priority-applied "stack" | 21:06 |
lkcl | https://opencores.org/websvn/filedetails?repname=hwlu&path=%2Fhwlu%2Ftrunk%2Fdoc%2Fhwlu_spec.pdf | 21:07 |
Veera[m] | lkcl: Did you used libftd2xx or libftdi1 is enough? | 21:17 |
lkcl | if i remember correctly one of them is proprietary (so is off the list) the other is libre/open (so is ok) | 21:23 |
Veera[m] | ok | 21:30 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!