Products > Programming

Memory Allocation in C: Compile Time vs. Run Time

<< < (10/10)

tggzzz:

--- Quote from: ejeffrey on October 02, 2023, 06:14:30 pm ---
--- Quote from: tggzzz on October 02, 2023, 09:59:42 am ---Some aspects of C really cannot be understood without understanding how processors+memory work. Even "experts" have had problems with that concept, as demonstrated by Hans Boehm (of the conservative GC fame) needing to write "Threads cannot be implemented as a library" in exhaustive detail http://hboehm.info/misc_slides/pldi05_threads.pdf

--- End quote ---

I look at that in exactly the opposite way.  Understanding the machine doesn't really help you here.  Actually it can and does lead you astray, since the guarantees that the hardware makes don't matter if the compiler doesn't expose them to the programmer in a usable fashion.  For instance, even recently I have argued against to people still using volatile for multi-thread synchronization that they shouldn't do that because it is incorrect.  They usually claim something like "I only care about x86 and this code is correct under x86 memory order guarantees."  That would be fine if they were using assembly, but it's not correct when writing C (or C++) because the C memory model is not the same as the architectural memory model.

--- End quote ---

We agree, except that my attitude is that not understanding the hardware allowed people to be blind to C's manifest deficiencies w.r.t. memory consistency.

I say "manifest" because K&R C was explicit that the language did not address threading, and that that was the responsibility of libraries. Subsequent generations of programmers didn't realise that, and blithely ignored the issue. Hence the need for Boehm's paper.

Instead the C committee spent years amusing themselves about whether it should be possible or impossible to "throw away  constness"; there are solid arguments for and against each.

That lack of decision made me decide that C was becoming part of the problem rather than part of the solution.

Others finally seem to agree, and soon Rust will supplant C in the same way that COBOL has been supplanted by Java and other languages.


--- Quote ---C and C++ needed a memory model to enable multi-threaded programming, and knowledge of the underlying architecture and it's memory model *was not* sufficient to produce correct multi-threaded code without it.

--- End quote ---

Scandalously C took quarter of a century to gain a memory model, even though is was obviously mandatory - as per Java!

Whether C's memory model and compilers' implementation is sufficient and correct is an open question in my mind. It is a very complex subtle topic; even Java got it subtly wrong and had to correct it after a decade of experience.


--- Quote ---
--- Quote ---The OP is targeting the 8051. Given how hostile that is to plain-vanilla C without extensions, good luck getting C code to work on that without understanding the 8051's arhitectural features.

--- End quote ---

That's a fair point, although at that point you have to debate whether you are programming C or "a C-like language"

--- End quote ---

Yup :)

tggzzz:

--- Quote from: SiliconWizard on October 02, 2023, 07:29:02 pm ---If you want much lower level than C, use assembly. Conversely, if the high-level aspects of C are not high-level enough to you or for implementing a given piece of software - at least according to your standards - use another language as well.

--- End quote ---

In the 1990s C.reached a point where it needed to decide whether to be a general purpose high level programming language, or a special purpose close to the silicon language. Either is good and acceptable.

It failed to decide, tried to be both, and failed at both.

People have moved on to Java for HLL purposes, and are moving on to Rust for close to silicon purposes. Good! About time too :)

SL4P:
You can be allocated a parking space, but never use it,
You can be assigned a parking space, but never use it,

There is a subtle difference.
Allocation means a space (unknown) has been noted, will be given ‘assigned to you when you need it.. it will be assigned to you.

Until it’s been ‘assigned’, other vehicles can use it, and you’ll never know about it,

c64:
Short answer to the original question.

Global variables

If your target has OS, it will be OS who allocate memory. Before your main() is started.

If you are on bare metal, there is no allocation needed. You already own all the memory available.

Locals and dynamic

These are allocated by your running application. Usually on stack/heap

c64:
Compiler or linker do not allocate anything. They calculate how much memory your application will require for all the global variables, and there they will be (variable x will be at address 0, variable y at address 8, etc.) when the application is running on your target device

Navigation

[0] Message Index

[*] Previous page