Thursday, 2023-01-19

*** gnucode <gnucode!~gnucode@user/jab> has quit IRC03:28
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC04:30
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc05:34
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:20
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:21
*** ghostmansd <ghostmansd!> has quit IRC06:36
*** ghostmansd <ghostmansd!> has joined #libre-soc07:26
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:06
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc10:38
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC11:12
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc11:12
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC14:48
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc14:56
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC16:19
ghostmansdprogrammerjake, lkcl, is it intentional that operands for fptrans at minor_59 are mapped in a different order in CSVs and mdwn?17:35
ghostmansdexample below17: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 wg17:36
ghostmansd* fdmadds FRT,FRA,FRC,FRB (Rc=0)17:36
ghostmansd* fdmadds. FRT,FRA,FRC,FRB (Rc=117:36
ghostmansdNotice "FRA,FRC,FRB" vs "FRA,FRB,FRC"17:37
programmerjakeyeah, afaict, the csv matches the binary field encoding, the mdwn matches assembly syntax17:38
ghostmansdAha, OK, got it. That's why some tests fail17:39
ghostmansdFrankly, this is quite a strange decision.17:40
programmerjakefdmadds should match the existing official powerisa fp fma ops17:40
ghostmansdWhy not map 1:1?17:40
ghostmansdAnd that one already does it that way, if I got it correctly?17:40
programmerjakecuz precedent in official fma ops17:41
ghostmansdI'm just clarifying, I'll adopt the algorithm anyway.17:41
ghostmansdOK, thanks for the clarification!17:41
ghostmansdThis is quite anoying since I used mdwn to iterate over fields :-)17:41
ghostmansdA lot of time spent on checking that arguments got swapped17:42
programmerjakenote that integer mul-add arguments aren't swapped, only fp are17:43
programmerjakeif you find fp fma ops that aren't swapped, please let us know, it's likely a mistake17:44
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc17:54
lkclghostmansd, there's a couple of things at play, here17:56
lkclfirstly 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 conventions17:57
lkclsecondly, following from microwatt there is mappings to in1/in2/in3 and o/o217:57
lkclwhich is some coding conventions that we follow (right the way through to svp64 decoding).  it's important not to confuse the two17:58
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC18:57
ghostmansdAre 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
ghostmansdCan it happen that operand which was in1 in say minor_XX.csv becomes in2 in RMXXXX.csv?19:45
ghostmansdAh, 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
programmerjakeafaict once the columns are loaded from csv, they are always referred to by name, so order shouldn't matter19:47
ghostmansdThis is exactly the problem: I have some name in markdown which I need to map to some selector.19:49
ghostmansdAfter this, I need to shuffle the _arguments_ in exact the same order as _operands_ have them.19:49
ghostmansdThat is, we start with some list of strings, which need to be passed to some Operand.assemble method.19:50
ghostmansdUntil recent I've used the order in which operands appeared in markdown.19:50
ghostmansdBut perhaps I need to follow the order in selectors.19:51
lkclghostmansd, yes. examples are usually RS and RA.  you can see the full mapping list of what's allowed in power_decoder2.py19:52
ghostmansdHm. I've just found that operand classes already have the mapping by name...19:52
lkclwhich obviously matches In1Sel19:52
lkclprogrammerjake, by In1Sel etc. yes19:53
lkcli carried out a remapping in the svp64-csv-record-extending which provides a reverse-mapping (i think)19:54
ghostmansdI think I'll try accessing by name. This should be sufficient.19:54
ghostmansdWhen we collect all operands from markdown, we build a mapping by name.19:54
ghostmansdprogrammerjake, could, please, give me some fma instruction from vanilla power isa?20:10
ghostmansdI'd like to check its assembly and then check unofficial insns20:11
ghostmansdAh OK fmadds goes20:12
programmerjakefmadd on page 198 of the v3.1B spec section
ghostmansdWe don't ahve unofficial fma ops in binutils, by the way20:22
ghostmansdsv_binutils_fptrans only covers FPTRANS_INSNS20:23
ghostmansdThis needs a task20:23
*** markos <markos!> has quit IRC20:33
*** markos <markos!> has joined #libre-soc20:45
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc21:01
*** markos <markos!> has quit IRC21:01
*** markos <markos!> has joined #libre-soc21:12
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC21:13
ghostmansdprogrammerjake, lkcl: again about the ordering.21:14
ghostmansdfdmadds FRT,FRA,FRC,FRB (Rc=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 wg21:15
ghostmansdAh wait, never mind21:15
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc21:59
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC22:09
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc23:55

Generated by 2.17.1 by Marius Gedminas - find it at!