| *** zemaye <zemaye!~zemaye@31-209-215-224.dsl.dynamic.simnet.is> has joined #libre-soc | 00:01 | |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC | 00:14 | |
| ghostmansd | Hm. Branch modes relied on bc_svstep which I dropped (it's always 0). | 00:17 |
|---|---|---|
| ghostmansd | And it became 0 or 1 depending on CTR. | 00:17 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 00:20 | |
| *** zemaye <zemaye!~zemaye@31-209-215-224.dsl.dynamic.simnet.is> has quit IRC | 00:20 | |
| ghostmansd | before/after | 00:28 |
| ghostmansd | for sv.bc/all 12,*1,0xc | 00:29 |
| ghostmansd | svp64_rm 0x42400 0b000001000010010000000000 | 00:29 |
| ghostmansd | svp64_rm 0x82400 0b000010000010010000000000 | 00:29 |
| ghostmansd | previously it used to set bit 18 | 00:30 |
| ghostmansd | now it sets bit 19 | 00:30 |
| ghostmansd | 18 is SLu, 19 is mode[0] | 00:30 |
| ghostmansd | And to me it looks setting 19 is correct | 00:31 |
| ghostmansd | OK I've been counting backwards it seems. Bits 5 and 4 respectively, corresponding to SNZ and ALL. | 00:37 |
| ghostmansd | - sv_mode = ((bc_svstep << SVP64MODE.MOD2_MSB) | | 00:39 |
| ghostmansd | - (bc_vlset << SVP64MODE.MOD2_LSB) | | 00:39 |
| ghostmansd | - (bc_snz << SVP64MODE.BC_SNZ)) | 00:39 |
| ghostmansd | - srcwid = (bc_vsb << 1) | bc_lru | 00:39 |
| ghostmansd | - destwid = (bc_lru << 1) | bc_all | 00:39 |
| ghostmansd | It seems that originally the code did something unrelated to the current tables. | 00:40 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 00:53 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 01:03 | |
| lkcl | yes, remember i had to stop working on sv.bc as it was taking too long | 01:10 |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 01:26 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 01:27 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 01:41 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 02:16 | |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc | 06:32 | |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC | 07:21 | |
| lkcl | programmerjake, good to see you caught up that there's too much to do in such a short timespan | 08:19 |
| lkcl | means picking the task very carefully. | 08:19 |
| lkcl | absolute max of 60-100 lines of assembler, one function only | 08:19 |
| lkcl | if you want to pick a task with *less* budget that's up to you but it doesn't seem sensible to do so! | 08:20 |
| markos | lkcl, is there a way to silence this message (it's still printed even with SILENCELOG=1: /home/markos/src/openpower-isa/src/openpower/decoder/power_decoder.py:199: DriverConflict: Signal '(sig internal_op)' is driven from multiple fragments: top.pdecode2, top.pdecode2.dec; hierarchy will be flattened | 10:27 |
| lkcl | markos, no there isn't. | 10:28 |
| markos | ok, no biggie | 10:28 |
| lkcl | not that i know of. | 10:28 |
| markos | ok, so I've written a pythoncallwrapper_example.c file which is to be used as a template for the other wrappers in vp8/vp9 and whoever else wants to use it | 10:30 |
| markos | I'm going to commit this first and then work on the actual vp9 | 10:30 |
| markos | I've been running it for a few minutes now, calling the same function in a for loop with changing values, so far so good, no errors | 10:30 |
| markos | it's slow but it's not that slow as if emulating the whole program | 10:31 |
| markos | feel free to suggest a different name, pypowersimwrapper_example.c maybe? | 10:33 |
| lkcl | pffh, we're traditionally terrible at names in this project :) | 10:54 |
| lkcl | ghostmansd[m], rebase good | 10:54 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 11:14 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 11:17 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 11:17 | |
| ghostmansd | lkcl, if one puts /snz, it won't be correct to output /snz/sz in disassembly, right? | 11:21 |
| ghostmansd | Even though /sz ends up being set, too | 11:21 |
| ghostmansd | yeah seems like this | 11:27 |
| ghostmansd[m] | Pushed. Do we consider 917 completed? | 11:44 |
| lkcl | correct it wouldn't | 11:54 |
| lkcl | i'd say yes - additional tests can be added as things progress | 11:54 |
| lkcl | oh, just to make sure, can you add a test for some sv.LD/ST-indexed ? i don't think there are any (test_pysvp64dis.py) | 11:55 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 11:58 | |
| lkcl | urrrr there's over 800 tests generated by the permutations, sigh | 12:01 |
| lkcl | that alphabetical sorting is going to be important! | 12:01 |
| lkcl | ghostmansd[m], ah - found a missing permutation: sv.bc/m=r3/sz | 12:04 |
| ghostmansd[m] | On it | 12:05 |
| ghostmansd[m] | By missing you mean error? | 12:05 |
| lkcl | yes. | 12:06 |
| lkcl | git pull | 12:06 |
| lkcl | need to also sort out alphabetical order | 12:06 |
| lkcl | ok added specifiers.sort() and actually (duh) put the /x/y/z options *in* alphabetical order in test_pysvp64dis.py | 12:14 |
| lkcl | (git pull) | 12:14 |
| ghostmansd[m] | Oh, cool | 12:17 |
| ghostmansd[m] | Will check soon | 12:17 |
| ghostmansd[m] | Thanks! | 12:17 |
| lkcl | - sv.bc/m=r3/snz 12,*1,0xc | 12:19 |
| lkcl | ? ----- | 12:19 |
| lkcl | + sv.bc/snz 12,*1,0xc | 12:19 |
| lkcl | that could just as well be because sv/trans/svp64.py isn't doing its job correctly. | 12:19 |
| lkcl | will investigate | 12:19 |
| lkcl | branch is marked as 2P which it can't be (i think that's because there's a src BI and a dest CTR) | 12:21 |
| lkcl | which is an error back in sv_analysis.py | 12:21 |
| ghostmansd[m] | I'll work on ld/st idx tests then | 12:29 |
| ghostmansd[m] | And then will finally move to binutils | 12:29 |
| lkcl | ack, good idea | 12:37 |
| *** ckie <ckie!~ckie@user/cookie> has quit IRC | 12:39 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 12:51 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:51 | |
| *** yambo <yambo!~yambo@69.146.1.110> has quit IRC | 12:51 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 12:51 | |
| *** mx08 <mx08!~mx08@user/mx08> has quit IRC | 12:51 | |
| *** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC | 12:51 | |
| *** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has quit IRC | 12:51 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 12:52 | |
| *** ckie <ckie!~ckie@user/cookie> has joined #libre-soc | 12:52 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 12:54 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 12:54 | |
| *** yambo <yambo!~yambo@69.146.1.110> has joined #libre-soc | 12:54 | |
| *** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has joined #libre-soc | 12:54 | |
| *** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc | 12:54 | |
| *** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 12:54 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc | 12:54 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 12:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:55 | |
| *** yambo <yambo!~yambo@69.146.1.110> has quit IRC | 12:55 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC | 12:58 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC | 12:58 | |
| *** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC | 12:58 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 12:58 | |
| *** psydroid <psydroid!~psydroid@user/psydroid> has quit IRC | 12:58 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 13:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:00 | |
| *** yambo <yambo!~yambo@69.146.1.110> has joined #libre-soc | 13:00 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC | 13:01 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc | 13:08 | |
| *** octavius <octavius!~octavius@251.183.115.87.dyn.plus.net> has joined #libre-soc | 13:10 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc | 13:11 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 13:14 | |
| *** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc | 13:27 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 13:28 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:28 | |
| ghostmansd | lkcl, I'm not quite sure what we need to test for LDST. The instructions themselves? All specifiers except for VLi and zz are already covered. | 13:30 |
| ghostmansd[m] | I'll add zz and vli. | 13:36 |
| ghostmansd[m] | We don't support VLi in assembly, though. Should this be /vli | 13:37 |
| ghostmansd[m] | ? | 13:37 |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc | 13:37 | |
| lkcl | there just aren't any instructions lbux 0,1,2 in the unit tests for example | 13:55 |
| lkcl | or lharx | 13:55 |
| lkcl | sv.lharx | 13:55 |
| ghostmansd[m] | Aaah | 13:59 |
| ghostmansd[m] | OK got it | 13:59 |
| ghostmansd[m] | Will add instructions | 13:59 |
| ghostmansd[m] | I've just added vli | 13:59 |
| lkcl | excellent | 14:05 |
| ghostmansd | lkcl, am I right that branch supports m/dm/sm and w/dw/sw specifiers? | 14:21 |
| ghostmansd | and, also, are these supported by CR ops? | 14:28 |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc | 14:29 | |
| ghostmansd | OK, I totally forgot that sw/ew bits are reused in branches. | 14:52 |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC | 14:58 | |
| ghostmansd | What does it have, then? Only dm=? Or m= which only affects RM.mask? | 15:04 |
| ghostmansd | OK, I've sorted this. The latter. | 15:15 |
| ghostmansd | The last commits add vli (both asm and dis) plus tests for it, and refactor the specifiers so that they work with branches and anything else. | 15:17 |
| markos | ok, some more progress, now to figure out how memory works | 15:26 |
| markos | File "/home/markos/src/openpower-isa/src/openpower/decoder/isa/mem.py", line 119, in st | 15:26 |
| markos | raise exc | 15:26 |
| markos | openpower.decoder.isa.mem.MemException: ('unaligned', 'Unaligned access Error') | 15:26 |
| markos | In order to pass a buffer to a function, I set a fixed pointer (eg 0x100000) and I copy the bytes manually from the original buffer to the destination | 15:27 |
| markos | and just update the elements of the initial_mem dict, address: value | 15:28 |
| markos | ah wait | 15:28 |
| markos | I'm doing byte copies, but it needs steps of 64-bits | 15:29 |
| markos | as I'm filling the memory map with unaligned addresses... | 15:29 |
| markos | ok makes sense | 15:29 |
| markos | ok it runs :) | 15:32 |
| ghostmansd | lkcl, we already check LDST in test_7_batch | 16:01 |
| ghostmansd | should I drop more there? some ideas? | 16:02 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:18 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:28 | |
| markos | it's still running, no errors yet, but it's taking a loooong time | 16:29 |
| markos | it's taking less than a second to run native | 16:29 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.166.110> has joined #libre-soc | 16:29 | |
| markos | but no errors yet | 16:29 |
| markos | and no assertions that values differ between ref and simulated function | 16:29 |
| markos | it's still Power and not SVP64 but it's running through the simulator, SVP64 is next | 16:30 |
| *** zemaye <zemaye!~zemaye@31-209-215-224.dsl.dynamic.simnet.is> has joined #libre-soc | 16:43 | |
| lkcl | very cool | 17:16 |
| lkcl | yes i did say, memory accesses all have to be 8-byte-aligned. | 17:17 |
| lkcl | ghostmansd[m], wha-hey! sv/bc/pm=r3 works! | 17:17 |
| lkcl | ghostmansd[m], wha-hey! sv/bc/m=r3 works! | 17:17 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.166.110> has quit IRC | 18:31 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.213> has joined #libre-soc | 18:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.213> has quit IRC | 18:37 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:37 | |
| lkcl | ghostmansd[m], i split out the biiiig pysvp64dis branch tests into its own file. it's over 1,000 combinations (!). mad. mad i say. | 18:53 |
| ghostmansd[m] | Whoa | 18:58 |
| ghostmansd[m] | Madness | 18:58 |
| lkcl | lists = [[None, 'all'], | 19:01 |
| lkcl | [None, 'm=r3', 'sz', 'snz'] | 19:01 |
| lkcl | [None, 'vs', 'vsi', 'vsb', 'vsbi'], | 19:01 |
| lkcl | [None, 'ctr', 'cti'], | 19:01 |
| lkcl | [None, 'sl'], | 19:01 |
| lkcl | [None, 'slu'], | 19:01 |
| lkcl | [None, 'lru'], | 19:01 |
| lkcl | results in... 2*2*2*3*5*4*2 options | 19:02 |
| lkcl | 960 | 19:02 |
| lkcl | also needed are the b, ba, bl, bla, bc bca bcl bcla, bclr bclrl, bcctr, bcctrl, bctar, bctarl combinations | 19:03 |
| lkcl | urp :) | 19:04 |
| programmerjake | > Speaking of languages, it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability. the industry should declare those languages as deprecated. | 19:22 |
| programmerjake | -- Mark Russinovich, CTO of Microsoft Azure | 19:22 |
| programmerjake | https://twitter.com/markrussinovich/status/1571995117233504257 | 19:23 |
| ghostmansd[m] | Ok, I'm following this man's advice, it's Microsoft, no reason not to believe. :-) | 19:32 |
| ghostmansd[m] | lkcl, for l/a stuff, these are available on a top level, but on PPC records, these are synthetic. | 19:33 |
| programmerjake | well, even if you don't like Microsoft, they're far from the only well known software company that recommends Rust | 19:34 |
| ghostmansd[m] | Perhaps you recall this crappy chunk of code, with names "mangling". | 19:34 |
| ghostmansd[m] | Well, I simply don't understand why you think it's gonna persuade someone. | 19:34 |
| ghostmansd[m] | You know my opinion on Rust. | 19:34 |
| ghostmansd[m] | The fact that some guy from M$ recommends it won't change it. | 19:35 |
| programmerjake | i don't think just that quote will persuade you, but imho lots of people would be convinced to think about writing code in Rust because of that, as well as all the other Rust-related news | 19:37 |
| ghostmansd[m] | I don't even think these quotes change anything, at all. | 20:18 |
| ghostmansd[m] | I choose the language based on real projects which I like. | 20:18 |
| ghostmansd[m] | Or, at least, find interesting. | 20:18 |
| ghostmansd[m] | On the other hand, I'd hardly choose some project written in Rust. :-) | 20:19 |
| programmerjake | firefox? | 20:19 |
| ghostmansd[m] | Because, why? There's already an alternative written in normal language. | 20:19 |
| ghostmansd[m] | Frankly, I use it, but I wouldn't bother checking their code base. | 20:19 |
| ghostmansd[m] | This applies to any browser, though. | 20:20 |
| programmerjake | https://github.com/xiph/rav1e | 20:20 |
| ghostmansd[m] | And, frankly, I'm dissatisfied how Firefox looks and feels today. | 20:20 |
| markos | if you think firefox codebase is bad, try chrome :D | 20:20 |
| ghostmansd[m] | Is it because of the language? | 20:20 |
| ghostmansd[m] | Oh for sure I believe there's always something more crappy. :-) | 20:21 |
| markos | no, it's because of google | 20:21 |
| ghostmansd[m] | What really is funny is that rust fans go here and there and advocate this language. | 20:21 |
| markos | this is not funny tbh | 20:21 |
| ghostmansd[m] | You know, when I started learning C, there was no need to advocate it at all. | 20:21 |
| ghostmansd[m] | Well to some point it's annoying. | 20:22 |
| markos | I find it dangerous, rust is a tool, you use it where it's needed | 20:22 |
| ghostmansd[m] | Well yeah, this is indeed a perfectly valid and nice point. | 20:22 |
| markos | if I want to try out something fast in C, I dont' want to spend half a day satisfying the compiler because it wants to be pedantic about safety | 20:22 |
| ghostmansd[m] | I agree. | 20:22 |
| ghostmansd[m] | There's a lot of code I wouldn't write in C. | 20:22 |
| ghostmansd[m] | Despite that I kinda love it. | 20:23 |
| ghostmansd[m] | (this is not a real love, rather a Stockholm syndrome) | 20:23 |
| programmerjake | https://blog.torproject.org/announcing-arti/ | 20:23 |
| markos | I would like to learn rust, but I wouldn't just switch everything to it, even if I had the time/money to do it | 20:23 |
| markos | because there is no point in doing that | 20:23 |
| markos | and it would be as boring as any monoculture | 20:24 |
| ghostmansd[m] | > Why write Tor in Rust? | 20:24 |
| ghostmansd[m] | Stopped reading at this point | 20:24 |
| ghostmansd[m] | Indeed, why? | 20:24 |
| ghostmansd[m] | Ok checked below | 20:25 |
| ghostmansd[m] | Lol | 20:25 |
| ghostmansd[m] | First off: Don't use Arti for real privacy yet. | 20:25 |
| programmerjake | that's what they say about any new crypto codebase -- don't use it yet, they're not done ensuring it's secure | 20:25 |
| ghostmansd[m] | Ok, so few paragraphs about how shitty C is, and then conclusion: don't use our whistles and bells. :-) | 20:25 |
| ghostmansd[m] | "Eventually we'll do it right" | 20:26 |
| programmerjake | reasons to use rust for tor: multithreaded crypto | 20:26 |
| ghostmansd[m] | Anything is doable in C | 20:26 |
| programmerjake | rust has built-in type checking that ensures multithreading is done correctly, C doesn't and C's missing that means large multi-threaded programs are much harder to write because of that | 20:27 |
| ghostmansd[m] | If you voluntarily put your dick in the closing door and pinch it, it's not the door to blame. | 20:28 |
| markos | programmerjake, reg. rav1e, it's faster than all the av1 encoders, but at the sake of quality | 20:28 |
| programmerjake | ghostmansd[m]: Anything is doable in Assembly too | 20:28 |
| ghostmansd[m] | Yep, treat C as fast-development assembly in this regard | 20:28 |
| programmerjake | except C has more gotchas than assembly, because of things like UB | 20:29 |
| ghostmansd[m] | This is just a higher level assembler, short and simple | 20:29 |
| ghostmansd[m] | Yes, for the sake of portability | 20:29 |
| markos | ghostmansd[m], exactly that | 20:29 |
| markos | high level assember | 20:29 |
| markos | it allows you to do even stupid things, just for the sake of it | 20:29 |
| ghostmansd[m] | markos, I for a moment thought you meant the door's passage :-) | 20:29 |
| markos | :D | 20:30 |
| ghostmansd[m] | I mean, I know C limitations | 20:30 |
| ghostmansd[m] | I've been developed with it for years | 20:30 |
| ghostmansd[m] | If you attempt to persuade me C is not perfect, — well, that I know | 20:30 |
| markos | neither is rust for that matter | 20:31 |
| ghostmansd[m] | Yep | 20:31 |
| markos | there is no such thing as a perfect language | 20:31 |
| ghostmansd[m] | And anything else | 20:31 |
| ghostmansd[m] | Yep! | 20:31 |
| programmerjake | Rust isn't perfect, but it's much better in most the places where C has issues | 20:31 |
| ghostmansd[m] | looks like we're totally on the same page with markos | 20:31 |
| ghostmansd[m] | Yehyeh, same with Python, it's much better in other places. | 20:31 |
| ghostmansd[m] | Or Go. | 20:31 |
| ghostmansd[m] | Or Perl. | 20:32 |
| markos | I don't dislike rust, but I wouldn't choose it myself except very specific usecases | 20:32 |
| ghostmansd[m] | Or any shitty language I might implement. | 20:32 |
| ghostmansd[m] | So what? | 20:32 |
| ghostmansd[m] | Go and use it. | 20:32 |
| markos | for that matter, if I had to choose a *new* language I would try Zig | 20:32 |
| programmerjake | imho Rust is much better in the places where C or Python have issues | 20:32 |
| markos | python is popular because it's easy to develop and deliver quickly | 20:33 |
| markos | you can't do that with Rust, period | 20:33 |
| ghostmansd[m] | https://youtu.be/pWdd6_ZxX8c | 20:33 |
| markos | it has a very very steep learning curve | 20:33 |
| programmerjake | imho Zig falls for C/C++'s gotchas, with optional bounds checking and no lifetime checking | 20:33 |
| markos | it has multiple levels for that matter | 20:33 |
| ghostmansd[m] | This is about opinions | 20:33 |
| markos | if you have to use such stuff, you can use D | 20:33 |
| ghostmansd[m] | Yep | 20:33 |
| ghostmansd[m] | Some even used it | 20:33 |
| ghostmansd[m] | As yet another better C | 20:34 |
| markos | no, this is a fact, Rust has a much steeper learning curve | 20:34 |
| ghostmansd[m] | This was reply to programmerjake :-) | 20:34 |
| ghostmansd[m] | About opinions | 20:34 |
| markos | I used to develop in D, even maintained ldc for Debian for a few years | 20:34 |
| markos | I really liked the language | 20:34 |
| ghostmansd[m] | But well, perhaps some people find Rust simpler, who knows | 20:34 |
| markos | sadly the developers of D failed in marketing | 20:34 |
| ghostmansd[m] | I cannot predict anyone's deviations | 20:34 |
| markos | it was much older than Rust, also much better than C in some aspects | 20:35 |
| markos | but their insistence on licensing, or on keeping things like GC by default -that changed but much much later | 20:35 |
| programmerjake | in my experience, if you know Rust, it is much higher speed of writing code for large projects when compared to Python, because Rust is designed specifically to make it difficult to accidentally mess up your system architecture | 20:35 |
| markos | meant that the effort was split in 3 (d compiler, ldc, gdc) | 20:35 |
| programmerjake | it has tons of features specifically designed for large code bases that Python is severely lacking | 20:36 |
| markos | if you know *any* language well, you can be productive at a high speed | 20:36 |
| markos | heck, even Cobol is used in very very large codebases even now | 20:37 |
| markos | I tried Cobol, a few years ago, it's awful | 20:37 |
| markos | just because people use a language on large scale projects, doesn't mean the language is good, just that the tooling helps | 20:37 |
| markos | let's not confuse these things | 20:38 |
| programmerjake | well, lkcl and I apparently know Python well, but due to Python's lack of the large-systems features that Rust has, our project has a huge amount of code rot and is very difficult to refactor | 20:38 |
| markos | Java is used on multi-million lines of code projects, because of the tooling, doesn't mean the language is good | 20:38 |
| markos | code-rot is also possible in rust | 20:39 |
| programmerjake | didn't say it isn't, but code rot is much less of an issue in Rust because modifications that would cause code rot usually cause compile errors so whoever is making those changes have to fix the errors by keeping other parts up-to-date | 20:40 |
| programmerjake | there are other reasons too | 20:40 |
| markos | I have to say, while I don't dislike Rust, discussing about its merits all the time here, and having it pushed as hard by you as the perfect solution, has the opposite effect, I kind of miss any will to learn it | 20:41 |
| programmerjake | whereas Python you only find out months later when you run whatever code-rotted code in a new and interesting way | 20:41 |
| markos | no it isn't, code rot is dependent on the developers and the teams supporting a project and the policies they follow, it has very little to do with the language itself | 20:42 |
| programmerjake | well, sorry, making you dislike Rust is not my intention | 20:42 |
| markos | just because you may be a thorough and meticulous developer doesn't mean that every one in every company is | 20:43 |
| markos | pretty sure you can find sloppy code in Rust too | 20:43 |
| programmerjake | even if you have few tests, Rust does a better job of dealing with code rot. | 20:43 |
| ghostmansd[m] | > well, sorry, making you dislike Rust is not my intention | 20:43 |
| ghostmansd[m] | Well you practically do it | 20:43 |
| ghostmansd[m] | Because I'm frankly fed up with these "let's move to Rust" from all corners around :-D | 20:44 |
| programmerjake | ok, i'll quit talking about rust now then | 20:44 |
| ghostmansd[m] | It's not really your fault | 20:44 |
| ghostmansd[m] | But rather the fact that there's too much hype | 20:44 |
| markos | no, don't do that, but you could do it for a particular usecase | 20:44 |
| markos | and you have to take into account that you may be the only one supporting it as you're pretty much the single Rust developer here -afaik | 20:45 |
| ghostmansd[m] | (please don't start with this code base though, I don't believe it'll be more readable) | 20:45 |
| ghostmansd[m] | lkcl keeps silence:-) | 20:45 |
| markos | having said that, I would very much welcome a speed increase in the simulator | 20:46 |
| ghostmansd[m] | lkcl, aren't you the biggest Rust fan ever? | 20:46 |
| programmerjake | lkcl's probably distracted by pack/unpack | 20:46 |
| ghostmansd[m] | Yeah I know, but it'd be fun to invite him to the party :-D | 20:47 |
| ghostmansd[m] | Anyway, I agree with markos | 20:47 |
| programmerjake | well, I found an article on SIMD-ifying jpeg huffman stuff: https://blog.cloudflare.com/doubling-the-speed-of-jpegtran/ | 20:47 |
| ghostmansd[m] | I tried formulating the same, but his language was way clearer | 20:47 |
| markos | ok, after lowering the number of iterations to 20, it's finally over: | 21:08 |
| markos | [ OK ] SVP64/SumOfSquaresTest.Ref/0 (1594406 ms) | 21:08 |
| markos | [----------] 2 tests from SVP64/SumOfSquaresTest (3026232 ms total) | 21:08 |
| markos | [----------] Global test environment tear-down | 21:08 |
| markos | [==========] 2 tests from 1 test suite ran. (3026232 ms total) | 21:08 |
| markos | [ PASSED ] 2 tests. | 21:08 |
| markos | previously the tests were doing 100 & 256 iterations resp. | 21:08 |
| markos | this is again to prove that running the function inside the simulator works, it's still Power assembly | 21:08 |
| markos | but the function is pretty trivial to do in SVP64 so shouldn't be that hard | 21:09 |
| markos | ok, committed everything so far, the PoC pypowersim_wrapper code and the libvpx test code using that wrapper, next step is fill in the actual SVP64 code | 21:17 |
| markos | but should be much simpler now | 21:17 |
| markos | if someone wants to use the simulator from within C, take a look at pypowersim_wrapper_example.c and pypowersim_wrapper_common.h | 21:18 |
| markos | I tried to make it modular so that part of the code can be reused | 21:18 |
| markos | please don't change this code, as I'm not finished with it yet | 21:18 |
| markos | lkcl, ^ | 21:20 |
| markos | as promised, no binaries were committed :) | 21:21 |
| markos | got this when I pushed: | 21:22 |
| markos | remote: warning: unrecognized negative pattern: '/*' | 21:22 |
| markos | remote: warning: disabling cone pattern matching | 21:22 |
| markos | is it safe to ignore? | 21:22 |
| programmerjake | iirc that just means that the partial checkout used for the wiki underlay has bad patterns, you should be safe to ignore it | 21:23 |
| programmerjake | sparse checkout | 21:23 |
| markos | ok | 21:24 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 21:37 | |
| programmerjake | meeting in 13min | 21:47 |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc | 22:49 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 22:58 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!