↙ time adjusted for second-chance
BIO: The Bao I/O Coprocessor (bunniestudios.com)
I loved this article and had wanted to play with PIO for a long time (or at least, learn from it through playing!). One thing jumped out here - I assumed CISC inside PIO had a mental model of "one instruction by cycle" and thus it was pretty easy to reason about the underlying machine (including any delay slots etc...). For this RISC model using C, we are now reasoning about compiled code which has a somewhat variable instruction timing (1-3 cycles) and that introduces an uncertainty - the compiler and understanding its implementation. I think this means that the PIO is timing-first, as timing == waveform where BIO is clarity-first with C as the expression and then explicit hardware synchronization. I like both models! I am wondering about the quantum delays however that are being used to set the deadlines - here, human derived wait delays are utilized knowledge of the compiled instructions to set the timing. Might there not be a model of 'preparing the next hardware transaction' and then 'waiting for an external synchronization' such as an external signal or internal clock, so we don't need to count the instruction cycles so precisely. On the external signal side, I guess the instruction is 'wait for GPIO change' or something, so the value is immediately ready (int i = GPIO_read_wait_high(23) or something) and the external one is doing the same, but synchronizing (GPIO_write_wait_clock( 24, CLOCK_DEF)) as an alternative to the explicit quantum delays. This might be a shadow register / latch model in more generic terms - prep the work in shadow, latch/commit on trigger. Anyway, great work Bunnie!
> And no one in the security business seems to consider the overall burden of yet another step. Each of which is simple in by itself, but cumulatively they are a giant hassle, and so people look for workarounds. This is certainly not true. I personally consider how much friction things introduce for users, things like normalizing having to reenter your password too much making phishing easier, and so on. It's well understood that you will get shadow IT, which is worse, if you make doing things the right way too difficult. I regularly advocate for streamlining processes and procedures, introducing more user-friendly systems, hosting office hours where the security team is available for any question or concern you have making us more available to the company, etc. What's the issue? Well, for one, there's a ton of incompetent people in the field, so they'll just do whatever to make themselves look like they're working. Two, most security departments are criminally understaffed, so even if you have competent people they just have to put things together quickly and can't clean it up. Three, there's tons of idiotic regulatory and legal requirements that take forever to modernize. And finally, half of security is playing politics and arguing with the rest of the company, meaning that half the time the solutions you get are a slop of compromise with which nobody is happy. TL;DR we aren't psychopaths without empathy, we struggle for the same reasons you developers have tech debt and other things that suck even though you would prefer not to.
 Top