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.

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

"Stephen Pelc" <s...@mpeforth.com> wrote in message 
news:45537c89.91198578@192.168.0.50...
> On Thu, 9 Nov 2006 18:09:42 -0000, "Tom Lucas"
> <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> 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 :-)
>
> How much are you prepared to pay? I have colleagues with 30 years
> experience from embedded design through database-driven websites
> (and connecting them together). They report pay rates have fallen
> because managers are scared to hire people aged 50+. Do you
> want good or cheap? I know everyone wants both, but ...
>
> Stephen
> Where? When? required experience?

I would be particularly interested in someone 50+ to be honest but, in 
these days of anti-discrimination, of course I didn't say that. I'm 
quite flexible on pay scales for the right person but most CVs I've seen 
are asking between £30 and £35 an hour which is fine but I don't know 
how much of that is the agencys' cut. That's contract rates though, if 
someone wanted a permanent position then I'd probably offer up to £40K + 
pension + private health etc. depending on experience.

The job is in near Catford in South London and will move to Biggin Hill 
in the second quarter next year. It's in a small R&D department and I 
initially need someone experienced enough to pick up and run with a 
80188/Z8 Encore based product straight away to cover sickness. Once the 
original staff member returns from sick then there would still be a 
permanent job available for the right person which would be mainly 
Analogue/Digital design, PCB layout and EMC/environmental qualification. 
The initial contract would probably be for about 3 months if the 
candidate prefers to take the contracting route in.

The specs I've been asking for are:
10+ years hardware experience with both analogue and digital design.
PCB Layout for multi-layer surface mount boards.
Power Supply Design
Designing hardware for a safety critical enviroment.
3+ years of software experience (C & C++) for embedded microcontrollers 
(specifically 80188 and Z8) in a safety critical environment.

It would also be very nice if the candidate were to have experience in:
Use of Seetrax Ranger for Schematic capture
Use of Cadence Specctra for PCB layout.
Use of Paradigm C/C++ compiler for 80188
USe of Noral SDT-X emulator.

If you know anyone who fits the bill then please let them know because I 
am looking for someone ASAP. My e-mail is tlucas at autoflame dot com 
and my direct line is oh eight four five eight seven two two oh two 
nine. 

rTrenado wrote:
> 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.
> 
> 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...
> 

You seem to be misunderstanding the way C is specified, and the way C 
compilers work.  C is described in terms of a virtual C machine, and the 
compiler must generate code that is consistent in measurable 
functionality with that machine.  That does not mean it has to generate 
object code to match the source code - just that it must generate code 
that has the same effect.  There is absolutely no requirement for a 
compiler to generate run-time computation to initialise automatic 
variables - but it must act as though it does.

And it is not a matter of optimisation flags - the compiler is allowed 
to do all the optimisation it wants, regardless of any flags.  The flags 
are merely hints, asking the compiler to spend time generating tighter 
code, or to generate weaker code that may be easier to debug.  But they 
are hints, not demands.

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

No one is assuming anything about the code after the dots, since we 
don't know what it contains.

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

I think that is reading too much into the question.  But even if z is 
used later on, there is no requirement for the compiler to have 
initialised it to 3 at the breakpoint.  It is quite possible for it to 
be initialised later, just before it is used.  That would be 
particularly practical if the same register is used for other purposes, 
in which case the debugger will report an incorrect value (assuming it 
is not smart enough to know that z is not "alive").

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

Op Fri, 10 Nov 2006 09:53:56 +0100 schreef David Brown  =

<d...@westcontrol.removethisbit.com>:
> Tom Lucas wrote:
>> "Eric" <e...@hotmail.com> wrote in message  =

>> news:1...@m73g2000cwd.googlegroups.com...
>>> [...]

>> 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. The=
re  =

> are plenty of mistakes in the following code:
>
>
> uint16 msecsCounter;
>
> void timerFunc(void) {		// Called by timer interrupt
> 	msecsCounter++
> }
>
> void delay10(void) {
> 	uint16 startTime =3D msecsCounter;
>
> 	while (1) {
> 		if (msecsCounter > (startTime + 10)) return;
> 	}
> }

There's only one mistake with this code.  If you're using an OS and the =
 =

kernel+BSP doesn't provide basic timing and delay functionality, then yo=
u  =

should reconsider using this kernel or get someone to write a proper BSP=
.   =

If you're not using an OS then you should consider using a well-written =
 =

and re-usable piece of code to accomplish basic timing and delay.



-- =

Gemaakt met Opera's revolutionaire e-mailprogramma:  =

http://www.opera.com/mail/

Tom Lucas <news@remove_auto_this_flame_to_reply.clara.co.uk> wrote:
> someone wanted a permanent position then I'd probably offer up to ?40K + 
> pension + private health etc. depending on experience.

Being blunt about it, that wouldn't be enough to tempt a lot of people
South. 40k is less than good seniors and principals are making in the
North, and taking into account cost of living isn't remotely attractive 
for London. Unless you can find someone who's not in need of relocation
I think you're aiming a bit low.

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

