Friday, 2021-03-19

awyglelkcl: quite likely I would yes00:50
programmerjakelxo: ^ for a more convincing argument for why I think Rust is worth using over C/C++01:19
lxoprogrammerjake, thanks.  funny how some of the features presented as advantages make me want to run away screaming in horror :-)   "dependencies like npm" comes to mind03:55
lxoI'm afraid I find the article largely unconvincing.  mainly because C/C++ are mostly the devil we know, I don't need to be convinced about their abstraction weaknesses.  I'd be more interested in comparisons with other languages that aim to provide both safety and performance03:57
programmerjakeobviously...just because rust can do something (such as easily manage thousands of dependencies) doesn't mean you have to use it that way :)03:57
programmerjakea little out-of-date, but:
lxo> Ada developers either use a garbage collector, or they avoid freeing memory entirely and design the whole application as a finite state machine (both of which are possible in Rust, too, but the point is you don’t have to).04:21
lxothe author lost me there.  seems clueless about Ada04:22
lxooh, that's just a collection of comments from multiple authors, not a coherent article04:23
programmerjakeit's a forum, not everyone's correct. the fact that they're wrong is pointed out later04:23
programmerjakewell, hopefully you at least found that interesting, if not convincing :)04:34
lkcllxo, programmerjake: alain modra is ok with "/" but "=" has to be replaced with "?" in svp64 assembler12:29
lkclcesar[m]1, i've done a couple of minor code-shuffles this morning14:42
lkcland also written equivalent functions for decoding the predicate mask fields14:44
programmerjakehmm, 'subvl?3' seems very unintuitive, would something else work, such as 'subvl:3' or 'subvl(3)' or 'subvl[3]' or 'subvl{3}'?15:42
programmerjakelkcl, lxo ^15:42
lxoI'm lacking context.  is this supposed to be an opcode name, an insn identifier, or what?15:51
programmerjakelxo: kinda like 'sv.add/subvl=4/elwid=32 10.v, 20.v, 30.v'15:54
lkclit's just for element width, predicate masks etc16:08
lkclsv.add/subvl?4/ew?32 10.v etc. etc16:09
lkclthere's not a lot of choice here.  there are gnu-as macro expressions which use up standard math operators -+*/ and assignment "="16:10
lkcllinks to discussions on binutils and gcc16:10
lxohow about "//subvl/4//ew/32" ?16:12
lxouhh, I wonder if // would be discarded by asm preprocessors16:14
programmerjakeare any of those args ever negative?16:18
programmerjake`pred=~r31` could become `pred_not_31`16:20
programmerjake`pred=1<<r3` could become `pred_onehot_3`16:21
lkclassembly mnemonics need to be kept extremely short. wasting processing power on text string parsing is frowned upon16:22
lkclyet a minimum balance on "understandability" also maintained16:23
programmerjakek, though I'd expect actual usage of assemblers (usually as a gcc backend) to be on the order of a few ms for the entire assembler, compared to many several seconds for gcc for the same file16:25
programmerjakeso, I don't really think processing power is a good argument...16:25
programmerjakeif the assembly file actually becomes big enough that the assembler runs for an appreciable time, i'd expect gcc to still have taken >10x as long, likely >100x16:27
programmerjakeappreciable time for assembler means >1s here16:27
programmerjakeit might have been a good argument 40 years ago...16:28
programmerjakeI'd expect taking an appreciable time for the assembler to only happen for something the scale of chromium, and then it'll be on the order of a few secs, compared to the many minutes/hours it takes for gcc to run.16:30
programmerjakeif the assembler does take longer, i'd expect that to only happen if writing the .o files was i/o bound...such as compiling on a hard drive or usb2 flash drive16:32
lxounderscore is normally part of symbol names, not a separator16:58
lxomaybe /subvl 4 /ew 3216:59
programmerjakesince it's part of the instruction mnemonic rather than an argument where you could put symbols, it all works out.17:10
programmerjakethough it did just occur to me that we could instead have matching lists of svp64 argument names in the mnemonic separated by / and have the argument values prepended in the same order to the argument list--examples in a sec...17:16
programmerjakeso, if the base instruction is add r10, r20, r30:17:20
programmerjakethen, adding elwid=16 would produce: sv.add/elwid 16, r10.v, r20.v, r30.v17:22
programmerjakeadding elwid=32 and subvl=2 would produce:17:23
programmerjakeeither: sv.add/elwid/subvl 32, 2, r10.v, r20.v, r30.v17:23
programmerjakeor: sv.add/subvl/elwid 2, 32, r10.v, r20.v, r30.v17:23
lxothis will make it more painful to output these split operands17:25
programmerjakebasically, sv.mnemonic{/sv_arg_name} {sv_arg_value, } original_args17:26
programmerjakewhere {x} indicates 0 or more repetitions of x17:26
lxohow about sv.add r10.v, r20.v, r30.v [,/] subvl 2 [,/] elwid 32  ?17:26
programmerjakethat could also work17:28
lxowe could also use \/ (backslash slash) as the separator.  it looks like a V :-)17:29
programmerjakeI think we should choose one canonical order for all possible sv arguments and enforce that the provided sv arguments are in the same order17:30
programmerjakefor your suggestion of appending arguments, the separators would likely have to be , and not / since / could be confused by the expression parser for division17:32
programmerjakeI'm liking the `sv.add r10.v, r20.v, r30.v, subvl 2, elwid 32` format the best17:36
lkclthat's "no" on changing the number of arguments.  i've already made that clear on the binutils mailing list that that's not happening18:13
lkclthe reason is explained publicly on the post.18:13
lxothat's not changing the arguments to the opcode, just overloading the comma for use also as separator between operands and prefix parameters, and between prefix parameters, given how difficult it is to find other available separators18:20
lkcli am concentrating on some bit-decoding.  can you please look at the bugreport, track down the conversation on binutils, and read it18:22
lkclbut whatever you do, please do *not* send messages which make Alain nervous18:22
lkcli repeat again: i have *already said* - to Alain - the respected person in charge of binutils for powerpc - that the number of arguments is not going to change due to SVP6418:23
lkclcontradicting that publicly tells IBM that we have no idea what the hell we are doing.18:24
lkclbottom line: Alain has already approved the syntax.  therefore it's not changing unless we can demonstrate a *technical* reason why it cannot work.18:27
lxoI guess I'll just stay out of the conversation altogether.  you can't really add arguments without changing the number of arguments, and the prefix augmentations or however you wish to call them *are* additional arguments to the prefixed vector operation.  I can't really engage in the sort of double-thinking that makes them additional arguments that aren't additional arguments, so I won't get in the way of your commitment18:27
lkclotherwise we risk alienating Alain18:27
lkclthe syntax that's in SVP64Asm "works".18:28
lkclAlain's reviewed it18:28
lkclwe worked through it and he suggested using "?" instead of "="18:28
lxoI'm glad we've had the conversation with binutils and gcc before we had put a lot of effort into an implementation.  I'd have felt a fool if I'd spent a significant amount of time just to find out a lot of it went to waste18:28
lkcltrying to change that now wastes his time18:28
lkclyes, that's why i raised it18:29
lkclwe have to demonstrate that we're listening to what they tell us.18:29
lxoOTOH, I'm also surprised at pushback about asm syntax.  as unusual as what we had before was, I'd never seen binutils maintainers tell hardware designers to get lost because their asm syntax sucked.  we've worked with documented or implemented asm syntax, whatever it was18:29
lkclgoing back now and saying "actually we changed our minds", there has to be *exceptionally* good reasons18:29
lkclthe changes to OpenPOWER from outside IBM initially was freaking them out18:30
lkclsomewhere along the line, in the past 7-10 days, there's been an internal sea-change18:30
lkcl(for the better :) )18:31
lxogreat news18:31
lkclit's a delicate situation18:32
programmerjakelkcl: afaik powerpc-solaris is just powerpc but running the solaris os .. the assembler changes are kinda like how x86 syntax changes between at&t syntax and intel syntax but the exact same binary instructions are generated18:40
programmerjakeso, our processor (assuming it supports 32-bit mode) will support powerpc-solaris18:41
programmerjakesince that's only software-level18:41
lkclahh ok.18:55
lkcli wonder what Alain was referring to, that the assembly syntax has "/" as a comment18:55
* programmerjake < >18:57
programmerjakethough it may only work on blank lines, i'd have to check18:58
lkclthat's a URL again18:58
programmerjakethat means that solaris' variant of assembly can have comments like so:18:59
programmerjake.text / <-- the single slash starts a comment18:59
programmerjake / more comment18:59
programmerjakeaddi 5, 5, 2345 / wow comments!18:59
programmerjakekinda like // in C++ or # in bash19:00
programmerjakealso, . totally works as separators: the Rc=1 . just goes at the end: sv.add.subvl=5.elwid=32.19:12
programmerjakealternatively just have 2 . in sequence: sv.add..subvl=5.elwid=3219:12

Generated by 2.17.1 by Marius Gedminas - find it at!