Re: C- Syntax to allocate Global variables to consecutive memory locations

On Mon, 09 Apr 2007 17:56:43 -0500, R Pradeep Chandran <see@xxxxxxxxx>
wrote:

On Mon, 09 Apr 2007 18:04:23 GMT, Jonathan Kirwan
<jkirwan@xxxxxxxxxxxxxx> wrote:
To put my question in exact context, one of the things I miss having
in C and readily find with assembly coding (usually) is the ability to
define link-time constants. By this, I mean the equivalent in x86 asm
of:

_abc EQU 0x123
PUBLIC _abc

This places a symbolic value in the OBJ file that can be linked into
other files and used as constant values. In c, I might use:

extern int abc;
#define MYCONST (&abc)

and then refer to MYCONST throughout the c source. The result allows
me to modify the constant definitions without requiring recompilation
of the c sources. The link process is all that is required.

Are you sure that only the link process is required.

Yes. Been there, done it.

I think that you
need to compile (or assemble) the file containing the declaration of
abc (or _abc).

In the example I gave, where I've used two source files -- one in
assembly and one in c -- changing a constant value requires editing
the assembly code and re-assembly of that file in order to produce the
OBJ file, plus a link step to complete the executable.

My point was that there was no _c_ compilation required -- not that
the file containing the constants didn't need re-assembly.

Normally, in c-only projects, the only type of symbolic named constant
that doesn't require storage is found in the pre-processor's #define.
If you change the value of such symbolic constants, all of the c
source files which reference those constants must be recompiled by the
c compiler.

In the example I gave, no c source file which references those
constants need to be recompiled.

These kinds of constants are nothing new in object files. They've
been in use for the 30+ years I've been programming and they existed
in the linkers I've written in my long past. The current linkers
required for c do this all the time, as well. The only problem is
that there is no syntax in c specifically for this semantic.

People who can only think in terms of the higher level language
semantics they are hand-fed, conflate the ideas I'm talking about. In
c, for example, the language will only generate a link-time symbolic
reference from a declaration where the definition is external to the
module. And when it does so, it depends upon the linker to provide
the actual value for that link-time symbol. The only other case with
c is where the compiler generates a definition (and a declaration) of
the object -- but that requires storage -- and in any case, it again
allows the linker to actually fill in the symbolic value that replaces
other symbolic references, once the linker is finished with placement.
In the assembly language case I mentioned, the assembler is perfectly
free to provide a link-time symbolic constant where the value is
provided by the assembler and not by the linker's location process.
This semantic ability is explicitly missing in c.

A possibly good way to handle this without changing the c standard (at
least, not changing the behavior of resulting code) would be to follow
how a smart c++ compiler and its linker might interpret Stan's
example:

const int abc= 0x123;

In c, this is not only a declaration but also a definition. It
creates storage for 'abc' and initializes it -- in other words, there
exists an address where the value 0x123 is stored, at run-time. If
you placed that into a common include file, used by a variety of c
source files, you'd be in a peck of trouble as each compilation unit
would provide separate definitions. If placed into a single c file
for compilation, storage would be allocated when perhaps none would be
required.

In c++, if my feeble recollection about it remains, it is possible for
the c++ compiler to remove the storage (if the compiler and linker are
able to determine than an address reference is never required) and
simply replace the value. I have one central problem in talking about
c++: I don't use c++ in my embedded work. I also don't know of any
embedded c++ compilers and linker combinations that achieve this, in
practice. But even if they existed it wouldn't change my question
regarding c.

Jon
.

Relevant Pages

  • Re: C- Syntax to allocate Global variables to consecutive memory locations
    ... me to modify the constant definitions without requiring recompilation ... it depends upon the linker to provide ... In the assembly language case I mentioned, the assembler is perfectly ... how a smart c++ compiler and its linker might interpret Stan's ...
    (comp.arch.embedded)
  • Re: Building/Running C64x from commandline
    ... It is for sure possible to compile and build TMS6200C64xx executables. ... I use the stand alone compiler and linker, ... The Assembler ...
    (comp.dsp)
  • Re: Wheels falling off CLAX again ?
    ... The first one being what you say: As long as the Assembler is able to compile itself, we can keep sure that, at least, this one was successful on that task. ... system device drivers, high performance DLLs and of course, high performance object modules for C compilers. ... Which assembler, compiler, linker, resource compiler and many other tricks for binary output that a kiddies toy cannot come near. ... MASM with a linker builds a similar sized program using a linker in about 200 milliseconds so even adjusting the machine difference, masm with a linker is 4 to 5 time faster and this is on a real world application. ...
    (alt.lang.asm)
  • Re: Wheels falling off CLAX again ?
    ... > There are many other reasons for writing an Assembler ... An assembler is a technically trivial application alongside a compiler, ... Which assembler, compiler, linker, resource compiler and many ...
    (alt.lang.asm)
  • Re: What micros do you actually hate to work with?
    ... with less than tiny asm ... hassle to work with 32 bit longs in assembler for an 8 bit uP, ... Microchip's C compiler tools and their assembly under MPLAB. ... is that other programmers for C are easier to find. ...
    (comp.arch.embedded)