We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
In one of my project I am talking with MX909 Driver IC with C51 ucontroller. To initialize MX909 if I write module in Assembly language it's working fine. Once I replaced with C same module it's not working.
The only difference I can make for both assembly and C languages is NOP and _nop_() instruction. Is both instructions will take same number of machine cycles?
Thanks, Suresh Kumar Kavula
Erik,
Thanks for your quick response. By using keil C I am trying to generate 2.4uSeconds delay by writing 4 _nop_() instructions. For this I am using I am using AT89C5131, X1 clock Mode with 20 MHZ.
Same C routine if I replace 4 NOP instructions by using #pragma ASM working fine.
I don't know what the reason is.
ONCE MORE
LOOK AT THE ASM GENERATED BY THE COMPILER!!
Erik
Yes, disassembly generating NOP instructions only for each _nop_() instruction.
It seems problem in some where else.
Thanks a lot Erik for your help.
Yes, disassembly
That is just too cumbersome a method, why not use the .lst file?. Or to be real fancy do a 'test compile' with #pragma SRC
"Yes, disassembly generating NOP instructions only for each _nop_() instruction"
I should hope so too - that's exactly what it is defined to do: http://www.keil.com/support/man/docs/c51/c51__nop_.htm
However, this is where any code-generation guarantee ends!
It is fundamental to the nature of High-Level Languages (HLLs; including 'C') that you have absolutely no control whatsoever over the code that will be generated by the compiler.
Therefore, although the _nop_() Intrinsic Function is guaranteed to insert a single NOP instruction, you have absolutely no control whatsoever over the rest of the code that will be generated around the _nop_() "call".
Therefore, you must use an assembler routine if you need a predictable delay!
Or to be real fancy do a 'test compile' with #pragma SRC
I'd advise extra care with that approach. There's no guaranteed whatsoever that the code output in #pragma SRC mode is the same as otherwise.
The only reliable ways to find out what the compiler did are the list file, absolute list file (if linker optimizations are enabled) and disassembler/debugger views.
"There's no guaranteed whatsoever that the code output in #pragma SRC mode is the same as otherwise."
There is also no guarantee whatsoever that the results will remain the same on subsequent re-compiles!
How many times does "no guarantee whatsoever" have to be said make the point that this is a bad idea...?
www.milinkito.com/.../bart.php
Andy,
I'm going to have to make a favourite of that one!
Thanks.