>I have recently started working more with people in the embedded community,
>and they have a strong interest in putting as much data into ROM as they
>can.  As a general rule, compilers are willing to ROM only constant
>expressions.

>The Diab C++ Compiler for PowerPC maps the first array (AnotherTabROM) to
>ROM and the second array (TabROM) to RAM, even though the contents of the
>second array are the same as those in the first array.

Scott

As someone who has about 5 years experience with the Diab data
compiler (and a few other embedded compilers), I will stick up for it
and say it is actually very good at ROMing all it can.

A related issue is that I tend to find in practice most compilers
reach a point of expression complexity where they give up trying to
ROM a value even though it looks constant to the programmer. e.g.

const int a = (1 << 25) ; // will get ROMed

const int b = (1 << 25) | (1 << 15 ); // also will

const int c = (~(((1 << 25) & 0xfffe)) | 37; // probably wont be

I can see that the value of c is constant, but somewhere around this
point of expression complexity the compiler gets too confused and
computes the value at run (before main() ) time - which means it has
to go in the RAM.

I think your example may be related to this, the value is constant but
there is too much complexity for the compiler to work it out.

Matt

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Matthew Towler" <newsgroups@mattnmanda.co.uk> wrote in message > A related issue is that I tend to find in practice most compilers
> reach a point of expression complexity where they give up trying to
> ROM a value even though it looks constant to the programmer. e.g.
>
> const int a = (1 << 25) ; // will get ROMed
>
> const int b = (1 << 25) | (1 << 15 ); // also will
>
> const int c = (~(((1 << 25) & 0xfffe)) | 37; // probably wont be

I don't understand why any of the above are any different.   All are
constant integer expressions.   No compiler that calls itself C++,
will have any problem reducing the above to a simple compile
time initialization.   For it is perfectly valid to do something like:

        char array[ (~(((1 << 25) & 0xfffe)) | 37 ];

Now for things that the compiler is not required to do at compile time, such as floating
point expressions, I could buy that.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Scott Meyers <Usenet@aristeia.com> wrote:
> I have recently started working more with people in the embedded community,
> and they have a strong interest in putting as much data into ROM as they
> can.  As a general rule, compilers are willing to ROM only constant
> expressions.  On the face of it, this seems reasonable, but consider the
> following (real) example:

>     int Var1, Var2, Var3;

>     int* const AnotherTabROM[] =
>     {
>       &Var1,
>       &Var2,
>       &Var3
>     };

Suppose a compilation unit end here, and in another one you have

extern int* const AnotherTabROM[];

>     class cOptimizedPtrTab
>     {
>       static int* const TabROM[];
>     };

>     int* const cOptimizedPtrTab::TabROM[] =
>     {
>       AnotherTabROM[0],
>       AnotherTabROM[1],
>       AnotherTabROM[2]
>     };

> The Diab C++ Compiler for PowerPC maps the first array (AnotherTabROM) to
> ROM and the second array (TabROM) to RAM, even though the contents of the
> second array are the same as those in the first array.

> 8.5.1/14 says that TabROM is statically initialized if all the member
> initializer expressions are constant expressions.  5.19/4 seems to say that
> TabROM's initializers don't qualify, because the pointers aren't "created
> explicitly, using the unary & operator, or implicitly using a non-type
> template parameter of pointer type, or using an expression of array (4.2)
> or function (4.3) type."  And yet it's clear that TabROM can be statically
> initialized and ROMed.  Given the Standard's utter silence on the topic of
> ROM, one must officially lay the blame at the feet of the compiler vendor,
> but in view of the tight coupling between constant expressions (as defined
> by the Standard) and what compiler vendors are generally willing to ROM, it
> would be nice to know whether there is any chance that the Standard's
> definition of "constant expression" could be enlarged a bit to handle
> situations such as this and, ideally, other circumstances where data values
> can be computed prior to runtime.

> Is any work being done in this area for C++0x?

The definition of a constant expression cannot be easily enlarged unless
the set of operations that the linker can perform is widened.

To put TabROM in the const data segment, the linker must handle
relocations of a (fantasy) type DEREF_RELOC
(compute the value of an expression with relocations and dereference it),
and the compiler must be sure of that linker capability.

        Leo (axe X's and squash Q's)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Scott Meyers wrote:
>
> Is any work being done in this area for C++0x?
>

Only what you've just done. Flesh it out and propose it.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
 George Santayana

"Bring them on."
 George W. Bush

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 13 Jul 2003 05:37:31 +0000 (UTC),  wrote:
> The definition of a constant expression cannot be easily enlarged unless
> the set of operations that the linker can perform is widened.

I agree that enlarging it across translation units would require linker
support, but what about enlarging it within a single translation unit?

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Usenet@aristeia.com (Scott Meyers) wrote in message news:<MPG.197be6ea33ca9cd59896fd@news.hevanet.com>...
> On Sun, 13 Jul 2003 05:37:31 +0000 (UTC),  wrote:
> > The definition of a constant expression cannot be easily enlarged unless
> > the set of operations that the linker can perform is widened.
>
> I agree that enlarging it across translation units would require linker
> support, but what about enlarging it within a single translation unit?

That can be done, but basing a language standard on restrictions of some N years
old linker is dubious at best. Therefore, I'd prefer the standard to enlarge the
definition of constant expression  across translation units, then the implementors
can do the part that does not require linker support right away.

      Leo

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I have recently started working more with people in the embedded community,
and they have a strong interest in putting as much data into ROM as they
can.  As a general rule, compilers are willing to ROM only constant
expressions.  On the face of it, this seems reasonable, but consider the
following (real) example:

    int Var1, Var2, Var3;

    int* const AnotherTabROM[] =
    {
      &Var1,
      &Var2,
      &Var3
    };

    class cOptimizedPtrTab
    {
      static int* const TabROM[];
    };

    int* const cOptimizedPtrTab::TabROM[] =
    {
      AnotherTabROM[0],
      AnotherTabROM[1],
      AnotherTabROM[2]
    };

The Diab C++ Compiler for PowerPC maps the first array (AnotherTabROM) to
ROM and the second array (TabROM) to RAM, even though the contents of the
second array are the same as those in the first array.

8.5.1/14 says that TabROM is statically initialized if all the member
initializer expressions are constant expressions.  5.19/4 seems to say that
TabROM's initializers don't qualify, because the pointers aren't "created
explicitly, using the unary & operator, or implicitly using a non-type
template parameter of pointer type, or using an expression of array (4.2)
or function (4.3) type."  And yet it's clear that TabROM can be statically
initialized and ROMed.  Given the Standard's utter silence on the topic of
ROM, one must officially lay the blame at the feet of the compiler vendor,
but in view of the tight coupling between constant expressions (as defined
by the Standard) and what compiler vendors are generally willing to ROM, it
would be nice to know whether there is any chance that the Standard's
definition of "constant expression" could be enlarged a bit to handle
situations such as this and, ideally, other circumstances where data values
can be computed prior to runtime.

Is any work being done in this area for C++0x?

Thanks,

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]