I am programming an embbeded software on C for the MSP430. I need to allocate a certain pointer to a memory position....What I am trying to do is to get some info from my memory positions from 0x200 to 0x3c0 as volatile data. At a certain moment an interrupt at processor level through assembler inserts the variables into the memory where I will read... So far so good. The problem is that my own program overwrites this data sometimes by writting it's own enviroment variables. I would need a method to either allocate memory staticly or "reserve" certain memory positions from my ram so that my program cannot mess up with them on a dynamic memory allocation.... By the way, I am using IAR embedded workbench.
"Jan Homuth" wrote in news:bil6as$abl10$ snipped-for-privacy@ID-139563.news.uni-berlin.de:
Although all C compilers I've used act this way, the C standard does not require this behavior.
To the OP, you should ask the linker to reserve a block of RAM for you using the linker control file. The default linker control file is used when you build without explicitly specifiying one. I think they have the extension .xcl for the IAR toolchain. Anyhow, copy the default one you are using to a new name, like myproj.xcl, edit the RAM map area and create a new section, like myReservedRam, and then tell the toolchain to link with myproj.xcl using the correct flag to override the default .xcl file.
2 Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,11) which are changes in the state of the execution environment. Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (A summary of the sequence points is given in annex C.)
5 The least requirements on a conforming implementation are:
- At sequence points, volatile objects are stable in the sense that previous accesses are complete and subsequent accesses have not yet occurred.
11) The IEC 60559 standard for binary floating-point arithmetic requires certain user-accessible status flags and control modes. Floating-point operations implicitly set the status flags; modes affect result values of floating-point operations. Implementations that support such floating-point state are required to regard changes to it as side effects - see annex F for details. The floating-point environment library provides a programming facility for indicating when these side effects matter, freeing the implementations in other cases. ...
7 More stringent correspondences between abstract and actual semantics may be defined by each implementation.
EXAMPLE 1 An implementation might define a one-to-one correspondence between abstract and actual semantics: at every sequence point, the values of the actual objects would agree with those specified by the abstract semantics. The keyword volatile would then be redundant.
9 Alternatively, an implementation might perform various optimizations within each translation unit, such that the actual semantics would agree with the abstract semantics only when making function calls across translation unit boundaries. In such an implementation, at the time of each function entry and function return where the calling function and the called function are in different translation units, the values of all externally linked objects and of all objects accessible via pointers therein would agree with the abstract semantics. Furthermore, at the time of each such function entry the values of the parameters of the called function and of all objects accessible via pointers therein would agree with the abstract semantics. In this type of implementation, objects referred to by interrupt service routines activated by the signal function would require explicit specification of volatile storage, as well as other implementation-defined restrictions.
6.7.3 Type qualifiers
6 An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 188.8.131.52. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.114) What constitutes an access to an object that has volatile-qualified type is implementation-defined.
114) A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be ''optimized out'' by an implementation or reordered except as permitted by the rules for evaluating expressions.
As you can see the ISO standard (as the successor of the ANSI X3 159-1990 standard) does require this behaviour.
I assume that most crosscompilers for embedded targets adhere to this standard. At least the ones I have used so far do so. (TASKING, Keil, IAR, ... just to name a few).
with kind regards
Mark A. Odell schrieb in im Newsbeitrag: Xns93E577C265B0iiiCopyrightMarkOdel@184.108.40.206...