| lkcl | whewwww | 00:03 |
|---|---|---|
| lkcl | markos, ghostmansd[m] has been doing binutils-gas he's currently going through the macro system etc. | 00:03 |
| lkcl | we maay have to redefine identification of vectors to make it easier for binutils to recognise | 00:04 |
| * lkcl is worn out from 2 late-night back-to-back meetings | 00:04 | |
| lkcl | programmerjake, 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 already | 00:22 |
| lkcl | instructions exist to perform mvs between the halves | 00:23 |
| lkcl | and when SVP64-Vectorised, those transfer instructions will gain the full access to the full range of 128 FPR registers | 00:24 |
| programmerjake | imho 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 file | 00:25 |
| lkcl | yes 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 it | 00:25 |
| lkcl | but jacob | 00:25 |
| lkcl | please | 00:25 |
| lkcl | will you stop | 00:25 |
| lkcl | please stop | 00:25 |
| lkcl | distracting | 00:25 |
| lkcl | from what is designed | 00:25 |
| lkcl | it is | 00:25 |
| lkcl | not | 00:25 |
| lkcl | going | 00:26 |
| lkcl | to change | 00:26 |
| lkcl | from what has | 00:26 |
| lkcl | been designed | 00:26 |
| lkcl | it is | 00:26 |
| lkcl | too | 00:26 |
| lkcl | much | 00:26 |
| programmerjake | e.g. sv.fadd f10.v, f20.v, f30.v could use all 1280 bits of the f10-f19 vector | 00:26 |
| lkcl | jacob: please stop | 00:26 |
| lkcl | i don't want to discuss it | 00:26 |
| lkcl | i don't want the distraction | 00:26 |
| lkcl | i do not want to waste my time on it | 00:27 |
| lkcl | i do not want to have to go over years of work re-evaluating it | 00:27 |
| lkcl | so | 00:27 |
| lkcl | please | 00:27 |
| lkcl | will you | 00:27 |
| lkcl | please | 00:27 |
| lkcl | for god's sake | 00:27 |
| programmerjake | the 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 svp64 | 00:27 |
| lkcl | STOP | 00:27 |
| lkcl | please STOP | 00:27 |
| lkcl | i want to get through the ISA WG with what we have *already done* | 00:28 |
| lkcl | you are risking derailing the entire process of what has been done | 00:28 |
| lkcl | by throwing it into jeapordy and doubt | 00:28 |
| lkcl | because it will be perceived as "not ready" | 00:28 |
| lkcl | ok? | 00:28 |
| lkcl | please STOP | 00:28 |
| lkcl | whatever ideas you have for extending to 128 bit and to greater than 128 registers *please bury it* | 00:29 |
| lkcl | until AFTER we have got through the first ISA WG proposal | 00:29 |
| programmerjake | the 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 clashes | 00:29 |
| lkcl | if IBM wants to invest the time and money into it then they can do so | 00:29 |
| lkcl | but we are NOT in a position, time or funding wise, to do that work for them | 00:30 |
| lkcl | the answer is very blunt and very simple | 00:30 |
| programmerjake | all i want is a note in the setvl docs that how i described is how it can be done, no other thought necessary | 00:30 |
| lkcl | if you, other ISA WG members, want that idea considered, please put up the funding and the engineering teams necessary to do it | 00:30 |
| lkcl | it's TOO MUCH | 00:30 |
| lkcl | any note about extending should be marked "completely out of scope for this version of SVP64" | 00:31 |
| programmerjake | just like extending to >=256 registers | 00:31 |
| lkcl | i 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 consider | 00:32 |
| lkcl | we DO NOT HAVE TIME | 00:32 |
| lkcl | ok? | 00:32 |
| lkcl | please get this through your head that we are under time and budget pressure and HAVE to say NO | 00:32 |
| lkcl | ok? | 00:32 |
| lkcl | i know you have difficulty with this | 00:32 |
| lkcl | but please | 00:33 |
| lkcl | for god's sake | 00:33 |
| lkcl | please listen | 00:33 |
| lkcl | it doesn't matter if it's "better" | 00:33 |
| lkcl | what matters is that we don't get screwed over by people expecting *us* to do their design work | 00:33 |
| programmerjake | yeah, 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 well | 00:33 |
| lkcl | if 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 it | 00:34 |
| lkcl | jacob | 00:34 |
| lkcl | i don't | 00:34 |
| lkcl | have | 00:34 |
| lkcl | time | 00:34 |
| lkcl | to go over it | 00:34 |
| lkcl | *i* don't have time to go through the full implications, ok? | 00:34 |
| lkcl | i have told you this multiple times | 00:34 |
| lkcl | i am barely keeping the entire design - the entire document - in my head, as it is | 00:35 |
| lkcl | i stopped for only 2 months to do ls2 and it was a serious mistake | 00:35 |
| lkcl | i CANNOT COPE with the additional task of assessing what you are proposing | 00:35 |
| programmerjake | then don't...you can trust me to have considered the implications enough to think it'll likely work... | 00:35 |
| lkcl | because i know it will take me WEEKS TO MONTHS to go over it | 00:35 |
| lkcl | i will be the one proposing it | 00:36 |
| programmerjake | you c | 00:36 |
| lkcl | and advocating it to the ISA WG | 00:36 |
| lkcl | (through RED Semiconductor) | 00:36 |
| programmerjake | you *can* propose something that has other people's opinion/thoughts... | 00:36 |
| lkcl | and if i don't fully understand it then it will jeapordise confidence in the entire effort | 00:36 |
| lkcl | so NO | 00:37 |
| programmerjake | so make it a team effort... | 00:37 |
| lkcl | please get it through your head, the answer is NO | 00:37 |
| programmerjake | so, 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 him | 00:38 |
| lkcl | no, i'm not. | 00:39 |
| 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:39 |
| lkcl | absolutely NO discussion of potential ideas, no options, nothing | 00:39 |
| markos | apologies 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 |
| lkcl | basically yes, but UNDER NO CIRCUMSTANCES should there be, in the spec, one SINGLE mention of any of what those potential ideas are | 00:40 |
| lkcl | PRIVATELY they can be discussed | 00:40 |
| lkcl | (on the bugtracker) | 00:40 |
| markos | plus it's easier to push for an update once you get your foot inside the door if I'm using the phrase correctly | 00:40 |
| lkcl | but in the spec? absolutely not | 00:40 |
| programmerjake | how about "there are some proposals for how 128-bit registers can interoperate with svp64, they are out of scope for this version" | 00:41 |
| lkcl | we cannot put a specification to the ISA WG "err we had maybe some ideas" | 00:41 |
| lkcl | no | 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 |
| programmerjake | why not, iirc the risc-v spec has some notes to that effect | 00:42 |
| markos | lkcl, what if they ask for a roadmap for next revisions? | 00:42 |
| lkcl | with "there are reserved bits for extending capabilities" | 00:42 |
| markos | which they probably will tbh | 00:42 |
| * lkcl thinking | 00:42 | |
| lkcl | you need a stakeholder to drive whatever it is | 00:43 |
| markos | it wouldn't be an actual commitment to do anything | 00:43 |
| lkcl | the 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 cross | 00:44 |
| lkcl | my problem with these 128-bit and >128 registers is, i know how much f*****g work it is in hardware | 00:44 |
| programmerjake | then *don't implement them* in libre-soc's core... | 00:45 |
| markos | I 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 others | 00:45 |
| lkcl | and even just *considering* to extend to 128-bit and/or >128 registers, you *have* to actually do a full work-through | 00:45 |
| lkcl | in order to be able to fully ensure that you don't end up creating an ISA that is fundamentally unimplementable | 00:45 |
| markos | they have to see that their choice is sound and future-proof for many revisions, not just the next | 00:46 |
| programmerjake | no 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 all | 00:46 |
| lkcl | programmerjake, 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 ISA | 00:46 |
| programmerjake | ^ in reply to lkcl | 00:46 |
| lkcl | in RISC-V, absolutely nobody has actually done a 128-bit or greater implementation | 00:47 |
| lkcl | thus the entire issue can be deferred | 00:47 |
| programmerjake | i did a bit of design walkthrough in my head... | 00:47 |
| lkcl | programmerjake, exactly | 00:47 |
| lkcl | that was my biggest concern, that you would do that, and not spend the time on things that keep NLnet happy with us | 00:48 |
| programmerjake | 128-bit registers does *not* mean 128-bit addresses or that openpower's scalar instructions default to 128-bit, it's still a 64-bit isa | 00:48 |
| lkcl | folks, i'm done. | 00:48 |
| lkcl | this has been almost an hour wasted of my time which i SPECIFICALLY did not wish to get into | 00:48 |
| markos | in my POV, you both are right, but I think you are disagreeing too early for what is essentially a non-issue | 00:48 |
| lkcl | because i know how much time is involved | 00:48 |
| lkcl | i DO NOT WANT MY TIME WASTED DISCUSSING THIS | 00:49 |
| lkcl | i am really angry jacob that you keep doing this | 00:49 |
| lkcl | you keep pushing | 00:49 |
| lkcl | and pushing | 00:49 |
| lkcl | and pushing | 00:49 |
| lkcl | and pushing | 00:49 |
| markos | I think you should defer this discussion for a later date | 00:49 |
| lkcl | i don't want to discuss it AT ALL | 00:49 |
| lkcl | i don't want to have discussions about whether it should or should not be discussed | 00:49 |
| lkcl | i do noit | 00:49 |
| lkcl | want | 00:49 |
| lkcl | 128 bit | 00:49 |
| lkcl | in | 00:49 |
| lkcl | any discussions | 00:49 |
| lkcl | AT ALL | 00:49 |
| programmerjake | yeah, ttyl, i have to go pick our cherry tree (fun...kinda) | 00:50 |
| lkcl | until we have FINISHED the NLnet grants | 00:50 |
| lkcl | and got proposals in to the ISA WG of what is already done | 00:50 |
| lkcl | i can't cope | 00:50 |
| lkcl | ok? | 00:50 |
| lkcl | so please | 00:50 |
| lkcl | no more | 00:50 |
| programmerjake | how 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 |
| programmerjake | the ones that expire in oct | 00:51 |
| markos | how about we go for prime-number vector sizes, eg 127? :D | 00:52 |
| markos | /jk | 00:52 |
| markos | it's really late here, ttyt, I'd love to start playing with the new binutils on svp64 soon, so I'll ask for help tomorrow | 00:53 |
| programmerjake | ooh, 2^127-1 bits :) need a planet-worth of ram chips | 00:53 |
| programmerjake | https://en.wikipedia.org/wiki/Mersenne_prime#List_of_known_Mersenne_primes | 00:54 |
| 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 try | 09:16 |
| ghostmansd[m] | Today I can only help with the stuff I recall and can type via mobile | 09:16 |
| markos | ghostmansd[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 |
| markos | I guess for c) it's still the python simulator | 11:21 |
| ghostmansd[m] | a) there's a script in dev-env-setup repository or how is it called | 11: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) yes | 11:23 |
| ghostmansd[m] | Let me dig the link... | 11:23 |
| ghostmansd[m] | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=binutils-gdb-install;h=1e2ebe71cb31a413be7c90d5dbd875c31804e582;hb=HEAD | 11:24 |
| ghostmansd[m] | markos, ^^^ | 11:24 |
| markos | thanks | 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 |
| lkcl | i'm in the middle of a headless-chicken mode focus to convert the spec from markdown to PDF | 13:22 |
| lkcl | https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/Makefile;hb=HEAD | 13:22 |
| lkcl | octavius ^ | 13:22 |
| octavius | that's a lot.... | 13:24 |
| octavius | Do you want me to run it? | 13:24 |
| lkcl | yes please, see if you can repro it | 13:25 |
| octavius | "repro", reproduce? | 13:25 |
| lkcl | yes | 13:26 |
| lkcl | 164 pages. | 13:26 |
| lkcl | dang | 13:26 |
| octavius | Contents are empty | 13:26 |
| octavius | the links didn't convert properly "[[sv/propagation]]" etc. | 13:26 |
| lkcl | correct, i know. | 13:27 |
| lkcl | filters will need to be written to deal with that | 13:27 |
| octavius | Amazing that it worked at all. But I guess it makes sense | 13:27 |
| lkcl | (custom pandoc filters, that is) | 13:27 |
| octavius | Ah ok | 13:27 |
| lkcl | pandoc's pretty awesome | 13:27 |
| lkcl | in latex you have to compile twice | 13:28 |
| lkcl | the first time creates the contents file, the second time actually includes it | 13:28 |
| octavius | I 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 |
| lkcl | best that can be done is replace the page with a chapter name, i feel | 13:29 |
| lkcl | also an image filter sigh | 13:30 |
| octavius | Most importantly, the code sections look good :) | 13:30 |
| lkcl | yeah | 13:30 |
| lkcl | oh frick, frickin svg images in latex, sigh | 13:31 |
| octavius | Oh yes, that'll be "fun" to do XD | 13:31 |
| octavius | I guess we could add the inkscape shell conversion | 13:31 |
| lkcl | yehyeh | 13:32 |
| octavius | Wait, if we have to use a Makefile anyway, maybe use a tool like ImageMagik? | 13:32 |
| octavius | convert to jpg | 13:32 |
| octavius | save a bit of space | 13:32 |
| lkcl | https://tex.stackexchange.com/questions/233511/inkscape-and-shell-escape-with-texstudio | 13:33 |
| lkcl | not scalable | 13:33 |
| octavius | What's not scalable? | 13:34 |
| octavius | the inkscape method? | 13:34 |
| octavius | If we moved *all* the images for sv into one folder, then create a "png_out" with the converted images | 13:35 |
| lkcl | <octavius> convert to jpg | 13:35 |
| octavius | Is it quite slow? | 13:35 |
| octavius | Surely you could do convert *.svg in a dir? | 13:36 |
| octavius | Doing a quick test with "convert *.svg *.png" (this isn't quite right") took about 5-10 sec for 5 images | 13:39 |
| octavius | Jpg took about the same | 13:40 |
| lkcl | it's not quite that simple: for every image so converted the latex source has to also be converted and it is autogenerate | 13:54 |
| octavius | The overview.tex file has this: "{[}{[}!img ``svp64-primer/img/power\_pipelines.svg'' {]}{]}" | 13:56 |
| octavius | so a pandoc filter to convert this to a "begin{figure} block"? | 13:57 |
| octavius | Or a step between pandoc and pdf, find and replace | 13:57 |
| octavius | What's the priority for this? Just to get at least one version of the spec out? | 13:59 |
| octavius | If you want help I can manually convert images for the pdf | 13:59 |
| octavius | Just realised that only the overview page has an image | 14:20 |
| lkcl | i'm currently working out how to do filters | 14:33 |
| lkcl | manual conversion would be a bad idea because the converted images would need to be placed somewhere | 14:33 |
| lkcl | ngggh getting there | 14:35 |
| octavius | The 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 afk | 14:54 | |
| lkcl | gaaah got it | 14:55 |
| octavius | What did you get? The Pandoc filter? | 14:56 |
| lkcl | but i need to also modify the markdown files to the standard img format | 14:56 |
| lkcl | yes | 14:56 |
| octavius | I played with an online regex tester for a phew min, got an expression which finds the markdown line with the img link | 14:56 |
| octavius | ^{\[}{\[}!img ``[0-9a-zA-Z\-/_\.\\]+'' {\]}{\]} | 14:57 |
| octavius | But it needs to be converted to awk (or grep, or sed, etc.) | 14:57 |
| lkcl | i can't handle regexs | 14:57 |
| octavius | Ah ok | 14:57 |
| lkcl | i'm going to try actually replacing [[!image ...]] with {standard markdown} | 14:57 |
| octavius | Ah good, that should be easier to do at the pandoc stage as well | 14:58 |
| * octavius now actually going afk | 14:59 | |
| lkcl | ah ha! | 15:00 |
| lkcl | holy cow it worked | 15:05 |
| octavius | What have you fixed? | 15:28 |
| octavius | Oooh, just saw the commit, I'll try regenerating | 15:29 |
| octavius | Ah lkcl, you didn't commit the pandoc_img.py script | 15:30 |
| lkcl | octavius, yep i know, just done now | 15:43 |
| octavius | Another thing I noticed is the table headings aren't aligned with the entries (section4 SVP64) | 15:43 |
| octavius | Oh perfect, fixed now | 15:45 |
| octavius | Need to install the pandocfilters pip package | 15:45 |
| octavius | *needed | 15:45 |
| octavius | Looking really good | 15:47 |
| octavius | now just the local links | 15:48 |
| * lkcl head spinning | 15:48 | |
| lkcl | a couple of them work | 15:48 |
| octavius | do you have a bug for this spec? | 15:49 |
| lkcl | no, needs one, can you create it? | 16:00 |
| octavius | Sure, | 16:01 |
| lkcl | then can i leave it with you to look at the last commit and do the same for all the other chapter hyperlinks? | 16:01 |
| octavius | yeah | 16:02 |
| lkcl | https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=7f0039f151798b41fe5e542f407ca08bd5c246b5 | 16:02 |
| lkcl | https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=a1dc08964d8a817f45752467f1d5bf6d1252ef92 | 16:02 |
| lkcl | pandoc -f markdown -t latex --top-level-division=section \ | 16:02 |
| lkcl | + --filter pandoc_img.py \ | 16:02 |
| lkcl | -N -o tex_out/sv.tex sv.mdwn | 16:02 |
| * lkcl head spinning need a break | 16:02 | |
| octavius | lkcl, implementation section hasn't been added, shall I add it? | 17:16 |
| octavius | lkcl, what does this mean in markdown: "[[SV|sv]]" | 17:23 |
| octavius | Can't convert this link properly (sv.mdwn is in the root dir, whereas most files are in ./sv/)) | 17:24 |
| programmerjake | lkcl: pandoc is insufficient for restructuredtext tables last i checked since pandoc doesn't/didn't support tables where cells span multiple rows/columns | 17:56 |
| programmerjake | same with html tables embedded in markdown | 17:56 |
| programmerjake | https://github.com/jgm/pandoc/issues/6991 | 18:02 |
| programmerjake | note that a fast way to find incorrectly-converted stuff in the pdf is to search for `[[` or `[[!` | 18:37 |
| programmerjake | since those are generally ikiwiki-specific directives -- not commonly supported markdown | 18:38 |
| programmerjake | also, svgs shouldn't need to be converted to png to use them in latex, there is an `\includesvg` directive: https://tex.stackexchange.com/questions/2099/how-to-include-svg-diagrams-in-latex/74693#74693 | 18:43 |
| lkcl | yeah i just redid the entirety of opcode_regs_deduped.mdwn to not use the tables directive | 19:25 |
| lkcl | pandoc isn't detecting a difference of extension to output \includesvg so i did the conversion explicitly | 19:26 |
| lkcl | and there aren't any .rst files in the spec pages | 19:28 |
| lkcl | so i think we're good | 19:28 |
| lkcl | octavius, it's expressing a wiki link with a different text to display | 19:29 |
| octavius | Ah ok | 19:33 |
| octavius | So 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 |
| octavius | https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/pandoc_img.py#l57 | 19:35 |
| lkcl | octavius, like this https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=ebc1a463c3c7cf3a9d2b7ec68e859ccd5fdd136b | 19:44 |
| lkcl | urr there's a comma in the text being searched for | 19:45 |
| lkcl | [[xxxxx], | 19:45 |
| lkcl | yuk | 19:45 |
| octavius | :O | 19:45 |
| lkcl | k v f meta 'Str' '[[sv/mv.vec]],' 'latex' {} | 19:48 |
| lkcl | blech | 19:48 |
| octavius | ah that's why | 19:49 |
| lkcl | sorted | 19:54 |
| tplaten | Even 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 |
| lkcl | tplaten, try for a different target | 20:06 |
| octavius | lkcl, why did add an extra lookup for sv? https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=ebc1a463c3c7cf3a9d2b7ec68e859ccd5fdd136b | 20:06 |
| octavius | *did you add | 20:07 |
| tplaten | I've tried for the versa_ecp5_85, which fails with a different error | 20:08 |
| tplaten | something where maxfreq is about 49mhz | 20:08 |
| tplaten | nextpnr ran about three hours before I got this error | 20:09 |
| octavius | I noticed that in the overview page (section 2.1), the link to Scalable Vectors for Power ISA (sv) is broken | 20:09 |
| tplaten | for orangecrab it takes about half an hour until I get an error | 20:09 |
| lkcl | octavius, wrong hyperlink ref, 1 sec | 20:16 |
| octavius | thanks lkcl! | 21:01 |
| octavius | There 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 |
| lkcl | octavius: no, they're not part of the spec | 22:49 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!