Sunday, 2022-09-11

lkcltests ran, rebase good00:42
lkclghostmansd[m], all good with CR5/CR3. needs cleanup (tomorrow!) but works01:45
lkclcesar, markos, ghostmansd[m], sorry message went out couple days ago, late-notice on IRC
lkclis everyone good for a meeting 17:00 UTC (about 15 hours from now)01:48
lkcltarget is to put in the ls001 External RFC *by monday evening latest*01:48
lkclsome cleanup on CR5Operand and CR3Operand is needed, all that code desperately needs a common base class02:16
ghostmansd[m]Wow Luke thanks for help!07:35
ghostmansd[m]I'll make the cleanup and adopt it somehow into the base class07:35
*** ghostmansd <ghostmansd!> has joined #libre-soc08:22
ghostmansdLuke, what do vshift, sshift and spshft stand for, and where did one of them lost i? :-D08:49
ghostmansdOK refactoring this a bit10:28
lkcllook at the diff.10:30
lkcl@@ -651,11 +651,16 @@ class GPRFPROperand(RegisterOperand):10:30
lkcl             if vector:10:30
lkcl-                value = ((value << 2) | spec)10:30
lkcl+                value = ((value << vshift) | (spec<<spshft))10:30
lkcl             else:10:30
lkcl-                value = ((spec << 5) | value)10:30
lkcl+                value = ((spec << sshift) | value)10:30
lkclthen i took the comments above10:31
*** tplaten <tplaten!> has joined #libre-soc10:31
lkcldid an "A is to B, as C is to D" analysis10:32
lkcland came up with equivalent numbers10:32
lkclit was late - i think in my mind i called then "vshift vector shift"10:32
lkcl"sshift scalar shift"10:32
lkcl"spshift spec shift"10:32
lkcli suspect it will be possible to do this10:33
lkclclass CR3Operand(SomeBaseClass):10:33
lkcl    vshift = 410:33
lkcl    sshift = 310:33
lkcl    spshift = 210:33
lkclwhich is static class-variable allocation10:33
lkclbut still use them as "self.sshift" etc.10:34
lkcli have vague recollections that static class-variables can still be accessed "self." rather than needing to be accessed by class-name10:34
ghostmansd[m]These are same for both10:35
lkclbut if you look *really* closely10:35
ghostmansd[m]Only lsbs differ10:35
lkclyou'll be able to see that *all* those numbers are actually derivable entirely from len(value) (value.bits)10:35
lkclincluding this:10:35
lkcl+                span = (span[0:3] + spec_span + ('{0}', '{0}') + span[3:5])10:36
lkcl+                span = (span[0:3] + spec_span + spshift * ('{0}',) + span[3:5])10:36
lkclbut spshift = 5-len(value)10:36
ghostmansdThat's literally the diff between these two classes10:36
lkclso that can be one of the parameters.10:37
lkclor even basically it's spshift10:37
lkclthat number value.value>>2 is spshift10:37
lkclaaaallll that information, vshift sshift spshift10:38
lkclis aalllll derivable from len(value)10:38
ghostmansd[m]I've been rather thinking of remembering and discarding 2 bits, then calling the common code, the adding10:38
ghostmansd[m]*then adding10:38
lkclif you set spshift to zero for GPR/FPR/5-bit-CR10:39
lkclthat idea becomes redundant / moot10:39
lkclbecause you would remove ZERO lsbs and shift value.value *by* zero10:39
lkclanyway. i leave it with you10:40
ghostmansdAaah I see you also touched the code for GPRFPR10:41
ghostmansdThat part I missed10:41
ghostmansdSo you suggest unifying ALL of these10:41
ghostmansdWhere each one will provide the shifts10:41
lkclyou can *calculate* all of them from len(value) (aka value.bits)10:42
ghostmansdyes to first no to second?10:42
lkclcorrect :)10:44
ghostmansdThese are all register operands, it just happens that some of them are 3-bit10:44
lkcland some of them have a couple of LSBs which need to be left alone (passed through), yes10:45
ghostmansdOK, got it!10:45
ghostmansdI'll do it10:45
ghostmansdMany thanks for making this code, it's much clearer now10:46
lkclah i just realised i got this wrong10:47
lkcl<lkcl> +                span = (span[0:3] + spec_span + spshift * ('{0}',) + span[3:5])10:47
lkclno it's right. it's spshift.10:48
lkcllet me drop in some comments10:48
*** octavius <octavius!> has joined #libre-soc10:53
lkclok done10:54
lkclnow CR5Operand class should *be* the one (only) class needed10:54
lkcli leave it to you to check these10:55
lkcl            sshift = 3 # len(value) aka value.bits10:55
lkcl            vshift = 4 # 7-sshift10:55
lkcl            spshft = 2 # 5-sshift10:55
lkclthere's only one parameter needed, spshft10:55
lkclyep i've confused the parameter which does the lsbs10:56
lkcldamn 1 sec10:56
lkclok corrected.10:58
lkcla new parameter, lsbshf.10:58
lkclthis is the *only* one that needs to be passed in as a parameter, it distinguishes 5-bit CRnum from 3-bit CRfield-num10:59
ghostmansdit actually complicated the stuff :-)11:04
ghostmansdbut OK11:05
lkclfortunately it's all the _same_ complicated stuff :)11:07
*** octavius <octavius!> has quit IRC11:13
cesarlkcl: I'm OK with a meeting at 17:00 UTC today.11:13
lkclcesar, great. sorry it's short notice11:14
ghostmansd[m]I'll join too11:16
lkcltoshywoshy, we've 5 people, you want to do the calendar-invite? email addresses on probably not paul :)11:17
lkclmarkos, ya good? or are you enjoying your weekend, like sane people? :)11:17
lkclthis is timezones11:19
lkclah wait added sao paulo as well11:20
ghostmansdlkcl, there's more11:25
ghostmansdthe span also differs11:25
ghostmansdGPR vs CR311:26
ghostmansdCR3 vs CR511:30
ghostmansdOK shshft is the same, so there's no span differences...11:31
ghostmansdCR3 vs CR5, better diff
ghostmansdI guess lsbshf is incorrect11:36
ghostmansd+            lsbshf = 011:36
ghostmansd+            lsbmsk = (1<<lsbshf)-111:36
lkcllsbshf should be zero for CR311:36
ghostmansdShould be 211:36
lkclno, it's definitely 0 for CR311:37
lkclbecause there are no LSBs to remove11:37
lkclthe LSBs refer to the bit *in* the CR Field.  EQ LT GT SO11:37
lkcli think.11:37
ghostmansdthis is diff between cr3 and cr511:38
lkcl1 sec11:38
ghostmansddiff -u cr3 cr511:38
lkclargh errr...11:38
ghostmansdI cleaned the code a bit but you get the idea11:39
ghostmansdYeah so 2, OK11:39
lkcl<lkcl> lsbshf should be zero for CR311:39
ghostmansdthat's a relief :-)11:39
lkcli had it at zero for *CR5*, whoops11:39
ghostmansdOK got it, just got surprised it was CR511:40
lkclthese reaaallly need proper unit tests11:44
*** tplaten <tplaten!> has quit IRC11:44
lkcli got the ball rolling with test_pysvp64dis.py11:44
lkclbut for some unknown reason addpcis gets converted to a .long11:44
ghostmansd[m]You missed my message11:45
ghostmansd[m]We don't have addpcis11:45
ghostmansd[m]So obviously it won't be found11:45
ghostmansd[m]Nothing to find :-)11:45
lkclbut it still should not be converted to .long11:45
ghostmansd[m]How come? Anything unknown is converted.11:46
lkcl- addpcis 12,511:46
lkcl+ .long 0x4d82000511:46
lkclFAIL: test_2_d_custom_op (__main__.SVSTATETestCase) [addpcis]11:46
lkclit worked as of when i first created that test11:46
ghostmansd[m]If db[self] or db[self.suffix] gets nothing, it goes to .long11:46
lkclthen 2 days later it didn't11:46
lkclahh ok11:46
lkcllet me "fix" that11:47
lkcloo-err maybe not11:48
lkcl  INSN_addpcis     =>  (ALU,  NONE, OP_ADD,       CIA,        CONST_DXHI4, NONE, RT,   '0', '0', '0', '0', ZERO, '0', NONE, '0', '0', '0', '0', '0', '0', NONE, '0', '0', NONE),11:48
lkclin microwatt11:48
lkclin1=CIA (moo?!)11:48
* lkcl scared!11:48
lkclyeah :)11:49
ghostmansd[m]Should be d0, d1, d211:49
ghostmansd[m]Like with fish move11:49
lkclit's a minor_19....11:50
lkclurrrr and it's one of those multi-pattern ones sigh11:50
lkclsigh first convert all of minor_19 to bitpattern11:51
lkclthen run all unit tests...11:53
lkclit worked!12:00
lkclpython3 src/openpower/sv/trans/  > /tmp/f12:01
ghostmansdoooh cool12:06
ghostmansd-                span = (span + spec_span)12:08
ghostmansd+                span = (span[0:3] + spec_span + (spshft * ('{0}',)) + span[3:5])12:08
ghostmansdThis is a tricky part between GPR and CR312:08
ghostmansd             if vector:12:08
ghostmansd                 value = ((value << vshift) | (spec<<spshft))12:08
ghostmansd-                span = (span + spec_span)12:08
ghostmansd+                span = (span[0:3] + spec_span + (spshft * ('{0}',)) + span[3:5])12:08
ghostmansd             else:12:08
ghostmansd                 value = ((spec << sshift) | value)12:08
ghostmansd-                span = (spec_span + span)12:08
ghostmansd+                span = ((spshft * ('{0}',)) + spec_span + span)12:08
ghostmansdHmm... Perhaps this can vary depending on len(value).12:09
lkclalmost certainly yes12:24
lkclit matches exactly what happens in value = .....12:25
ghostmansdYeah I know12:25
ghostmansdJust not sure how to make it common due to the fact that span[3:5] goes to the end12:25
lkclperhaps if value was expressed in the same way (without the <<) it might be clearer, might be not12:25
lkclthat's the 2 LSBs hum hum12:26
lkclhum hum it's assuming len(span)==512:27
lkclwhich urk is wrong for CR3Operand12:28
ghostmansdso there should be none span[3:5] for CR3, eh?12:44
ghostmansdonly for CR512:44
ghostmansdYeah it seems this span in the end is from LSBs12:47
lkclthat makes sense13:18
lkclmake tests then rebase13:25
markoslkcl, sorry was out for lunch with family, is it still on for 17:00 UTC?13:31
ghostmansdlkcl, I think I refactored CRs13:43
ghostmansdI'm not sure about `vector_shift = (2 + (5 - value.bits))` and stuff below. Subtracting it from 5 does not seems like the best option.13:44
ghostmansdKeep in mind though that we don't have these expressive instruments in C. So perhaps later I'll refactor it again so that it generates the fields automatically for C.13:47
ghostmansdIf I'll write something like this for binutils, they will for sure ban me from mailing thread. :-)13:48
lkclmarkos, yes14:32
* lkcl pokes toshywoshy, calendar invite jitsi url?14:32
lkcl- sv.isel 12,2,3,*48314:33
lkcl?                 ^^^14:33
lkcl+ sv.isel 12,2,3,*9914:33
lkcl?                 ^^14:33
lkcl : instruction does not match 'sv.isel 12,2,3,*99' expected 'sv.isel 12,2,3,*483'14:33
lkcl python3 src/openpower/sv/trans/  > /tmp/f14:34
lkclthat's in latest dis branch14:34
lkclwhereas current master works14:34
ghostmansd[m]Damn. I forgot to pull on Talos.14:51
lkclnew sv.crand test added as well (which is broken in master)14:55
lkcli didn't look at it last night, only 5-bit14:55
*** tplaten <tplaten!> has joined #libre-soc14:55
toshywoshysorry, just looking again at irc, can we move it to 18:00 UTC please15:01
lkclit was like 3am. i ran the unit tests on sv.isel but not sv.crand15:01
lkcl... sure15:01
lkcltoshywoshy, sure not a problem15:02
ghostmansdno-no lkcl, that's not related to crand15:02
lkcli'll ping everyone15:02
lkclghostmansd, ahhh15:02
ghostmansdecho -n -e "\xc0\x00\x40\x05\xde\x19\x82\x7d" | python3 src/openpower/sv/trans/pysvp64dis.py15:02
ghostmansdc0 00 40 05    sv.isel r12,r2,r3,*9915:02
ghostmansdde 19 82 7d15:02
ghostmansdIt's related to this bit15:02
ghostmansdwhat the deuce15:03
toshywoshyok, sending the invite15:04
lkclcesar, programmerjake, markos, ghostmansd, toshywoshy asked to move to 1 hour later ^15:04
lkcltoshywoshy, thx15:04
tplatenI had a look at ls2/simsoc.fst, there is activity on the wishbone bus that goes to the uart, but there is no activity on the tx line in gtkwave. I used the coldboot/coldboot.bin program for this test.15:04
lkcltplaten, you maaay be running into SYSCON not giving out the right information15:06
lkclnot using the right version of uart1655015:06
ghostmansdAh wait I see, *483 expected15:06
ghostmansdmmm... is it even legal?15:07
programmerjakelkcl, etc.: new time is fine with me15:08
tplatenyes, maybe. How is syscon generated?15:08
lkclit's not generated it's static compile-time information, read-only.15:10
ghostmansdLadies and gentlemen, this man is innocent!15:10
ghostmansd.long 0x054000c0; isel 12, 2, 3, 31 # sv.isel 12,2,3,*48315:10
ghostmansd.long 0x054000c0; isel 12, 2, 3, 7 # sv.isel 12,2,3,*9915:10
ghostmansdIt's pysvp64asm error not to check for operands15:10
ghostmansdThe disassembler gets the same results.15:10
ghostmansdaaaah wait...15:10
ghostmansd31, not 715:10
lkclghostmansd, deep joy :)15:11
lkclghostmansd, master-branch still gets *99 right...15:11
tplatenI also tested using verilator, and it does work in this case.15:14
tplatenmaybe I am using the wrong version of uart1655015:19
tplatenWhen I do git remote show origin, I get, git pull shows Already up to date.16:22
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC16:39
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:40
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:50
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc16:51
*** octavius <octavius!> has joined #libre-soc16:58
octaviusah ok, the meeting's been moved17:00
octaviusThought it was going to be at 5pm. Just got back from driving, good to have some rest XD17:01
ghostmansdlkcl, I think I've done it17:25
ghostmansdI haven't checked crand yet, though17:26
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC17:32
tplatenMy MicrowattSYSCON is:17:32
tplatensys_clk_freq 50000000.017:32
tplatencore_clk_freq 100000000.017:32
tplatenmem_clk_freq 50000000.017:32
tplatenhas_uart True17:32
tplatenspi_offset None17:32
tplatendram_addr 017:32
tplatenuart_is_16550 True17:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc17:33
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:44
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc17:45
tplatenI think I have found the error: In simsoctb.v I read "Generate 100 Mhz clock", but my design has 50 Mhz17:52
ghostmansdlkcl, as for crand: we don't support BRANCH or CR units yet. The code cannot match the mode.18:16
ghostmansdYou mentioned that neither CR nor BRANCH are ready. I can adopt code from and if you want.18:20
ghostmansd[m]I'll be late, hopefully in 5-10 minutes18:52
*** tplaten <tplaten!> has quit IRC20:14
programmerjakelkcl: update ext58/63 opcode counts -- so 58 10-bit xo ops in fptrans20:24
lkclprogrammerjake, ack20:34
lkclghostmansd[m], "doh" on crops. of course.20:34
lkcli kept these separate20:34
lkcl"an additional 8 instructions" .... (fminss/fmaxss, fminmag/fmaxmag)20:34
ghostmansdI fixed the error for recognizing the mode20:35
ghostmansdBasically added the stub20:35
ghostmansdYet another difficult part is this BA_BB crap.20:35
lkclyou're saying there's 58 *without* those 8-or-so?20:35
lkclghostmansd, awesome.20:35
lkclsigh, yes i know.20:35
ghostmansdCan we start with adding cr_out2?20:35
ghostmansdBecause then it'd work automatically.20:35
lkclbasically really BA and BB should be split into in1/in2/in3, it is a major hack20:35
ghostmansdIt simply cannot match either BA or BB with BA_BB.20:36
ghostmansdBut, if these are split, it will be matched.20:36
lkclmmm stress just don't break PowerDecoder220:36
lkclhang on20:36
lkclclass DecodeCRIn(Elaboratable):20:37
lkcl            with m.Case(CRInSel.BA_BB):20:37
lkcl                comb +=[2:5])20:37
lkcl                comb += self.cr_bitfield.ok.eq(1)20:37
lkcl                comb +=[2:5])20:37
lkcl                comb += self.cr_bitfield_b.ok.eq(1)20:37
lkcl                comb +=[2:5])20:37
lkcl                comb += self.cr_bitfield_o.ok.eq(1)20:37
lkcli'm reluctant to change that but it can be done20:37
programmerjakefptrans includes max/min/fmod/remainder now, it totals 58 10-bit xo values, so 116 instructions due to f*/f*s20:37
lkclghostmansd, yep no please don't do it - it involves too many changes to PowerDecoder2 right now20:38
programmerjake(basically easiest to look at the table and count the holes, then subtract from 64)20:38
lkclprogrammerjake, ok i want to keep them as a separate group20:38
lkclas they're IEEE754-2019 specific20:39
ghostmansdOK, but please let's plan this change.20:39
ghostmansdI'll do some sort of awful hackery now, but this is essential.20:39
lkclghostmansd, ack20:39
programmerjakeactually, it includes all of ieee 754-2008/2019 and x86-style fmin/max20:39
lkcljust... not right now :)20:39
ghostmansdlkcl, OK :-)20:40
programmerjakefmin/max is 8 xo, fmin/maxmag is another 8 xo, so without either of those it's 42 xo20:42
lkclis that *per 59/63*?20:43
lkcl16 for 5920:43
lkcl16 for 63?20:43
programmerjakeall fptrans ops have identical xo for f*/f*s variants20:44
programmerjakeso the opcode table is just shared between 59/6320:45
programmerjakelkcl: the min/max ops are *not* all ieee 754-2019, some are ieee 754-2008 and some are x86 maxss style20:47
programmerjakein particular, 1/2 of the xo are -2019, 1/4 are -2008 and 1/4 are x86 maxss-style (fminc/fmaxc, borrowing *c* from vsx)20:51
lkclnot going to worry about it20:59
lkclput that in the bugreport20:59
programmerjakeuuh, idk why it needs to go in #923, it's already in the wiki in the opcode tables...21:02
programmerjakei was more worried about factual correctness of;a=commitdiff;h=286420a80dbf56f6ada5bd180e7723cddefe540b21:03
lkclyep not going to worry about it21:04
lkclif it's already in #923 that some are 2008 and some 2019 that's for them to read and find out21:04
lkclghostmansd, a cheat would be to pre-process the csv files to add some new columns.21:07
ghostmansdI haven't thought about it21:07
ghostmansdBut this looks like the best option21:08
ghostmansdI'm already trying to adopt the code for about two hours in total, and it's really tricky21:08
lkcljust watch out for sv_analysis (etc) not freaking out21:08
ghostmansdYeah, let's totally cheat.21:08
* lkcl quick break21:09
ghostmansdNo I think I'll do it on the level where we already got the data but haven't converted it to dictionary yet.21:09
lkclhead spinning21:09
lkclohh yehyeh good call21:09
ghostmansdIIRC sv_analysis doesn't use power_insn21:09
ghostmansdOK at the point where we actually got a dictionary but don't have an object yet21:09
ghostmansdI mentioned cr_out2, I was wrong, cr_in2 I think it should be.21:10
ghostmansdOr CR out can be such too?21:11
ghostmansdI don't see it in CSVs, but hypothetically21:11
ghostmansd[[!tag opf_rfc]] is it expected in the end of RFC?21:18
ghostmansdlkcl, you'll like it: after this trick, `sv.crand *16,*2,*33` immediately started working.21:46
ghostmansdThe scalar version doesn't work yet (`sv.crand 12,2,33`).21:47
lkclyes, so it appears on the rfc list21:48
lkclyes actually cr_in1/2/321:48
lkclwait no21:48
lkclcr_in1/2 and cr_out21:48
lkcl            with m.Case(CRInSel.BA_BB):21:48
lkcl                comb +=[2:5])21:48
lkcl                comb +=[2:5])21:48
lkcl                comb +=[2:5])21:49
lkclso you can fake-drop BA into existing cr_in21:49
lkclbut need to create a 2nd fake-column... yes, cr_in2 .... which you put BB21:50
lkclif you create a new CRin2Sel to match it, that will help when it comes to modifying PowerDecoder221:51
lkclits only 2 options shoud be NONE and BB21:51
lkclyou'll also sigh need a new option on CRInSel: BA21:51
lkcli'll do it21:51
ghostmansdcf last changes21:54
ghostmansdthere's cr_in221:55
ghostmansdI added BB and BA to CRInSel, though21:55
ghostmansdlkcl ^21:56
ghostmansdAm I right that we need a custom operand, like target_addr?21:56
ghostmansdIt seems this cuts 2 bits from each BT/BA/BB21:57
lkclno it really shouldn't21:58
lkcli know why the microwatt team did it21:58
lkclthey didn't want to add just one extra column to the CSV files *just* for those cr* group of instructions21:58
lkclthey're the only ones that use BA BB BT i believe21:58
lkclp40 v3.0C section 2.5.121:59
ghostmansdso many fuss for these21:59
ghostmansdanyway, if we're careful, things will work even this way21:59
ghostmansdlkcl, about the opcode matching. It turns out that we need to circumvent this for binutils, too.22:02 script stopped working due to the fact that binutils need a SINGLE opcode and a SINGLE mask22:02
ghostmansdand, well... we have MANY.22:02
ghostmansdReproducer, if you're curious: `python src/openpower/sv/ include/opcode/ppc-svp64-gen.h`22:03
lkcldeep joy22:03
lkclhey there's this thing for merging to one opcode... :)22:03
lkclbut won't work for svshape, oh well22:04
ghostmansdStill it might depend on order22:04
ghostmansdThat said... We have hack for svshape in binutils.22:04
ghostmansdBut I don't like it.22:04
ghostmansdMoreover, I'm more and more inclined to think that one day we might perhaps replace main binutils table.22:05
ghostmansd(don't ever tell it to anyone!)22:05
ghostmansdWhat we might do is to have a big list of opcodes, expressed as static const uint32_t[].22:06
ghostmansdOr rather uint64_t, since that's what they use.22:07
ghostmansdAnd for each struct svp64_record, we might have a pointer to some section there, plus size.22:07
ghostmansdBasically offset for the first opcode and count of them.22:07
ghostmansdObviously code is totally unready for such experiments. They use huge static table, sorted by the opcode.22:08
ghostmansdAnyway, I'll return to binutils only when we're ready on disassembly part.22:09
ghostmansdI'd rather prefer to even start it after refactoring assembly, but, damn, these time constraints.22:10
lkclsigh i know22:11
lkclwell things still continue (and $)22:11
lkclbtw do remember we can define tasks as "completed" by cutting down their definition22:12
ghostmansdYeah I will reserve this as a last resort :-)22:12
ghostmansdI could go with "providing a solid and rapid basis for binutils disassembly", lol22:12
ghostmansd(not as rapid in terms of how much time it takes to create it, eh?)22:13
ghostmansdbut rapid in terms "fuck look they just cut the fields by names and indices, what a drama!"22:13
ghostmansdI cannot really resist to an idea that the whole `struct svp64_ctx` goes down the drain and is replaced with a single 64-bit `struct svp64_insn` with getters and setters.22:14
ghostmansdMAGA really stands for "make assembly great again!"22:15
lkclgooood :)22:15
ghostmansdlkcl, FYI, I rebased over the change you did to enums22:17
ghostmansdlkcl, I thought more. We really can generate list of opcodes.22:21
ghostmansdWe do use our own lookup function. We lookup in both tables, vanilla powerpc_opcodes and our svp64_records.22:24
ghostmansdSo, we can employ whatever form we need.22:24
ghostmansdFor disassembly.22:24
ghostmansdFor assembly, we lookup in both tables, too (hashed), but use the opcode from binutils table.22:25
ghostmansdFor old vanilla instructions it works; for new ones, we just have to be careful (svshape2, I'm looking at you!).22:26
*** lkcl <lkcl!> has quit IRC22:27
ghostmansdSo, here:
ghostmansd...we can just check not a single opcode but multiple ones.22:32
ghostmansdNot sure which one should be considered for a assembly when (if) we start generating this. Probably the crap I produced by merge function.22:33
ghostmansdBecause for assembly we don't need to lookup opcodes; we only need PO, XO and static fields, both in opcode and mask form.22:33
ghostmansd[m]Hopefully one last note today: some modes re-use the fields (e.g. elwidth). I think we should rather have multiple different RM layouts.22:40
*** ghostmansd <ghostmansd!> has quit IRC22:53
*** alain <alain!> has joined #libre-soc23:17
*** alain <alain!> has left #libre-soc23:17
octaviuslkcl, is there meant to be extra indentation in the example assembler code?23:42
octaviusFor example in the DCT section, all but the first line have extra indentation23:43

Generated by 2.17.1 by Marius Gedminas - find it at!