| awygle | lkcl: quite likely I would yes | 00:50 |
|---|---|---|
| programmerjake | interesting: https://kornel.ski/rust-c-speed | 01:18 |
| programmerjake | lxo: ^ for a more convincing argument for why I think Rust is worth using over C/C++ | 01:19 |
| lxo | programmerjake, thanks. funny how some of the features presented as advantages make me want to run away screaming in horror :-) "dependencies like npm" comes to mind | 03:55 |
| lxo | I'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 performance | 03:57 |
| programmerjake | obviously...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 |
| programmerjake | a little out-of-date, but: https://users.rust-lang.org/t/if-ada-is-already-very-safe-why-rust/21911 | 04:07 |
| 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 |
| lxo | the author lost me there. seems clueless about Ada | 04:22 |
| lxo | oh, that's just a collection of comments from multiple authors, not a coherent article | 04:23 |
| programmerjake | it's a forum, not everyone's correct. the fact that they're wrong is pointed out later | 04:23 |
| lxo | *nod* | 04:27 |
| programmerjake | well, hopefully you at least found that interesting, if not convincing :) | 04:34 |
| lkcl | lxo, programmerjake: alain modra is ok with "/" but "=" has to be replaced with "?" in svp64 assembler | 12:29 |
| lkcl | cesar[m]1, i've done a couple of minor code-shuffles this morning | 14:42 |
| lkcl | and also written equivalent functions for decoding the predicate mask fields | 14:44 |
| programmerjake | hmm, 'subvl?3' seems very unintuitive, would something else work, such as 'subvl:3' or 'subvl(3)' or 'subvl[3]' or 'subvl{3}'? | 15:42 |
| programmerjake | lkcl, lxo ^ | 15:42 |
| lxo | I'm lacking context. is this supposed to be an opcode name, an insn identifier, or what? | 15:51 |
| programmerjake | lxo: kinda like 'sv.add/subvl=4/elwid=32 10.v, 20.v, 30.v' | 15:54 |
| lkcl | it's just for element width, predicate masks etc | 16:08 |
| lkcl | sv.add/subvl?4/ew?32 10.v etc. etc | 16:09 |
| lkcl | there's not a lot of choice here. there are gnu-as macro expressions which use up standard math operators -+*/ and assignment "=" | 16:10 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=615 | 16:10 |
| lkcl | links to discussions on binutils and gcc | 16:10 |
| lxo | how about "//subvl/4//ew/32" ? | 16:12 |
| lxo | uhh, I wonder if // would be discarded by asm preprocessors | 16:14 |
| programmerjake | `subvl_4_ew_32`? | 16:18 |
| programmerjake | are 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 |
| lkcl | assembly mnemonics need to be kept extremely short. wasting processing power on text string parsing is frowned upon | 16:22 |
| lkcl | yet a minimum balance on "understandability" also maintained | 16:23 |
| programmerjake | k, 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 file | 16:25 |
| programmerjake | so, I don't really think processing power is a good argument... | 16:25 |
| programmerjake | if 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 >100x | 16:27 |
| programmerjake | appreciable time for assembler means >1s here | 16:27 |
| programmerjake | it might have been a good argument 40 years ago... | 16:28 |
| programmerjake | I'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 |
| programmerjake | if 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 drive | 16:32 |
| lxo | underscore is normally part of symbol names, not a separator | 16:58 |
| lxo | maybe /subvl 4 /ew 32 | 16:59 |
| programmerjake | since it's part of the instruction mnemonic rather than an argument where you could put symbols, it all works out. | 17:10 |
| programmerjake | though 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 |
| programmerjake | so, if the base instruction is add r10, r20, r30: | 17:20 |
| programmerjake | then, adding elwid=16 would produce: sv.add/elwid 16, r10.v, r20.v, r30.v | 17:22 |
| programmerjake | adding elwid=32 and subvl=2 would produce: | 17:23 |
| programmerjake | either: sv.add/elwid/subvl 32, 2, r10.v, r20.v, r30.v | 17:23 |
| programmerjake | or: sv.add/subvl/elwid 2, 32, r10.v, r20.v, r30.v | 17:23 |
| lxo | this will make it more painful to output these split operands | 17:25 |
| programmerjake | basically, sv.mnemonic{/sv_arg_name} {sv_arg_value, } original_args | 17:26 |
| programmerjake | where {x} indicates 0 or more repetitions of x | 17:26 |
| lxo | how about sv.add r10.v, r20.v, r30.v [,/] subvl 2 [,/] elwid 32 ? | 17:26 |
| programmerjake | that could also work | 17:28 |
| lxo | we could also use \/ (backslash slash) as the separator. it looks like a V :-) | 17:29 |
| programmerjake | I think we should choose one canonical order for all possible sv arguments and enforce that the provided sv arguments are in the same order | 17:30 |
| programmerjake | for your suggestion of appending arguments, the separators would likely have to be , and not / since / could be confused by the expression parser for division | 17:32 |
| lxo | exactly | 17:34 |
| programmerjake | I'm liking the `sv.add r10.v, r20.v, r30.v, subvl 2, elwid 32` format the best | 17:36 |
| lkcl | that's "no" on changing the number of arguments. i've already made that clear on the binutils mailing list that that's not happening | 18:13 |
| lkcl | the reason is explained publicly on the post. | 18:13 |
| lxo | that'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 separators | 18:20 |
| lkcl | i am concentrating on some bit-decoding. can you please look at the bugreport, track down the conversation on binutils, and read it | 18:22 |
| lkcl | but whatever you do, please do *not* send messages which make Alain nervous | 18:22 |
| lkcl | i 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 SVP64 | 18:23 |
| lkcl | contradicting that publicly tells IBM that we have no idea what the hell we are doing. | 18:24 |
| lkcl | bottom 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 |
| lxo | I 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 commitment | 18:27 |
| lkcl | otherwise we risk alienating Alain | 18:27 |
| lkcl | the syntax that's in SVP64Asm "works". | 18:28 |
| lkcl | Alain's reviewed it | 18:28 |
| lkcl | we worked through it and he suggested using "?" instead of "=" | 18:28 |
| lxo | I'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 waste | 18:28 |
| lkcl | trying to change that now wastes his time | 18:28 |
| lkcl | yes, that's why i raised it | 18:29 |
| lkcl | we have to demonstrate that we're listening to what they tell us. | 18:29 |
| lxo | OTOH, 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 was | 18:29 |
| lkcl | going back now and saying "actually we changed our minds", there has to be *exceptionally* good reasons | 18:29 |
| lkcl | the changes to OpenPOWER from outside IBM initially was freaking them out | 18:30 |
| lkcl | somewhere along the line, in the past 7-10 days, there's been an internal sea-change | 18:30 |
| lkcl | (for the better :) ) | 18:31 |
| lxo | great news | 18:31 |
| lkcl | it's a delicate situation | 18:32 |
| programmerjake | lkcl: 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 generated | 18:40 |
| programmerjake | so, our processor (assuming it supports 32-bit mode) will support powerpc-solaris | 18:41 |
| programmerjake | since that's only software-level | 18:41 |
| lkcl | ahh ok. | 18:55 |
| lkcl | i wonder what Alain was referring to, that the assembly syntax has "/" as a comment | 18:55 |
| * programmerjake < https://matrix.org/_matrix/media/r0/download/matrix.org/fjxHbyrMKCMtjKyjVoEIfvtO/message.txt > | 18:57 | |
| programmerjake | though it may only work on blank lines, i'd have to check | 18:58 |
| lkcl | that's a URL again | 18:58 |
| lkcl | https://matrix.org/_matrix/media/r0/download/matrix.org/fjxHbyrMKCMtjKyjVoEIfvtO/message.txt | 18:59 |
| programmerjake | that means that solaris' variant of assembly can have comments like so: | 18:59 |
| programmerjake | .text / <-- the single slash starts a comment | 18:59 |
| programmerjake | / more comment | 18:59 |
| programmerjake | addi 5, 5, 2345 / wow comments! | 18:59 |
| programmerjake | kinda like // in C++ or # in bash | 19:00 |
| programmerjake | also, . totally works as separators: the Rc=1 . just goes at the end: sv.add.subvl=5.elwid=32. | 19:12 |
| programmerjake | alternatively just have 2 . in sequence: sv.add..subvl=5.elwid=32 | 19:12 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!