2

I know that when a variable declaration precedes with register keyword compiler may put the variable in CPU's register for faster access. Same way I know that compiler can put const variable in ROM because const variable's value won't change throughout the execution of program.I know also that register specifier is a request to the implementation to put variable in CPU register. But where the variable will be stored if it is marked with both const & register? Consider following program:

#include <stdio.h>
int main()
{
    register const int a=3;
    printf("%d",a);
    return 0;
}

In this case where the variable gets stored? In the CPU register or on the stack(if compiler ignores the register request) or in the ROM if compiler optimizes it.

Destructor
  • 14,123
  • 11
  • 61
  • 126
  • 4
    To be clear, nothing can be put in ROM since ROM is read-only. So the compiler cannot write to ROM either. See also [this answer](http://stackoverflow.com/a/3685092/33499) – wimh Jan 31 '15 at 09:22
  • 3
    Your program above will likely be optimized as `{ putchar('3'); return 0; }` with no variables at all – pmg Jan 31 '15 at 09:23
  • 6
    Don't use `register`, it's an anachronism. Today's compilers will do a much better job at register allocation. The only difference that this makes is that you can't take the address of a register variable. In any case, `register` is a suggestion, the compiler is free to ignore it. – Ulrich Eckhardt Jan 31 '15 at 09:36
  • 7
    It may not be put anywhere. The compiler may precompute any constant expression it is part of, or embed it into the instruction stream instead of RAM or ROM. – user207421 Jan 31 '15 at 09:39
  • What OP wrote makes sense if you expand "ROM" as "Read-only Memory". Constants get put in the executable's data section and marked as read-only when loaded into memory. Obviously, it's not a ROM chip because that gets burned once by the manufacturer and can then no longer be changed. – uliwitness Jan 31 '15 at 11:02
  • The compiler might even replace it with a constant. – barak manos Jan 31 '15 at 11:17
  • A compiler/linker for an embedded system may very well arrange for static read-only data to be put into something that's burned to ROM. That's not going to happen for a hosted implementation (if you can compile and run your program without hooking up extra hardware nothing will be burned to ROM). – Keith Thompson Jan 31 '15 at 22:51
  • A compiler is free to put *anything* into a register, whether it's declared as `register` or not, as long as the resulting program behaves correctly. In fact, if the `register` keyword is actually enforced, it's likely to interfere with the compiler's own register-allocation algorithm. – Keith Thompson Jan 31 '15 at 22:52

2 Answers2

1

First when you declare a variable as const, the compiler will never put it in ROM, because ... neither the compiler, nor the linker, nor later loader can write anything in ROM ! It can only put it in read-only segments that will still reside in RAM even if any write access at run time will cause an error.

Then to answer more precisely your question, the compiler may always do what it wants.

  • when you declare a variable const, the compiler should throw an error if it detects a change and can put it in a read-only segment
  • when you declare a variable register, the compiler should throw en error if it detects an attempt to take its address, and can try to keep it in register.

The only thing that is explicitely required is that a compiler correctly processes correct code. It is requested to throw an error if it cannot compile some code, but it is allowed to accept incorrect code : that may be called extensions or special features. For example a compiler is free to declare that it fully ignores register declaration and allows taking the address of a register variable but it must at least issue a warning [edit see below for details]. Simply it must not choke on correct register (or const usage).

And it can make use of register and const declaration for its optimisations but is perfectly free to ignore them. For example the following code :

const int a = 5;
const int *b = (int *) &a;
*b = 4;

leads to Undefined Behaviour. It is implementation dependant if after that :

  • a = 5
  • a = 4
  • the program crashed
  • the computer was burned to fire (but this one should be uncommon :-) )
  • ...

EDIT :

JensGustedt noted in comment that C language specification contains in paragraph 6.5.3.2 Address and indirection operators this constraint clause :

The operand of the unary & operator shall ..., or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier. (emphasize mine)

As it in a constraint clause, paragraph 5.1.1.3 Diagnostics of same specification requires that A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint.

So a conforming C compiler shall at least issue a warning if programmer tries to take the address of a register variable.

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
  • Last line would be hilarious cosequence of U.B.! +1. – Am_I_Helpful Jan 31 '15 at 10:57
  • 1
    Did you mean to write `*b = (int*) &a;` here? There is no b declaration at all in your example. – uliwitness Jan 31 '15 at 10:58
  • You forgot 'universe implodes to a singularity and re-boots' in your list of 'undefined behaviour'. That was common with some of the early x86 platforms. – Persixty Jan 31 '15 at 11:16
  • 3
    "take its value"? ITYM "take its address". – Jens Jan 31 '15 at 11:26
  • No a compiler has less liberty than you are claiming. If it would allow taking the address of a `register` variable it wouldn't be a compliant C compiler. – Jens Gustedt Jan 31 '15 at 11:39
  • @SergeBallesta Compiler can put const variable in ROM. Visit this: http://www.dansaks.com/articles/1998-05%20Placing%20Data%20into%20ROM.pdf & also this: http://www.dansaks.com/articles/1998-11%20Placing%20Data%20into%20ROM%20with%20Standard%20C.pdf – Destructor Jan 31 '15 at 11:55
  • @meet To be exact, compiler can put `const` variables in a read only segment. Then if you are building an embedded system, the read only segments can reside in ROM. But when you write a normal program on a normal computer, you cannot put anything in ROM. – Serge Ballesta Jan 31 '15 at 14:28
  • 1
    @SergeBallesta, this is 6.5.3.2 p1 of C11, which is a "Constraint" section which forces a compiler to give a diagnostic when such a constraint is violated: *The operand of the unary & operator shall be.... an object that is not a bit-field and is not declared with the register storage-class specifier.* – Jens Gustedt Jan 31 '15 at 20:10
  • @JensGustedt : Thanks for the reference ! I've updated my post – Serge Ballesta Jan 31 '15 at 22:24
1

I don't actually know what any individual compiler does in this situation, but from logic, and given that register is more of a suggestion, and the compiler is permitted to ignore it as far as the standard goes, I'd say there are three likely outcomes:

  1. As constants are usually pretty efficient, and can often be encoded as part of the instruction or optimized out, and therefore might not even need to be loaded from the data section into a register explicitly, it might just ignore the register keyword completely and treat it as just const.

  2. If there is any code generation step that needs to decide which values to put in a register and which elsewhere, and a is one of these values, the compiler might take into account that you declared it as register and prefer that.

  3. (And this may just be a variation on #2) The compiler may decide that you had a reason to specify register here and always force a into a register when it can. Worst case, this could run counter to how the optimizer would usually assign your code to registers though, and could result in sub-optimal code. Or if you really know what you're doing, it might work around an optimizer bug.

uliwitness
  • 8,532
  • 36
  • 58