C- Syntax to allocate Global variables to consecutive memory locations

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I agree that no C files need to be compiled. But, you said that only the link process is required. I was merely pointing out that the statement you made is not entirely accurate.

They do, Don't they? :-)

I agree. It is nice to have this feature especially for platforms with very small amounts of memory. I guess not too many people on the ISO committee felt that this feature was required.

An aggressive compiler can optimize this under many conditions. As far as I can see, the ISO standard for C does not require that storage be allocated.

Tasking C++ compiler for the C166/ST10 platform (v6 r7 if I remember correctly) does this optimization. In fact, a later version (not sure which one) does this for C as well.

Also, as far as putting const declarations in header files is concerned, there is a difference between C and C++.

By default, const has external linkage in C. By default, const has internal linkage in C++. This is what creates the separate definitions that you mentioned.

Have a nice day, Pradeep

--
All opinions are mine and do not represent the views or
policies of my employer.
R Pradeep Chandran                 rpc AT pobox DOT com

But I said, "... without requiring recompilation of the c sources." I agree that I am not always clear. But I think I did a fair job here in being clear. In addition to the above, I provided an explicit example along with the comment, "... creates the object equivalent of a PUBDEF and an EXTDEF, but no LEDATA..." It's hard to do more, frankly. I did work at it. If you correction helps anyone else, I'm glad you added it.

My point wasn't about situations with very small amounts of memory. I would use this feature on very large systems with hundreds of small source files, in fact. And use it well.

In any case, I'm sure there were a lot of things on their (ISO) plate and I am just interested in Walter's comment. I'm not in trying to make a case for some ISO committee, much as I would like being able to control the value of link-time symbolics. If I were tilting that windmill, I've got much better issues to present them which would make a much larger difference in my life.

(Of course, if I were pressing the issue there I'd probably point out that the feature could be designed to have added no burden and cost nothing in terms of the development tools while providing a useful new semantic. Not that such an argument would have aided the idea.)

I disagree. But we'd need to dig into the details to be sure and I suspect that the compiler vendors would be able to nail that question far more quickly and decisively than either of us. So if they comment on this, I'll take their word about it either way.

Across all modules? I'm glad to hear it happens well in some cases.

I think my point regarding c remains.

Thanks for the discussion, Jon

Thank you all,

for your suggestions.. I'm certain to stumble ahead, but know where to start off now...

thanks again

krish.

Just another nitpicking... Casting integers to pointers are implementation defined rather than undefined...

3 An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. 5 An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

Rob

In C you'd have to emit the definition always, in C++ only if the address was taken. In both cases you can aggressively inline the constant and the definition will not end up in the executable as the linker will remove it.

To get back to the OP's question, what he wants to do is perfectly and efficiently supported in standard C like this:

typedef struct { int x, y, z; } T; T *const ptr = (T*) 0x8000; ptr->y = 1; // write to 0x8004

This means there is little reason to add non-standard extensions. The only gotcha that remains is ensuring the linker won't use this memory for something else, this can be done with linker scripts.

Wilco

Not in standard C. Because this conversion is implementation defined. Besides, this construct gives a wrong picture. Here storage is not allocated dynamically. There is also no transfer of storage [1] from another scope. Under these circumstances, using pointer notation is misleading.

A clean way of avoiding these pointer hacks would be to use a compiler extension.

There is that too. :-)

Have a nice day, Pradeep

[1] I am not sure about the term. What I mean is that the variable is declared in a scope that is visible to the code that operates on it. Hence there is no reason to use a pointer to the variable.

--
All opinions are mine and do not represent the views or
policies of my employer.
R Pradeep Chandran                 rpc AT pobox DOT com

Most compilers allow this, and don't even give a warning in their strictest mode. Compilers that don't do the obvious here are considered defective by their (soon to be ex) customers.

Pointers are useful in many ways, and definitely not just for dynamically allocated memory. For example pointers are the most obvious way to access peripherals.

However if you hate pointers there is nothing that stops you from writing:

#define p (*ptr) p.y = 1;

Unlike the pointer method, that doesn't work on most compilers, and the semantics of explicit variable placement vary significantly across compilers. It would be good if it was standardized at some point, but one can hope...

Wilco

To put it simply, somehow you need to put the new desired value of the constant into a form that the linker can understand.

You could open an old .o file in emacs and manually alter it...

You could put the definitions alone into a small .c file and recompile only those. Or the same with an assembly language file that you would assemble.

You could write a linker that lets you define things on the command line

You could write a tool that takes command line options and creates an object file...

It may, if those symbolics can be referenced in the c source. But I'm looking for source language constructs, too.

Agreed.

Jon

I can't agree. Your example requires storage for the pointer. In the case I'm talking about, there is no such storage required.

Jon

I was trying to explain above why this wasn't required - obviously I didn't do a good job! The definition can be optimised away as nothing refers to it. The ARM compiler generates this for the above statement:

MOV r0,#1 MOV r1,#0x8000 STR r0,[r1,#4]

On CPUs that have absolute addressing this would be even more efficient. Of course you need to recompile if you change the address.

Wilco

Thanks for the counterpoint. That may be true on some c++ compiler, but it would NOT be true for c compilers, which is what this is about (at least, to me.) And even in the c++ case, there remains a difference. I don't need to recompile c/c++ sources when I change the symbolic constant defined by the assembly module I use in some projects. I just re-assemble the symbolic constant file and relink the project.

Jon

I still wasn't clear enough - the above code is generated by a C compiler. There is no difference between C and C++ in this respect.

Sure, if you don't want to recompile then you need to use symbolic variables and explicitly place them. This can sometimes be done in the assembler or otherwise at linktime.

Wilco

Hmm. That may be, but wouldn't that violate the c standard? I have a vague memory that such optimizations aren't considered strictly correct.

Jon

The compiler/linker is much more likely to optimise away fetching a const pointer than it is to optimise away the const pointer completely you need to look for ptr in the data segment not at the generated code using ptr.

However,

typedef struct{int x, y, z;} T; #define ptr ((T*)0x8000) ptr->y = 1;

This works just the same and there is definitely no stored pointer.

You stopped reading too soon. I included the part "and proceeds to dereference that pointer" in that statement for a reason.

[...]

Exactly. And now you have to look up what happens if you dereference a pointer that currently is a trap representation. Guess what: that causes undefined behaviour.

The C standard defines a virtual machine which allows any optimizations as long as the observeable side effects (eg. output) remain the same.

How could you possibly observe the effect of constant folding or removal of unused variables (other than by looking at the binary)?

Wilco

My mind already went the way you just took. But another part of me says that the standard requires the storage be allocated. I just can't say, not being quite that deep into being a language lawyer. Are you?

Jon

Definitely not! But I'd always check with the language lawyers before adding exciting new optimizations. It was a long time ago, but I recall that the only issue in removing unused data or code could be the changed debug view. We took the decision that with maximum optimization the debug view was already so affected (or rather impaired) that this would hardly make a difference. At lower optimization levels these optimizations would not be done anyway.

Wilco