Thursday, 2022-06-30

lkclmarkos, ghostmansd[m] has been doing binutils-gas he's currently going through the macro system etc.00:03
lkclwe maay have to redefine identification of vectors to make it easier for binutils to recognise00:04
* lkcl is worn out from 2 late-night back-to-back meetings00:04
lkclprogrammerjake, it's unnecessary. the "problem" that you are perceiving does not exist, because VSX has solved the problem of transferring between FPR and VSX registers already00:22
lkclinstructions exist to perform mvs between the halves00:23
lkcland when SVP64-Vectorised, those transfer instructions will gain the full access to the full range of 128 FPR registers00:24
programmerjakeimho that's an insufficient solution...svp64 *should* be extended so it can use all the bits of the fpr/vsx/gpr/etc. registers, otherwise it's wasting 1/2 the register file00:25
lkclyes there are enough reserved bits in SVSTATE to be able to extend in the future: it'll need a 64-bit instruction or a second 32-bit instruction to do it00:25
lkclbut jacob00:25
lkclwill you stop00:25
lkclplease stop00:25
lkclfrom what is designed00:25
lkclit is00:25
lkclto change00:26
lkclfrom what has00:26
lkclbeen designed00:26
lkclit is00:26
programmerjakee.g. sv.fadd f10.v, f20.v, f30.v could use all 1280 bits of the f10-f19 vector00:26
lkcljacob: please stop00:26
lkcli don't want to discuss it00:26
lkcli don't want the distraction00:26
lkcli do not want to waste my time on it00:27
lkcli do not want to have to go over years of work re-evaluating it00:27
lkclwill you00:27
lkclfor god's sake00:27
programmerjakethe setvl idea is so it can use 128-bit regs as an extension, not as base svp64...just like 256/512 registers are an extension on svp6400:27
lkclplease STOP00:27
lkcli want to get through the ISA WG with what we have *already done*00:28
lkclyou are risking derailing the entire process of what has been done00:28
lkclby throwing it into jeapordy and doubt00:28
lkclbecause it will be perceived as "not ready"00:28
lkclplease STOP00:28
lkclwhatever ideas you have for extending to 128 bit and to greater than 128 registers *please bury it*00:29
lkcluntil AFTER we have got through the first ISA WG proposal00:29
programmerjakethe idea is a way to make svp64 more palatable to the ISA WG...we put some thought into how svp64 will work with the existing openpower instructions, rather than just saying idk, figure it out on your own, idk if it clashes00:29
lkclif IBM wants to invest the time and money into it then they can do so00:29
lkclbut we are NOT in a position, time or funding wise, to do that work for them00:30
lkclthe answer is very blunt and very simple00:30
programmerjakeall i want is a note in the setvl docs that how i described is how it can be done, no other thought necessary00:30
lkclif you, other ISA WG members, want that idea considered, please put up the funding and the engineering teams necessary to do it00:30
lkclit's TOO MUCH00:30
lkclany note about extending should be marked "completely out of scope for this version of SVP64"00:31
programmerjakejust like extending to >=256 registers00:31
lkcli DO NOT want the entire efforts of 4 years to be derailed by people deciding to add something that will take an ADDITIONAL 1-2 years to consider00:32
lkclwe DO NOT HAVE TIME00:32
lkclplease get this through your head that we are under time and budget pressure and HAVE to say NO00:32
lkcli know you have difficulty with this00:32
lkclbut please00:33
lkclfor god's sake00:33
lkclplease listen00:33
lkclit doesn't matter if it's "better"00:33
lkclwhat matters is that we don't get screwed over by people expecting *us* to do their design work00:33
programmerjakeyeah, i get that you think we're out of time...imho all we need to do for now is add that note to show we actually considered it and think it'll work well00:33
lkclif someone with MONEY and ENGINEERS comes along and says "we're prepared to HELP you to add 128-bit registers and extend to 256 registers" i have absolutely no problem with it00:34
lkcli don't00:34
lkclto go over it00:34
lkcl*i* don't have time to go through the full implications, ok?00:34
lkcli have told you this multiple times00:34
lkcli am barely keeping the entire design - the entire document - in my head, as it is00:35
lkcli stopped for only 2 months to do ls2 and it was a serious mistake00:35
lkcli CANNOT COPE with the additional task of assessing what you are proposing00:35
programmerjakethen don' can trust me to have considered the implications enough to think it'll likely work...00:35
lkclbecause i know it will take me WEEKS TO MONTHS to go over it00:35
lkcli will be the one proposing it00:36
programmerjakeyou c00:36
lkcland advocating it to the ISA WG00:36
lkcl(through RED Semiconductor)00:36
programmerjakeyou *can* propose something that has other people's opinion/thoughts...00:36
lkcland if i don't fully understand it then it will jeapordise confidence in the entire effort00:36
lkclso NO00:37
programmerjakeso make it a team effort...00:37
lkclplease get it through your head, the answer is NO00:37
programmerjakeso, are you ok with me adding that *i* think it'll work as a note in setvl's docs? you can say, jacob wrote that, ask him00:38
lkclno, i'm not.00:39
lkclthe only thing i am ok with is "128-bit registers and greater than 128 registers is out of scope for this version of SVP64"00:39
lkclabsolutely NO discussion of potential ideas, no options, nothing00:39
markosapologies for intruding, but you're discussing in the public channel anyway, my 2c, it doesn't have to be all complete in the first proposal, or even in the first SOC, you could always say there will be a version 2 with many extra features/changes/etc incl. 128-bit vectors and be done with it? :-)00:39
lkclbasically yes, but UNDER NO CIRCUMSTANCES should there be, in the spec, one SINGLE mention of any of what those potential ideas are00:40
lkclPRIVATELY they can be discussed00:40
lkcl(on the bugtracker)00:40
markosplus it's easier to push for an update once you get your foot inside the door if I'm using the phrase correctly00:40
lkclbut in the spec? absolutely not00:40
programmerjakehow about "there are some proposals for how 128-bit registers can interoperate with svp64, they are out of scope for this version"00:41
lkclwe cannot put a specification to the ISA WG "err we had maybe some ideas"00:41
lkcl<lkcl> the only thing i am ok with is "128-bit registers and greater than 128 registers is out of scope for this version of SVP64"00:41
programmerjakewhy not, iirc the risc-v spec has some notes to that effect00:42
markoslkcl, what if they ask for a roadmap for next revisions?00:42
lkclwith "there are reserved bits for extending capabilities"00:42
markoswhich they probably will tbh00:42
* lkcl thinking00:42
lkclyou need a stakeholder to drive whatever it is00:43
markosit wouldn't be an actual commitment to do anything00:43
lkclthe amount of time that we've spent, and the amount of time and money i know will be needed to put this into silicon, there has to be a line drawn in the sand that we do not cross00:44
lkclmy problem with these 128-bit and >128 registers is, i know how much f*****g work it is in hardware00:44
programmerjakethen *don't implement them* in libre-soc's core...00:45
markosI understand that, but esp the business people might want to see that you have a pretty good idea about how you're going to take them to the next level and keep them ahead of the others00:45
lkcland even just *considering* to extend to 128-bit and/or >128 registers, you *have* to actually do a full work-through00:45
lkclin order to be able to fully ensure that you don't end up creating an ISA that is fundamentally unimplementable00:45
markosthey have to see that their choice is sound and future-proof for many revisions, not just the next00:46
programmerjakeno you don't, you just say it's a partially thought out idea and it's better than insisting on not thinking about it at all00:46
lkclprogrammerjake, if we don't implement them (or at least do the design walk-through, which takes months) then we are in absolutely no position whatsoever to design the ISA00:46
programmerjake^ in reply to lkcl00:46
lkclin RISC-V, absolutely nobody has actually done a 128-bit or greater implementation00:47
lkclthus the entire issue can be deferred00:47
programmerjakei did a bit of design walkthrough in my head...00:47
lkclprogrammerjake, exactly00:47
lkclthat was my biggest concern, that you would do that, and not spend the time on things that keep NLnet happy with us00:48
programmerjake128-bit registers does *not* mean 128-bit addresses or that openpower's scalar instructions default to 128-bit, it's still a 64-bit isa00:48
lkclfolks, i'm done.00:48
lkclthis has been almost an hour wasted of my time which i SPECIFICALLY did not wish to get into00:48
markosin my POV, you both are right, but I think you are disagreeing too early for what is essentially a non-issue00:48
lkclbecause i know how much time is involved00:48
lkcli am really angry jacob that you keep doing this00:49
lkclyou keep pushing00:49
lkcland pushing00:49
lkcland pushing00:49
lkcland pushing00:49
markosI think you should defer this discussion for a later date00:49
lkcli don't want to discuss it AT ALL00:49
lkcli don't want to have discussions about whether it should or should not be discussed00:49
lkcli do noit00:49
lkcl128 bit00:49
lkclany discussions00:49
lkclAT ALL00:49
programmerjakeyeah, ttyl, i have to go pick our cherry tree (fun...kinda)00:50
lkcluntil we have FINISHED the NLnet grants00:50
lkcland got proposals in to the ISA WG of what is already done00:50
lkcli can't cope00:50
lkclso please00:50
lkclno more00:50
programmerjakehow about "until we have finished the nlnet pet grants", i expect we'll have nlnet grants of some sort for years to come...00:51
programmerjakethe ones that expire in oct00:51
markoshow about we go for prime-number vector sizes, eg 127? :D00:52
markos /jk00:52
markosit's really late here, ttyt, I'd love to start playing with the new binutils on svp64 soon, so I'll ask for help tomorrow00:53
programmerjakeooh, 2^127-1 bits :) need a planet-worth of ram chips00:53
ghostmansd[m]markos, be aware that current binutils don't support macros in SVP64 mode. I'm working on this, but it needs time.06:48
ghostmansd[m]Also, markos, today I won't be able to help, I'm basically AFK today, but tomorrow I might try09:16
ghostmansd[m]Today I can only help with the stuff I recall and can type via mobile09:16
markosghostmansd[m], well, basically it comes down to : a) how do I build the new binutils b) what works and what doesn't and finally c) how can I test the binaries?11:21
markosI guess for c) it's still the python simulator11:21
ghostmansd[m]a) there's a script in dev-env-setup repository or how is it called11:22
ghostmansd[m]b) it can encode sv. insns and some custom 32-bit insns (with few exceptions which were recently added)11:23
ghostmansd[m]c) yes11:23
ghostmansd[m]Let me dig the link...11:23
ghostmansd[m]markos, ^^^11:24
ghostmansd[m]Not that this binutils branch, svp64, is not the most recent code. I'm updating it, and I decided to move it into another branch.11:25
ghostmansd[m]But this is the most working code for now, until I implement support for macros.11:25
lkcli'm in the middle of a headless-chicken mode focus to convert the spec from markdown to PDF13:22
lkcloctavius ^13:22
octaviusthat's a lot....13:24
octaviusDo you want me to run it?13:24
lkclyes please, see if you can repro it13:25
octavius"repro", reproduce?13:25
lkcl164 pages.13:26
octaviusContents are empty13:26
octaviusthe links didn't convert properly "[[sv/propagation]]" etc.13:26
lkclcorrect, i know.13:27
lkclfilters will need to be written to deal with that13:27
octaviusAmazing that it worked at all. But I guess it makes sense13:27
lkcl(custom pandoc filters, that is)13:27
octaviusAh ok13:27
lkclpandoc's pretty awesome13:27
lkclin latex you have to compile twice13:28
lkclthe first time creates the contents file, the second time actually includes it13:28
octaviusI wonder how you'd do links within the doc's sections? Cause at the pandoc stage you don't have the section names yet?13:28
lkclbest that can be done is replace the page with a chapter name, i feel13:29
lkclalso an image filter sigh13:30
octaviusMost importantly, the code sections look good :)13:30
lkcloh frick, frickin svg images in latex, sigh13:31
octaviusOh yes, that'll be "fun" to do XD13:31
octaviusI guess we could add the inkscape shell conversion13:31
octaviusWait, if we have to use a Makefile anyway, maybe use a tool like ImageMagik?13:32
octaviusconvert to jpg13:32
octaviussave a bit of space13:32
lkclnot scalable13:33
octaviusWhat's not scalable?13:34
octaviusthe inkscape method?13:34
octaviusIf we moved *all* the images for sv into one folder, then create a "png_out" with the converted images13:35
lkcl<octavius> convert to jpg13:35
octaviusIs it quite slow?13:35
octaviusSurely you could do convert *.svg in a dir?13:36
octaviusDoing a quick test with "convert *.svg *.png" (this isn't quite right") took about 5-10 sec for 5 images13:39
octaviusJpg took about the same13:40
lkclit's not quite that simple: for every image so converted the latex source has to also be converted and it is autogenerate13:54
octaviusThe overview.tex file has this: "{[}{[}!img ``svp64-primer/img/power\_pipelines.svg'' {]}{]}"13:56
octaviusso a pandoc filter to convert this to a "begin{figure} block"?13:57
octaviusOr a step between pandoc and pdf, find and replace13:57
octaviusWhat's the priority for this? Just to get at least one version of the spec out?13:59
octaviusIf you want help I can manually convert images for the pdf13:59
octaviusJust realised that only the overview page has an image14:20
lkcli'm currently working out how to do filters14:33
lkclmanual conversion would be a bad idea because the converted images would need to be placed somewhere14:33
lkclngggh getting there14:35
octaviusThe long-term solution could be to have a single folder for svg's under the openpower dir (img), and have a converted img dir (img_out). However since we don't use many diagrams we probably don't need it.14:40
* octavius going afk14:54
lkclgaaah got it14:55
octaviusWhat did you get? The Pandoc filter?14:56
lkclbut i need to also modify the markdown files to the standard img format14:56
octaviusI played with an online regex tester for a phew min, got an expression which finds the markdown line with the img link14:56
octavius^{\[}{\[}!img ``[0-9a-zA-Z\-/_\.\\]+'' {\]}{\]}14:57
octaviusBut it needs to be converted to awk (or grep, or sed, etc.)14:57
lkcli can't handle regexs14:57
octaviusAh ok14:57
lkcli'm going to try actually replacing [[!image ...]] with {standard markdown}14:57
octaviusAh good, that should be easier to do at the pandoc stage as well14:58
* octavius now actually going afk14:59
lkclah ha!15:00
lkclholy cow it worked15:05
octaviusWhat have you fixed?15:28
octaviusOooh, just saw the commit, I'll try regenerating15:29
octaviusAh lkcl, you didn't commit the script15:30
lkcloctavius, yep i know, just done now15:43
octaviusAnother thing I noticed is the table headings aren't aligned with the entries (section4 SVP64)15:43
octaviusOh perfect, fixed now15:45
octaviusNeed to install the pandocfilters pip package15:45
octaviusLooking really good15:47
octaviusnow just the local links15:48
* lkcl head spinning15:48
lkcla couple of them work15:48
octaviusdo you have a bug for this spec?15:49
lkclno, needs one, can you create it?16:00
lkclthen can i leave it with you to look at the last commit and do the same for all the other chapter hyperlinks?16:01
lkcl        pandoc -f markdown -t latex --top-level-division=section \16:02
lkcl+               --filter \16:02
lkcl             -N -o tex_out/sv.tex sv.mdwn16:02
* lkcl head spinning need a break16:02
octaviuslkcl, implementation section hasn't been added, shall I add it?17:16
octaviuslkcl, what does this mean in markdown: "[[SV|sv]]"17:23
octaviusCan't convert this link properly (sv.mdwn is in the root dir, whereas most files are in ./sv/))17:24
programmerjakelkcl: pandoc is insufficient for restructuredtext tables last i checked since pandoc doesn't/didn't support tables where cells span multiple rows/columns17:56
programmerjakesame with html tables embedded in markdown17:56
programmerjakenote that a fast way to find incorrectly-converted stuff in the pdf is to search for `[[` or `[[!`18:37
programmerjakesince those are generally ikiwiki-specific directives -- not commonly supported markdown18:38
programmerjakealso, svgs shouldn't need to be converted to png to use them in latex, there is an `\includesvg` directive:
lkclyeah i just redid the entirety of opcode_regs_deduped.mdwn to not use the tables directive19:25
lkclpandoc isn't detecting a difference of extension to output \includesvg so i did the conversion explicitly19:26
lkcland there aren't any .rst files in the spec pages19:28
lkclso i think we're good19:28
lkcloctavius, it's expressing a wiki link with a different text to display19:29
octaviusAh ok19:33
octaviusSo how would you search for the main sv.mdwn page in "lookups" dict (pandoc_img), if other links also use sv (as a directory)19:35
lkcloctavius, like this;a=commitdiff;h=ebc1a463c3c7cf3a9d2b7ec68e859ccd5fdd136b19:44
lkclurr there's a comma in the text being searched for19:45
lkclk v f meta 'Str' '[[sv/mv.vec]],' 'latex' {}19:48
octaviusah that's why19:49
tplatenEven if I set dram_clk_freq to None for orangecrab, I get a Warning: Failed to find a route for arc 2 of net ddrphy_ddr3_0__a__o_fclk and an ERROR: Routing design failed. Still I am trying to understand why.20:02
lkcltplaten, try for a different target20:06
octaviuslkcl, why did add an extra lookup for sv?;a=commitdiff;h=ebc1a463c3c7cf3a9d2b7ec68e859ccd5fdd136b20:06
octavius*did you add20:07
tplatenI've tried for the versa_ecp5_85, which fails with a different error20:08
tplatensomething where maxfreq is about 49mhz20:08
tplatennextpnr ran about three hours before I got this error20:09
octaviusI noticed that in the overview page (section 2.1), the link to Scalable Vectors for Power ISA (sv) is broken20:09
tplatenfor orangecrab it takes about half an hour until I get an error20:09
lkcloctavius, wrong hyperlink ref, 1 sec20:16
octaviusthanks lkcl!21:01
octaviusThere are a bunch of other pages that aren't included in the report (propagation, discussion, implementation, byteswap etc.). Do you want those added?21:02
lkcloctavius: no, they're not part of the spec22:49

Generated by 2.17.1 by Marius Gedminas - find it at!