Tom Lucas wrote:

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

Very true, I have been in similar situations myself. There are a few
infamously 'elitist' companies here in Sydney which pride themselves on
having only the 'cream of the crop' employees. Well, at least that's
what they like to tell themselves. No different to a few law firms I
could name.

I still laugh about the company that came into my uni to hire for
industrial year and would only consider 'distinction' students. Most of
them took the bait only to find out a year later that they'd been paid
significantly less than everyone else (this was during a chronic
shortage in programmers) and got pressured into finishing the course
part time.

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

rTrenado wrote:

(I've tried to correct the top-posting, and snipped a little, to keep 
sense of the thread here.  Comments below.)

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

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

There is certainly a difference between what the standard says a 
compiler can do, and what real compilers do in practice.  The compiler 
is free to generate any code it wants as long as the object code acts as 
specified by the standard and the source code, but there are practical 
limitations to the sophistication of optimisation that can be achieved.

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

I know how automatic variables work, and how they are initialised.

Consider the code:

extern void test(int a);
extern int bar(int b);
void foo(void) {
	int x = 1;
	int y = 2;
	int z;

	z = x + y;
	test(z);
	test(y);
	x++;
	test(x);
	x = bar(x);
	test(y + x);
}

That function contains two initialised and one uninitialised automatic 
variables.  The actual code generated by most compilers will be roughly:

void foo(void) {
	test(3);
	test(2);
	test(2);
	int temp = bar(2);
	temp += 2;
	test(temp);
}

There is no need for run-time initialisation of the automatic variables, 
or any sort of allocation for them.

mvh.,

David



 > Regards
 > Rene

Mark Borgerson wrote:
> In article <45549534$0$8083$8...@news.wineasy.se>, 
> d...@westcontrol.removethisbit.com says...
>> 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.
> 
> Does your compiler allow you to omit the semicolon after
>     msecsCounter++??   Codewarrior won't let me get away with that.

Well done, you spotted the extra deliberate mistake :-)

>>> 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.
>>>
> 
> An even more interesting case might occur if you needed a delay less 
> than 10 milliseconds  and tried to use an OS where the delay routines
> do not have sub-millisecond resolution.  I run into this problem almost 
> every time I try to do high-resolution timing with an OS.   You often
> have to switch to a different  set of system calls when you change
> timing delays by an order of magnitude or more.
> 
> 
> Mark Borgerson
> 
> 

Pete Fenelon wrote:
> Eric <e...@hotmail.com> wrote:
>> 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?
> 
> You ask them questions that involve writing code, on a whiteboard, to do
> realistic but simple embedded systems tasks.  Another good question to
> asks is getting them to explain their understanding of how an embedded
> system starts up - which leads on to their understanding of code and
> data sections, interrupt vectors, linkers and loaders etc.
> 
> A good open-ended question we used to ask was 
> 
> ...
> int x=1;
> int y=2;
> int z;
> 
> z = x+y;
> <---- breakpoint here
> ...
> 
> At the breakpoint, z does not equal 3. Why?
> 
> A good candidate should be able to come up with many failure modes... 
> 
> pete

I have a particular device that's got a 4 stage pipeline, and the result 
of an operation won't necessarily be available at the next machine 
cycle. That's also an issue with MIPS cores for branches - the assembler 
has constructs to insert no-ops but occasionally they get turned off for 
various reasons. (The instruction _after_ the branch instruction is 
actually picked up and executed during the branch itself which can be 
really useful but can also cause great pain and grief).

I've seen the most amusing bugs because the assembler directive to turn 
them on again was 'forgotten'.

When I get this sort of question I ask if the assembler listing is 
available.

Cheers

PeteS

Agree with you David, however, the correct response is that the code
you show will be roughly what you tell it will depending on the
platform it runs NOT on the compiler you use and that was the point I
wanted to make. One cannot generalize about how compilers work, that is
why standards are for. Even in the code you presented, it could be
proven that some allocation and initialization could happen even in the
simplest of the CPUs (one accumulator, one register index and of course
physical stack).

Rene


David Brown wrote:
> rTrenado wrote:
>
> (I've tried to correct the top-posting, and snipped a little, to keep
> sense of the thread here.  Comments below.)
>
> > 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.
> >>
>
>  > 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."
>  >
>
> There is certainly a difference between what the standard says a
> compiler can do, and what real compilers do in practice.  The compiler
> is free to generate any code it wants as long as the object code acts as
> specified by the standard and the source code, but there are practical
> limitations to the sophistication of optimisation that can be achieved.
>
>  > 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?
>  >
>
> I know how automatic variables work, and how they are initialised.
>
> Consider the code:
>
> extern void test(int a);
> extern int bar(int b);
> void foo(void) {
> 	int x = 1;
> 	int y = 2;
> 	int z;
>
> 	z = x + y;
> 	test(z);
> 	test(y);
> 	x++;
> 	test(x);
> 	x = bar(x);
> 	test(y + x);
> }
>
> That function contains two initialised and one uninitialised automatic
> variables.  The actual code generated by most compilers will be roughly:
>
> void foo(void) {
> 	test(3);
> 	test(2);
> 	test(2);
> 	int temp = bar(2);
> 	temp += 2;
> 	test(temp);
> }
>
> There is no need for run-time initialisation of the automatic variables,
> or any sort of allocation for them.
> 
> mvh.,
> 
> David
> 
> 
> 
>  > Regards
>  > Rene

