Tuesday, 2022-09-20

*** zemaye <zemaye!~zemaye@31-209-215-224.dsl.dynamic.simnet.is> has joined #libre-soc00:01
*** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC00:14
ghostmansdHm. Branch modes relied on bc_svstep which I dropped (it's always 0).00:17
ghostmansdAnd 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 IRC00:20
*** zemaye <zemaye!~zemaye@31-209-215-224.dsl.dynamic.simnet.is> has quit IRC00:20
ghostmansdfor sv.bc/all 12,*1,0xc00:29
ghostmansdsvp64_rm 0x42400 0b00000100001001000000000000:29
ghostmansdsvp64_rm 0x82400 0b00001000001001000000000000:29
ghostmansdpreviously it used to set bit 1800:30
ghostmansdnow it sets bit 1900:30
ghostmansd18 is SLu, 19 is mode[0]00:30
ghostmansdAnd to me it looks setting 19 is correct00:31
ghostmansdOK 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_lru00:39
ghostmansd-            destwid = (bc_lru << 1) | bc_all00:39
ghostmansdIt 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 IRC00:53
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc01:03
lkclyes, remember i had to stop working on sv.bc as it was taking too long01:10
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC01:26
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc01:27
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc01:41
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC02:16
*** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc06:32
*** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC07:21
lkclprogrammerjake, good to see you caught up that there's too much to do in such a short timespan08:19
lkclmeans picking the task very carefully.08:19
lkclabsolute max of 60-100 lines of assembler, one function only08:19
lkclif 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
markoslkcl, 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 flattened10:27
lkclmarkos, no there isn't.10:28
markosok, no biggie10:28
lkclnot that i know of.10:28
markosok, 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 it10:30
markosI'm going to commit this first and then work on the actual vp910:30
markosI'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 errors10:30
markosit's slow but it's not that slow as if emulating the whole program10:31
markosfeel free to suggest a different name, pypowersimwrapper_example.c maybe?10:33
lkclpffh, we're traditionally terrible at names in this project :)10:54
lkclghostmansd[m], rebase good10:54
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc11:14
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC11:17
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc11:17
ghostmansdlkcl, if one puts /snz, it won't be correct to output /snz/sz in disassembly, right?11:21
ghostmansdEven though /sz ends up being set, too11:21
ghostmansdyeah seems like this11:27
ghostmansd[m]Pushed. Do we consider 917 completed?11:44
lkclcorrect it wouldn't11:54
lkcli'd say yes - additional tests can be added as things progress11:54
lkcloh, 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 IRC11:58
lkclurrrr there's over 800 tests generated by the permutations, sigh12:01
lkclthat alphabetical sorting is going to be important!12:01
lkclghostmansd[m], ah - found a missing permutation: sv.bc/m=r3/sz12:04
ghostmansd[m]On it12:05
ghostmansd[m]By missing you mean error?12:05
lkclgit pull12:06
lkclneed to also sort out alphabetical order12:06
lkclok added specifiers.sort() and actually (duh) put the /x/y/z options *in* alphabetical order in test_pysvp64dis.py12:14
lkcl(git pull)12:14
ghostmansd[m]Oh, cool12:17
ghostmansd[m]Will check soon12:17
lkcl- sv.bc/m=r3/snz 12,*1,0xc12:19
lkcl?       -----12:19
lkcl+ sv.bc/snz 12,*1,0xc12:19
lkclthat could just as well be because sv/trans/svp64.py isn't doing its job correctly.12:19
lkclwill investigate12:19
lkclbranch 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
lkclwhich is an error back in sv_analysis.py12:21
ghostmansd[m]I'll work on ld/st idx tests then12:29
ghostmansd[m]And then will finally move to binutils12:29
lkclack, good idea12:37
*** ckie <ckie!~ckie@user/cookie> has quit IRC12:39
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC12:51
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC12:51
*** yambo <yambo!~yambo@> has quit IRC12:51
*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC12:51
*** mx08 <mx08!~mx08@user/mx08> has quit IRC12:51
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC12:51
*** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has quit IRC12:51
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc12:52
*** ckie <ckie!~ckie@user/cookie> has joined #libre-soc12:52
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc12:54
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc12:54
*** yambo <yambo!~yambo@> has joined #libre-soc12:54
*** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has joined #libre-soc12:54
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc12:54
*** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc12:54
*** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc12:54
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC12:55
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC12:55
*** yambo <yambo!~yambo@> has quit IRC12:55
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC12:58
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC12:58
*** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC12:58
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC12:58
*** psydroid <psydroid!~psydroid@user/psydroid> has quit IRC12:58
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc13:00
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc13:00
*** yambo <yambo!~yambo@> has joined #libre-soc13:00
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC13:01
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc13:08
*** octavius <octavius!~octavius@> has joined #libre-soc13:10
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc13:11
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc13:14
*** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc13:27
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC13:28
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc13:28
ghostmansdlkcl, 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 /vli13:37
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc13:37
lkclthere just aren't any instructions lbux 0,1,2 in the unit tests for example13:55
lkclor lharx13:55
ghostmansd[m]OK got it13:59
ghostmansd[m]Will add instructions13:59
ghostmansd[m]I've just added vli13:59
ghostmansdlkcl, am I right that branch supports m/dm/sm and w/dw/sw specifiers?14:21
ghostmansdand, also, are these supported by CR ops?14:28
*** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc14:29
ghostmansdOK, I totally forgot that sw/ew bits are reused in branches.14:52
*** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC14:58
ghostmansdWhat does it have, then? Only dm=? Or m= which only affects RM.mask?15:04
ghostmansdOK, I've sorted this. The latter.15:15
ghostmansdThe 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
markosok, some more progress, now to figure out how memory works15:26
markos File "/home/markos/src/openpower-isa/src/openpower/decoder/isa/mem.py", line 119, in st15:26
markos    raise exc15:26
markosopenpower.decoder.isa.mem.MemException: ('unaligned', 'Unaligned access Error')15:26
markosIn 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 destination15:27
markosand just update the elements of the initial_mem dict, address: value15:28
markosah wait15:28
markosI'm doing byte copies, but it needs steps of 64-bits15:29
markosas I'm filling the memory map with unaligned addresses...15:29
markosok makes sense15:29
markosok it runs :)15:32
ghostmansdlkcl, we already check LDST in test_7_batch16:01
ghostmansdshould I drop more there? some ideas?16:02
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC16:18
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC16:28
markosit's still running, no errors yet, but it's taking a loooong time16:29
markosit's taking less than a second to run native16:29
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:29
markosbut no errors yet16:29
markosand no assertions that values differ between ref and simulated function16:29
markosit's still Power and not SVP64 but it's running through the simulator, SVP64 is next16:30
*** zemaye <zemaye!~zemaye@31-209-215-224.dsl.dynamic.simnet.is> has joined #libre-soc16:43
lkclvery cool17:16
lkclyes i did say, memory accesses all have to be 8-byte-aligned.17:17
lkclghostmansd[m], wha-hey! sv/bc/pm=r3 works!17:17
lkclghostmansd[m], wha-hey! sv/bc/m=r3 works!17:17
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:31
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc18:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:37
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc18:37
lkclghostmansd[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
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
lkclresults in... 2*2*2*3*5*4*2 options19:02
lkclalso needed are the b, ba, bl, bla, bc bca bcl bcla, bclr bclrl, bcctr, bcctrl, bctar, bctarl combinations19:03
lkclurp :)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 Azure19:22
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
programmerjakewell, even if you don't like Microsoft, they're far from the only well known software company that recommends Rust19: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
programmerjakei 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 news19: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
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
ghostmansd[m]And, frankly, I'm dissatisfied how Firefox looks and feels today.20:20
markosif you think firefox codebase is bad, try chrome :D20: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
markosno, it's because of google20:21
ghostmansd[m]What really is funny is that rust fans go here and there and advocate this language.20:21
markosthis is not funny tbh20: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
markosI find it dangerous, rust is a tool, you use it where it's needed20:22
ghostmansd[m]Well yeah, this is indeed a perfectly valid and nice point.20:22
markosif 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 safety20: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
markosI would like to learn rust, but I wouldn't just switch everything to it, even if I had the time/money to do it20:23
markosbecause there is no point in doing that20:23
markosand it would be as boring as any monoculture20:24
ghostmansd[m]> Why write Tor in Rust?20:24
ghostmansd[m]Stopped reading at this point20:24
ghostmansd[m]Indeed, why?20:24
ghostmansd[m]Ok checked below20:25
ghostmansd[m]First off: Don't use Arti for real privacy yet.20:25
programmerjakethat's what they say about any new crypto codebase -- don't use it yet, they're not done ensuring it's secure20: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
programmerjakereasons to use rust for tor: multithreaded crypto20:26
ghostmansd[m]Anything is doable in C20:26
programmerjakerust 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 that20: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
markosprogrammerjake, reg. rav1e, it's faster than all the av1 encoders, but at the sake of quality20:28
programmerjakeghostmansd[m]: Anything is doable in Assembly too20:28
ghostmansd[m]Yep, treat C as fast-development assembly in this regard20:28
programmerjakeexcept C has more gotchas than assembly, because of things like UB20:29
ghostmansd[m]This is just a higher level assembler, short and simple20:29
ghostmansd[m]Yes, for the sake of portability20:29
markosghostmansd[m], exactly that20:29
markoshigh level assember20:29
markosit allows you to do even stupid things, just for the sake of it20:29
ghostmansd[m]markos, I for a moment thought you meant the door's passage :-)20:29
ghostmansd[m]I mean, I know C limitations20:30
ghostmansd[m]I've been developed with it for years20:30
ghostmansd[m]If you attempt to persuade me C is not perfect, — well, that I know20:30
markosneither is rust for that matter20:31
markosthere is no such thing as a perfect language20:31
ghostmansd[m]And anything else20:31
programmerjakeRust isn't perfect, but it's much better in most the places where C has issues20:31
ghostmansd[m]looks like we're totally on the same page with markos20: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
markosI don't dislike rust, but I wouldn't choose it myself except very specific usecases20: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
markosfor that matter, if I had to choose a *new* language I would try Zig20:32
programmerjakeimho Rust is much better in the places where C or Python have issues20:32
markospython is popular because it's easy to develop and deliver quickly20:33
markosyou can't do that with Rust, period20:33
markosit has a very very steep learning curve20:33
programmerjakeimho Zig falls for C/C++'s gotchas, with optional bounds checking and no lifetime checking20:33
markosit has multiple levels for that matter20:33
ghostmansd[m]This is about opinions20:33
markosif you have to use such stuff, you can use D20:33
ghostmansd[m]Some even used it20:33
ghostmansd[m]As yet another better C20:34
markosno, this is a fact, Rust has a much steeper learning curve20:34
ghostmansd[m]This was reply to programmerjake :-)20:34
ghostmansd[m]About opinions20:34
markosI used to develop in D, even maintained ldc for Debian for a few years20:34
markosI really liked the language20:34
ghostmansd[m]But well, perhaps some people find Rust simpler, who knows20:34
markossadly the developers of D failed in marketing20:34
ghostmansd[m]I cannot predict anyone's deviations20:34
markosit was much older than Rust, also much better than C in some aspects20:35
markosbut their insistence on licensing, or on keeping things like GC by default -that changed but much much later20:35
programmerjakein 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 architecture20:35
markosmeant that the effort was split in 3 (d compiler, ldc, gdc)20:35
programmerjakeit has tons of features specifically designed for large code bases that Python is severely lacking20:36
markosif you know *any* language well, you can be productive at a high speed20:36
markosheck, even Cobol is used in very very large codebases even now20:37
markosI tried Cobol, a few years ago, it's awful20:37
markosjust because people use a language on large scale projects, doesn't mean the language is good, just that the tooling helps20:37
markoslet's not confuse these things20:38
programmerjakewell, 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 refactor20:38
markosJava is used on multi-million lines of code projects, because of the tooling, doesn't mean the language is good20:38
markoscode-rot is also possible in rust20:39
programmerjakedidn'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-date20:40
programmerjakethere are other reasons too20:40
markosI 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 it20:41
programmerjakewhereas Python you only find out months later when you run whatever code-rotted code in a new and interesting way20:41
markosno 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 itself20:42
programmerjakewell, sorry, making you dislike Rust is not my intention20:42
markosjust because you may be a thorough and meticulous developer doesn't mean that every one in every company is20:43
markospretty sure you can find sloppy code in Rust too20:43
programmerjakeeven 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 intention20:43
ghostmansd[m]Well you practically do it20:43
ghostmansd[m]Because I'm frankly fed up with these "let's move to Rust" from all corners around :-D20:44
programmerjakeok, i'll quit talking about rust now then20:44
ghostmansd[m]It's not really your fault20:44
ghostmansd[m]But rather the fact that there's too much hype20:44
markosno, don't do that, but you could do it for a particular usecase20:44
markosand 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 -afaik20: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
markoshaving said that, I would very much welcome a speed increase in the simulator20:46
ghostmansd[m]lkcl, aren't you the biggest Rust fan ever?20:46
programmerjakelkcl's probably distracted by pack/unpack20:46
ghostmansd[m]Yeah I know, but it'd be fun to invite him to the party :-D20:47
ghostmansd[m]Anyway, I agree with markos20:47
programmerjakewell, 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 clearer20:47
markosok, 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-down21:08
markos[==========] 2 tests from 1 test suite ran. (3026232 ms total)21:08
markos[  PASSED  ] 2 tests.21:08
markospreviously the tests were doing 100 & 256 iterations resp.21:08
markosthis is again to prove that running the function inside the simulator works, it's still Power assembly21:08
markosbut the function is pretty trivial to do in SVP64 so shouldn't be that hard21:09
markosok, 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 code21:17
markosbut should be much simpler now21:17
markosif someone wants to use the simulator from within C, take a look at pypowersim_wrapper_example.c and pypowersim_wrapper_common.h21:18
markosI tried to make it modular so that part of the code can be reused21:18
markosplease don't change this code, as I'm not finished with it yet21:18
markoslkcl, ^21:20
markosas promised, no binaries were committed :)21:21
markosgot this when I pushed:21:22
markosremote: warning: unrecognized negative pattern: '/*'21:22
markosremote: warning: disabling cone pattern matching21:22
markosis it safe to ignore?21:22
programmerjakeiirc that just means that the partial checkout used for the wiki underlay has bad patterns, you should be safe to ignore it21:23
programmerjakesparse checkout21:23
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc21:37
programmerjakemeeting in 13min21:47
*** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc22:49
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC22:58

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!