global vars

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again; a short question I should really have check on, though;

 

 

when compiling separate files (gcc for C files), and having vars declared "outside", like global declarations when made in file containing main(); does the compiler really cope with those

and make these global, but accessible only the the routines in the separately complied file unit. (I have some feeling that there could be problems/mixup, though I have used it)

When I look at map/list files they give the impression that it is ok......

OR do all globals have to be placed before main in the file contining main ?

 

many thanks (for possible stupid question, but these issues arn't really obvious for where answers appear (ref-man) )

/georg

Last Edited: Sat. Aug 15, 2020 - 05:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The thing that makes them "global" (and hence accessible from any other .c in the project) is simply that they are defined outside the body of any function. Doesn't have to be the file with main() and if it is it doesn't matter whether before or after that function.

 

But before using globals widely find out about "static" and when it's a good idea to use it. Also find out about "scope" and how to limit it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aha, so what Im possibly after is static, will read. However, if they are global, I guess they are static as well...... the file structure in different .o files couldnt imply re-initiations of variable at runtime could they.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To access functions and variables in other files, you need to declare them.  For example

int foo(int x);  // now I can call foo, which is defined in another file
extern double x;  // now I can reference the variable x defined in another file

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gechxx wrote:
However, if they are global, I guess they are static as well.
No

[page 224]

Box 7-2: Bug Alert -- The Dual Meanings of static

[second paragraph]

One way of reconciling these dual meanings [1. override auto, 2. scope] is to think of static as signifying both file scoping and fixed duration. ...

in C: A Software Engineering Approach | Peter A. Darnell | Springer

[page 235]

Table 7-1. Semantics of Storage-Class Specifiers

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know it's far out but one could actually argue that a global just is a static that happens to be seen in the hole scope.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well sparrow, that was my thought, the variables I have in the local compiled routines file, are "visible" only to the routines there (if not using external in another routine, which will bring them in),

but still preserved in fixed locations, untouched between calls to functions of that file

 

while the answer from you chapman gives indication that there could be difference ( I have experieced "overwrite" problems, that go away when moving out declarations from local file definition, to be in the main file, while that might just be coincidence, guess I at last will need to move out of my m8 to an m88 and get a bugger :)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a relative newcomer to embedded development, coming from a background of 'big' computers, my sense is that globals are 'bad' and variable scope should be as limited as possible. I would always prefer to allocate automatically or dynamically, and then pass references/pointers to other functions.

 

However, on small memory processors, the use of globals (or function-local statics) means that memory usage is much more deterministic. That is, if most variables are global/static (as opposed to automatic/stack or dynamic/heap), then if the program runs at all, it's less likely to face out-of-memory errors later on, because stack usage is reduced to a minimum.

 

Of course, you might argue that a program's runtime should always be deterministic, and thus it's memory use as well. You might also argue that the processor (and its memory capacity) should be chosen to meet the program's requirements, but we all know about creeping featurism, etc.

 

(Variables shared with ISRs are clearly an exception, and volatile).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gechxx wrote:

when compiling separate files (gcc for C files), and having vars declared "outside", like global declarations when made in file containing main(); does the compiler really cope with those

and make these global, but accessible only the the routines in the separately complied file unit.

 

The meaning of "global" is not always strictly defined. Typically, the term "global variables" refers to variables with external linkage, i.e. variables that are [potentially] accessible ("linkable") from the entire program, from all translation units of the program.

 

Having said that, yes, the compiler sees external variables as global (unless they are declared with internal linkage: e.g. `static`) and assumes that they are truly global. For example, it assumes that virtually any call to an unknown function defined in other translation unit can change any of these variables. This can significantly impede optimizations. For this reason alone, it is an extremely bad practice to declare variables as global when they don't need to be global. 

 

Many modern implementations support so called "global optimizations", which can potentially eliminate the negative impact from unjustified pessimizations triggered by global variables, but things are still far from perfect in this area.

 

If you need a persistent variable accessible in only one translation unit, make sure to declare it with internal linkage (e.g. `static`). This will easily result in much better code generated by the compiler.

Dessine-moi un mouton

Last Edited: Sat. Aug 15, 2020 - 08:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, Im not sure I get the significance of this.

 

Basically I use the "local globals" in a specific compilation unit (c file), as a "package", that ie variables that are of concern only to the routines in that file.

(so I dont need to declare them in main when including the package).

However I do peep into those variables (mainly or even only) for debug purposes, using extern declaration.

 

So, if I get things, if I do declare them as static and on the "outside" of the routines (package) of the specific compilation unit(file), that will

be "more efficiently" treated (hmm including erroneous handling avoidance ?) by the compiler/linker ? but not accessible via extern declaration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
... my sense is that globals are 'bad' ...
yet sometimes necessary.

Globals are visible to the linker and binder; existing C source code can be re-used with the remainder of the application implemented in another computer language.

obdevel wrote:
... because stack usage is reduced to a minimum.

 

Of course, you might argue that a program's runtime should always be deterministic, and thus it's memory use as well.

Stack is good and stack usage can be verified (tools) and constrained (by exceptions and/or assertions)

 


C: A Software Engineering Approach | Peter A. Darnell | Springer

7.3 Global Variables

[top of page 225]

Because global names must be recognized not only by the compiler but also by the linker or binder, their naming rules are a little different.

...

[pages 227 and 228]

Box 7-3: Non-ANSI Strategies for Declaring Global Variables

[K&R, Unix, portable]

Programming Languages Supported by GCC | G++ and GCC (Using the GNU Compiler Collection (GCC))

On Stacks - The Embedded Muse 309

Other stack-usage analysis tools

GNATstack - Adacore

AVR | 7. Machine Specific Topics — GNATstack 20.0w documentation

Mastering stack and heap for system reliability: Part 1 – Calculating stack size | Embedded

How to Prevent and Detect Stack Overflow | Barr Group

 

a lamentation in a comment :

Are We Shooting Ourselves in the Foot with Stack Overflow? « State Space

 

edit :

Detecting and Avoiding Stack Overflow in IoT/Embedded Systems | ThreadX | Express Logic

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Aug 15, 2020 - 09:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure I read you straight, but I think the answer is yes:   By the way C calls the file (and its included files) you hand to the compiler a "translation unit".  IIRC, if you define a function in a translation unit as static then gcc will optimize out save/restore of registers that are called out by the (avr-libc) spec.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gechxx wrote:

Basically I use the "local globals" in a specific compilation unit (c file), as a "package", that ie variables that are of concern only to the routines in that file.

(so I dont need to declare them in main when including the package).

However I do peep into those variables (mainly or even only) for debug purposes, using extern declaration.

 

In order to peep into those variables from other translation units of your code, you will be forced to give these variables external linkage. For this reason it makes sense to have two configurations of your project: debug and release. In debug configuration you give all such variables external linkage to make them "peepable" form anywhere. In release configuration you make them `static` to allow the compiler to generate the most efficient code.

 

Of course, within this approach you will have to ensure that all such variables have globally unique names. (While variables with permanent internal linkage do not need to have globally unique names.)

 

Another approach would be to give these variables permanent internal linkage ('static'), but provide an externally linkable function (in the same translation unit), which will report the values of interest to other translation units.

 

gechxx wrote:

So, if I get things, if I do declare them as static and on the "outside" of the routines (package) of the specific compilation unit(file), that will

be "more efficiently" treated (hmm including erroneous handling avoidance ?) by the compiler/linker ? but not accessible via extern declaration.

 

True.

 

Note, BTW, that in a typical step-by-step debugger variables with internal linkage are normally still "peepable" from anywhere through debugger commands. 

Dessine-moi un mouton

Last Edited: Sun. Aug 16, 2020 - 10:49 AM