[sdiy] Organisation of tasks in synth's main uP

[Amos]

I love writing really "clever-looking" c code that works a whole
complex branching operation into a single (on-screen) line of source.

My compiler thinks I'm not so hot though, and seldom/never does as
well with this kind of input as when I think about opcodes and write c
in a more lined-out way, where each c statement only "says" one or two
lines-of-code.  I'm learning not to be so fancy as a result.

Back to the original question, I'm a big fan of RTOS for synths. Fits
very well and allows a lot of flexibility.  There are some challenges
merging run-loop and interrupt-driven approaches to resource use; I
use flags and simple state machines to make sure everyone is playing
nicely.


On 11/23/10, grant at musictechnologiesgroup.com
<grant at musictechnologiesgroup.com> wrote:
>> pro-question time: in assembly, I rely heavily on the overflow bit
>> being set to detect wrap-around, e.g. in 8-bit registers.  But these
>> days I program mainly in C and I can't figure out how to access that
>> overflow bit.
>> I have gone so far as to use 7-bit numbers and treat the MSB as an
>> overflow, but does anyone know how to read the CPU's overflow bit from
>> C?
>
> Admittedly it hurts at first moving to C (and procedural methods). I
> don't think you want to look at the overflow bit. It's too hardware and
> compiler dependent. The nice thing about C, when used "properly" is that
> the code really is quite portable.  I think in order to really benefit
> from C you need to allow yourself to accept the spirit of it. Same goes
> for C++ -- if you don't adopt the spirit you just keep writing C and
> missing out on the great benefits.  So I would say to try and think at a
> slightly higher level. "There are no CPU flags". The penalty is minimal
> and the benefits huge. Just use a for or while loop and get creative
> with the start and/or end conditions. If that's not intuitive try moving
> up to an unsigned int or doing an extra C statement before or after the
> loop.  Using an unsigned int now and then shouldn't be a barrier. If
> it's a local variable the compiler will recapture the variable space and
> the difference in execution speed probably one uS. I also try to avoid
> being "too clever".  If it's hard to understand now, it will be way hard
> later when you go back to revisit that code.
>
> GB
>
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>

-- 
Sent from my mobile device