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

[Jason Proctor]

>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


At 1:27 PM -0500 11/23/10, Amos wrote:
>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.
>

#pragma convert_to_posting_style(bottom)

clever-looking code == hard to read, rarely clever-working code, 
often written in such a way to ensure job security ;-)