[Bug c++/43745] New: g++ puts VTABLES in SRAM

[Bug c++/43745] New: g++ puts VTABLES in SRAM

[tfrancuz at mp dot pl]

On AVR target g++ generates code which copies object’s VTABLES from FLASH
to SRAM wasting the memory. Due to the Harvard architecture of AVR processors
the solution is not trivial. This behavior can be observed in any c++ program
which has object with virtual method, e.g:
Class test
{
        virtual void example();
};

The VTABLE of class test will be generated in FLASH and next copied to SRAM,
any reference to virtual example() method will take the method address from
SRAM.


-- 
           Summary: g++ puts VTABLES in SRAM
           Product: gcc
           Version: 4.3.5
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tfrancuz at mp dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[eric dot weddington at atmel dot com]

------- Comment #1 from eric dot weddington at atmel dot com  2010-04-14 19:52 -------
What is your suggestion?


-- 

eric dot weddington at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target
 GCC target triplet|                            |avr
            Summary|g++ puts VTABLES in SRAM    |[avr] g++ puts VTABLES in
                   |                            |SRAM


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[tfrancuz at mp dot pl]

------- Comment #2 from tfrancuz at mp dot pl  2010-04-14 20:39 -------
(In reply to comment #1)
> What is your suggestion?

Because VTABLES are generated during compile time and they are const data there
is no need to copy them into SRAM. Appropriate addresses of virtual methods can
be read directly from FLASH and used to make indirect call as usual. As far as
I know the problem is that AVR port of gcc doesn’t have appropriate isns
to do that. The problem is extremely important because for example my program
uses 964 bytes of SRAM, from which 860 bytes are used for VTABLES (wasted).
This is a typical situation for any C++ program on AVR.
The only problem is speed penalty, LD instruction on AVR takes 1 cycle, whereas
LPM instruction needed for FLASH access 3 cycles, which gives total 2 or 6
cycles to read virtual method address respectively. So probably the best
solution is to add another gcc option (or pragma) to choose between storing
VTABLES only in FLASH (slower code execution) or moving it to SRAM (faster
execution for the cost of higher SRAM memory occupation).


-- 

tfrancuz at mp dot pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tfrancuz at mp dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745