On processors where the code store is in the same address space as all other variables, compilers will typically place "const"-qualified global or static variables into their own link section, and linkers will typically be configured to place that section in the system's code store (flash, OTP, or whatever). This will reduce the amount of RAM required by the program, and will reduce the amount of work the startup code has to do.
On processors where the code store is in a different address space (e.g. the PIC or 8051), some compilers will use a
const qualifier to signal that they should place the variables into the code store and use different instructions to access them, while others will not. Such compilers will require that only pointers with a
const qualifier may be used to access
const-declared variables, since without that requirement the compilers wouldn't know that special instructions had to be used to access such pointers.
On the 8051 compilers I've seen (Archimedes and Keil), there are 8051-compiler-specific keywords __data, __idata, __code, __bdata, _pdata, and_xdata available to indicate that variables should be loaded in a particular address space. By default, the names can be used with or without underscores; the non-underscore versions are more convenient, but may be disabled if, e.g. one is porting a program which uses identifiers named
data). If a pointer is declared without applying one of those keywords to its target, the compiler will allocate three bytes: one to indicate what memory space the target is in, and two to hold a 16-bit address if one is required. Declaring a variable
const without also applying a
code qualifier will cause the variable to be placed in the default RAM address space, and loaded with the default value at startup; a variable declared that way may be passed to code expecting a pointer in the default address space (but will use RAM). Adding a
code, if enabled) declaration will cause the variable to be placed in code space. It's usually better to use the
code declaration than not, but in some cases, especially if the item in question is small, the comparative ease of accessing things in
idata RAM might make up for the loss of a few bytes of that space.