* Ask them to calculate the number of pixels on the screen that
corresponded to some real-world distance.
corresponded to some real-world distance.
* Ask them to write said calculation in C (it was just one line -- at
least if we were going to hire them).
least if we were going to hire them).
* Ask them to rewrite said calculation without using floating point.
* Then we'd ask some leading questions to see if they'd realize that
they had an overflow or underflow problem (with 16-bit integer
arithmetic you either had one or the other).
they had an overflow or underflow problem (with 16-bit integer
arithmetic you either had one or the other).
* Ask them how to avoid underflow.
* Ask them how to avoid overflow.
* As a bonus, if they were still standing we'd ask them how to rearrange
the calculation so that it would round to the nearest 1/2, instead of
always down.
the calculation so that it would round to the nearest 1/2, instead of
always down.
It's amazing how many telecom guys have never realized that 'int' means
'could be 16 bit' and how many 16-bit processor guys have never realized
that 'long' means 'at least 32 bits'.
'could be 16 bit' and how many 16-bit processor guys have never realized
that 'long' means 'at least 32 bits'.
We would _not_ look for people to get all of the answers right while
standing there by the white board. What we _did_ look for was a general
knowledge of C, flexibility, the ability to listen to guidance from
fellow engineers, and grace under pressure.
standing there by the white board. What we _did_ look for was a general
knowledge of C, flexibility, the ability to listen to guidance from
fellow engineers, and grace under pressure.
Later on we'd ask them to describe some project that they'd worked on.
We were looking both for communications skills and for indications that
they had actually participated in the project somehow, and not just been
responsible for keeping the coffee warm.
We were looking both for communications skills and for indications that
they had actually participated in the project somehow, and not just been
responsible for keeping the coffee warm.
Then we'd hand them off to the EE's, who would make them read
schematics. Once again they wouldn't necessarily be expected to know
how to do circuit design, they were just expected to know how to hook up
an oscilloscope -- even knowing how to ask an EE to hook up an
oscilloscope was considered sufficient.
schematics. Once again they wouldn't necessarily be expected to know
how to do circuit design, they were just expected to know how to hook up
an oscilloscope -- even knowing how to ask an EE to hook up an
oscilloscope was considered sufficient.
And Lewin, if you're listening -- we didn't ask one C++ question, yet
when we trained them up on it they did just fine.
when we trained them up on it they did just fine.
Say the variable is really a hardware status bit, memory mapped.
If declared volatile in the code there will be a memory access for
each read. If the hardware diverts that read to the cached value,
it will no longer reflect reality. So the system needs some means
of automatically invalidating the cache. To me, this is a primary
objection to using memory mapped i/o ports, which can easily be
avoided with a separate i/o space.
If declared volatile in the code there will be a memory access for
each read. If the hardware diverts that read to the cached value,
it will no longer reflect reality. So the system needs some means
of automatically invalidating the cache. To me, this is a primary
objection to using memory mapped i/o ports, which can easily be
avoided with a separate i/o space.
I don't know if this is the OPs problem, but it seems likely.
And how would the compiler do this? Will it insert a complete cache
flushing sequence after the variable update?
flushing sequence after the variable update?
On the other hand, if you only worry about different threads, you do not
need to worry about the cache. All threads run on the same CPU (multi
core excluded here ;-) and will therefore use the same cached value, no
problem.
need to worry about the cache. All threads run on the same CPU (multi
core excluded here ;-) and will therefore use the same cached value, no
problem.
You only need to worry about the cache if there is some kind of DMA at
work. You might also run into problems with self modifying code using
separate data and instruction caches.
work. You might also run into problems with self modifying code using
separate data and instruction caches.
Use volatile for variables that get updated outside the normal execution
flow (from an interupt or from another thread). This prevents the compiler
from re-using a value read into a register, but this has nothing to do
with caches.
flow (from an interupt or from another thread). This prevents the compiler
from re-using a value read into a register, but this has nothing to do
with caches.
Interview Questions
- 1. Design a DMA controller and then API for it.
2. Find algorithm to plan a route of a spaceship on 2D grid to visit places while avoiding obstacles (Dijkstra).
3. Write code to process a log file with timing marks from functions.
4. Design a system to reduce/measure power consumption on a tiny embedded battery powered device
0 Comments