"Pete Fenelon" <p...@fenelon.com> wrote in message 
news:q...@stratos.fenelon.com...
> Tom Lucas <news@remove_auto_this_flame_to_reply.clara.co.uk> wrote:
>> someone wanted a permanent position then I'd probably offer up to 
>> ?40K +
>> pension + private health etc. depending on experience.
>
> Being blunt about it, that wouldn't be enough to tempt a lot of people
> South. 40k is less than good seniors and principals are making in the
> North, and taking into account cost of living isn't remotely 
> attractive
> for London. Unless you can find someone who's not in need of 
> relocation
> I think you're aiming a bit low.

We were certainly hoping to not have to relocate someone. Are you sure 
people are on more than 40K? I reckoned that that was about the going 
rate for someone with 10 or so years experience, in fact a little over 
even for London. Has there been a big jump in the average recently? 

Boudewijn Dijkstra wrote:
> Op Fri, 10 Nov 2006 09:53:56 +0100 schreef David Brown 
> <d...@westcontrol.removethisbit.com>:
>> Tom Lucas wrote:
>>> "Eric" <e...@hotmail.com> wrote in message 
>>> news:1...@m73g2000cwd.googlegroups.com...
>>>> [...]
> 
>>> 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;
>>     }
>> }
> 
> There's only one mistake with this code.  If you're using an OS and the 
> kernel+BSP doesn't provide basic timing and delay functionality, then 
> you should reconsider using this kernel or get someone to write a proper 
> BSP.  If you're not using an OS then you should consider using a 
> well-written and re-usable piece of code to accomplish basic timing and 
> delay.
> 

That's perhaps true, but completely beside the point (although a good 
embedded programmer can write such busy-waiting delay loops faster than 
they can search websites or documentation to find ready-written code, 
and they can write it correctly first time round).  This is an example 
for an interview question, remember.

Op Fri, 10 Nov 2006 13:29:27 +0100 schreef David Brown  =

<d...@westcontrol.removethisbit.com>:
> Boudewijn Dijkstra wrote:
>> Op Fri, 10 Nov 2006 09:53:56 +0100 schreef David Brown  =

>> <d...@westcontrol.removethisbit.com>:
>>> Tom Lucas wrote:
>>>> "Eric" <e...@hotmail.com> wrote in message  =

>>>> news:1...@m73g2000cwd.googlegroups.com...
>>>>> [...]
>>
>>>> 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 =3D msecsCounter;
>>>
>>>     while (1) {
>>>         if (msecsCounter > (startTime + 10)) return;
>>>     }
>>> }
>>  There's only one mistake with this code.  If you're using an OS and =
 =

>> the kernel+BSP doesn't provide basic timing and delay functionality, =
 =

>> then you should reconsider using this kernel or get someone to write =
a  =

>> proper BSP.  If you're not using an OS then you should consider using=
 a  =

>> well-written and re-usable piece of code to accomplish basic timing a=
nd  =

>> delay.
>
> That's perhaps true, but completely beside the point (although a good =
 =

> embedded programmer can write such busy-waiting delay loops faster tha=
n  =

> they can search websites or documentation to find ready-written code, =
 =

> and they can write it correctly first time round).  This is an example=
  =

> for an interview question, remember.

Yes, and the purpose of the interview is not only to find out whether th=
e  =

candidate is skilled in writing code, but also (but not limited to)  =

reading code.  In particular, whether the candidate can recognize the  =

usefullness of code fragments in certain contexts.  Knowing the  =

usefullness of a collection of known good re-useable code versus writing=
  =

code yourself, indicates how well the candidate knows his own skill and =
 =

how he can use this knowledge to his own advantage.

So the point is not whether the candidate can point out all the little  =

mistakes, but whether the candidate can recognize that the fragment is  =

_bad_ and whether he knows how to find the best way to transform it into=
  =

something acceptable.

Nevertheless, my original answer will most likely be the beginning of my=
  =

answer, if and when the question will ever arise during an interview.


-- =

Gemaakt met Opera's revolutionaire e-mailprogramma:  =

http://www.opera.com/mail/

David Brown wrote:

> 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;
> 	}
> }

Of course, atomic access is typically only a problem for this code on 8
bit systems.

The code above also has an issue when the timer wraps around.

I agree it would be interesting to see a candidate find and fix these
problems, as well as the obvious "volatile" that's missing.

A recommendation to add an OS to solve this problem wouldn't score any
bonus points for me. There are many cases where a full-fledged OS is
overkill, and embedded programmers need to be able to fix this, and
similar, code themselves.

Arlet wrote:
> David Brown wrote:
> 
>> 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;
>> 	}
>> }
> 
> Of course, atomic access is typically only a problem for this code on 8
> bit systems.
> 
> The code above also has an issue when the timer wraps around.
> 
> I agree it would be interesting to see a candidate find and fix these
> problems, as well as the obvious "volatile" that's missing.
> 

You spotted all the problems that apply on small embedded systems. 
There may be other issues on big cpus ("volatile" doesn't necessarily 
work as you would like when you have caches, out-of-order execution, 
parallel processing, etc.) - but then you really do want to use an OS 
and make the issues into SEPs.  For small micros, it is a common mistake 
to think that "volatile" gives you atomic access, when obviously it does 
not.

> A recommendation to add an OS to solve this problem wouldn't score any
> bonus points for me. There are many cases where a full-fledged OS is
> overkill, and embedded programmers need to be able to fix this, and
> similar, code themselves.
>