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.
HLL source code specifies what is to be done - not how it is to be done.
In particular, timing is a "how" thing.
In 'C' parlance, the "what" is referred to as Side Effects
"HLL source code specifies what is to be done - not how it is to be done."
HLL source code = "what is to be done" in a user-specified sequence <> how it is to be done?
the HLL user may not specify to the utmost detail how each step is to be done (nor do most assembly applications), but a C source code certainly specify how a task is to be done.
Whatever.
But, as you very well know, timing is totally outside the scope of the 'C' source.
"But, as you very well know, timing is totally outside the scope of the 'C' source."
depending on how you define "scope" and one can argue, not without merit, that timing is totally outside the scope of the 'assembly' source too.
not that it strengthens one's argument (for or against).
depending on how you define "scope"
Err, that would be the C standard...?
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.
"Err, that would be the C standard...?"
if you define "scope" to be within a language standard, then "scope" is undefined for assembly language as there is no such standard.
so what does it mean by saying that timing in assembly is within the scope of something that doesn't exist?
"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.