(C lang) how do compilers deal with volatile, const, and register keywords?

"Scott Bissett" <sbisse01NoSpam@harris.com>
1 Apr 2000 14:12:37 -0500

          From comp.compilers

Related articles
(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 jejones@microware.com (James Jones) (2000-04-05)
| List of all articles for this month |

From: "Scott Bissett" <sbisse01NoSpam@harris.com>
Newsgroups: comp.compilers
Date: 1 Apr 2000 14:12:37 -0500
Organization: Harris Electronic System Sector
Keywords: C, practice, comment

Hello,


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.


Thank you,
Scott Bissett
Harris Corporation
[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.
-John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.