Monday, 2022-07-11

ghostmansd[m]lkcl, I read the Alan's reply and your additions. I think it'd be easier to really just change the conventions.06:14
ghostmansd[m]That said, if time permits, I can try some tricks with a tree.06:16
lkclghostmansd[m], yeah agreed about changing conventions.10:02
lkclsigh, ~ff=ne as well10:02
ghostmansd[m]What does it mean, ~ff=ne?10:04
lkclfail-first based on inverted CR bit... oh right10:04
lkcl~ff=eq10:04
lkclhmmm that's not obvious at all is it10:05
lkclinverted fail-first equal10:05
lkcldon't like it.10:05
lkcltree-changing is probably a better overall approach.10:06
octaviushi lkcl, I've been looking at the spec pdf, and noticed the fields.tex doesn't separate the bitfields lines.10:59
octaviusIf there's a way to add \par at the end of every line, that could make things clearer. Another problem is the column padding, as well as sub-columns (for example bits 6-10 corresponding to the RT bitfield/column in X-FORM) which look the same.10:59
lkclbitfield lines, que? que?11:00
lkclfields.tex... ahh11:00
lkclwe have to be careful about fields.tex because power_fields.py is its corresponding machine-reader11:01
octaviusAh ok11:02
lkclfields.tex is very deliberately *not* done as tables because the "|"s are bit-aligners using ascii11:02
lkcllook at DQ-Form for an example11:02
lkcl  33 #1.6.6 DQ-FORM11:03
lkcl  34    |0     |6     |11    |16    |28|29 |31 |11:03
lkcl  35    | PO   |  RTp |   RA |   DQ |   PT     |11:03
lkcl  36    | PO   |  S   |   RA |   DQ |SX| XO    |11:03
lkclPT spreads across 28-3111:03
octaviusAt least for the entries, there's probably a way to add \par? Otherwise the document just shows a stream of numbers, letters and | XD11:04
lkclbut SX is bit 28 and XO bits 28-31 for the other variant of DQ-Form11:04
lkclno it doesn't.11:04
octaviusI mean in the filtering11:04
lkclgit pull on openpower-isa, you are out-of-date11:04
octaviusah ok11:05
lkclhttps://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=b7bdc6cb587beab6c34408a5137ac451ec546e2711:05
lkcl@@ -1,318 +1,318 @@11:05
lkcl #1.6.1 I-FORM11:05
lkcl-   | PO   |      LI  |AA|LK |11:05
lkcl+    |0     |6         |30|31 |11:05
lkcli added one extra space which brings it to a total of 4 spaces which is the trigger for "fixed-width-font-code-block" in markdown11:06
octaviusAh ok, something wrong with my repo (comparing against the generated pdf on the ftp server)11:08
octaviusI did git pull already11:08
lkclmake clean11:12
octaviusAh, I was dumb. My libreriscv repo is not in a chroot, and I have a separate copy of openpower which I didn't git pull11:12
lkcl:)11:12
octaviusNow I did fix some missing spaces for three sub-headings in fields.text, it caused the pandoc to not generate correctly11:17
lkcl*DON'T* alter fields.text.11:20
lkclit is a mission-critical file where if you make a mistake it will terminate absolutely everything11:21
lkclsimulator11:21
lkclunit tests11:21
lkclTestIssuer11:21
lkclabsolutely everything fundamentally and critically relies on those machine-readable files.11:21
lkclthere are a couple of mistakes i've spotted (compared to the v3.0B spec that fields.txt was taken from) but fortunately those aren't in use11:22
lkclplease drop a -/+ diff here in irc for review on *exactly* what you mean "fix some missing spaces for three sub-headings"11:24
lkclhttps://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=6aa7a4619676d4c5a5ce245489feb607e83b5e5811:25
lkcldid you run any unit tests to check that those changes did not break anything?11:25
octaviusNo I didn't, sorry about that.11:25
lkcloctavius, that is absolutely critical to do11:26
lkclyou may have terminated everyone's ability to do any work11:26
lkclthis is source code, not a "random document"11:26
octaviusWhere are the tests that I need to run before any submission?11:27
lkclit might seem "obvious" that "oh just add a space"11:27
lkclall of them in this case!11:27
lkclexecuting power_fields.py to check it reads is the first priority11:27
octaviusin openpower-isa, or are you talking about *all* the dev repos?11:27
lkclwell it is diminishing returns11:27
lkclin this case, if just one of test_caller*.py works then chances are that you didn't do any damage to the file format11:28
lkclbut even pywriter critically depends on fields.text through power_fields.py11:28
lkclsv_analysis11:28
lkclsv_binutils11:28
lkclabsolutely everything11:28
lkclif you had changed one of the Forms itself then that could have damaged just one of the instructions11:29
lkclor more11:29
lkcland finding out which? the only way: run *all* unit tests.11:29
lkclso you have to be intelligent about it.11:30
lkclin this case as it is just headings that you changed, chances are high that there's not been any damage11:30
lkclbut you still have to check (running power_fields.py and a couple of test_caller*.py tests would do that)11:31
octaviusI ran the power_fields.py and it generated. I'll try some of the test_caller tests now11:32
lkclbrilliant11:33
lkclone (short one) will do.11:33
octaviustest_caller_bcd ran and passed. test_caller_bitmanip ran and passed, but has an UnboundLocalError: local variable 'insn' referenced before assignment11:40
lkcloctavius, 1 sec11:41
octaviusAh sorry, that's found in svp64.py11:41
octaviushttps://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=f4b03a5f276967d0570f2f97660fc3e7228b97a9;hb=HEAD#l29311:43
octaviusthe grev function doesn't define insn11:44
lkclyep, that's ghostmansd[m] sorting out svp64.py last week, consolidating things.11:45
octaviusAlso, I apologise for not running the commit with the team beforehand. And thank you for the warning and lesson, it's a good thing you taught me now before we had any serious consequences11:45
lkclif you want to have a go at fixing that it's easily done, insn = PO = 511:45
octaviussure11:45
lkclreally, a list of dependencies is needed (in graphical form)11:45
lkclsomehow11:46
ghostmansd[m]lkcl, but we have both eq and ne.11:46
ghostmansd[m]Why invent ne == ~eq?11:46
lkclghostmansd[m], yes. hence ~sm=CRfieldbit is not... exactly11:46
lkcland saying (in your head), "negated eq" is... meh11:47
ghostmansd[m]Aaaah I got what you mean11:47
ghostmansd[m]You're talking of how it looks to anyone familiar with English11:47
lkclyes. reading it out in their head11:48
ghostmansd[m]You know what? Let me check how it goes with expression tree.11:48
ghostmansd[m]Perhaps it goes better than I expect.11:48
ghostmansd[m](actually I really think it will go smoothly enough)11:48
octaviusAdded the insn init, ran test and passed (both 0 and 1)11:48
* lkcl learned a couple of years ago that programmers use the same foreign language centres for understanding11:48
octavius" foreign language centres" ?11:48
lkcloctavius, fantastic, then that's good enough / clearance to commit it.11:48
lkclfrench, english, spanish, greek, serbo-croat, mandarin11:49
lkclanything-not-native-tongue11:49
octaviusAh, you meant in you brain11:49
lkclyour brain uses the exact same centres for processing *computer* languages11:49
octaviusI thought you talked about 'centres' as in institutions or buildings11:50
ghostmansd[m]Yes, because, after all, it's still a language11:50
ghostmansd[m]And we all know these are for people not computers11:50
ghostmansd[m](unless we have someone here who speaks in 0 and 1)11:50
octaviusDa net naverno ;D (yes no maybe)11:51
ghostmansd[m]Well that's ternary logic11:52
ghostmansd[m]Should've been placed this way: net naverno da11:52
ghostmansd[m]Or - 0 +11:52
octaviusNah, I meant that it's a valid phrase (essentially no)11:53
ghostmansd[m]Ah I guess it'd be difficult to translate it11:53
ghostmansd[m]I mean, "yes no maybe" doesn't explain it :-)11:53
octaviusProbably not11:54
lkclthat's called "covering your bases" :)11:54
octavius:P11:54
lkcli heard a story about someone who did a Cambridge Entrance Exam11:54
lkcl3 hours to write an essay on the topic "Is this a question?"11:55
lkclthey first wrote:11:55
lkclyes11:55
lkclthen after half an hour, crossed it out and wrote:11:55
lkclno11:55
lkclafter another hour, they crossed that out and wrote:11:55
lkclmaybe11:55
lkclthey got a Distinction and an acceptance letter.11:56
octaviusXD11:58
ghostmansd[m]lkcl, yes, I think what we want is doable; I guess this will constitute some special machine-dependent operand type, but this is even better.12:12
markosghostmansd[m], ok, so *finally* I can resume actual work on svp64, so how do I build binutils with svp64 support? is it upstream already?12:13
lkclmarkos, yay!12:15
lkclthis should do it12:16
lkclhttps://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=binutils-gdb-install;hb=HEAD12:16
markoslkcl, sorry it has taken so long12:16
lkclbear in mind, ghostmansd[m] is literally working on field-support right now for things like the "sm=r3" part of "sv.addi/sm=r3"12:17
lkclhey no problem12:17
ghostmansd[m]Actually the current version resides in a different branch, svp64-ng.12:18
ghostmansd[m]But at this point I think I might as well move it to svp64 branch. This svp64-ng is a heavy refactoring, and also has macros support.12:19
ghostmansd[m]markos, I'll sync the branch12:19
lkclVeera[m], looks really good12:21
ghostmansd[m]markos, I've overridden the legacy svp64 branch with the current state of art; I'll continue tuning macros and prefix stuff on svp64-ng.12:21
ghostmansdmarkos, please also check this commit c58f3e556d4b7271ec90a1fb26ec47fd84aae37612:22
markosok12:22
ghostmansdIt shows some updates we did to assembly recently12:22
ghostmansdAnd binutils follow this notation (we'll also do, but later)12:23
Veera[m]lkcl: I am thinking of working on bug #883 - add cvc5 and bitwuzla to hdl-yosys-tools13:07
Veera[m]lkcl: After that I wanted to submit RFPs13:07
lkclVeera[m], yes good idea, then do all R... yes :)13:07
lkcldo make the installs in /usr/local, which is the default. no need to set PREFIX=13:08
lkcland especially no need to set prefix=/usr/local/somewhere_non_standard13:08
lkclit means having to explicitly add to $PATH which is getting inconvenient13:08
Veera[m]lkcl: One question: Did DDR3 64x16 Mb worked on ECP5 Versa Dev Board13:08
Veera[m]lkcl: OKay13:09
lkcllast time i checked, yes13:09
lkclmy board would only run at 55 mhz though.  the manufacturing tolerances on the DRAM ICs are *between* 48 and 55 mhz13:09
Veera[m]ECP5 Versa Dev Board: What is the price? 85K version13:10
lkclthere is no 85k version13:10
lkclraptor engineering got a one-off ultra-expensive custom board13:10
Veera[m]digikey shows one with price around $100. I was not sure so asked!13:11
lkclyou're probably thinking of this13:12
lkclhttps://www.digikey.co.uk/en/products/detail/lattice-semiconductor-corporation/LFE5UM5G-85F-EVN/955390713:12
lkclwhich is *not* a VERSA_ECP5, it's a bare-bones evaluation board with pretty much one IC on it: the ECP5-85K FPGA13:12
Veera[m]Not. https://www.digikey.in/en/product-highlight/l/lattice/ecp5-versa-evaluation-board13:14
lkclthat's a top-level product listing page.13:14
lkcltheLFE5UM-45F-VERSA is only a 45k LUT4.13:14
Veera[m]Sorry. I missed the meaning.13:15
Veera[m]Aside. Did Orangecrab ecp5 84k lut worked with memory?13:16
lkclapparently it works in other systems.13:16
Veera[m]mean other verilog code13:17
lkclyes13:17
Veera[m]For versa it is in docs that it works upto 800Mbps mode. And for SDRAM 133MHz the lowest limit is around 50Mhz.13:19
lkclDRAM ICs have manufacturing tolerances.13:20
lkclthe data sheet for the MT64k(something) says "100mhz"13:20
Veera[m]What the doc for Versa's says about its DDR3 lower limit of frequency?13:20
lkclin reality, as low as 48-55 mhz works13:20
lkclnothing.13:20
lkclit's not their responsibility.13:20
markosok, fyi, trying git clone in the schroot fails with libcurl3-gnutls from backports, it gives 'Failed sending HTTP request'14:54
markosafter some search, I found out that you need to downgrade to latest from stable  and pin it there, ie 7.64.0-4+deb10u214:55
markosbackports version is 7.74.0-1.2~bpo10+114:55
markosor in other words, how to spend half your day cloning a git repo14:56
markoshttps://stackoverflow.com/questions/65556397/git-clone-always-fails-with-failed-sending-http-request14:58
ghostmansdlkcl, https://bugs.libre-soc.org/show_bug.cgi?id=849#c2015:32
ghostmansdTL;DR: macros _are_ difficult. It's funny that we stuck on modes, but it seems that this revealed an issue in vanilla PPC (or not, if they choose not to support stuff like ".set REG, %r0" at all).15:33
ghostmansdAnyway, we're almost here, I think. Once we can use registers in macros, we're really close to stuff like 1<<%r3.15:34
ghostmansdI'll need Alan's advice on this, though.15:34
markosghostmansd, ok, binutils built, how to test svp64 compilation?16:07
markosassembler rather16:08
markosI mean what's the compilation flags used?16:17
lkclmarkos, that's a pain. i've added the voodoo magic incantation to install-hdl-apt-reqs16:32
lkclghostmansd, ah 1<<%r3 is not needed. that's too much.16:33
lkclmarkos, "powerpc64le-linux-gnu-as file.s -o file.o" will do it.16:34
markosso, what works and would I need to change?16:36
lkclpysvp64asm absolute basic use of ".set something regnum" works16:37
lkcllike this https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/audio/mp3/mp3_0_apply_window_float_basicsv.s;hb=HEAD16:38
lkcl  26 # SV floats16:38
lkcl  27 .set fv0, 3216:38
lkcl  75         sv.fmuls *fv0, *fv0, *fv116:38
lkclbeyond that i recommend the trick of taking a c version, compiling to assembler, and hand-editing16:40
lkclgcc -s c_version.c -o converted_to_assembler.s -mnovsx -mnoaltivec16:41
lkclsomething like that16:41
markosI think it may have not picked up the right branch, cause it gives me 'unrecognized opcode'  errors for sv.* instructions in this file16:41
markosit's svp64 branch right?16:41
markos$ powerpc64le-linux-gnu-as -v16:41
markosGNU assembler version 2.39.50 (powerpc64le-linux-gnu) using BFD version (GNU Binutils) 2.39.50.2022071116:42
markosis this correct?16:42
markosit's running natigve on a power9 system/vm if that helps16:42
ghostmansd[m]markos, you need -mlibresoc flag16:53
ghostmansd[m]powerpc64le-linux-gnu-as -mlibresoc asm.s -o asm.o16:54
ghostmansd[m]>> ghostmansd, ah 1<<%r3 is not needed. that's too much.16:54
ghostmansd[m]lkcl, we've already discussed it, this is how PPC assembly works: you need to either use %, or always pass -mregnames16:55
ghostmansd[m]So you can use 1<<r3 but no sooner than you pass -mregnames.16:56
ghostmansd[m]In some contexts, you can omit r, e.g. in instruction operands.16:56
ghostmansd[m]But I doubt it's doable on macro level. Moreover, what would 1<<3 mean to anyone? Hardly a register.16:57
markosstill unrecognized opcodes, maybe I missed something16:57
ghostmansd[m]So yeah, either 1<<%r3, or -mregnames and 1<<r3.16:57
markosa50e2deae0dcfca57cd95abee416ed4e8d87d175 last commit, looks ok16:57
markosmaybe the configure cmd needs something extra?16:58
ghostmansd[m]Markos, afk. What exactly do you try to compile and how?16:59
markospowerpc64le-linux-gnu-as -mlibresoc mp3_0_apply_window_float_basicsv.s16:59
markosmp3_0_apply_window_float_basicsv.s: Assembler messages:17:00
markosmp3_0_apply_window_float_basicsv.s:56: Error: unrecognized opcode: `setvl'17:00
markosetc17:00
markoschecked if I'm running the right as and I am17:00
ghostmansd[m]Please show the top commit17:07
ghostmansd[m]Does -mlibresoc work?17:07
ghostmansd[m]Aaahh17:07
ghostmansd[m]Yeah17:07
markosit seems so17:07
ghostmansd[m]Crap17:08
ghostmansd[m]Open this file17:08
ghostmansd[m]And set .machine to libresoc17:08
markosah cool17:08
ghostmansd[m]Does it work now?17:09
markosyup17:09
ghostmansd[m]It should :-)17:09
ghostmansd[m]Awesome :-)17:09
markosok, now compiling my own code17:09
markosuncommented the sv.* instructions17:09
markosas expected, I get syntax errors :)17:09
markossetvl 0,0,18,0,1,1                      # Set VL to 18 elements17:10
markos        # Load 18 floats from (in)17:10
markos        sv.lfs 8.v, 0(5)17:10
markosmp3_1_imdct36_float.s:70: Error: syntax error; found `.', expected `,'17:10
markosmp3_1_imdct36_float.s:70: Error: junk at end of line: `.v,0(5)'17:10
markosso I guess it doesn't like the offset17:10
markosor the .v annotation?17:11
markosI see it has changed in the other file17:11
markosit's now *17:11
markoswhat's the /els for?17:12
markosyup * worked17:12
ghostmansd[m]markos, sorry, I'm driving now :-) I'll help you later17:20
ghostmansd[m]I see you found a new convention already :-)17:20
markosit's ok, I'll do some tests17:21
markosthanks a lot for your work17:21
markosit's a game changer17:21
markosdo we by any chance have an instruction to load a float constant immediate ?17:30
markosalso, another question, but does "pointer" arithmetic work eg. sv.adds *fvs+1, *fvs+1, *fvs17:38
ghostmansd[m]Hm, not sure, I haven't checked it.17:53
ghostmansd[m]What do you expect from it?17:53
ghostmansd[m]What is fvs, for example?17:53
ghostmansd[m]How it works is: 1) we find whether * is present and if so remember that this is vector; 2) we parse the operand into vanilla PPC expression; 3) afterwards, if it was a vector, we tune it appropriately.17:55
ghostmansd[m]Other than that, we do nothing IIRC.18:03
ghostmansd[m]So, we record the fact that it was a vector, and simply store this fact into some structure associated with the expression.18:04
ghostmansd[m]On the other hand, there might be some stuff to be updated. For example, I have yet to check the routine which takes care of optimization.18:07
lkclmarkos, *fvs+1 would be "the register number from the macro fvs, plus one"18:22
lkclso if you had18:23
lkcl.set fvs 1218:23
lkclthen *fvs+1 i would expect to become *1318:23
ghostmansd[m]Yep, mine impression too18:23
lkclthat's if the expression logic works at all, reducing down to numbers18:24
ghostmansd[m]It likely does, yeah18:24
ghostmansd[m]I mean, if it worked before me, it still should :-)18:24
ghostmansd[m]Because this part I haven't touched18:24
lkclmarkos, fmvis i haven't implemented in the simulator yet, if you wanted to have a go at it yourself i can walk you through the process18:26
lkcl(and justify some budget for doing so)18:26
lkclmarkos, if you can do the two instructions fmvis and its other half i can justify a budget of EUR 2000 (i'll need some to help you out) under this https://bugs.libre-soc.org/show_bug.cgi?id=23418:29
lkclaaand i thiiink... DX-Form i already added.... soo... https://libre-soc.org/openpower/sv/int_fp_mv/#fmvis18:30
lkclthe pseudocode's already in that page...18:30
lkcland there's two patches here which show how it's done https://bugs.libre-soc.org/show_bug.cgi?id=234#c118:31
ghostmansd[m]> Should I put it on the review on mailing list, or it's a bit early yet?18:35
ghostmansd[m]lkcl, ^^^ we forgot about it18:35
lkcldon't worry about it18:35
lkclmarkos: /els means "element-strided"18:36
lkclhttps://libre-soc.org/openpower/sv/ldst/18:36
lkclelement strided (sequential but regularly offset, with gaps)18:37
lkclhave a look at the pseudo-code for op_load18:37
lkcl      # element stride mode18:37
lkcl      srcbase = ireg[RA]18:37
lkcl      offs = i * immed18:37
lkclthis is something unique to Vector ISAs18:37
markoslkcl, I will check this out, it doesn'19:08
markos+doesn't look like something too advanced for my level19:08
markosreg. the *fvs+1, yes, that's exactly what I would expect it to be19:09
markosie:19:09
markos# equivalent to: for (i = 17; i >= 1; i--) in[i] += in[i-1];19:09
markos        sv.fadds/mrr *vin+1, *vin+1, *vin19:09
lkclwow and that actually makes sense, too19:37
lkclthat one is "map-reduce, reverse-gear"19:40
lkclit's actually a complete misnomer, "mapreduce"19:40
lkclyou actually want the reverse-gear mode but "/mrr" is the easiest way to get it19:41
markoswell, it already worked before19:41
markosbut with absolute register numbers19:42
markosnow it's more intuitive I think19:42
markosand plenty more like that in the code19:42
lkclthe way mapreduce works btw is that it relaxes the conditions of terminating the looping if the result is a scalar19:46
lkclmapreduce *keeps going*19:46
lkcltherefore it's up to you to use it with a scalar-source-equal-to-destination19:46
lkclto give the *appearance* of a mapreduce19:46
lkclbut in this case it's being used entirely with vector-source and vector-dest19:47
lkclbut19:47
lkclthere's no other easy way to enable reverse-loop (VL-1..0 rather than 0..VL-1)19:47
markosis fmvis supposed to take hex constants only? I mean is the fp -> int conversion supposed to happen in the assembler? or should I handle fp constants as well?19:54
markosie fmvis f4, 0x40000000 vs fmvis f4, 2.0f19:54
lkclmarkos, for now yes.20:06
lkclas this is an entirely new instruction it's down to us to *define* what it takes20:07
lkclbut none of the sv/trans/svp64.py infrastructure copes with fp numbers and likely not hex or binary either20:07
ghostmansd[m]Well, svp64.py can't, but binutils can.21:08
ghostmansd[m]I mean f prefix.21:09
ghostmansd[m]As for constants, I haven't checked it yet, but this is doable, if not present yet.21:11

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!