| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 03:28 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 04:30 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 05:34 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:20 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:21 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 06:36 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 07:26 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:38 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 11:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.156> has joined #libre-soc | 11:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.156> has quit IRC | 14:48 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:56 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 16:19 | |
| ghostmansd | programmerjake, lkcl, is it intentional that operands for fptrans at minor_59 are mapped in a different order in CSVs and mdwn? | 17:35 |
|---|---|---|
| ghostmansd | example below | 17:36 |
| ghostmansd | -----11011,FPU,OP_FP_MADD,FRA,FRB,FRC,FRT,NONE,CR1,0,0,ZERO,0,NONE,0,0,0,0,1,0,RC_ONLY,0,0,fdmadds,A,,1,3-in 2-out: implicit FRS. unofficial until submitted and approved/renumbered by the opf isa wg | 17:36 |
| ghostmansd | * fdmadds FRT,FRA,FRC,FRB (Rc=0) | 17:36 |
| ghostmansd | * fdmadds. FRT,FRA,FRC,FRB (Rc=1 | 17:36 |
| ghostmansd | Notice "FRA,FRC,FRB" vs "FRA,FRB,FRC" | 17:37 |
| programmerjake | yeah, afaict, the csv matches the binary field encoding, the mdwn matches assembly syntax | 17:38 |
| ghostmansd | Aha, OK, got it. That's why some tests fail | 17:39 |
| ghostmansd | Frankly, this is quite a strange decision. | 17:40 |
| programmerjake | fdmadds should match the existing official powerisa fp fma ops | 17:40 |
| ghostmansd | Why not map 1:1? | 17:40 |
| ghostmansd | And that one already does it that way, if I got it correctly? | 17:40 |
| programmerjake | cuz precedent in official fma ops | 17:41 |
| ghostmansd | I'm just clarifying, I'll adopt the algorithm anyway. | 17:41 |
| ghostmansd | OK, thanks for the clarification! | 17:41 |
| ghostmansd | This is quite anoying since I used mdwn to iterate over fields :-) | 17:41 |
| ghostmansd | A lot of time spent on checking that arguments got swapped | 17:42 |
| programmerjake | note that integer mul-add arguments aren't swapped, only fp are | 17:43 |
| programmerjake | if you find fp fma ops that aren't swapped, please let us know, it's likely a mistake | 17:44 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:54 | |
| lkcl | ghostmansd, there's a couple of things at play, here | 17:56 |
| lkcl | firstly the conventions in the ISA have been decided by the ISA WG - there is not a snowball in hell's chance we can disregard their conventions | 17:57 |
| lkcl | secondly, following from microwatt there is mappings to in1/in2/in3 and o/o2 | 17:57 |
| lkcl | which is some coding conventions that we follow (right the way through to svp64 decoding). it's important not to confuse the two | 17:58 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:57 | |
| ghostmansd | Are at least in1/in2/in3/out/out2/CR in/CR out/CR out2 guaranteed to be consistent accross CSVs for word instructions and CSVs for remap? | 19:44 |
| ghostmansd | Can it happen that operand which was in1 in say minor_XX.csv becomes in2 in RMXXXX.csv? | 19:45 |
| ghostmansd | Ah, never mind. I'll just pass one of these records which has the selectors, either PPCRecord or SVP64Record, and let the code decide which one of these is to be used. | 19:47 |
| programmerjake | afaict once the columns are loaded from csv, they are always referred to by name, so order shouldn't matter | 19:47 |
| ghostmansd | This is exactly the problem: I have some name in markdown which I need to map to some selector. | 19:49 |
| ghostmansd | After this, I need to shuffle the _arguments_ in exact the same order as _operands_ have them. | 19:49 |
| ghostmansd | That is, we start with some list of strings, which need to be passed to some Operand.assemble method. | 19:50 |
| ghostmansd | Until recent I've used the order in which operands appeared in markdown. | 19:50 |
| ghostmansd | But perhaps I need to follow the order in selectors. | 19:51 |
| lkcl | ghostmansd, yes. examples are usually RS and RA. you can see the full mapping list of what's allowed in power_decoder2.py | 19:52 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_decoder2.py;h=1b00e24d01966d38bab8f3328be4849ef2a795cc;hb=87f064999aa77d593ba1dc802ec0e42749f15da7#l106 | 19:52 |
| ghostmansd | Hm. I've just found that operand classes already have the mapping by name... | 19:52 |
| lkcl | which obviously matches In1Sel | 19:52 |
| lkcl | programmerjake, by In1Sel etc. yes | 19:53 |
| lkcl | i carried out a remapping in the svp64-csv-record-extending which provides a reverse-mapping (i think) | 19:54 |
| ghostmansd | I think I'll try accessing by name. This should be sufficient. | 19:54 |
| ghostmansd | When we collect all operands from markdown, we build a mapping by name. | 19:54 |
| ghostmansd | programmerjake, could, please, give me some fma instruction from vanilla power isa? | 20:10 |
| ghostmansd | I'd like to check its assembly and then check unofficial insns | 20:11 |
| ghostmansd | Ah OK fmadds goes | 20:12 |
| programmerjake | fmadd on page 198 of the v3.1B spec section 4.6.6.2 | 20:13 |
| ghostmansd | We don't ahve unofficial fma ops in binutils, by the way | 20:22 |
| ghostmansd | sv_binutils_fptrans only covers FPTRANS_INSNS | 20:23 |
| ghostmansd | This needs a task | 20:23 |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC | 20:33 | |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has joined #libre-soc | 20:45 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 21:01 | |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC | 21:01 | |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has joined #libre-soc | 21:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 21:13 | |
| ghostmansd | programmerjake, lkcl: again about the ordering. | 21:14 |
| ghostmansd | fdmadds FRT,FRA,FRC,FRB (Rc=0) | 21:14 |
| ghostmansd | fdmadds,NORMAL,,1P,EXTRA2,NO,d:FRT;d:CR1,s:FRA,s:FRB,s:FRC,FRA,FRB,FRC,FRT,0,CR1,0 | 21:14 |
| ghostmansd | -----11011,FPU,OP_FP_MADD,FRA,FRB,FRC,FRT,NONE,CR1,0,0,ZERO,0,NONE,0,0,0,0,1,0,RC_ONLY,0,0,fdmadds,A,,1,3-in 2-out: implicit FRS. unofficial until submitted and approved/renumbered by the opf isa wg | 21:15 |
| ghostmansd | Ah wait, never mind | 21:15 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 21:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 22:09 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 23:55 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!