AndyK wrote:
>>Ahh, so. "Deterministic timing" is whatever the compiler **gives** you,
>>whether it gives 10 cycles to code a loop, or 25 - whether a C instruction
>>gets coded into 1 cycle or 8. Slowly it's coming across.
>
>
>Maybe the definition of "determinism" is the problem.  It simply means that I
>know ahead of time how long something takes, whether 5 or 50 cycles (or 6/51 in
>certain cases).
>
>It means nothing about the identical timing of some routine(s).
>
>If I need to make something ALWAYS take the same amount of time, I adjust the
>generated code so it does.  That is a special case of determinism.
>
>Deterministic behavior means it will always come to a (correct) answer.  It can
>also have time limitations added to it if you like.
>


Andy, I think you painted yourself into a corner. With C, if you
change just one instruction, the timing may be 10s of cycles different.
This is not deterministic. Fiddling with the C, counting the #cycles
in the assembler output, and iterating endlessly just doesn't seem
especially elegant or efficient.

Best to know both C and assembler, and use the latter when you
need an exact number of cycles.

I think it's time to retract your initial statement that C can produce
deterministic code - don't you think? [come'on , give up already - I
need to do some work today - even if it is monday].

cheers,
- danM

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu