Readonly variables
Martin Minow
minow at decvax.UUCP
Thu Aug 18 09:37:25 AEST 1983
The C language specification specifically requires that
strings be stored in writable memory. This is unfortunate
in many applications (such as stand-alone real-time
control systems) where RAM space is limited (and initializing
RAM contents on power-up doubly expensive).
It also prevents string space compression (for example, if
strings were read-only, "bar" and "foobar" would share
the same storage space). Furthermore, if strings were
read-only, they could be stored in "code" space, allowing
short displacement operations in certain cases. On paging
systems, string space need not be written back to disk.
It would be nice to have a compiler directive that stored
constant strings in read-only memory, in addition to
the readonly keyword.
Note, that in constructions such as
char *foo = "bar";
There are two pieces of memory being initialized, the vector of
char's ('b', 'a', 'r', '\000') and the pointer to the 'b'.
readonly char *foo = "bar";
would change the allocation characteristic of 'foo' but not
necessarily "bar".
In a large C program that will run in a stand-alone computer,
we "solved" the problem by a terribly ugly hack: we defined
three macros that generated "magic cookies" in the assembly-
language output file. A post-pass program ate the cookies,
generating appropriate program section directives. The
macros were as follows:
ROM_SECT(_C_Dnn) The following is read-only data
RAM_SECT(_C_Dnn) The following is read-write data,
initialized to zero on powerup.
IRAM_SECT(_C_Dnn) The following is initialized
read-write data.
'nn' in the above was a unique integer. These macros generated
something like:
static int _C_Dnn = 1; 1, 2, 3 signal the "flavor" of the
section to be generated.
It would be nice to have this in the language.
Martin Minow
decvax!minow
More information about the Comp.lang.c
mailing list