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.
I have a doubt regarding the simulator/debugger tool. In the window displaying the code, one can see that the left-most column would be highlighted green once the line of code is executed. My doubt is, if the code of a particular function is for example the following : void example(char abc){ //Line 1 /*some code*/ } is Line 1 suppose to be executed ? (Will the left column of that particular line be highlighted green?) Interestingly, my observation is that some of the functions in my program has it's first line highlighted while some don't when I execute my program. I am also experiencing weird behavoir when the first line of the function is not executed (ie highlighted green). Using the above example, I call the function .... example(1); .... and pass in a value of 1 as the parameter abc. However, when my program runs to the function code itself, the value of char abc is not 1 eventhough the value passed in is clearly a 1. I might be missing out something. Could anyone possibly provide some reasons for this unexplained behavior. Thank you.
MOV DPTR,#abc MOV A,R7 MOVX @DPTR,A
There is nothing 'weird' about what happens. an example a variable is - by the keil standard - transferred in R7. The function need R7 for other purposes and thus move the variable to R2. The debugger is thus informed that R2 hold the value of the variable. SO, till the variable is moved to R2, the debugger does not 'know' what it is. If Keil either could charge $10.000 for the software - or - sold 100.000 copies per year I would consider your 'problem' a complaint. But if you expect every little detail to be 'perfect' you need to switch to using high volume software only. What is so friggin problematic about not seing the value of a variable till you are a step or two into a function? Erik
Perhaps I wasnt clear in my explaination. The problem I have is that the I do not see the value of the variable at all, not even after a step or two into the function. The thread I created was not meant to be a complaint but to share with others an unexpected behavior and hopefully someone can provide some opinions why this happen. Although it might be difficult to pinpoint a problem, any constructive comments is appreciated. Anyway, to make my case clearer, the segment of code I displayed in my previous post is something which is suppose to be there but was missing in my assembly output. Hence as a result, my variable abc was not the value passed in as it should be.
void example(char abc){ //Line 1 /*some code*/ } I call the function .... example(1); .... If example() does not use abc for anything, the debugger will not be able to 'see' it since no code refer to it. Erik
Thank you for your response. Yes I did actually use variable abc within the function itself. But unfortunately the value does not tally. Other than that, I have also observed that certain lines of code in the function are ommited (for no reasons that I know of) when I run my debugger. Meantime I am still working on this problem. Any suggestions are welcomed.
Meantime I am still working on this problem. Any suggestions are welcomed. Set the optimizer level to 1 and see if you can see everything in the debugger. The C51 compiler is an optimizing compiler and is able to figure out if code has no net effect. Similarly, some optimization levels can obfuscate the assembly code associated with a line (or lines) of C code. Jon
I have, on occasion, said unkind words about the compiler when trying to trace things in my ICE. However, in all cases it has been the compiler being 'smart' and combining code which makes the ICE go "huh?". In those cases I have learned just to follow a step ot two in assembly rather than C. I have learned to live with and expect these tricks when using the default optimization and now we are friends again. It would be totally wrong to optimize at different levels for debug and production (you never know what will happen) so there are 3 options: total source compliance in the ICE - slow bulky code optimal optimization - next to impossible ICE stepping default optimization - an excellent compromise. Erik
The problem I have is that the I do not see the value of the variable at all, not even after a step or two into the function. To find out what exactly happened, you will have to supply a good deal more detail about what exactly you did. As in: show a complete, compilable example, and tell exactly how you built it, what method you're using to debug it, and what you're doing to find out the value of that variable. In particular: is your method prepared for the case that 'abc' may never be moved out of the registers? Have even bothered to look at the assembly listing or the debugger's disassembly window? the segment of code I displayed in my previous post is something which is suppose to be there No, it's not. You were expecting it to be there, but that expectation is founded on a lack of understanding of what the compiler is doing, especially as you switch on optimization.
"Have [you] even bothered to look at the assembly listing or the debugger's disassembly window?" Note that some of the higher optimisations in the latest Keil version are performed by the Linker; ie, the Linker modifies the code after it is generated by the compiler. Therefore, the assembler shown in the Compiler listing may not actually match the code that you are debugging! You really do need to look at the debuger's disassembly listing to understand what's going on!
Note that some of the higher optimisations in the latest Keil version are performed by the Linker; ie, the Linker modifies the code after it is generated by the compiler. Which virtually makes debugging impossible. If you, like me, follow the NASA paradigm "fly what you debug" you simply can not use these optimizations. Erik PS, I am not 'bashing' the existence of the above, just giving an opinion.
You really do need to look at the debuger's disassembly listing to understand what's going on! Yes. Well, either that or that new-fangled "linker code listing" thingy which comes with those optimization levels.
Note that some of the higher optimisations in the latest Keil version are performed by the Linker; ie, the Linker modifies the code after it is generated by the compiler. Interesting dilemma. I'm with Erik, if the compiler listing does not match the executing code how will someone (probably me) find those pesky little undesirable features that seem to arise ... after release ... in large projects. Unless I am really strapped for space, I only let the compiler optimize and skip the LX linker.
if the compiler listing does not match the executing code how will someone (probably me) find those pesky little undesirable features that seem to arise Congratulations, you've just re-discovered the reason why LX51, which does those kinds of optimization, comes with its own listing option ("linker code listing" on the listings page of uV2).