| lkcl | woo! NLnet's grant application to the EU looks like it got accepted https://nlnet.nl/entrust/ - EUR 9.6 million | 09:14 |
|---|---|---|
| programmerjake | ooh, maybe we should submit a proposal for https://bugs.libre-soc.org/show_bug.cgi?id=209 | 09:33 |
| programmerjake | since the other grant with that didn't get approved | 09:34 |
| ghostmansd[m] | I'm totally sure llvm's worth the shot. | 10:58 |
| ghostmansd[m] | Perhaps other OS bring up is too, but that one might take a lot of time. | 10:59 |
| ghostmansd[m] | I'm thinking of FreeBSD in particular. They also happen to use llvm. | 11:00 |
| ghostmansd[m] | And, as far as FreeBSD is concerned, Netflix uses it, so various codecs-related extensions might be beneficial. | 11:01 |
| programmerjake | iirc we were trying to get those into ffmpeg, kernel-level stuff shouldn't be needed (other than context-switching new registers) | 11:03 |
| lkcl | octavius, moornin. saw your messages but you dropped off before i could reply | 11:03 |
| programmerjake | and other user-space codec libraries | 11:03 |
| octavius | hello chaps | 11:03 |
| lkcl | octavius, i've put you down for EUR 4,000 for this one https://bugs.libre-soc.org/show_bug.cgi?id=739 | 11:04 |
| octavius | Yes, I did see that one | 11:04 |
| lkcl | that's a *contract* not a grant, so if you accept it, it absolutely has to be done on time | 11:04 |
| octavius | What's the time scale? | 11:05 |
| lkcl | september-ish | 11:05 |
| lkcl | and it really should not take long. | 11:05 |
| programmerjake | gn all, have fun! | 11:05 |
| octavius | Yeah, but how long will it take to understand that scary pinmux code? XD | 11:06 |
| octavius | gn programmerjake | 11:06 |
| lkcl | octavius, it's a cut/paste job. | 11:06 |
| lkcl | you don't have to "understand" it | 11:06 |
| lkcl | how much effort do you think it's going to take to literally cut/paste this file | 11:07 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/ls180.py;hb=HEAD | 11:07 |
| lkcl | and alter nothing but lines 61 to 114? | 11:07 |
| octavius | Oh, this is using the existing system? Last I time I played with it (Nov-ish) I thought something was broken | 11:08 |
| lkcl | in fact, if you simply use the existing ls180.py and add one single line, for rgmii (gigabit ethernet) on the NORTH side then strictly speaking it's done | 11:09 |
| lkcl | that's my responsibility to fix, not yours. | 11:09 |
| lkcl | i understand that code (or, having written it, can at least cope with re-learning to navigate it) | 11:10 |
| octavius | Ok, I'll have a look at it now | 11:11 |
| lkcl | if you want something quick then if you can do two SVG drawings for this then we can close it and put in the RFPs | 11:11 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=858 | 11:11 |
| octavius | Convert the diagrams to svg? | 11:13 |
| lkcl | yes | 11:13 |
| octavius | ok, will do | 11:13 |
| octavius | Also Paul has not replied yet | 11:14 |
| lkcl | https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=svp64-primer/img/svp64_regs.jpg;hb=HEAD | 11:14 |
| lkcl | yes i know. toshaan's got a brief opportunity to speak with him | 11:14 |
| lkcl | https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=svp64-primer/img/power_pipelines.jpg;hb=HEAD | 11:15 |
| octavius | ok good, let's hope he get's back to us | 11:15 |
| lkcl | i've upped the budget accordingly, it's easy work | 11:16 |
| lkcl | and also helps you understand the vector-register arrangement | 11:16 |
| octavius | Thanks luke :) | 11:17 |
| octavius | lkcl, give the reg svg a gander: https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=svp64-primer/img/svp64_regs.svg;h=8a6c283b5e1798fdc22c8487fbbb7510706a0cee;hb=dc33c33dc205e6a54039c8480982cb857cac95fb | 12:52 |
| octavius | Will update the bug once I get the others done. Also needed to generate a png for the latex doc (adding svg requires inkscape cmd conversion with ConTeXt, probably not worth the complexity | 12:53 |
| lkcl | octavius, cool! | 12:53 |
| lkcl | that looks really good | 12:54 |
| lkcl | does it make sense? | 12:54 |
| octavius | The diagram? Yeah | 12:55 |
| octavius | I wasn't quite sure of the coloured boxes, but I figured they were the elements | 12:55 |
| lkcl | yes | 12:58 |
| lkcl | predication simply enables the required byte-enable-write-lines and err that's all there is to predication | 12:59 |
| octavius | Oh yeah, that makes sense. I meant the actual drawing itself XD | 13:04 |
| octavius | Just overcomplicated it in my head, that's all | 13:04 |
| lkcl | the next priority one is probably that 1st one, with the loop (extra pipeline stage) | 13:05 |
| octavius | yeah, doing it now | 13:06 |
| lkcl | that's annoying, svg importing needs --shell-escape | 13:14 |
| octavius | yeah | 13:15 |
| ghostmansd[m] | Hell Luke, you've written to Stallman himself! :-) | 13:32 |
| ghostmansd[m] | You don't beat around the bush, do you?... | 13:32 |
| ghostmansd | Perhaps we might include Alan as well... | 13:36 |
| octavius | lkcl, added powerlines: https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=svp64-primer/img/power_pipelines.png;h=98afc6b8b06c6a1958cc7e2adfe182afb153d8b2;hb=ca47450704a3ae2137194a6ea8cdcac02bb23f69 | 13:54 |
| octavius | Shall I update the Cray vector and SIMD diagrams? | 13:54 |
| ghostmansd | https://pastebin.com/YqV5w3vC | 14:15 |
| ghostmansd | Fuck I'm both impressed and horrified :-D | 14:15 |
| ghostmansd | de_fault | 14:15 |
| octavius | Ah, goto's... | 14:15 |
| octavius | oh | 14:15 |
| octavius | lkcl, I just started writing a bug comment XD | 14:57 |
| octavius | Oh, didn't realise your comment was a few hours ago | 14:58 |
| octavius | Deleted the jpg's lkcl, can I set as Resolved Fixed? (I seem to remember it cause the bug to disappear for you?) | 15:32 |
| octavius | I'll be back, gotta grab some food | 15:36 |
| ghostmansd | Luke, they've finally sent the copyright assignment form! | 16:06 |
| ghostmansd | Folks, I'm wondering whether we can change the naming convention for registers. | 19:09 |
| ghostmansd | As of now, I suspect these flavors are possible: %r32.s and 32.s. pysvp64asm, IIRC, only handles the latter. | 19:10 |
| ghostmansd | But for binutils %d.s is a complete disaster. Whenever binutils meets something starting with digit, it tries to parse the whole string as an integer. | 19:11 |
| octavius | unless there's an issue elsewhere, the r# notation (r0, r1, etc.) sounds reasonable | 19:13 |
| ghostmansd | I suggest that we either always start registers with "%r", or, alternatively, change the convention so that the type of the register goes before the number: "S32" and "V32", or, even better, %s32 and %v32. | 19:13 |
| ghostmansd | It seems that lower-case v and r are already occupied... https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l320 | 19:15 |
| ghostmansd | At the same time, please, take a look at the table there and think of possible names we could use. | 19:15 |
| ghostmansd | Alternative way is to parse register names _before_ binutils arrives to expression parsing. | 19:16 |
| ghostmansd | But, frankly, I'd like to re-use the existing stuff as much as possible, and simply tune the internal register tables in some way (perhaps having yet another table which is checked right after the one I posted). | 19:17 |
| ghostmansd | lkcl programmerjake ^^^ | 19:18 |
| ghostmansd | I'd think about %S and %V (note the upper case). | 19:18 |
| programmerjake | vr10 instead of 10.v? | 19:19 |
| programmerjake | since lowercase v is already taken | 19:20 |
| programmerjake | imho reusing lowercase r for scalar registers should be fine | 19:20 |
| programmerjake | for f10.v, use vf10? | 19:20 |
| programmerjake | ghostmansd, lkcl, what do you think of ^ idea? | 19:21 |
| programmerjake | another idea is to copy what risc-v does and change sv.add/elwid=16 10.v, 20.s, 30.v to sv.add.vsv/elwid=16 10, 20, 30 or sv.add/elwid=16/vsv 10, 20, 30 | 19:24 |
| ghostmansd | vr10 looks fine to me | 19:27 |
| ghostmansd | Parsing registers on a per-operand-basis is much better and simpler, to be honest. | 19:28 |
| programmerjake | there'd also be vcr10 instead of cr10.v | 19:29 |
| ghostmansd | I'd suggested vs10, not vr10, but this is also occupied... | 19:30 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l720 | 19:30 |
| ghostmansd | Couldn't we re-use the original names, but prefix these with v or V? | 19:30 |
| ghostmansd | I mean, keep simple %r10 and know that this is scalar... | 19:30 |
| ghostmansd | ...and, for vector, have %rv10 or something akin, | 19:31 |
| programmerjake | basically, i'm suggesting s/\(.*\)\.v/v\1/g and s/\(.*\)\.s/\1/g | 19:32 |
| ghostmansd | This is barely readable :-) | 19:32 |
| ghostmansd | Drop it before Luke sees it :-D | 19:32 |
| lkcl | ghostmansd, nope, i don't :) yes i've known Dr Stallman and been writing on-and-off to him since... err.. 2006? | 19:32 |
| ghostmansd | He hates regex, right lkcl? :-) | 19:32 |
| programmerjake | translation to english: reg.v -> vreg and reg.s -> reg | 19:33 |
| lkcl | i love gotos, i am literally unable to read regex's | 19:33 |
| programmerjake | (sorta english) | 19:33 |
| programmerjake | for regs named v/r/cr<number> | 19:33 |
| programmerjake | f/r/cr<number> i meant | 19:34 |
| programmerjake | so f123.v -> vf123 | 19:34 |
| ghostmansd | and cr1.v -> vcr1? | 19:35 |
| lkcl | .vsv separates things from the actual registers, which means visually, for people like me with weird-form-dyslexia, it's very difficult to associate 1st v with 10, 2nd s with 20 3rd v with 30 | 19:35 |
| programmerjake | ghostmansd: yes | 19:35 |
| ghostmansd | programmerjake, and what for scalars? they simply don't get any prefix at all, right? | 19:36 |
| ghostmansd | e.g. f123.s => f123? | 19:36 |
| programmerjake | yup | 19:36 |
| lkcl | octavius, yes do set as flxed, i'm tracking bugreports with budget-sync now | 19:36 |
| ghostmansd | hm, seems reasonable | 19:36 |
| ghostmansd | can we have vector of altivec vectors? :-D | 19:36 |
| ghostmansd | and Vector Scalar? | 19:37 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l587 | 19:37 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l654 | 19:37 |
| lkcl | ghostmansd, yes!! | 19:37 |
| ghostmansd | I'm kidding, but, I'm worrying about these are kinda mixed | 19:37 |
| ghostmansd | lkcl, yes what? :-) | 19:37 |
| lkcl | because altivec vector registers are actually not vectors at all | 19:37 |
| ghostmansd | ah OK :-) | 19:37 |
| ghostmansd | I thought these are vectors already | 19:38 |
| lkcl | they're "registers whose length is 128-bit and which can be used for SIMD-within-a-register purposes" | 19:38 |
| ghostmansd | OK let's choose some convention. Again, alternatively I can hack binutils internals, sure. But this makes some non-trivial stuff... | 19:38 |
| ghostmansd | e.g. what COCOJUMBO.v means? | 19:39 |
| ghostmansd | Should I look up the macro? | 19:39 |
| ghostmansd | And how's it different from 1.v? | 19:39 |
| lkcl | welcome to a marketing misrepresentation f*****-up that is peretrated by a *lot* of industry giants | 19:39 |
| programmerjake | they are also used for "this instruction operates on a 128-bit scalar" stuff | 19:39 |
| lkcl | yes COCOJUMBO would be a macro lookup | 19:39 |
| ghostmansd | And so on, all these must be handled manually. | 19:39 |
| ghostmansd | Yeah that I get :-) | 19:39 |
| ghostmansd | But it would basically mean "whenever you see an unknown name, treat it as a register" | 19:40 |
| ghostmansd | This would also imply calling expression() inside expression(). | 19:40 |
| lkcl | nniiiice | 19:40 |
| programmerjake | other idea: f10.v -> v.f10 and f10.s -> s.f10 | 19:40 |
| ghostmansd | binutils call the main parsing stuff expression() | 19:40 |
| ghostmansd | And allow to hook it so that, when it sees an unknown crap, it calls some user-defined routine. | 19:41 |
| ghostmansd | But, all in all, I'd rather prefer seeing an alternative register calling convention. | 19:41 |
| ghostmansd | Let me find the problem code so that you understand the problem... | 19:41 |
| programmerjake | v.10 avoids the parse-as-integer problem that 10.v has... | 19:42 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/expr.c;h=6ad8bee2733cc44aa8cb4f6d72b70292392a42c9;hb=HEAD#l794 | 19:43 |
| ghostmansd | Here's the actual issue I hit. | 19:43 |
| ghostmansd | You see, when this code sees some digit... | 19:43 |
| ghostmansd | It calls integer_constant(). | 19:44 |
| ghostmansd | I suspect this is also the reason why they tend to call registers like ymm0, not 0.ymm :-) | 19:44 |
| ghostmansd | I can hack the things so that this code is never reached... | 19:44 |
| ghostmansd | ...that is, that we produce our own ExpressionS... | 19:45 |
| ghostmansd | ...but I'd rather avoid doing such crappy things. If I were to maintain binutils, I'd forbid such tricks, to be honest. | 19:45 |
| ghostmansd | Because it won't follow the conventions everybody else uses. | 19:45 |
| lkcl | i don't have a problem with adding "#ifdef PPC64 && LIBRESOC" look for follow-up | 19:48 |
| lkcl | or | 19:48 |
| lkcl | just don't let people use "NN.v" | 19:48 |
| lkcl | tell them it has to be "r0.v" and "r128.v" | 19:48 |
| lkcl | the issue with changing things is, there's 780+ instances of "NN.v" in the openpower-isa unit tests alone | 19:49 |
| programmerjake | forcing people to use r23.v rather than 23.v sounds like a good and easy solution imho | 19:49 |
| programmerjake | lkcl, regex replace it! | 19:50 |
| programmerjake | i can do that if you like... | 19:50 |
| lkcl | the ".v" is different enough from the standard power isa reg names that there's unlikely to be a conflict | 19:50 |
| lkcl | which was why i picked it | 19:50 |
| ghostmansd[m] | This still keeps the issue of separating with dot... | 19:50 |
| lkcl | coming up with new names is non-uniform (non-RISC) | 19:51 |
| lkcl | it would require the addition of a table (lots of tables) in tc-ppc.c | 19:51 |
| ghostmansd[m] | I mean, we'll have to differentiate cocojumbo128.v and r128.v. | 19:51 |
| ghostmansd[m] | And understanding that cocojumbo128 is a macro and it must be expanded... | 19:52 |
| programmerjake | imho just don't support macros in reg names | 19:52 |
| programmerjake | https://git.libre-soc.org/?p=openpower-isa.git&a=search&h=HEAD&st=grep&s=%5Cb%5B0-9%5D%2B%5C.%5Bsv%5D%5Cb&sr=1 | 19:52 |
| programmerjake | pretty short list imho ^ | 19:52 |
| ghostmansd[m] | Nope, we already have these | 19:52 |
| lkcl | programmerjake, they're important | 19:53 |
| ghostmansd[m] | In mp3 audio | 19:53 |
| programmerjake | make 2 macros: my_reg_v and my_reg_s | 19:53 |
| ghostmansd[m] | We have stuff like ".set cocojumbo, 0" and then "sv.add. cocojumbo.v, ..." | 19:53 |
| lkcl | which was the very first "real-world" piece of svp64 assembler written (by lauri) | 19:54 |
| lkcl | and the very first thing he did was use ".set win 32" | 19:54 |
| lkcl | then asked me why pysvp64asm didn't support it | 19:54 |
| programmerjake | oh, wait: cheat: make the define macro function define macro and macro.v macro.s too | 19:54 |
| lkcl | hmmmm :) | 19:55 |
| ghostmansd | I can, in case of an unknown stuff, check whether it ends with .s/.v, and then handle it differently. But this would lead to more changes we want. | 19:56 |
| ghostmansd | The canonical way for binutils is to have unique register names, and define macros to these. | 19:57 |
| ghostmansd | That is, if one wants to make a macro to vector register 53, this would be `.set cocojumbo %v53` | 19:57 |
| programmerjake | so, like i suggested: vr10, vf10, and vcr10 | 19:58 |
| ghostmansd | Yes, exactly. | 19:58 |
| ghostmansd | I mean, pysvp64 allows such tricks, but it just performs a text substitution. And binutils do way more, they treat this as an expression, and even simplify these expressions. | 19:58 |
| ghostmansd | And so we have choice to either follow common patterns, or hack stuff around. | 19:59 |
| ghostmansd | I'd prefer the former, like vr10, vf10, etc. | 19:59 |
| programmerjake | and you'll just have to give up having 1 macro for my_reg.s and my_reg.v...you'll need my_reg_s = r10 and my_reg_v = vr10 | 19:59 |
| lkcl | ghostmansd, i'm looking towards the end of expr.c operand() function | 20:04 |
| lkcl | and it calls md_parse_name() | 20:05 |
| lkcl | which is #defined to... | 20:05 |
| lkcl | ppc_parse_name | 20:05 |
| ghostmansd | Yeah | 20:05 |
| ghostmansd | That's the place I mentioned | 20:05 |
| ghostmansd | To be hacked | 20:05 |
| ghostmansd | (if we choose this way) | 20:06 |
| lkcl | have you tried simply modifying that to search (and exclude) ".v" and ".s" if found? | 20:06 |
| ghostmansd | Yes | 20:06 |
| lkcl | what happened? | 20:06 |
| ghostmansd | And it works | 20:06 |
| lkcl | on r0.v and fp0.v? | 20:06 |
| ghostmansd | Well, with some global context, I even can keep track of whether it's scalar or vector | 20:06 |
| ghostmansd | lkcl, I just checked some nonsensial name like cocojumbo.v | 20:07 |
| ghostmansd | Which was .set before | 20:07 |
| ghostmansd | Not the actual registers | 20:07 |
| lkcl | with a ... ah i was going to ask, with a .set | 20:07 |
| ghostmansd | Yep | 20:07 |
| lkcl | and it worked? | 20:07 |
| ghostmansd | Yes, since... | 20:07 |
| ghostmansd | let me find it... | 20:07 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l3424 | 20:08 |
| ghostmansd | so, here we call expression()... | 20:08 |
| ghostmansd | it finds an unknown name... | 20:08 |
| ghostmansd | and gets to ppc_parse_name... | 20:09 |
| ghostmansd | I don't recall, though, whether we get to cocojumbo being actually expanded. | 20:09 |
| ghostmansd | Or whether we end up with some unknown relocation against cocojumbo. | 20:10 |
| ghostmansd | But, even if it doesn't work, we can do expression() inside ppc_parse_name(), after we trim .v and .s. | 20:11 |
| lkcl | i wouldn't recommend using global state then | 20:14 |
| lkcl | but add an extra field to expressionS | 20:14 |
| * lkcl just doing a new clone and compile of binutils-gdb | 20:15 | |
| lkcl | octavius, if paul comes back to us with some modifications needed then there's an additional EUR 1,000 left | 20:15 |
| octavius | Nice | 20:16 |
| ghostmansd[m] | I'd rather switch to register names which act like all other register names around, because this way there's no need to hack anything at all. | 20:17 |
| lkcl | it's too much | 20:17 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l915 | 20:17 |
| lkcl | and in future, when there's an initiative to put SVP64 on top of VSX, the entirety of the VSX regfile also needs duplicating | 20:18 |
| ghostmansd | OK I got it, I'll tune the code then. | 20:18 |
| lkcl | so literally every single register name ends up duplicated. | 20:18 |
| ghostmansd | Well, it's depends on how you look at this. Isn't this with suffix is duplication too? | 20:19 |
| ghostmansd | I mean, for me both prefix and suffix are kinda similar. | 20:19 |
| ghostmansd | And in prefix you can even have dot, lol. | 20:20 |
| ghostmansd | But I get your point with a lot of code written with .s and .v. | 20:20 |
| ghostmansd | Totally valid and fair remark. | 20:20 |
| ghostmansd | I'll tune binutils, then. | 20:20 |
| ghostmansd | As for global state... there's not much options. | 20:21 |
| lkcl | ew | 20:21 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l903 | 20:21 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l3421 | 20:21 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l875 | 20:21 |
| ghostmansd | ...well, you get the idea. :-) | 20:21 |
| lkcl | errrr... errr.... frick | 20:21 |
| ghostmansd | That said... | 20:21 |
| lkcl | frickin frick i just realised | 20:21 |
| ghostmansd | we can have our own X_op | 20:21 |
| lkcl | r32-r127 aren't in tc-ppc.c | 20:21 |
| ghostmansd | well this is easy to fix | 20:22 |
| lkcl | yeees, but you musn't add them for the *Scalar* Power ISA to find them | 20:22 |
| ghostmansd | Previously it was not a problem, before we started messing with macros. | 20:22 |
| ghostmansd | Previously we parsed this on our own. | 20:23 |
| ghostmansd | Even not bothering abot possible %r prefix. | 20:23 |
| lkcl | ngggh | 20:23 |
| ghostmansd | Now, when we want to re-use the vanilla code... we must be good citizens. | 20:23 |
| ghostmansd | And, if we want to parse operands and expand macros, I guess we should stick to common patterns. | 20:23 |
| lkcl | nggggggh | 20:24 |
| ghostmansd | As for this r32/r127... | 20:24 |
| ghostmansd | well, you know... | 20:24 |
| ghostmansd | ppc_cpu variable, ahem... ahem... is alos global. | 20:24 |
| ghostmansd | [coagh] | 20:24 |
| lkcl | blech :) | 20:24 |
| ghostmansd | so yeah, we might be total fucking idiots and rely on several global variables :-) | 20:25 |
| ghostmansd | Actually I'm kidding a bit. They use global objects everywhere. | 20:25 |
| ghostmansd | Ditto input_line_pointer | 20:25 |
| ghostmansd | This comes from the depths of the expression parser. | 20:25 |
| lkcl | i can hear the screams on the binutils mailing list alread.... no, i can hear the screams of all software engineers already | 20:25 |
| ghostmansd | They affect the parser state!!! | 20:26 |
| ghostmansd | When I found this I was really pissed. | 20:26 |
| ghostmansd | I mean, two independent translation units share a global variable which is a state and can be changed from any side-effect. | 20:26 |
| lkcl | the joys of heavily-optimised code... | 20:26 |
| ghostmansd | Crazy. | 20:26 |
| ghostmansd | No I guess this is not an optimization TBH. | 20:27 |
| ghostmansd | I guess this is legacy. | 20:27 |
| ghostmansd | And unwillingness to refactor. | 20:27 |
| programmerjake | actually, globals are often slower than function arguments... | 20:27 |
| ghostmansd | Anyway. | 20:27 |
| ghostmansd | As for register names, actually I guess 0.s is OK as well, I can make it work. | 20:28 |
| ghostmansd | But cocojumbo.s is not OK. | 20:28 |
| ghostmansd | This makes recursive expression() call. | 20:28 |
| ghostmansd | Or, well, forces to add more logic. | 20:29 |
| ghostmansd | That said... | 20:29 |
| ghostmansd | `.set cocojumbo, 1.s` is also not OK | 20:29 |
| ghostmansd | ...because it breaks the .set statement logic, it doesn't allow dots. | 20:30 |
| ghostmansd | So, you see, that's why I'd like to see something similar to the stuff they already have. | 20:30 |
| lkcl | macros changing registers from scalar to vector... this does not seem to be a sane idea | 20:31 |
| ghostmansd | .set fv0, 32.s | 20:31 |
| ghostmansd | test.s:1: Error: junk at end of line, first unrecognized character is `.' | 20:31 |
| lkcl | i can live with not supporting ".set cocojumbo, 32.v" | 20:31 |
| lkcl | changing the type of the register from scalar to vector based on a macro i don't think is safe / sane | 20:32 |
| ghostmansd | https://pastebin.com/NxkXbQL6 | 20:33 |
| ghostmansd | Let's take a look at this code | 20:33 |
| lkcl | yep that works - it's not changing the *type* of the register from scalar to vector based on a macro | 20:34 |
| lkcl | .set fv0, 32 | 20:34 |
| lkcl | sv.lfs/els fv0.v, 256(win) | 20:35 |
| ghostmansd | First, parsing fv0.v is difficult, because we must hack the parser. For any name we will think it's a register, possibly hidden under macro, so there might be yet another expression() call inside ppc_parse_name. | 20:35 |
| ghostmansd | Second, .set fv0, 32.v won't work at all without tuning too. | 20:35 |
| lkcl | ".set fv0, 32.v" is not desirable | 20:35 |
| ghostmansd | In both cases, the culprit is dot in suffix. | 20:35 |
| lkcl | it's not safe or sane | 20:36 |
| ghostmansd | Had we it as prefix, there wouldn't be any issues. | 20:36 |
| lkcl | drat | 20:36 |
| ghostmansd | Ah, so the thing is, you want to have .v even with macro? | 20:36 |
| lkcl | hell no | 20:37 |
| ghostmansd | To make it explicit it's vector? | 20:37 |
| lkcl | not ".set fv0, 32.v" absolutely not | 20:37 |
| ghostmansd | No, I mean, fv0.v | 20:37 |
| lkcl | yes | 20:37 |
| programmerjake | hmm, recursive expression calls should be fine (assuming you don't need to reset a bunch of globals before you call it), they're needed anyway to parse parenthesized sub-expressions such as 3 * (5 + 7) | 20:37 |
| programmerjake | expr calls operand which calls expr | 20:38 |
| * lkcl afk keeping an eye on irclogs online though | 20:39 | |
| ghostmansd[m] | Yes, from this point of view, it's OK. | 20:39 |
| ghostmansd[m] | My point is that we added something that strange and alienish that we now have to invoke expression recursively where it was not needed previously. | 20:40 |
| ghostmansd[m] | That's the potential problem I'm thinking of. | 20:41 |
| * octavius test | 20:46 | |
| lkcl | ngggh frickin nuisance as it would be, the swapping-round of r0.v to v.r0 and s.r32 would be a lot easier, wouldn't it | 21:43 |
| lkcl | one issue is, there's videos from the past 2 years with 0.v (etc.) | 21:43 |
| lkcl | and if that becomes v.0 it'll be less disruptive | 21:44 |
| lkcl | it's a big decision however so i'm going to write on the list about it | 21:50 |
| ghostmansd[m] | lkcl, perhaps there was another message... What's the big decision? | 21:50 |
| ghostmansd[m] | I thought due to code compatibility we should come up with some changes on binutils side. | 21:51 |
| lkcl | to change the name convention on registers. | 21:51 |
| ghostmansd[m] | OK, to what form? 0.s/0.v? | 21:51 |
| lkcl | well, i thought about it, and i suspect you might agree that if the operands *start* with "v." or "s." then that's far, far easier to spot in expression() | 21:52 |
| ghostmansd[m] | Yes, for sure. | 21:52 |
| lkcl | plus it solves the problem of registers being numbers | 21:52 |
| ghostmansd[m] | Yep. | 21:52 |
| lkcl | ok i'll write on list about it | 21:52 |
| ghostmansd[m] | (keep in mind they already have v. registers IIRC) | 21:52 |
| lkcl | o arse, yes they do | 21:53 |
| lkcl | drat | 21:53 |
| lkcl | mrrhhmm... ermermerm... | 21:53 |
| ghostmansd[m] | They do | 21:53 |
| lkcl | how about v:0 | 21:53 |
| ghostmansd[m] | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l588 | 21:53 |
| ghostmansd[m] | Perfect | 21:53 |
| lkcl | yep i've got tc-ppc.c open | 21:53 |
| ghostmansd[m] | I've been thinking of upper case | 21:54 |
| ghostmansd[m] | But a different delimiter is perhaps also an option. | 21:54 |
| lkcl | i hate uppercase but yes it works too | 21:54 |
| ghostmansd[m] | v!1 | 21:54 |
| lkcl | bleh / meh | 21:54 |
| ghostmansd[m] | May be even @ | 21:55 |
| lkcl | blerk | 21:55 |
| ghostmansd[m] | Something non-mathematical, though. | 21:55 |
| lkcl | yes | 21:55 |
| ghostmansd[m] | Otherwise lexer will fuck it up | 21:55 |
| ghostmansd[m] | Semicolon is good I think | 21:56 |
| ghostmansd[m] | Keep in mind that they use % sign before | 21:56 |
| ghostmansd[m] | So it might look like %v:0 | 21:57 |
| lkcl | meh. too many characters | 21:57 |
| ghostmansd[m] | Depending on a context and command-line arguments. This % is optional. | 21:57 |
| lkcl | ahh ok | 21:57 |
| ghostmansd[m] | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c#l840 | 21:58 |
| ghostmansd[m] | reg_names_p is a global which stores -regnames option | 21:58 |
| ghostmansd[m] | perhaps %xv128? | 22:00 |
| lkcl | blerk | 22:00 |
| ghostmansd[m] | And %xr? | 22:00 |
| ghostmansd[m] | x for extended | 22:00 |
| lkcl | oh ok | 22:01 |
| lkcl | hmmm | 22:01 |
| lkcl | kinda too different from existing (docs, etc.) | 22:01 |
| ghostmansd[m] | Yeah I know :-( | 22:01 |
| ghostmansd[m] | This is important problem, because our ideas clash with existing conventions. | 22:01 |
| lkcl | welcome to the party :) | 22:02 |
| ghostmansd[m] | This makes it difficult to approach... | 22:02 |
| lkcl | aaalll of SVP64 clashes with existing conventions :) | 22:02 |
| lkcl | i know what you mean | 22:02 |
| ghostmansd[m] | :-) | 22:02 |
| octavius | have you tried with "sv" in the name? | 22:02 |
| octavius | sv0.r | 22:02 |
| octavius | sv0.v | 22:02 |
| ghostmansd[m] | The problem is suffix. | 22:02 |
| lkcl | hmmmm | 22:03 |
| ghostmansd[m] | We actually kinda try to find a way to get rid of suffix to follow existing conventions... | 22:03 |
| lkcl | sv is too confusing - is it scalar or is it vector? | 22:03 |
| octavius | Ah | 22:03 |
| lkcl | but keep the existing register names "embedded" in it somehow | 22:03 |
| lkcl | (basically, still applying the strict RISC principle) | 22:04 |
| ghostmansd[m] | Luke, I think we should not even touch scalars | 22:04 |
| lkcl | (so that future Power ISA revisions have less work to do) | 22:04 |
| octavius | ...so retain the existing nomenclature (0.v, 0.s), but add something else | 22:04 |
| ghostmansd[m] | Because, well, these are exactly like they were, just are extended | 22:04 |
| ghostmansd[m] | So we only have vectors to approach, right? | 22:04 |
| lkcl | hmmmm hm hm hm.... | 22:04 |
| ghostmansd[m] | We can say r128/f128, right? | 22:05 |
| ghostmansd[m] | And this can be valid. | 22:05 |
| ghostmansd[m] | So, if only vectors... | 22:05 |
| ghostmansd[m] | vr128/vf128 is one option, as programmerjake suggested | 22:05 |
| ghostmansd[m] | And perhaps xr128/xf128 is better | 22:05 |
| lkcl | what i was thinking was, you could use the prefix "s:" or "v:" to say to ppc_parse_name, "oh, you want to use the extended SVP64 names here" | 22:06 |
| ghostmansd[m] | Because we also have original registers which start with v | 22:06 |
| lkcl | then have this | 22:06 |
| lkcl | { "cr7", 7, PPC_OPERAND_CR_REG }, | 22:06 |
| lkcl | { "cr8", 8, PPC_OPERAND_CR_REG|PPC_OPERAND_SVP64_ONLY }, | 22:07 |
| lkcl | because cr8 *only* exists in svp64 | 22:07 |
| lkcl | although... ahh, the lovely global state can cover that | 22:07 |
| ghostmansd[m] | If cr7 exists in both, why do you need to mark it with s:? | 22:07 |
| ghostmansd[m] | I mean, why don't you write simply cr7 or cr8, if they're scalar. | 22:08 |
| lkcl | you don't. it was just an idea to give an explicit way to say, "this is *definitely* scalar" | 22:08 |
| ghostmansd[m] | Well if it's not marked as vector, it's explicit enough to me :-) | 22:08 |
| lkcl | so as to avoid possible confusion in the minds of assembler writers and readers going "errr cr7? is that scalar or is it vector? i don't know" | 22:08 |
| octavius | what's cr7? | 22:09 |
| lkcl | Condition Register Field number 7 | 22:09 |
| ghostmansd[m] | Cond reg | 22:09 |
| ghostmansd[m] | I thought about x for vectors, it's not explicit enough. | 22:10 |
| lkcl | aka in MSB0 barse-ackwards order it's.... CR[63-4*7:63-4*6+1] or something bananas | 22:10 |
| ghostmansd[m] | I mean, x is ok to mark that register is extended... | 22:10 |
| ghostmansd[m] | But not to show it's vector | 22:10 |
| octavius | The Condition Register (CR) is a 32-bit register which reflects the result of certain operations, and provides a mechanism for testing (and branching). | 22:10 |
| lkcl | the CR register is 32 bits fitting into 64, and is subdivided into 8 4-bit fields | 22:10 |
| lkcl | yes, and CR *Fields* are 4-bit | 22:11 |
| lkcl | quantity 8 | 22:11 |
| ghostmansd[m] | Damn for ducks sake why we are not the first to occupy "v" prefix | 22:11 |
| octavius | section 2.3.1 in the spec | 22:11 |
| ghostmansd[m] | Oh that was autocorrection | 22:11 |
| ghostmansd[m] | But you got the idea | 22:11 |
| lkcl | with totally balls-ed-up numbering that melted everyone's brain and caused a bug to go unspotted for *five months* sigh | 22:11 |
| lkcl | we have to be careful that nobody proposes an SPR that starts with the letters "xv" | 22:12 |
| ghostmansd[m] | It can be anyone, frankly. | 22:12 |
| ghostmansd[m] | Because, you see, there are already v and v. and even vs. | 22:13 |
| ghostmansd[m] | By the way, speaking of sv.128 prefix | 22:13 |
| lkcl | yaaa? | 22:13 |
| ghostmansd[m] | This would totally blow the mind :-) | 22:13 |
| ghostmansd[m] | Imagine arch which has vs.3 register and also has sv.3 register | 22:14 |
| ghostmansd[m] | Crazy psychos they'd call us | 22:14 |
| * lkcl brain melts and dribbles out my ears | 22:14 | |
| lkcl | oh and is then SVP64-prefixed | 22:14 |
| lkcl | sv.vs.3 | 22:14 |
| octavius | XD | 22:14 |
| ghostmansd[m] | :-D | 22:15 |
| ghostmansd[m] | LMAO | 22:15 |
| lkcl | v:vs.3 is safer | 22:15 |
| ghostmansd[m] | Yeah I agree | 22:15 |
| octavius | Isn't "vs" taken already? | 22:15 |
| ghostmansd[m] | Not sure whether we need s: | 22:16 |
| ghostmansd[m] | Luke means extended vs which is vectorized | 22:16 |
| octavius | Ah ok | 22:16 |
| lkcl | yes, really, this is possible in future, because i'm going to advocate / recommend that all *scalar* VSX instructions (the Quad-precision FP128 etc.) be SVP64-Vectoriseable | 22:16 |
| ghostmansd[m] | That is, vanilla vs., but vectorized | 22:16 |
| ghostmansd[m] | Fair enough | 22:16 |
| lkcl | octavius, it does not help that IBM, NVIDIA, ARM and many others all call "Packed SIMD" a "Vector" ISA | 22:16 |
| ghostmansd[m] | Ok I think semicolon with extension is OK | 22:17 |
| ghostmansd[m] | What'd be the correct way to define macros, then? | 22:17 |
| ghostmansd[m] | v:cocojumbo? | 22:17 |
| octavius | Definitely lkcl. Strictly speaking SIMD uses scalar registers, right? | 22:17 |
| lkcl | "v:" is off-limits for macro-parsing | 22:17 |
| lkcl | octavius, yyyyeeess, basically. the technical term in Flynn's Taxonomy is "SIMD-Within-A-Register" (SWAR) | 22:18 |
| lkcl | as in, actually, you just hand the contents of the 128-bit registers over to an ALU | 22:18 |
| ghostmansd[m] | Yeah macro likely won't allow it in `.set cocojumbo, v:0` | 22:18 |
| ghostmansd[m] | Or do you mean something else? | 22:19 |
| lkcl | and oh look! the instruction said "Do Some SIMD Sub-dividing on it" | 22:19 |
| lkcl | no that's exactly what i meant | 22:19 |
| lkcl | ghostmansd[m], i have no problem with you implementing this and then posting a follow-up on how much easier it was than the alternatives :) | 22:20 |
| lkcl | nggh am stressing out already on the documentation change though | 22:20 |
| lkcl | i'll get over it | 22:21 |
| ghostmansd[m] | Sorry :-) | 22:21 |
| ghostmansd[m] | I wish I knew it two years ago lol | 22:21 |
| octavius | Hindsight 20-20 ;) | 22:22 |
| ghostmansd[m] | We must not forget there are also floating point registers, CRs, etc. | 22:22 |
| lkcl | and mathematical expressions "4.0 / 2.5" | 22:22 |
| ghostmansd[m] | Well these are not so much a problem to be honest | 22:23 |
| ghostmansd[m] | (unless we want to calculate register number) | 22:23 |
| lkcl | which is technically possible (i tried it) | 22:23 |
| ghostmansd[m] | e.g. v:r(4/2) or like this | 22:23 |
| lkcl | you might find that v:(4/2) works | 22:24 |
| lkcl | or more | 22:24 |
| ghostmansd[m] | Well with simple integers — why not? | 22:24 |
| lkcl | (4/2) works | 22:24 |
| lkcl | but not r(4/2) | 22:24 |
| ghostmansd[m] | I mean, should we allow it for registers? | 22:24 |
| lkcl | yes | 22:24 |
| lkcl | because i can see a situation where, through macros, a user would want to define how much of a regfile is used | 22:24 |
| ghostmansd[m] | I don't feel like this is good. Who need to switch the register number based on calculations? | 22:24 |
| ghostmansd[m] | Even if needed, why not do it via .set macro? | 22:25 |
| ghostmansd[m] | Why do it inline in register name? | 22:25 |
| lkcl | because you may have a situation where you want to have more - or less - vector length | 22:25 |
| lkcl | and that would need both the vector length *and* the register numbering to be macro-definable | 22:25 |
| lkcl | .set vectorlength, 4 | 22:26 |
| lkcl | change to .set vectorlength, 8 | 22:26 |
| lkcl | yes, really. sigh | 22:26 |
| ghostmansd[m] | Well it's vector length, but not register id... | 22:27 |
| * lkcl need to get up and walk about | 22:27 | |
| lkcl | batches. | 22:27 |
| lkcl | algorithm adapts to use what's available, to avoid register spill | 22:27 |
| lkcl | and/or adapts to cut the vector register usage by 50% | 22:27 |
| lkcl | or increase it by 100% | 22:27 |
| lkcl | depending on other uses of the regfile at the same time | 22:28 |
| lkcl | unlike RISC-V Vectors and Cray Vectors, which have 32 and 8 *explicit* vector registers | 22:28 |
| lkcl | svp64 is on top of the *scalar* regfile | 22:29 |
| lkcl | so being able to adapt the maximum vector length by a scaling factor, in order to not have to use the stack, is quite important | 22:29 |
| lkcl | and also not have to go through 4 or 5 different variations of the assembler | 22:29 |
| lkcl | one using r0-r3 | 22:29 |
| lkcl | one using r0-r7 | 22:30 |
| ghostmansd[m] | Ah, OK. So you mean that it also affects the register id. | 22:30 |
| lkcl | one using r0-r15 | 22:30 |
| ghostmansd[m] | OK got it. | 22:30 |
| lkcl | one using r0-r31 | 22:30 |
| ghostmansd[m] | Well, this is doable, I think. | 22:30 |
| ghostmansd[m] | So, when ppc_parse_name is reached... | 22:30 |
| ghostmansd[m] | Check for say v: in front... | 22:31 |
| lkcl | ahh, and also check for a number | 22:31 |
| lkcl | in ppc_parse_name | 22:31 |
| ghostmansd[m] | If so, remember this is vectorized, drop it... | 22:31 |
| ghostmansd[m] | Then see if the next stuff is a number. If so, this is a usual rXXX. | 22:32 |
| lkcl | yes. | 22:32 |
| ghostmansd[m] | Then try checking if it's a known register... | 22:32 |
| ghostmansd[m] | Including the fact we have more of these. | 22:33 |
| ghostmansd[m] | Then, if everything went wrong, try expanding the macro. | 22:33 |
| lkcl | :) | 22:33 |
| * lkcl reaally need to get up and walk about | 22:34 | |
| ghostmansd[m] | Ok see you later :-) | 22:36 |
| ghostmansd[m] | Gotta get some rest | 22:36 |
| ghostmansd[m] | gn | 22:36 |
| octavius | I'll head of as well, gn | 22:38 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
