C program Time delay help!

But that isn't really any delay loops. You normally don't need an exact delay but a minimum delay

You're playing with words. A minimum delay is still a delay.

There is normally a nop intrinsic that the compiler knows it must not remove, even when running at high optimization levels.

<devils advocate>
So, all the talk in all those threads saying software delays are bad because they get optimized out is bunk.
</devils advocate>

And, while I'm at it, simulators can be very useful for checking software delays, especially on something like an older '51 core. Not for real time deduction of the delay, but for viewing cycle times and determining the absolute (minimum) delay at a given frequency.

I prefer to use software delays when they are the most appropriate way to achieve a goal.

But that isn't really any delay loops. You normally don't need an exact delay but a minimum delay

You're playing with words. A minimum delay is still a delay.

There is normally a nop intrinsic that the compiler knows it must not remove, even when running at high optimization levels.

<devils advocate>
So, all the talk in all those threads saying software delays are bad because they get optimized out is bunk.
</devils advocate>

And, while I'm at it, simulators can be very useful for checking software delays, especially on something like an older '51 core. Not for real time deduction of the delay, but for viewing cycle times and determining the absolute (minimum) delay at a given frequency.

I prefer to use software delays when they are the most appropriate way to achieve a goal.

Playing with words? I'm not the one who felt a need to write "fool" indicating that your main interest wasn't to push the debate forward.

And it is a play with words if you think my text tried to explain the use of nop for wait state generation as "not delay".

Do your devil's advocate if you like - I have brought up the use of the nop intrinsic in a number of threads without the need for anyone to first jump in with any "fool" statement.

A problem with software delays in a high-level language is that even when not optimized away, you can still suffer large variation in minimum time as cascaded result of how the compiler/linker operates. With C51, much of the optimization happens in the linker, which is quite unique, and the linker may split or merge code when it sees identical sequences of code in other functions even from other source modules. It may also switch between memory regions for variables.

With most other compilers, you normally only need to perform a manual validation if you modify the delay code, change compilation options, change memory speed settings, changes core speed or changes compiler version.

With C51, you also have to be prepared to verify that delay after every code change anywhere in the program, because of how the linker operates. And because of changes to register/variable mappings/reuse as a result of the call tree analysis performed. Most processors uses a real stack, while C51 plays with multiple memory regions with different access methods.

But all this is still irrelevant, since you activated Don Quixote mode by reading "always prefer" as meaning "only acceptable". And the thread can't be constructive until you decide to leave Don Quixote mode.

Playing with words? I'm not the one who felt a need to write "fool" indicating that your main interest wasn't to push the debate forward.

And it is a play with words if you think my text tried to explain the use of nop for wait state generation as "not delay".

Do your devil's advocate if you like - I have brought up the use of the nop intrinsic in a number of threads without the need for anyone to first jump in with any "fool" statement.

A problem with software delays in a high-level language is that even when not optimized away, you can still suffer large variation in minimum time as cascaded result of how the compiler/linker operates. With C51, much of the optimization happens in the linker, which is quite unique, and the linker may split or merge code when it sees identical sequences of code in other functions even from other source modules. It may also switch between memory regions for variables.

With most other compilers, you normally only need to perform a manual validation if you modify the delay code, change compilation options, change memory speed settings, changes core speed or changes compiler version.

With C51, you also have to be prepared to verify that delay after every code change anywhere in the program, because of how the linker operates. And because of changes to register/variable mappings/reuse as a result of the call tree analysis performed. Most processors uses a real stack, while C51 plays with multiple memory regions with different access methods.

But all this is still irrelevant, since you activated Don Quixote mode by reading "always prefer" as meaning "only acceptable". And the thread can't be constructive until you decide to leave Don Quixote mode.

???