03:09 <mithro> Hey, what is whitequark's real name?

03:33 <reportingsjr> mithro: odd question :P

04:58 <sb0> I want to make a constant current source that can handle fast voltage changes at its output. is it a good idea to use a Wilson circuit with an inductor in series with the output to compensate for the Miller effect? why do I never see such an inductor in typical schematics?

05:42 <mithro> is there a way to get Xst to generate a kind of usage report for all the blocks and stuff?

06:15 <sb0> it prints it by default

09:18 <whitequark> mithro: "whitequark"

09:18 <whitequark> if you want my name on government ID the answer is different but I don't see why you need that

10:00 <cr1901_modern> sb0: What's wrong w/ a BJT and a zener on the emitter?

10:01 <cr1901_modern> erm, not the emitter, you know what I mean

10:01 <sb0> fast voltage changes on the collector couple into the base via the CB parasitic capacitance

10:03 <mithro> sb0: I mean in a hierarchical like this -> https://github.com/openrisc/mor1kx/wiki/Implementation-Statistics#Small_with_small_cache

10:04 <sb0> also, it's unstable with temperature

10:04 <sb0> matched pairs on the same chip and a current mirror configuration is more precise

10:04 <cr1901_modern> fair. was just wondering

10:05 <mithro> whitequark: was just interested, perfectly fine if you don't want to share

10:08 <whitequark> mithro: generally all my work is attributed to "whitequark" so that's far more useful

10:23 <whitequark> sb0: hm, I wonder if we have the same problem with the floating point modulo

10:25 <sb0> whitequark, that's easily tested and fixed when relevant by copying the numba code, no?

10:26 <sb0> why does circuits.io need my date of birth and country of residence to create a pcb layout?

10:26 <sb0> sigh

10:27 <whitequark> yes, just writing it down that I need to test it, really

10:27 <whitequark> oh geez yeah the fmod code is also a terrible mess

10:28 <whitequark> I am just going to make it an intrinsic in the Rust runtime

10:28 <whitequark> generating that much code every time is pointless

10:29 <sb0> doesn't this code generation that you dislike enable llvm to optimize the code in cases e.g. when the modulo is constant?

10:32 <whitequark> __divsi3 is already an intrinsic

10:32 <whitequark> oh, nevermind

10:32 <whitequark> that's not what you mean

10:45 <whitequark> sb0: here's the expanded code in python

10:45 <whitequark> div *= div; /* hide "div = +0" from optimizers */

10:45 <whitequark> what.

10:46 <whitequark> ok, let me look at it some more

10:54 <whitequark> see, every time I look further into it there's more of this mess..

10:54 <whitequark> maybe I can inline a fast path or something

13:30 <sb0> whitequark, where is that div *=.... code from?

13:30 <whitequark> your numba link, and eventually from python source

13:31 <sb0> mh?

13:31 <sb0> the implementation of % in cpython?

13:31 <whitequark> yes

13:31 <sb0> so, why not do the numba thing?

13:32 <sb0> you say it generates too much code, but I don't see much of a problem with that. won't llvm optimize it away when relevant?

13:33 <whitequark> it'll only optimize it away when folding constants, otherwise all that crap stays in

13:33 <whitequark> I'm currently playing with this code again, I think I can make it a bit less awful

13:33 <sb0> and with a C implementation there is no "crap"? which could not even be optimized away when folding constants?

13:34 <whitequark> Rust implementation, and an intrinsic is not inlined every time

13:34 <whitequark> lack of optimizing is a problem so no this shouldn't be a bare intrinsic call

19:04 <GitHub182> [smoltcp] steffengy commented on issue #43: @whitequark ... https://git.io/vdZ8j