??? 05/19/08 20:34 Read: times |
#154919 - Confused? Responding to: ???'s previous message |
Shivaram Kumara Cunchala said:
When we use the word Optimise, we mean that the variable in the memory can be changed only by the compiler whenever the code is executed. No that is not what the term "Optimise" means at all. "Optimisation" is a process performed by the compiler at compile time (in some toolchains, the Linker can also perform some optimisations). The compiler cannot modify variables in memory at run-time! Volatile modifiers cannot be optimised by the compiler, Of course the modifier itself can't be optimised! The modifier tells the compiler that certain optimisations are disallowed for the affected variables. During linking process the code is allocated physical memory in the internal memory. Why only internal memory? Strictly, this is done by the Locator - but most Linkers these days include the Locator functionality. so during the link process (generation of .lnk file during compilation) The compilation process happens first; The Link process takes the output of the compilation process. Usage of a specific file type like ".lnk" would be entirely down to the particular toolchain - it has no general meaning. these variables are placed in the heap instead of main memory. What variables? The Heap is used for dynamic memory allocation at run-time - it is not allocated by the compiler or linker! Compiler cannot modify the variable until unless a copy is copied to RAM for execution. The Heap must be in RAM! The compiler cannot modify variables at all - that happens at run-time! So the compiler allocates a different memory location for the variable. Different from what? These are called un-optimised location. I have never heard that term used. the variables in this location are not dependent on the compiler to change the value. See above - the compiler cannot ever modify anything at runtime. Runtime modification are always done by the execution of your code! instead interrupt, ports, serial, hardware are given permission to access these variables when ever they raise a request. No: it's not the interrupts, ports, or anything else that modifies variables - it's your code! When a memory is optimised, then the life of that variable is limited only till the function executes then it is destroyed, No, that has nothing to do with optimisation! but volatile are not destroyed, but keep value in it till there is any change done by external entities. No, that is not true at all. Are you confusing 'volatile' with 'static'? Whenever these variables are accessed only the last updated value is seen in the register. Registers don't retain a "history" - so they can never have any value other than the last updated one! Uploading a example after this. the best example is RTC(Real Time Clock). in the PC. even when the PC is shut down , and later restarted, the clock updates the latest current time. Now I think you are confusing 'volatile' as a C keyword with "non-volatile" as applied to a memory that doesn't lose its contents when the power is removed! So when memory is optimised then it can be changed only through execution of explicit statement which modify the value. in the above case it does not change. That is missing the point. The volatile qualifier doesn't stop the variable from being changed - quite the opposite! The whole point of the volatile qualifier is precisely because the value can change - but the compiler has no visibility of the possible change, so may choose to optimise its access to the variable by not re-reading it if we use volatile modifier, this disables optimisation, forcing the program to fetch a new value from the variable every time variable is accessed. Yes, that is true! Always remember you cannot simulate the condition of volatile in c51 or any compiler Yes, you can. as Heap memory cannot be simulated in keil Heap memory has nothing to do with it - but it can be simulated in Keil or any other decent simulator! it can be seen only on hardware. Not true. |
Topic | Author | Date |
keyword volatile | 01/01/70 00:00 | |
Opposite! | 01/01/70 00:00 | |
volatile modifier | 01/01/70 00:00 | |
Incorrect | 01/01/70 00:00 | |
incorrect! | 01/01/70 00:00 | |
even more | 01/01/70 00:00 | |
A heap o' trouble | 01/01/70 00:00 | |
the curse of the PC programmers | 01/01/70 00:00 | |
meaning of "volatile" with example | 01/01/70 00:00 | |
example | 01/01/70 00:00 | |
gobbelygook | 01/01/70 00:00 | |
heap? | 01/01/70 00:00 | |
Confused? | 01/01/70 00:00 | |
Google told me... | 01/01/70 00:00 | |
link | 01/01/70 00:00 | |
go through my explanation | 01/01/70 00:00 | |
put simply... | 01/01/70 00:00 | |
thanks | 01/01/70 00:00 | |
answer accepted by interviewer | 01/01/70 00:00 | |
Not entirely | 01/01/70 00:00 | |
not input only | 01/01/70 00:00 | |
That's the kind of thing I'd be looking for...![]() | 01/01/70 00:00 |