"Arlet" <usenet+5...@ladybug.xs4all.nl> writes:
> 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.

Was there any specification that the timer has to be accurate?

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

The above code isn't OS-friendly.

"Lanarcam" <l...@yahoo.fr> wrote in message
news:4554c9d4$0$32020$4...@news.free.fr...
> Wim Ton a écrit :
> > I left the UK because nobody in Scotland was interested in an over 50
> > engineer. I had to resort to contracting on the continent where I had no
> > troubles at all finding work.
> >
> Could you tell us where on the continent?

Holland, Belgium, Switserland

Wim

Wim Ton a écrit :
> "Lanarcam" <l...@yahoo.fr> wrote in message
> news:4554c9d4$0$32020$4...@news.free.fr...
>> Wim Ton a écrit :
>>> I left the UK because nobody in Scotland was interested in an over 50
>>> engineer. I had to resort to contracting on the continent where I had no
>>> troubles at all finding work.
>>>
>> Could you tell us where on the continent?
> 
> Holland, Belgium, Switserland
> 
I suspected it was not here in France since we have
the same kind of problems you had in Scotland.

Thanks.

"Lanarcam" <l...@yahoo.fr> wrote in message 
news:45561d39$0$25707$4...@news.free.fr...
> Wim Ton a écrit :
>> "Lanarcam" <l...@yahoo.fr> wrote in message
>> news:4554c9d4$0$32020$4...@news.free.fr...
>>> Wim Ton a écrit :
>>>> I left the UK because nobody in Scotland was interested in an over 50
>>>> engineer. I had to resort to contracting on the continent where I had 
>>>> no
>>>> troubles at all finding work.
>>>>
>>> Could you tell us where on the continent?
>>
>> Holland, Belgium, Switserland
>>
> I suspected it was not here in France since we have
> the same kind of problems you had in Scotland.
>

There's also no discrimination in Sweden

My job there was the first time in about 10 years
I was working with permanent staff who were older
than me.

Strangely, at my current UK posting, the same is true,
but I suspect that is due to the 'difficult' location.

tim

"You seem to be misunderstanding the way C is specified, and the way C
compilers work. "

It is not what I understand it is what the standard says. It is one
thing to discuss how the C code works (and what the standard specifies
for that matter) and the other is how an actual compiler works. You
should have that in mind before making up your point because it seems
you dont have those things clear since you also mention that:

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

It seems you dont understand what an automatic variable is, if an
automatic object needs to be initialized then there MUST be a run-time
involvement at some degree otherwise it wouldnt be automatic regardless
of how, where (RAM, register etc.) and on which order this is
performed, you must be careful there, and if your compiler is not doing
that it would be great to hear its name and the example source code on
which this is tested. Would you share that with us?

Regards
Rene

David Brown wrote:

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

"rTrenado" <R...@Rocketmail.com> wrote in message 
news:1...@k70g2000cwa.googlegroups.com...
> "You seem to be misunderstanding the way C is specified, and the way C
> compilers work. "
>
> It is not what I understand it is what the standard says. It is one
> thing to discuss how the C code works (and what the standard specifies
> for that matter) and the other is how an actual compiler works. You
> should have that in mind before making up your point because it seems
> you dont have those things clear since you also mention that:
>
> "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."
>
> It seems you dont understand what an automatic variable is, if an
> automatic object needs to be initialized then there MUST be a run-time
> involvement at some degree otherwise it wouldnt be automatic regardless

Of course there must be run-time involvement when using
an automatic variable.

The bit that might not be necessary is the initialisation.
(Hopefully, I don't need to explain why.)

tim

On Fri, 10 Nov 2006 11:25:37 +1100, Mark McDougall <m...@vl.com.au>
wrote:

>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?" ;)

If the code was not compiled for debugging, how could one put the
breakpoint between two source lines in a high level language ?

While debuggers relying solely on disassembled machine instructions
work without any compiler/assembler assistance, any HLL debugging
requires cooperation from the compiler, either as some line number
information to be associated with the source code or putting the
actual source code as "comments" into the object file.

Paul

"Paul Keinanen" <k...@sci.fi> wrote in message 
news:o...@4ax.com...
> On Fri, 10 Nov 2006 11:25:37 +1100, Mark McDougall <m...@vl.com.au>
> wrote:
>
>>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?" ;)
>
> If the code was not compiled for debugging, how could one put the
> breakpoint between two source lines in a high level language ?

The debugger that I am most experienced with will do this,
even if the line is not there.  It will put the break on the next
most machine instruction which may never be reached in
the required path, or (worse?) may be reached from paths
unassociated with the one under test because that code
line has been optimised into that path.

As you say, debugging optimised code using a source level
debugger is difficult, but it is not fundamentally impossible.

tim

l...@ieee.org wrote:

>>> 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
> 
> yeh, the define won't work it won't even compile
> 
> why does know what #error does make someone a nerd?
> 
> wheter the "?" operator will make more optimal code that if/else it
> depends on the compiler
> 
> who cares about how you do an infinite loop, its just an infinite loop
> 
> but knowing when and why you need volatile and why an interrupt cannot
> return values or be passed parameters is a good start...

Hmm, so many "answers" have something wrong with them...  If I were the
interviewee I wouldn't want the job; the author should be embarrassed.

e.g. this guy seems to think that because he got non-NULL allocating 0
bytes that it is guaranteed, that because a macro has arithmetic
in it that implies the preprocessor is doing arithmetic, ...

Never mind the syntax errors...

Paul Keinanen wrote:

> If the code was not compiled for debugging, how could one put the
> breakpoint between two source lines in a high level language ?

As Tom also pointed out, in most cases it is possible to compile with
optimisations enabled and still allow debugging.

Regardless, who said I wasn't using an ICE?

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