Friday, 2023-03-17

*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC05:01
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:52
lkclok :)08:53
lkclcommit it let's have a look08:54
programmerjakeoh, btw, i realized that using all the pseudocode functions from the vsx section of the powerisa spec might not go over so well, so i'm thinking of rewriting the pseudocode for fcvt[f/t]g08:57
programmerjakeit would either be based off iirc book 1 appendix A which has suggested fp models, or just write the pseudocode without using existing fp functions08:59
programmerjakeexcept SINGLE/DOUBLE of course09:00
programmerjakei did at least check that all the vsx functions i used don't refer to any vsx-only registers afaict09:01
programmerjakelkcl & others: any comments?09:02
programmerjakethe vsx/vmx functions i used are in powerisa v3.1b book 1 sections 6.2.1 and
programmerjakeactually mostly just
markosrunning some final tests, I will commit the code so far in a while, refactored the code a bit better so that the constants are not created on every loop iteration but only at the start, so extra speedup09:32
markoslkcl, committed09:40
markosthe smaller function xchacha_hchacha20_svp64 works if used alone, when I enable (in test.c) the encrypt_bytes_svp64 function as well09:41
markosthen I'm getting failures, but *only* if I enable the quarterround macro call in src/xchacha_encrypt_bytes_svp64.s L6209:42
markoswhile at the same time I have to disable the quarterround loop in src/xchacha20.c L23109:43
markosat the end of the wrapper I'm displaying both outputs09:43
markosand in that case I'm getting the same outputs09:43
markosI thought I was doing some register clobbering but I double checked and I don't do that09:43
markosso it's something else that I'm missing09:44
markosall in all, assuming it's something easy to fix, total code size 252 SLOC, 179 without comments :)09:46
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc12:08
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:55
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc13:56
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC14:31
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc14:31
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC14:36
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc14:36
*** octavius <octavius!~octavius@2a01:4c8:807:3f72:383:6508:2386:a130> has joined #libre-soc16:52
octaviuslkcl, do you remember if there's any documented information on the ls180 test chip? The wiki page is a little sparse.16:55
octaviusIt' would be nice to get a sample running if it actually works16:55
*** octavius <octavius!~octavius@2a01:4c8:807:3f72:383:6508:2386:a130> has quit IRC17:11
lkclmarkos, if they do exactly the same job you can always run both (macro, non-macro) then diff -u the logs17:16
markoslkcl, tht's what I'm doing right now17:18
markostrying to figure out where it differs17:18
*** octavius <octavius!~octavius@2a01:4c8:807:3f72:a99:4e65:493e:98dd> has joined #libre-soc17:18
markoslkcl, is there a way to reset svstate for svindex/svshape?17:41
markosno, that's not it18:35
lkcljust don't use it. you do need to watch out for the "persistence" bit of svremap.18:54
lkclsvstate "establishes" the shapes 0-318:54
lkclsvremap says *which* shape applies to *which register* [and for how long - one instruction or all future instructions]18:55
markostrying to understand where it goes wrong, I've filled the place with prints to see what is different in pretty much every step19:20
markosI *did* find one mistake I had made, a very sneaky one19:20
markosI called the original C function on the same buffer and checked the result19:21
markoshowever, I did not notice that the XChaCha_ctx struct has a "counter" embedded19:21
markosso the actual input data in the context was different19:22
markosI only figured out compairing the register contents with the data from C19:22
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC19:41
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc19:43
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc20:00
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc20:03
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC21:31
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc21:47
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC22:20
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC22:24
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc22:31
markoslkcl, getting there:22:39
markosmsglen: 3422:39
markosee a7 c2 71 19 10 65 69 92 e1 ce d8 16 e2 0e 62 1b 25 17 82 36 71 6a e4 99 f2 97 37 a7 2a fc f8 6c 7222:39
markosee a7 c2 71 19 10 65 69 92 e1 ce d8 16 e2 0e 62 1b 25 17 82 36 71 6a e4 99 f2 97 37 a7 2a fc f8 00 2822:39
programmerjakelooks like just the last two bytes are busted...progress22:41
markosyup and just found the problem22:41
markosI store 64-bit values, using sv.std22:42
markosso I do len >> 3, and for len=34, len >> 3 = 4 -> 32 bytes22:43
programmerjakeso you forgot the remainder?22:44
markosI wonder if it's proper to just store the next 64-bit word even if not all elements are in the buffer22:45
programmerjakeyou could store to a temp storage location and copy the bytes you need, or, once elwid works you can setvl remainder-len and store bytes from the reg holding the word22:50
programmerjake(swapping needed on BE)22:50
markosLE assumed for now for simplicity22:50
markosfor now I'll just store one more word depending on size % 822:51
programmerjakewell as long as you can guarantee you're not buffer overflowing...22:52
markosyeah it's not a perfect solution22:53
markosonce we get elwidth I can do it properly then, I'll just add a TODO in the code22:53
markosno, it was even dumber than that23:05
markosthe assembly was correct23:05
markosin the wrapper I only copied 32 bytes from the pypowersim memory object to the buffer :D23:06
markosCryptographic tests passed23:21
markosfucking finally23:21
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc23:57

Generated by 2.17.1 by Marius Gedminas - find it at!