Products > Programming

Memory Allocation in C: Compile Time vs. Run Time

<< < (9/10) > >>

Kittu20:
AT89S52 microcontroller executes programs from its flash memory by fetching, decoding, and executing instructions stored in flash memory. It uses a program counter to keep track of the next instruction to execute, allowing it to run the program sequentially.

The opcode is the part of an instruction that defines the operation to be performed (e.g., 'MOV' for move), while the operand specifies the data or location involved (e.g., '#5' for a constant). Machine code is the binary representation of these instructions stored in the microcontroller's flash memory, which the CPU directly executes.

SFR (Special Function Register) addresses, as detailed in Datasheet Table 1 on Page 5, are memory-mapped locations that provide access to specific functions and configurations. Microcontroller programmers utilize these SFR addresses to configure I/O pins, set up timer/counters, control interrupts, and interact with other hardware modules.

I can find SFR address information in the header file.

https://www.keil.com/dd/docs/c51/atmel/regx51.h

I think the compiler assigns these addresses at compile time, so when it generates the executable file , they should be hard-coded. they remain the same when the program is running on the microcontroller.

ejeffrey:

--- 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.

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.


--- 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"

SiliconWizard:

--- 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,

--- End quote ---

I actually agree with both of you on different levels. The two are not mutually exclusive, contrrary to how it may look at first thought.

- I agree with that fact that understanding the low-level aspects of the hardware is a definite requirement for really understanding C.
- But I do agree that with this knowledge must come the appropriate level of abstraction when you design your code, and this level entirely depends on what exactly you are designing.

C is precisely this spot - that's often been considered a sweet spot, at least until now - between low-level and high-level, and as such requires a good command of both.

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.

SiliconWizard:

--- Quote from: DiTBho on October 02, 2023, 11:46:20 am ---Intel 51 is one of the architecture that you d best program in assembly.

--- End quote ---

It's not pretty but I've used C for 8051-based MCUs (like the Cypress FX stuff) using SDCC and it was perfectly usable once you got familiar with the limitations.

DiTBho:

--- Quote from: SiliconWizard on October 02, 2023, 07:30:43 pm ---
--- Quote from: DiTBho on October 02, 2023, 11:46:20 am ---Intel 51 is one of the architecture that you d best program in assembly.

--- End quote ---

It's not pretty but I've used C for 8051-based MCUs (like the Cypress FX stuff) using SDCC and it was perfectly usable once you got familiar with the limitations.

--- End quote ---

perfectly usable ... sure, even a colleague of mine also spoke well about it, then I noticed that he wasn't even aware of the various problems that the 8032 and 8051 have, he had taken a ready-made template project found on a GitHub, modified it, and "oh, look, it can be programmed, perfectly usable"

A bloody Genius  :o :o :o

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod