Hello. I copied "LCD_4bit.c" and "LCD.h" files from Keil examples folder to my project folder and add it to my project. Then I changed Pins definition in "LCD_4bit.c" according to my project board LCD pins(LPC 2378). (I don't think that The problem is here.) Then I could successfully Build it, but when I download it to my project board,there is no signs that LCD works. However when I compile "LCD_4bit.c" in IAR environment ,the produced "hex file" works well on my project board. Thanks for your help.
No, it isn't.
The timing of each instruction is documented - you yourself spoke of "cycle counting" earlier!
"The timing of each instruction is documented - you yourself spoke of "cycle counting" earlier!"
yes, but that doesn't mean you can predict their execution duration by looking at that piece of code alone - for reasons we have articulated earlier.
for example, in a particular compilation, the timing of each HLL "statement" is documented - you only need to look at the disassembly to confirm that.
"doesn't mean you can predict their execution duration by looking at that piece of code alone"
But you can predict the execution of that piece of code alone. And you can then make due allowance for the other effects.
"the timing of each HLL 'statement' is documented"
No, it is not - because, as you yourself agreed, you have no idea what machine code will be generated from a HLL.
It has already been agreed that you can analyse the generated code after the event. The point is that you cannot predict the timing of the HLL.
Because you cannot predict the timing of the HLL, you cannot just present a piece of HLL source and say, "this produces a delay of x".
I guess it might be possible to tie it down with an exhaustive list of tool versions, options, etc - but, as stated in the original linked post, it'd be easier to just do it in assembler in the first place!
And, as stated in the original linked post, you could very well use a HLL as your starting point in creating that assembler.
Yes, I missed the "in a particular compilation" bit.
Doesn't alter the original argument about predicting before compilation, though.
"But you can predict the execution of that piece of code alone."
I think (hope?) that we have established that. for confirmation, you could read that tamir had to say about it, for example.
"And you can then make due allowance for the other effects."
let me rephrase my HLL example then:
you can predict the executation of that piece of HLL code alone. and you can then make due allowance for the other effects.
does that mean by your own logic you should use HLL delays?
"No, it is not - because, as you yourself agreed, you have no idea what machine code will be generated from a HLL."
yes. But that doesn't mean that the code itself isn't documented - the disassembly is the place where such code is documented.
unless of course if you meant something different by your version of "document"?
"It has already been agreed that you can analyse the generated code after the event. The point is that you cannot predict the timing of the HLL."
you certainly can predict the timing of any HLL, as much as you would with assembly, before then making due allowance for the other effects.
"Because you cannot predict the timing of the HLL, you cannot just present a piece of HLL source and say, "this produces a delay of x"."
since it is on a false premise, ...
"And, as stated in the original linked post, you could very well use a HLL as your starting point in creating that assembler."
and you could very well use a HLL as your ending point as well. many applications do just that.
"you can predict the executation of that piece of HLL code alone"
No, you cannot: because you cannot predict - ie, know before compilation - what code will be generated.
"the disassembly is the place where such code is documented"
But, again, that is only available after compilation.
you can predict the executation of that piece of HLL code alone"
What I'm posting now has little to do with the choice of language (assembly, HLL), but I think that if, for example, a memory barrier is used calling any function, all assumptions about certain optimizations can fly out of the window. My conclusion? In order to make valid predictions, even in assembly, you need to be aware of many parameters (system load, memory barriers, scheduling issues if they apply, C compiler settings,...). In the end, just looking at HLL delay code might hide real faults, like loops being optimized out due to a forgotten "volatile" (certainly many here had that, when running out of ROM and needing to increase optimization level...). That's a little dangerous.
"No, you cannot: because you cannot predict - ie, know before compilation - what code will be generated."
maybe you are not talking about your definition of "predict": you probably mean predicting up to the exactly "click"?
in that case, you are right in that looking at a HLL delay loop doesn't allow you to predict its timing up to the exact click.
and you are wrong in that looking at an assembler delay loop doesn't allow you to predict its timing up to the exact click either - we have gone through that multiple times in this very thread.
"In order to make valid predictions, even in assembly, you need to be aware of many parameters (system load, memory barriers, scheduling issues if they apply, C compiler settings,...)."
agreed.
"In the end, just looking at HLL delay code might hide real faults, like loops being optimized out due to a forgotten "volatile" (certainly many here had that, when running out of ROM and needing to increase optimization level...). That's a little dangerous."
agreed too.
Looking at the HLL source does not allow you to make any prediction at all about its timing - because you cannot make any prediction about what code the compiler will generate.
"looking at a HLL delay loop doesn't allow you to predict its timing up to the exact click"
It does not not allow you to predict the timing at all.
"looking at an assembler delay loop doesn't allow you to predict its timing"
That is not necessarily true.
In summary:
In a HLL, you cannot predict the timing at all; In assembler, you might not be able to predict the timing.
Therefore, the original recommendation not to use a HLL stands.
The alternative should be qualified as, "if it can be done at all, it must be done in assembler"
"In a HLL, you cannot predict the timing at all;"
I am going to make the following prediction about the timing of any HLL delay, and I can guaranttee you that it is 100% accurate under any circumstance:
any delay, being it HLL or assembler, software or hardware, will generate a delay whose duration is between 0 and infinity
prove me wrong, please.
and totally worthless.
"totally worthless."
you insisted that no one could predict the timing and I just showed you how wrong that statement was.
but more seriously, here is a point that you have been unable to comprehend consistently: you can always predict the timing of anything. except that the tighter your tolerance, the more likely you are going to be wrong.
in the case of an assembler, baring any of the factors we discussed, you could more accurately predict the timing than you could with a HLL delay.
that statement means two things:
1) you can predict the duration of a hll delay - you may not be as accurately do so, but you can, nonetheless.
2) you can NOT predict the duration of an assembly delay with absolute accuracy. aka it is not a drop-in-and-forget-about-it scenario that you made it out to be.
think about that.
"you insisted that no one could predict the timing and I just showed you how wrong that statement was."
Not at all.
I can't predict any current just by saying that current is measured in Ampere. You have no more predicted any delay. You are just busy running around in larger and larger circles.
0 is no delay, so it isn't a delay. Hence, we can't bracket at [0..x] but must bracket at (0..x]
If 0 isn't a delay, then a delay that gets removed doesn't result in any accuracy error since you would get a division by zero - any delay guess you make would be infinitely wrong if the delay code ends up totally removed.
The big difference with the assembler in relation to the HLL implementation, is that the assembler delay always produces a delay. So it does allow us to talk about accuracy.
"think about that"
What most people are thinking is probably that this thread has ended up as random, irrelevant, noise. All because you constantly lose your focus on the important things because you don't have anything to do but to try to argue everything to death.
rubbish deleted.
"If 0 isn't a delay, then a delay that gets removed"
so your reason against using HLL delay has been moved from its (perceived) lack of "visibility" (which assembler suffers as well) now to its risk of being optimized out by a HLL compiler?
if that's the case, the solution is so rudimentarily simple that I am embarrassed that you don't know it.
No - I can still see all of your posts!