DPRG List  

DPRG: Poke

Subject: DPRG: Poke
Date: Tue Aug 17 15:54:46 CDT 1999

In future, please do not both post and copy me without telling me
what you are doing. I find that annoying, because then I have to
forward my own response to the echo.

)>But it seems to me that *any* use of peek(.) and poke(.,.) obscures the
)>intent of the code.
)            BLARF = 0x42;
)This gives no clue as to whether BLARF is a device register, an
)equivalenced field in a record structure, a shared global variable, or
)something else.

The fact that it is all uppercase is a strong hint that it is a macro,
and where to go look. peek() and poke() give no such hints.

)The statement:
)            poke(BLARF, 0x42);
)gives a very strong hint that BLARF is a memory-mapped device register.

Not to me, it doesn't. It gives me a strong hint that the programmer
doesn't understand how the language works.

)Consider for example the sequence:
)            BLARF = 0x41;
)            BLARF = 0x42;
)and compare and contrast it with the sequence:
)            poke(BLARF, 0x41);
)            poke(BLARF, 0x42);

Boy do I consider the previous to be superior.

)In the first sequence, we don't know whether the first assignment to BLARF
)is dead or not, and we don't know whether we can take it out.  In the
)second sequence, we have a strong hint that both steps are meaningful and

I'll reiterate: the strong hint it gives me is the the programmer
doesn't understand C.

)In any given real-time program, 95%-99% of the code is housekeeping stuff,
)that isn't particularly critical, and doesn't require a lot of worry.  In
)particular, this code frequently does not have interesting sequencing
)However, the other 1%-5% *IS* critical.  Part of the art of software
)engineering is communicating the criticality to the next programmer in
)line, so that he understands which parts of the code have subtlety and long
)sharp fangs.  Code that manipulates device registers is almost always in
)this area.
)Things like peek(.) and poke(.,.) serve as warning signs to the reader that
)there may be more going on than is immediately evident.  Their apparent
)obscurity forces the reader to take a closer look, or at least warns him
)off from indiscriminately making hamburger.

Well, maybe they do to you, I dunno. I'd never seen them used *anywhere*
in C programs until I encountered this robotics group and started
looking at code written by roboticists in the last year.

I've been doing embedded systems programming and control for about 17



More information about the DPRG mailing list