|(C lang) how do compilers deal with volatile, const, and register keyw sbisse01NoSpam@harris.com (Scott Bissett) (2000-04-01)|
|Re: (C lang) how do compilers deal with volatile, const, and register firstname.lastname@example.org (James Jones) (2000-04-05)|
|From:||"Scott Bissett" <sbisse01NoSpam@harris.com>|
|Date:||1 Apr 2000 14:12:37 -0500|
|Organization:||Harris Electronic System Sector|
|Keywords:||C, practice, comment|
I initially posted this question (or at least a variant of it) in
comp.lang.c, but the more I think about it, it's probably most
appropriate here. If you read that forum, and you've read this
question, I apologize for my apparent reposting. However, I am slowly
learning more about this matter every time I post, get answers, and
research the subject more.
First, I have no experience with compiler construction and internals,
so if I sound ignorant in that regard, well, I am!
Assume I have a header file, "proj_types.h", containing the following
type-definition (among others):
typedef volatile unsigned char * const mmio_ptr;
And in an implementation file, I have the following declaration:
register mmio_ptr SOME_REGISTER = 0xABCD1234;
The intent of the type-definition is to define a constant pointer to a
memory-mapped I/O register (thus the volatile; I don't want apparent
redundant references to the memory to be optimized out by the
compiler). The intent of using the register keyword in the definition
of SOME_REGISTER is not exactly to "encourage" or hint that I want
that pointer stored in a register, but more specifically, I want the
compiler to enforce this statement from K&R2, Section A8.1: "if an
object is declared register, the unary & operator may not be applied
to it, explicitly or implicitly".
Why am I asking about this? Mostly just for my own better
understanding of C, how a compiler interprets such
open-to-implementation issues as handling the volatile, const, and
register keywords. But also, I am a stickler about completeness of
specification in that I wish typedef's would encourage a bit stronger
enforcement in C, similar to Ada. I code very consistently, and I
feel that if I consistently defined memory-mapped I/O registers as
"register mmio_ptr ...", my code's readability would improve. Also,
and this is imminently more practical, I was hoping that this would
preserve the symbol SOME_REGISTER so it could be referenced in a
debugger, unlike mapping the register through a macro, such as:
#define SOME_REGISTER (unsigned char *)(0xABCD1234)
Obviously, any symbol I declare (beyond the scope of the
pre-processor) can be used by the debugger. But what I am trying to
avoid is actually allocating space for the variable SOME_REGISTER in
variable memory. That is, hopefully code that refers to SOME_REGISTER
(when defined as a register mmio_ptr) like such:
*SOME_REGISTER = <some value, bit mask, etc.>;
would result in an "(Move Immediate) 0xABCD1234, <some value>"
assembly line, instead of a "(Move Indirect) <location of
SOME_REGISTER>, <some value>". (I'm being generic in my assembly, of
course). Had I defined SOME_REGISTER as a macro, like I did earlier,
the first assembly macro gets generated. This is the desired effect,
but I would like to have the symbol present at the debugger.
Pardon me for making this post so long. I have a very good idea of
what I'm trying to say, but I'm not quite as lucid when it comes to
asking the question. I appreciate any insights or corrections
regarding anything I've said.
[It's true, taking the address of a register variable is forbidden, but a
lot of compilers just ignore "register" altogether and don't enforce that.
Return to the
Search the comp.compilers archives again.