Jim Stewart <j...@jkmicro.com> wrote:
> 
> Is "your tools are broke" an acceptable answer?
> 

One of many, but *how* might they be broken? ;)

pete
-- 
p...@fenelon.com "he just stuck to buying beer and pointing at other stuff"

Tom Lucas wrote:

> Maybe I can get one right....
> 1) With certain optimisers then the value of z may not be assigned until 
> it is used.
> 2) z may not get used elsewhere and get completely optimised out.

To which the interviewer may reply, "Why are you attempting to debug
software that hasn't been compiled for debugging?" ;)

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>;
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

In article <1...@h48g2000cwc.googlegroups.com>,
 "rTrenado" <R...@Rocketmail.com> 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.

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. 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.

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.

On 2006-11-10, Pete Fenelon <p...@fenelon.com> wrote:
> Jim Stewart <j...@jkmicro.com> wrote:
>> 
>> Is "your tools are broke" an acceptable answer?
>> 
>
> One of many, but *how* might they be broken? ;)

And how does one go about fixing them.  They are all
open-source, right?

-- 
Grant

Eric wrote:
> The company I work for is in the process of interviewing several
> > Any other ideas for interview questions?

Please visit this URL . It contains simple questions to make sure the
candidate is good at embedded systems.

h t t p://www.embedded.com/2000/0005/0005feat2.htm

Regards,
Visweswara R

David Kelly wrote:
> In article <1...@h48g2000cwc.googlegroups.com>,
>  "rTrenado" <R...@Rocketmail.com> 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.
> 
> 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. 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.
> 
> 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.

There is also no requirement that x or y exist at all, and nothing is 
said about where they might be placed (register or stack, or even hidden 
in main memory if you have a brain-dead cpu combined with a smart compiler).

People in this thread keep suggesting things like compiling without 
optimisation, and seem to believe that this will force the compiler to 
translate each code line into literally equivalent assembly.  That is 
quite simply not the case, though it may often seem like it in practice. 
  Optimisation flags are merely hints to the compiler (until you get to 
the level of flags allowing the compiler to make extra assumptions which 
change the C semantics).  Additionally, the debugger is allowed to be 
smart, and work with a smart compiler to give you logically correct 
results that are completely imaginary (such as showing z with the value 
3, even if it is optimised away).


Anyway, the answer to the original question is that you are using a 
cheapo two-bit compiler, and z is -1.

On Thu, 09 Nov 2006 18:09:42 +0000, Tom Lucas wrote:


> Is the UK currently experiencing a surplus of jobs for engineers? I'm 
> currently recruiting a contractor/permanent hardware engineer and I've 
> had several not even bother to turn up for the interview. This would 
> imply that there are so many jobs available that they are not having to 
> put any effort into finding them. Or perhaps they just take one look at 
> the rough estate our premises are on and turn around :-)

Might be an agency problem? 

Just this week an agent offer me an interview for a contract position. I
asked to be emailed the full job spec but didn't get it....

I picked up a message yesterday "confirm interview and then I can send you
full details of the job". What???

I have also had an agent tell absolute white lies about a job. All became
clear at the interview. Total waste of time.

Then there are the offers for interview out of the blue, where your cv
gets forwarded even though you didn't give permission to be sent to that
company. A few years back, I did actually receive a few spam emails
that included CVs from one particular agent.

And then there are the agents that when you tell them you would
like to be forwarded for a job, you never hear from them again.

Agents, don't you just love 'em. ;-)

Tom Lucas wrote:
> "Eric" <e...@hotmail.com> wrote in message 
> news:1...@m73g2000cwd.googlegroups.com...
>> The company I work for is in the process of interviewing several
>> embedded software candidates.
>>
>> What types of questions could we ask to make sure the interviewee is 
>> an
>> embedded software candidate and not just a high level CS major?
>>
>>
>> We've asked questions about whether they would feel more comfortable
>> doing low level drivers or application level stuff? The usual answer 
>> we
>> get is "I can do all of that"..... No, most people are better suited
>> for one or the other... many can do both, but that person usually has
>> strengths in one or the other.
>>
>> Another sample questions is "What steps would you have to go through 
>> to
>> set up an interrupt on a mirco?"
>>
>> Any other ideas for interview questions?
> 
> Ask them to explain where you would use a volatile variable. That's 
> always a good test to see if they've been paying attention. 
> 

Atomic access and mixing interrupt and main routine data is another 
goodie - some people mistakenly think adding "volatile" is enough. 
There are plenty of mistakes in the following code:


uint16 msecsCounter;

void timerFunc(void) {		// Called by timer interrupt
	msecsCounter++
}

void delay10(void) {
	uint16 startTime = msecsCounter;

	while (1) {
		if (msecsCounter > (startTime + 10)) return;
	}
}

visweswara wrote:
> Eric wrote:
>> The company I work for is in the process of interviewing several
>>> Any other ideas for interview questions?
> 
> Please visit this URL . It contains simple questions to make sure the
> candidate is good at embedded systems.
> 
> h t t p://www.embedded.com/2000/0005/0005feat2.htm

Kind of casts doubt on the rest of the questions and answers when the
answer to the first one is so far out.


-- 
Paul

"Mark McDougall" <m...@vl.com.au> wrote in message 
news:4553c68f$0$3045$5...@per-qv1-newsreader-01.iinet.net.au...
> Tom Lucas wrote:
>
>> Maybe I can get one right....
>> 1) With certain optimisers then the value of z may not be assigned 
>> until
>> it is used.
>> 2) z may not get used elsewhere and get completely optimised out.
>
> To which the interviewer may reply, "Why are you attempting to debug
> software that hasn't been compiled for debugging?" ;)

To which I might answer "It only fails when optimisation is turned on 
and I can compile debug support in with the optimisation on so that 
would be a good place to start." Of course this assumes that the code 
was not working but, more realistically, at this point in the interview 
I'd have become tired of trick questions and would have quietly changed 
the subject and re-evaluated why I wanted to work for someone who was 
more interested in catching me out than listening to the things I could 
offer the company ;-)