Monday, 2022-06-27

lkclwoo! NLnet's grant application to the EU looks like it got accepted - EUR 9.6 million09:14
programmerjakeooh, maybe we should submit a proposal for
programmerjakesince the other grant with that didn't get approved09: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
programmerjakeiirc we were trying to get those into ffmpeg, kernel-level stuff shouldn't be needed (other than context-switching new registers)11:03
lkcloctavius, moornin. saw your messages but you dropped off before i could reply11:03
programmerjakeand other user-space codec libraries11:03
octaviushello chaps11:03
lkcloctavius, i've put you down for EUR 4,000 for this one
octaviusYes, I did see that one11:04
lkclthat's a *contract* not a grant, so if you accept it, it absolutely has to be done on time11:04
octaviusWhat's the time scale?11:05
lkcland it really should not take long.11:05
programmerjakegn all, have fun!11:05
octaviusYeah, but how long will it take to understand that scary pinmux code? XD11:06
octaviusgn programmerjake11:06
lkcloctavius, it's a cut/paste job.11:06
lkclyou don't have to "understand" it11:06
lkclhow much effort do you think it's going to take to literally cut/paste this file11:07
lkcland alter nothing but lines 61 to 114?11:07
octaviusOh, this is using the existing system? Last I time I played with it (Nov-ish) I thought something was broken11:08
lkclin fact, if you simply use the existing and add one single line, for rgmii (gigabit ethernet) on the NORTH side then strictly speaking it's done11:09
lkclthat's my responsibility to fix, not yours.11:09
lkcli understand that code (or, having written it, can at least cope with re-learning to navigate it)11:10
octaviusOk, I'll have a look at it now11:11
lkclif you want something quick then if you can do two SVG drawings for this then we can close it and put in the RFPs11:11
octaviusConvert the diagrams to svg?11:13
octaviusok, will do11:13
octaviusAlso Paul has not replied yet11:14
lkclyes i know. toshaan's got a brief opportunity to speak with him11:14
octaviusok good, let's hope he get's back to us11:15
lkcli've upped the budget accordingly, it's easy work11:16
lkcland also helps you understand the vector-register arrangement11:16
octaviusThanks luke :)11:17
octaviuslkcl, give the reg svg a gander:;a=blob;f=svp64-primer/img/svp64_regs.svg;h=8a6c283b5e1798fdc22c8487fbbb7510706a0cee;hb=dc33c33dc205e6a54039c8480982cb857cac95fb12:52
octaviusWill 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 complexity12:53
lkcloctavius, cool!12:53
lkclthat looks really good12:54
lkcldoes it make sense?12:54
octaviusThe diagram? Yeah12:55
octaviusI wasn't quite sure of the coloured boxes, but I figured they were the elements12:55
lkclpredication simply enables the required byte-enable-write-lines and err that's all there is to predication12:59
octaviusOh yeah, that makes sense. I meant the actual drawing itself XD13:04
octaviusJust overcomplicated it in my head, that's all13:04
lkclthe next priority one is probably that 1st one, with the loop (extra pipeline stage)13:05
octaviusyeah, doing it now13:06
lkclthat's annoying, svg importing needs --shell-escape13:14
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
ghostmansdPerhaps we might include Alan as well...13:36
octaviuslkcl, added powerlines:;a=blob;f=svp64-primer/img/power_pipelines.png;h=98afc6b8b06c6a1958cc7e2adfe182afb153d8b2;hb=ca47450704a3ae2137194a6ea8cdcac02bb23f6913:54
octaviusShall I update the Cray vector and SIMD diagrams?13:54
ghostmansdFuck I'm both impressed and horrified :-D14:15
octaviusAh, goto's...14:15
octaviuslkcl, I just started writing a bug comment XD14:57
octaviusOh, didn't realise your comment was a few hours ago14:58
octaviusDeleted the jpg's lkcl, can I set as Resolved Fixed? (I seem to remember it cause the bug to disappear for you?)15:32
octaviusI'll be back, gotta grab some food15:36
ghostmansdLuke, they've finally sent the copyright assignment form!16:06
ghostmansdFolks, I'm wondering whether we can change the naming convention for registers.19:09
ghostmansdAs of now, I suspect these flavors are possible: %r32.s and 32.s. pysvp64asm, IIRC, only handles the latter.19:10
ghostmansdBut 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
octaviusunless there's an issue elsewhere, the r# notation (r0, r1, etc.) sounds reasonable19:13
ghostmansdI 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
ghostmansdIt seems that lower-case v and r are already occupied...;a=blob;f=gas/config/tc-ppc.c#l32019:15
ghostmansdAt the same time, please, take a look at the table there and think of possible names we could use.19:15
ghostmansdAlternative way is to parse register names _before_ binutils arrives to expression parsing.19:16
ghostmansdBut, 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
ghostmansdlkcl programmerjake ^^^19:18
ghostmansdI'd think about %S and %V (note the upper case).19:18
programmerjakevr10 instead of 10.v?19:19
programmerjakesince lowercase v is already taken19:20
programmerjakeimho reusing lowercase r for scalar registers should be fine19:20
programmerjakefor f10.v, use vf10?19:20
programmerjakeghostmansd, lkcl, what do you think of ^ idea?19:21
programmerjakeanother 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, 3019:24
ghostmansdvr10 looks fine to me19:27
ghostmansdParsing registers on a per-operand-basis is much better and simpler, to be honest.19:28
programmerjakethere'd also be vcr10 instead of cr10.v19:29
ghostmansdI'd suggested vs10, not vr10, but this is also occupied...19:30
ghostmansdCouldn't we re-use the original names, but prefix these with v or V?19:30
ghostmansdI mean, keep simple %r10 and know that this is scalar...19:30
ghostmansd...and, for vector, have %rv10 or something akin,19:31
programmerjakebasically, i'm suggesting s/\(.*\)\.v/v\1/g and s/\(.*\)\.s/\1/g19:32
ghostmansdThis is barely readable :-)19:32
ghostmansdDrop it before Luke sees it :-D19:32
lkclghostmansd, nope, i don't :)  yes i've known Dr Stallman and been writing on-and-off to him since... err.. 2006?19:32
ghostmansdHe hates regex, right lkcl? :-)19:32
programmerjaketranslation to english: reg.v -> vreg and reg.s -> reg19:33
lkcli love gotos, i am literally unable to read regex's19:33
programmerjake(sorta english)19:33
programmerjakefor regs named v/r/cr<number>19:33
programmerjakef/r/cr<number> i meant19:34
programmerjakeso f123.v -> vf12319:34
ghostmansdand 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 3019:35
programmerjakeghostmansd: yes19:35
ghostmansdprogrammerjake, and what for scalars? they simply don't get any prefix at all, right?19:36
ghostmansde.g. f123.s => f123?19:36
lkcloctavius, yes do set as flxed, i'm tracking bugreports with budget-sync now19:36
ghostmansdhm, seems reasonable19:36
ghostmansdcan we have vector of altivec vectors? :-D19:36
ghostmansdand Vector Scalar?19:37
lkclghostmansd, yes!!19:37
ghostmansdI'm kidding, but, I'm worrying about these are kinda mixed19:37
ghostmansdlkcl, yes what? :-)19:37
lkclbecause altivec vector registers are actually not vectors at all19:37
ghostmansdah OK :-)19:37
ghostmansdI thought these are vectors already19:38
lkclthey're "registers whose length is 128-bit and which can be used for SIMD-within-a-register purposes"19:38
ghostmansdOK let's choose some convention. Again, alternatively I can hack binutils internals, sure. But this makes some non-trivial stuff...19:38
ghostmansde.g. what COCOJUMBO.v means?19:39
ghostmansdShould I look up the macro?19:39
ghostmansdAnd how's it different from 1.v?19:39
lkclwelcome to a marketing misrepresentation f*****-up that is peretrated by a *lot* of industry giants19:39
programmerjakethey are also used for "this instruction operates on a 128-bit scalar" stuff19:39
lkclyes COCOJUMBO would be a macro lookup19:39
ghostmansdAnd so on, all these must be handled manually.19:39
ghostmansdYeah that I get :-)19:39
ghostmansdBut it would basically mean "whenever you see an unknown name, treat it as a register"19:40
ghostmansdThis would also imply calling expression() inside expression().19:40
programmerjakeother idea: f10.v -> v.f10 and f10.s -> s.f1019:40
ghostmansdbinutils call the main parsing stuff expression()19:40
ghostmansdAnd allow to hook it so that, when it sees an unknown crap, it calls some user-defined routine.19:41
ghostmansdBut, all in all, I'd rather prefer seeing an alternative register calling convention.19:41
ghostmansdLet me find the problem code so that you understand the problem...19:41
programmerjakev.10 avoids the parse-as-integer problem that 10.v has...19:42
ghostmansdHere's the actual issue I hit.19:43
ghostmansdYou see, when this code sees some digit...19:43
ghostmansdIt calls integer_constant().19:44
ghostmansdI suspect this is also the reason why they tend to call registers like ymm0, not 0.ymm :-)19:44
ghostmansdI 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
ghostmansdBecause it won't follow the conventions everybody else uses.19:45
lkcli don't have a problem with adding "#ifdef PPC64 && LIBRESOC" look for follow-up19:48
lkcljust don't let people use "NN.v"19:48
lkcltell them it has to be "r0.v" and "r128.v"19:48
lkclthe issue with changing things is, there's 780+ instances of "NN.v" in the openpower-isa unit tests alone19:49
programmerjakeforcing people to use r23.v rather than 23.v sounds like a good and easy solution imho19:49
programmerjakelkcl, regex replace it!19:50
programmerjakei can do that if you like...19:50
lkclthe ".v" is different enough from the standard power isa reg names that there's unlikely to be a conflict19:50
lkclwhich was why i picked it19:50
ghostmansd[m]This still keeps the issue of separating with dot...19:50
lkclcoming up with new names is non-uniform (non-RISC)19:51
lkclit would require the addition of a table (lots of tables) in tc-ppc.c19: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
programmerjakeimho just don't support macros in reg names19:52
programmerjakepretty short list imho ^19:52
ghostmansd[m]Nope, we already have these19:52
lkclprogrammerjake, they're important19:53
ghostmansd[m]In mp3 audio19:53
programmerjakemake 2 macros: my_reg_v and my_reg_s19:53
ghostmansd[m]We have stuff like ".set cocojumbo, 0" and then "sv.add. cocojumbo.v, ..."19:53
lkclwhich was the very first "real-world" piece of svp64 assembler written (by lauri)19:54
lkcland the very first thing he did was use ".set win 32"19:54
lkclthen asked me why pysvp64asm didn't support it19:54
programmerjakeoh, wait: cheat: make the define macro function define macro and macro.v macro.s too19:54
lkclhmmmm :)19:55
ghostmansdI 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
ghostmansdThe canonical way for binutils is to have unique register names, and define macros to these.19:57
ghostmansdThat is, if one wants to make a macro to vector register 53, this would be `.set cocojumbo %v53`19:57
programmerjakeso, like i suggested: vr10, vf10, and vcr1019:58
ghostmansdYes, exactly.19:58
ghostmansdI 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
ghostmansdAnd so we have choice to either follow common patterns, or hack stuff around.19:59
ghostmansdI'd prefer the former, like vr10, vf10, etc.19:59
programmerjakeand you'll just have to give up having 1 macro for my_reg.s and'll need my_reg_s = r10 and my_reg_v = vr1019:59
lkclghostmansd, i'm looking towards the end of expr.c operand() function20:04
lkcland it calls md_parse_name()20:05
lkclwhich is #defined to...20:05
ghostmansdThat's the place I mentioned20:05
ghostmansdTo be hacked20:05
ghostmansd(if we choose this way)20:06
lkclhave you tried simply modifying that to search (and exclude) ".v" and ".s" if found?20:06
lkclwhat happened?20:06
ghostmansdAnd it works20:06
lkclon r0.v and fp0.v?20:06
ghostmansdWell, with some global context, I even can keep track of whether it's scalar or vector20:06
ghostmansdlkcl, I just checked some nonsensial name like cocojumbo.v20:07
ghostmansdWhich was .set before20:07
ghostmansdNot the actual registers20:07
lkclwith a ... ah i was going to ask, with a .set20:07
lkcland it worked?20:07
ghostmansdYes, since...20:07
ghostmansdlet me find it...20:07
ghostmansdso, here we call expression()...20:08
ghostmansdit finds an unknown name...20:08
ghostmansdand gets to ppc_parse_name...20:09
ghostmansdI don't recall, though, whether we get to cocojumbo being actually expanded.20:09
ghostmansdOr whether we end up with some unknown relocation against cocojumbo.20:10
ghostmansdBut, even if it doesn't work, we can do expression() inside ppc_parse_name(), after we trim .v and .s.20:11
lkcli wouldn't recommend using global state then20:14
lkclbut add an extra field to expressionS20:14
* lkcl just doing a new clone and compile of binutils-gdb20:15
lkcloctavius, if paul comes back to us with some modifications needed then there's an additional EUR 1,000 left20:15
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
lkclit's too much20:17
lkcland in future, when there's an initiative to put SVP64 on top of VSX, the entirety of the VSX regfile also needs duplicating20:18
ghostmansdOK I got it, I'll tune the code then.20:18
lkclso literally every single register name ends up duplicated.20:18
ghostmansdWell, it's depends on how you look at this. Isn't this with suffix is duplication too?20:19
ghostmansdI mean, for me both prefix and suffix are kinda similar.20:19
ghostmansdAnd in prefix you can even have dot, lol.20:20
ghostmansdBut I get your point with a lot of code written with .s and .v.20:20
ghostmansdTotally valid and fair remark.20:20
ghostmansdI'll tune binutils, then.20:20
ghostmansdAs for global state... there's not much options.20:21
ghostmansd...well, you get the idea. :-)20:21
lkclerrrr... errr.... frick20:21
ghostmansdThat said...20:21
lkclfrickin frick i just realised20:21
ghostmansdwe can have our own X_op20:21
lkclr32-r127 aren't in tc-ppc.c20:21
ghostmansdwell this is easy to fix20:22
lkclyeees, but you musn't add them for the *Scalar* Power ISA to find them20:22
ghostmansdPreviously it was not a problem, before we started messing with macros.20:22
ghostmansdPreviously we parsed this on our own.20:23
ghostmansdEven not bothering abot possible %r prefix.20:23
ghostmansdNow, when we want to re-use the vanilla code... we must be good citizens.20:23
ghostmansdAnd, if we want to parse operands and expand macros, I guess we should stick to common patterns.20:23
ghostmansdAs for this r32/r127...20:24
ghostmansdwell, you know...20:24
ghostmansdppc_cpu variable, ahem... ahem... is alos global.20:24
lkclblech :)20:24
ghostmansdso yeah, we might be total fucking idiots and rely on several global variables :-)20:25
ghostmansdActually I'm kidding a bit. They use global objects everywhere.20:25
ghostmansdDitto input_line_pointer20:25
ghostmansdThis comes from the depths of the expression parser.20:25
lkcli can hear the screams on the binutils mailing list alread.... no, i can hear the screams of all software engineers already20:25
ghostmansdThey affect the parser state!!!20:26
ghostmansdWhen I found this I was really pissed.20:26
ghostmansdI mean, two independent translation units share a global variable which is a state and can be changed from any side-effect.20:26
lkclthe joys of heavily-optimised code...20:26
ghostmansdNo I guess this is not an optimization TBH.20:27
ghostmansdI guess this is legacy.20:27
ghostmansdAnd unwillingness to refactor.20:27
programmerjakeactually, globals are often slower than function arguments...20:27
ghostmansdAs for register names, actually I guess 0.s is OK as well, I can make it work.20:28
ghostmansdBut cocojumbo.s is not OK.20:28
ghostmansdThis makes recursive expression() call.20:28
ghostmansdOr, well, forces to add more logic.20:29
ghostmansdThat said...20:29
ghostmansd`.set cocojumbo, 1.s` is also not OK20:29
ghostmansd...because it breaks the .set statement logic, it doesn't allow dots.20:30
ghostmansdSo, you see, that's why I'd like to see something similar to the stuff they already have.20:30
lkclmacros changing registers from scalar to vector... this does not seem to be a sane idea20:31
ghostmansd.set fv0, 32.s20:31
ghostmansdtest.s:1: Error: junk at end of line, first unrecognized character is `.'20:31
lkcli can live with not supporting ".set cocojumbo, 32.v"20:31
lkclchanging the type of the register from scalar to vector based on a macro i don't think is safe / sane20:32
ghostmansdLet's take a look at this code20:33
lkclyep that works - it's not changing the *type* of the register from scalar to vector based on a macro20:34
lkcl.set fv0, 3220:34
lkclsv.lfs/els fv0.v, 256(win)20:35
ghostmansdFirst, 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
ghostmansdSecond, .set fv0, 32.v won't work at all without tuning too.20:35
lkcl".set fv0, 32.v" is not desirable20:35
ghostmansdIn both cases, the culprit is dot in suffix.20:35
lkclit's not safe or sane20:36
ghostmansdHad we it as prefix, there wouldn't be any issues.20:36
ghostmansdAh, so the thing is, you want to have .v even with macro?20:36
lkclhell no20:37
ghostmansdTo make it explicit it's vector?20:37
lkclnot ".set fv0, 32.v" absolutely not20:37
ghostmansdNo, I mean, fv0.v20:37
programmerjakehmm, 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
programmerjakeexpr calls operand which calls expr20:38
* lkcl afk keeping an eye on irclogs online though20: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 test20:46
lkclngggh 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 it21:43
lkclone issue is, there's videos from the past 2 years with 0.v (etc.)21:43
lkcland if that becomes v.0 it'll be less disruptive21:44
lkclit's a big decision however so i'm going to write on the list about it21: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
lkclto change the name convention on registers.21:51
ghostmansd[m]OK, to what form? 0.s/0.v?21:51
lkclwell, 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
lkclplus it solves the problem of registers being numbers21:52
lkclok i'll write on list about it21:52
ghostmansd[m](keep in mind they already have v. registers IIRC)21:52
lkclo arse, yes they do21:53
lkclmrrhhmm... ermermerm...21:53
ghostmansd[m]They do21:53
lkclhow about v:021:53
lkclyep i've got tc-ppc.c open21:53
ghostmansd[m]I've been thinking of upper case21:54
ghostmansd[m]But a different delimiter is perhaps also an option.21:54
lkcli hate uppercase but yes it works too21:54
lkclbleh / meh21:54
ghostmansd[m]May be even @21:55
ghostmansd[m]Something non-mathematical, though.21:55
ghostmansd[m]Otherwise lexer will fuck it up21:55
ghostmansd[m]Semicolon is good I think21:56
ghostmansd[m]Keep in mind that they use % sign before21:56
ghostmansd[m]So it might look like %v:021:57
lkclmeh. too many characters21:57
ghostmansd[m]Depending on a context and command-line arguments. This % is optional.21:57
lkclahh ok21:57
ghostmansd[m]reg_names_p is a global which stores -regnames option21:58
ghostmansd[m]perhaps %xv128?22:00
ghostmansd[m]And %xr?22:00
ghostmansd[m]x for extended22:00
lkcloh ok22:01
lkclkinda 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
lkclwelcome to the party :)22:02
ghostmansd[m]This makes it difficult to approach...22:02
lkclaaalll of SVP64 clashes with existing conventions :)22:02
lkcli know what you mean22:02
octaviushave you tried with "sv" in the name?22:02
ghostmansd[m]The problem is suffix.22:02
ghostmansd[m]We actually kinda try to find a way to get rid of suffix to follow existing conventions...22:03
lkclsv is too confusing - is it scalar or is it vector?22:03
lkclbut keep the existing register names "embedded" in it somehow22:03
lkcl(basically, still applying the strict RISC principle)22:04
ghostmansd[m]Luke, I think we should not even touch scalars22:04
lkcl(so that future Power ISA revisions have less work to do)22:04 retain the existing nomenclature (0.v, 0.s), but add something else22:04
ghostmansd[m]Because, well, these are exactly like they were, just are extended22:04
ghostmansd[m]So we only have vectors to approach, right?22:04
lkclhmmmm 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 suggested22:05
ghostmansd[m]And perhaps xr128/xf128 is better22:05
lkclwhat 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 v22:06
lkclthen have this22:06
lkcl  { "cr7", 7, PPC_OPERAND_CR_REG },22:06
lkcl  { "cr8", 8, PPC_OPERAND_CR_REG|PPC_OPERAND_SVP64_ONLY },22:07
lkclbecause cr8 *only* exists in svp6422:07
lkclalthough... ahh, the lovely global state can cover that22: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
lkclyou 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
lkclso 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
octaviuswhat's cr7?22:09
lkclCondition Register Field number 722:09
ghostmansd[m]Cond reg22:09
ghostmansd[m]I thought about x for vectors, it's not explicit enough.22:10
lkclaka in MSB0 barse-ackwards order it's.... CR[63-4*7:63-4*6+1] or something bananas22:10
ghostmansd[m]I mean, x is ok to mark that register is extended...22:10
ghostmansd[m]But not to show it's vector22:10
octaviusThe 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
lkclthe CR register is 32 bits fitting into 64, and is subdivided into 8 4-bit fields22:10
lkclyes, and CR *Fields* are 4-bit22:11
lkclquantity 822:11
ghostmansd[m]Damn for ducks sake why we are not the first to occupy "v" prefix22:11
octaviussection 2.3.1 in the spec22:11
ghostmansd[m]Oh that was autocorrection22:11
ghostmansd[m]But you got the idea22:11
lkclwith totally balls-ed-up numbering that melted everyone's brain and caused a bug to go unspotted for *five months* sigh22:11
lkclwe 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 prefix22: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 register22:14
ghostmansd[m]Crazy psychos they'd call us22:14
* lkcl brain melts and dribbles out my ears22:14
lkcloh and is then SVP64-prefixed22:14
lkclv:vs.3 is safer22:15
ghostmansd[m]Yeah I agree22:15
octaviusIsn't "vs" taken already?22:15
ghostmansd[m]Not sure whether we need s:22:16
ghostmansd[m]Luke means extended vs which is vectorized22:16
octaviusAh ok22:16
lkclyes, 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-Vectoriseable22:16
ghostmansd[m]That is, vanilla vs., but vectorized22:16
ghostmansd[m]Fair enough22:16
lkcloctavius, it does not help that IBM, NVIDIA, ARM and many others all call "Packed SIMD" a "Vector" ISA22:16
ghostmansd[m]Ok I think semicolon with extension is OK22:17
ghostmansd[m]What'd be the correct way to define macros, then?22:17
octaviusDefinitely lkcl. Strictly speaking SIMD uses scalar registers, right?22:17
lkcl"v:" is off-limits for macro-parsing22:17
lkcloctavius, yyyyeeess, basically.  the technical term in Flynn's Taxonomy is "SIMD-Within-A-Register" (SWAR)22:18
lkclas in, actually, you just hand the contents of the 128-bit registers over to an ALU22: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
lkcland oh look! the instruction said "Do Some SIMD Sub-dividing on it"22:19
lkclno that's exactly what i meant22:19
lkclghostmansd[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
lkclnggh am stressing out already on the documentation change though22:20
lkcli'll get over it22:21
ghostmansd[m]Sorry :-)22:21
ghostmansd[m]I wish I knew it two years ago lol22:21
octaviusHindsight 20-20 ;)22:22
ghostmansd[m]We must not forget there are also floating point registers, CRs, etc.22:22
lkcland mathematical expressions "4.0 / 2.5"22:22
ghostmansd[m]Well these are not so much a problem to be honest22:23
ghostmansd[m](unless we want to calculate register number)22:23
lkclwhich is technically possible (i tried it)22:23
ghostmansd[m]e.g. v:r(4/2) or like this22:23
lkclyou might find that v:(4/2) works22:24
lkclor more22:24
ghostmansd[m]Well with simple integers — why not?22:24
lkcl(4/2) works22:24
lkclbut not r(4/2)22:24
ghostmansd[m]I mean, should we allow it for registers?22:24
lkclbecause i can see a situation where, through macros, a user would want to define how much of a regfile is used22: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
lkclbecause you may have a situation where you want to have more - or less - vector length22:25
lkcland that would need both the vector length *and* the register numbering to be macro-definable22:25
lkcl.set vectorlength, 422:26
lkclchange to .set vectorlength, 822:26
lkclyes, really. sigh22:26
ghostmansd[m]Well it's vector length, but not register id...22:27
* lkcl need to get up and walk about22:27
lkclalgorithm adapts to use what's available, to avoid register spill22:27
lkcland/or adapts to cut the vector register usage by 50%22:27
lkclor increase it by 100%22:27
lkcldepending on other uses of the regfile at the same time22:28
lkclunlike RISC-V Vectors and Cray Vectors, which have 32 and 8 *explicit* vector registers22:28
lkclsvp64 is on top of the *scalar* regfile22:29
lkclso being able to adapt the maximum vector length by a scaling factor, in order to not have to use the stack, is quite important22:29
lkcland also not have to go through 4 or 5 different variations of the assembler22:29
lkclone using r0-r322:29
lkclone using r0-r722:30
ghostmansd[m]Ah, OK. So you mean that it also affects the register id.22:30
lkclone using r0-r1522:30
ghostmansd[m]OK got it.22:30
lkclone using r0-r3122: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
lkclahh, and also check for a number22:31
lkclin ppc_parse_name22: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
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 reaally need to get up and walk about22:34
ghostmansd[m]Ok see you later :-)22:36
ghostmansd[m]Gotta get some rest22:36
octaviusI'll head of as well, gn22:38

Generated by 2.17.1 by Marius Gedminas - find it at!