2 ms·

I feel like something like that would be worth writing in assembly directly anyway, wouldn't it? And with C you usually don't need to give up compiler optimizat

I feel like something like that would be worth writing in assembly directly anyway, wouldn't it? And with C you usually don't need to give up compiler optimization entirely, just carve out the specific sections. By that I mean that since you're sitting on a pretty thin abstraction anyway when you're on microcontrollers, doesn't it make sense to code the parts that require piercing the abstraction using the toolset that sits below the abstraction?

whatshisface 8y ago
Let's say it took 50us to compute the next value, but the circuit only needed the next value to show up at the register in 100us. If you were writing it all in C you couldn't time it at all (except maybe by trial and error). If you wrote just that one routine in assembly, you would have to wait for 50us after every loop doing nothing. If you were writing it all in assembly (abandoning C entirely), you could stick random instructions from elsewhere in the program into the 50us window of extra time. If instead of C there was a language that let you specify timing, the compiler could either wait or if it was smarter do that optimization automatically. Over time as new optimizations like that were invented the same code could become even better (completing the non-real-time tasks faster while still meeting timing deadlines), and if a new microcontroller was introduced the same code might still work. That's an example of the benefits of keeping implicit "you have to know how the compiler works" stuff out of your languages. (Pragmatically, you have to poke through the abstraction because what you have in real life is C. However if we recognize this as an opportunity to do better we might reach the ideal in the future.)