Printable View
Hi all,
we are working in an embedded environment. We do care where variables are placed, RAM or ROM.
We would like to know how we can force the compiler to put a const object in ROM.
As long as Bar is not derived from Foo the objects are placed in ROM, if derived they end up in RAM.Code:class Foo
{
};
class Bar : public Foo
{
public:
unsigned char var;
};
Bar const ParamConfig1={1};
Bar const ParamConfig2={2};
Can anyone help us out?
Jef
Something like this could work:Quote:
Originally Posted by Jef Patat
Code:const int * const romaddress1 = (const int * const)0x0c000000;
const int * const romaddress2 = (const int * const)0x0c000004;
class Foo
{
protected:
const int * p1;
const int * p2;
public:
Foo() : p1(romaddress1), p2(romaddress2) {};
int getParamCofnig1() { return *p1; }
int getParamCofnig2() { return *p2; }
};
class Bar : public Foo
{
public:
Bar(int i = 0, int j = 0) : Foo() {
p1 = new int(i);
p2 = new int(j);
}
// Define copy constructor, destructor and assignement operator !!
};
Isn't there an easier way than using the raw address? Then you need to take care of size of Bar, what if there are several Bars with different sizes?
C++ doesn't have any standard way to specify usage of different types of memory.
However, your particular embedded platform may come with such functions. Check the documentation.
If you are not using a specific (raw) address in ROM, what's the point then. Having a variable take its value from any random address in ROM does not quite make sense to me.Quote:
Originally Posted by Jef Patat
Maybe you can explain better what you are trying to achieve.
I would not expect it to be at a random place in memory. Since it is constant I would expect the compiler to place it somewhere in ROM. Just as if you would have a global constant integer variable. You don't care where the compiler puts it but it should not be in RAM.
In fact the behavior seems to be correct according to point D1 in this document .
The problem is that this is so limiting in embedded where RAM is limited. If this holds true then this is a major drawback of ec++.
It is not the responsibility of a language to provide the means to specify such details.
It is the responsibility of the compiler designed for the hardware to do so, and to provide any library calls required to support such.
For example, when coding on a Blackfin, I used VisualDSP++ and wrote in C. Although C does not have functions like heap_malloc() for specifying which of the various heaps I wanted to allocate from (external, internal, or scratch memory), that function was provided by VDSP++ because it's in the Blackfin library.
The above link seems to indicate that the compiler will use its discretion in deciding which objects will go in ROM. It merely offers guidelines on the allowed characteristics of ROM objects.