01:56 <awygle> anybody have a working I2C host module in nmigen?

01:58 <whitequark> glasgow

02:33 <awygle> ... fair

02:34 <awygle> wait that's omigen. or well, nmigen-compat

02:34 <awygle> guess it doesn't really matter tho

03:29 <whitequark> awygle: oh, i thought i ported it

03:43 <whitequark> kbeckmann: this should let you get rid of inlines https://github.com/YosysHQ/yosys/pull/2152

07:06 <kbeckmann> indeed it does! awesome.

07:10 <kbeckmann> whitequark: i made a tiny change in my test image generator and now i get 110 fps https://github.com/kbeckmann/pergola_projects/commit/ac44b60e6a7f6b7295dfc37a707d653ba84ef422

07:22 <kbeckmann> i know i'm not doing a lot of operations to generate the image, but is still blows my mind a bit that we can run this in actual real time and not even drop frames at 60fps.

08:20 <kbeckmann> i did some profiling and i am spending most time in mul_uu. it could be cool to have native implementations of these, but i realize that will require an substantial effort.

08:26 <kbeckmann> this made a significant improvement in mul_uu(): if (BitsY <= 64 && BitsA <= 32 && BitsB <= 32) { return value<BitsY>{a.data[0] * b.data[0]}; }

08:27 <kbeckmann> (60 fps in 1280x720 :o )

08:37 <kbeckmann> the code above is not correct, need to cast the values to uint64_t first. but you get the idea.

18:39 <whitequark> kbeckmann: yeah, that change would benefit the hardware greatly, too

18:39 <whitequark> strength reduction basically

18:44 <kbeckmann> ah yes, i guess i was thinking i was doing software again and relying on a compiler to optimize that.

18:49 <Sarayan> wq: You mean benefit the hardware by using specialized resources when they exist?

18:56 <whitequark> by not requiring any specialized resources

18:56 <whitequark> instead of x*[1,-1], use [x,-x]

18:56 <whitequark> so no multiplier needed

21:18 <_whitenotifier-f> [nmigen] BracketMaster opened issue #403: Records don't work in Assert - https://git.io/JfQsY

22:44 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JfQnn

22:44 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark 32c69e1 - Update to WASI SDK 11.0.

23:18 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/JfQcG

23:19 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark c5768f4 - Add CXXRTL backend to the package.

23:23 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JfQc4

23:23 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark cf45325 - Update README.

23:24 <whitequark> kbeckmann: regarding partial specialization for multiplication

23:24 <whitequark> yeah, that's a good idea! let me prepare a PR

23:29 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark pushed 8 commits to release [+2/-2/±14] https://git.io/JfQcz

23:29 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark 8796ace - Add support for [skip ci] tag in commit messages.

23:29 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark be1f1b3 - Lower Python version requirement to 3.5.

23:29 <_whitenotifier-f> [nmigen/nmigen-yosys] whitequark b91f0d5 - [skip ci] Fix incorrect comment.

23:29 <_whitenotifier-f> [nmigen/nmigen-yosys] ... and 5 more commits.

23:39 <kbeckmann> oh that's great! i tried to make a proper fix but gave up after i realized that i'm not that familiar with c++ templates. got stuck where i wanted to support >32 bits - the returned value would require two elements in the initialization which is not generic and thus failed to build for <=32 bit multiplications.

23:43 <whitequark> I was going to just skip >32 bits lol

23:43 <whitequark> can you show me your attempt? I might be able to help you with that

23:43 <whitequark> which would actually be preferable because I'm currently busy working on nmigen.back.cxxsim

23:46 <kbeckmann> for <=32 bits, i basically just did if (BitsY <= 32) { return value<BitsY>{a.data[0] * b.data[0]}; }

23:46 <whitequark> ahhh I see

23:46 <kbeckmann> overflow might get a bit nasty

23:47 <whitequark> yes that's actually not correct

23:47 <kbeckmann> mm especially if the operands are larger than 16

23:48 <kbeckmann> oh i also noticed a funky thing. it seems it's possible to create a value<24> foo{0x11223344u); where data contains the 8 "extra" MSB

23:48 <whitequark> yes

23:48 <kbeckmann> i guess i'm violating some contract here

23:48 <whitequark> and it's illegal

23:48 <whitequark> yep

23:48 <kbeckmann> alright

23:49 <whitequark> creating values directly isn't the preferred way

23:49 <whitequark> the problem is that the preferred way doesn't exist yet

23:49 <kbeckmann> what is the preferred way?

23:49 <kbeckmann> ah

23:49 <whitequark> https://github.com/YosysHQ/yosys/issues/2127

23:49 <whitequark> track this issue

23:49 <kbeckmann> thank you

23:49 <whitequark> I'll fix it soonish

23:49 <whitequark> there will be something like `.get<uint32_t>()`

23:49 <whitequark> and `.set<uint32_t>(...)`

23:49 <kbeckmann> oh that would be neat

23:49 <whitequark> the latter will assert if you're setting out of bounds