rTrenado wrote:
> Agree with you David, however, the correct response is that the code
> you show will be roughly what you tell it will depending on the
> platform it runs NOT on the compiler you use and that was the point I
> wanted to make. One cannot generalize about how compilers work, that is
> why standards are for. Even in the code you presented, it could be
> proven that some allocation and initialization could happen even in the
> simplest of the CPUs (one accumulator, one register index and of course
> physical stack).
> 
> Rene
> 

I suspect that we both understand what happens in the compiler, but one 
or the other of us is expressing things badly, or misreading the others 
post.

Generated code will normally follow roughly the same flow as source 
code, until you use compiler features such as automatic inlining, 
inter-procedural optimisations, and whole-program compilation.  The 
details of the code (and the sorts of optimisations used) depend heavily 
on the compiler as well as the target.  But the point I took issue with 
was your claim that the compiler MUST generate code for allocation and 
initialisation of automatic variables, as this is clearly not the case. 
  In testing my example, some compilers generate such code, others (on 
the same target) do not.

mvh.,

David

"Paul Taylor" <p...@tiscali.co.uk> wrote in message 
news:p...@tiscali.co.uk...
> 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?

Turns out that was exactly what is was but with more than one agency. 
They didn't bother to contact the candidate and then told us with a 
straight-face that the candidate was ill or just didn't fancy it. Over 
the last week I've had those same candidates turning up unannounced 
looking for interviews at whatever arbitrary time the agencies have told 
them.

It's disgusting considering the sums these agencies are asking.

"Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote in 
message news:1...@iris.uk.clara.net...
> "Paul Taylor" <p...@tiscali.co.uk> wrote in message 
> news:p...@tiscali.co.uk...
>>
>> Might be an agency problem?
>
> Turns out that was exactly what is was but with more than one agency. They 
> didn't bother to contact the candidate and then told us with a 
> straight-face that the candidate was ill or just didn't fancy it. Over the 
> last week I've had those same candidates turning up unannounced looking 
> for interviews at whatever arbitrary time the agencies have told them.
>
> It's disgusting considering the sums these agencies are asking.

A few years back an agency asked me to attend an interview for a contract in 
Bristol, which went well. On the drive home I received a call from another 
agency asking me to attend an interview in Reading, which I declined. I 
later discovered that this second agency was also bidding for the first job, 
and after phoning me had told the Bristol client that I wasn't available as 
I'd accepted a job elsewhere, which was of course a total lie.

I complained. I also looked into it, and discussed this with other agencies. 
The general consensus was "it happens all the time".

Some of the recruiters are very good, and some are lying scumbags.

Steve
http://www.fivetrees.com 

"Steve at fivetrees" <s...@NOSPAMTAfivetrees.com> wrote in message 
news:3...@pipex.net...
> "Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote 
> in message news:1...@iris.uk.clara.net...
>> "Paul Taylor" <p...@tiscali.co.uk> wrote in message 
>> news:p...@tiscali.co.uk...
>>>
>>> Might be an agency problem?
>>
>> Turns out that was exactly what is was but with more than one agency. 
>> They didn't bother to contact the candidate and then told us with a 
>> straight-face that the candidate was ill or just didn't fancy it. 
>> Over the last week I've had those same candidates turning up 
>> unannounced looking for interviews at whatever arbitrary time the 
>> agencies have told them.
>>
>> It's disgusting considering the sums these agencies are asking.
>
> A few years back an agency asked me to attend an interview for a 
> contract in Bristol, which went well. On the drive home I received a 
> call from another agency asking me to attend an interview in Reading, 
> which I declined. I later discovered that this second agency was also 
> bidding for the first job, and after phoning me had told the Bristol 
> client that I wasn't available as I'd accepted a job elsewhere, which 
> was of course a total lie.
>
> I complained. I also looked into it, and discussed this with other 
> agencies. The general consensus was "it happens all the time".
>
> Some of the recruiters are very good, and some are lying scumbags.

Any suggestions as to those which are very good? I've got several lying 
scumbags I can trade ;-) 

"Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote in 
message news:1...@despina.uk.clara.net...
> "Steve at fivetrees" <s...@NOSPAMTAfivetrees.com> wrote in message 
> news:3...@pipex.net...
>>
>> Some of the recruiters are very good, and some are lying scumbags.
>
> Any suggestions as to those which are very good? I've got several lying 
> scumbags I can trade ;-)

My data would be out of date, and related to specific individuals. I didn't 
get the impression that "lying scumbaggery" was a corporate policy [1], 
merely a tool employed by certain individuals to achieve their 
targets/bonuses.

[1] At least not overtly...

Steve
http://www.fivetrees.com