Re: A quick c programming survey question - Update!
From: Ben Bradley (ben_nospam_bradley_at_mindspring.com)
Date: 05/17/04
- Next message: pmm: "Re: one Devicenet Question please"
- Previous message: Neil Bradley: "Re: A quick c programming survey question - Update!"
- In reply to: Jim Granville: "Re: A quick c programming survey question - Update!"
- Next in thread: Rich Webb: "Re: A quick c programming survey question - Update!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 17 May 2004 00:41:08 -0400
On Mon, 17 May 2004 09:31:37 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:
> ...
>> So if the interviewer just wanted to find out if the
>> interviewee knew that bits aren't portable he should
>> have asked using a less roundabout question to
>> establish this and addressed the 'style' issues separately
>> (which I am sure my colleague would have got right).
>
>Still not easy to find the point...
>
> BOOLEAN BITS, by their nature are not portable.
FWIW, not only have I never used the built-in "bits" facility in C
(answer a) in the original thread), I forgot it was in the language. I
don't recall seeing any code that uses it (outside of k&r).
Now I at least see the 'agenda' that prompted the original
question. The answers were either a) or not a). I definitely do bit
manipulation by bitwise anding, oring, shifting and complementing,
either directly in the 'main' code or in functions or macros as I see
fit. This generally works (until changing to a processor with a
differen word size, then there are usually other considerations as
well) and is about as portable as can be expected.
>In embedded systems, they most commonly apply to hardware flags.
> Someone who thinks that a change in SW style can somehow create
>'more portable bits' probably should not be let near low level code!
I recall an interview I had maybe ten years ago. The company had
the same C code running on two different 8-bit microcontrollers, one
was, IIRC, an 8051, and the other was some other unrelated
(non-compatible) architecture. They were asking me questions to see
how much I knew about writing "portable" C code. I gave what answers I
could, about isolating I/O operations to separate functions that are
different for each chip and the main "portable" code calls those
functions to do I/O.
I didn't get a job offer, and looking back it's just as well (I
vaguely recall the products were related to "home networking" for
appliances like washer/dryers and refrigerators, so they could be
controlled remotely to do things like reduce peak power consumption -
this was hot at the time but I haven't heard anything about such
applications in years). It seemed to me at the time (though I could be
wrong, I can't think of another reason to do this) that they did this
for manufacturer/vendor independence - so that in case one chip maker
went out of business, they would have the code and hardware designed
with the other chip ready to manufacture. Perhaps they also played the
manufacturers and vendors against each other, saying "We've got the
code running on your compettitor's chip right here, and we're going
with the lowest priced solution at a few million units/year" in an
effort to negotiate lower prices. But it seemed like they were going
to great expense to be able to say they had "portable code" running on
both these chips.
> The embedded systems I work on have never had to change HW targets,
>so I code for best maintainance/interrupt integrity.
>-jg
-----
http://mindspring.com/~benbradley
- Next message: pmm: "Re: one Devicenet Question please"
- Previous message: Neil Bradley: "Re: A quick c programming survey question - Update!"
- In reply to: Jim Granville: "Re: A quick c programming survey question - Update!"
- Next in thread: Rich Webb: "Re: A quick c programming survey question - Update!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
