Re: Interview Embedded Software Questions


David Kelly wrote:
In article <1163096563.161393.88220@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"rTrenado" <ReneT@xxxxxxxxxxxxxx> wrote:

One thing is for certain, z should be 3 or the compiler is broken
period. Although this is NOT 100% true if we talk about the debugger!

In C:

...
int x=1;
int y=2;
int z;

are "local" defined variables ( even for main() ), they live in the
stack "assigned" to the function. Since x and y are initialized
statically we can assume that they do live in the stack (or scratch
registers depending on the compiler of course), z on the other hand
could be located in a register for optimization purposes, that is why a
Debugger wouldnt be able to catch Z as a variable...

You've made so many assumptions that you are going to have to unlearn
some things to go forward.

The compiler doesn't have to be broken at all. If there is any kind of
optimization taking place there is no rule that the compiler has to
evaluate expressions in the order give. Without "volatile" there is no
rule that the compiler has to evaluate the expression at all if it
notices z is never used anywhere else.

You are wrong here, "volatile" is not required when you are telling the
compiler to evaluate two objects with automatic storage duration as in
the statement "x+y" (after int x = 1 and such). Remember that volatile
is a type qualifier ONLY not a expression qualifier. Also keep in mind
that all computation for automatic initialization is done at execution
time, if those automatic storage objects are used then the code MUST be
executed, unless you are using compiler optimizations to get rid of
this (another assumption by the way). Dont believe me?, keep reading...


Even if z is used, but the compiler can tell that its only used as a
constant, no memory or register has to be allocated. The compiler will
simply slip a constant "3" in place of z.

z = 3, as I stated in my previous post. z = 3 and thats it, that is
what the programmer intended to, if this doesnt happen then the
compiler could be broken.

Also, the original post placed dots after the breakpoint implying more
code after it so we will never know if z is only used as a constant or
not ( one more assumtion )...

How is the debugger to know?
How does the debugger handle a reference which does not exist? The
original question was, "At the breakpoint, z does not equal 3. Why?" The
question doesn't state that a value was found for z, only that the
debugger doesn't report z = 3.


Careful there, the question: "At the breakpoint, z does not equal 3.
Why?" it means that if z does not equal 3 it equals to something else
implying that Z is there!!!!

gcc 3.4 with optimization enabled will reorder code and confuse many
unknowing users trying to single step with a debugger. Metrowerks C for
HC12 will reorder the executable code even more aggressively. The basic
order you write in the code is still honored but it will do things such
as reorder switch statements and hopscotch between to reuse common code.
And will delete code which does nothing but burn CPU cycles.

Totally agree with you here, and now that you mention it, try to
compile the following code for an HC12 in Codewarrior using all the
defaults on the wizard for a SIMULATION target:

#include <hidef.h> /* common defines and macros */
#include <mc9s12dp256.h> /* derivative information */

#pragma LINK_INFO DERIVATIVE "mc9s12dp256b"

void main(void) {

int x = 1;
int y = 2;
int z;

z = x + y;

/* put your own code here */
EnableInterrupts;
for(;;) {} /* wait forever */
}

run it in the debugger, you will see automatic storage in action and NO
volatile keyword needed, and if you read the assembly code carefully...
you will see that z=3.

Rene

.

Relevant Pages

  • Re: Interview Embedded Software Questions
    ... Although this is NOT 100% true if we talk about the debugger! ... int x=1; ... The compiler doesn't have to be broken at all. ... if those automatic storage objects are used then the code MUST be ...
    (comp.arch.embedded)
  • Re: Interview Embedded Software Questions
    ... Although this is NOT 100% true if we talk about the debugger! ... int x=1; ... The compiler doesn't have to be broken at all. ... If there is any kind of optimization taking place there is no rule that the compiler has to evaluate expressions in the order give. ...
    (comp.arch.embedded)
  • Re: Interview Embedded Software Questions
    ... z should be 3 or the compiler is broken ... Although this is NOT 100% true if we talk about the debugger! ... int x=1; ... could be located in a register for optimization purposes, ...
    (comp.arch.embedded)
  • Re: Interview Embedded Software Questions
    ... Although this is NOT 100% true if we talk about the debugger! ... int x=1; ... The compiler doesn't have to be broken at all. ... HC12 will reorder the executable code even more aggressively. ...
    (comp.arch.embedded)
  • [PATCH 04/37] Separate the gdbstub from the debug core
    ... kernel debugger exception logic and to the gdbstub.c which contains ... the logic for allowing gdb to talk to the debug core. ... -static int write_mem_msg ...
    (Linux-Kernel)