Re: AVR C++ - how to move vtables into FLASH memory

Re: AVR C++ - how to move vtables into FLASH memory

[Tomasz Francuz]

As I can see in my first post I would like to modify gcc AVR backend to 
support new feature – putting vtables into FLASH not SRAM. That’s why I 
sent my message here.

Ok, I’ve studied a little bit gcc sources, I’ve found sections 
responsible for generating different register loading instructions, and 
indeed there is no information telling to the compiler how to load data 
from FLASH. This is easy to correct, I suppose. But I have no idea how 
compiler generates code responsible for loading pointers from vtable. I 
found code responsible for generating vtable itself. So please, can 
anybody point me to the peace of code responsible for loading pointers 
from vtables?

Re: AVR C++ - how to move vtables into FLASH memory

[Ian Lance Taylor]

Tomasz Francuz <tfrancuz@mp.pl> writes:

> Ok, I’ve studied a little bit gcc sources, I’ve found sections
> responsible for generating different register loading instructions,
> and indeed there is no information telling to the compiler how to load
> data 
>> From FLASH. This is easy to correct, I suppose. But I have no idea
>> how 
> compiler generates code responsible for loading pointers from
> vtable. I found code responsible for generating vtable itself. So
> please, can anybody point me to the peace of code responsible for
> loading pointers 
>From vtables?

The build_vtbl_ref function.

Ian

AVR C++ - how to move vtables into FLASH memory

[Tomasz Francuz]

I would like to change gcc so AVR C++ port will use FLASH memory instead 
of SRAM to store virtual function pointers. Does anyone try to do it? I 
have no experience as gcc developer, so can you head me to appropriate 
files/literature about this particular problem?

TIA.

Re: AVR C++ - how to move vtables into FLASH memory

[Ian Lance Taylor]

Tomasz Francuz <tfrancuz@mp.pl> writes:

> I would like to change gcc so AVR C++ port will use FLASH memory
> instead of SRAM to store virtual function pointers. Does anyone try to
> do it? I have no experience as gcc developer, so can you head me to
> appropriate files/literature about this particular problem?

This question would be more appropriate for the mailing list
gcc-help@gcc.gnu.org than for gcc@gcc.gnu.org.  Please take any
followups to gcc-help.  Thanks.

Virtual tables will normally be placed in the .rodata section which
holds read-only data.  All you should need to do it arrange for the
.rodata section to be placed in FLASH rather than SRAM.  This would
normally be done in your linker script.

Ian

Re: AVR C++ - how to move vtables into FLASH memory

[Denis Chertykov]

2009/6/16 Ian Lance Taylor <iant@google.com>:
> Tomasz Francuz <tfrancuz@mp.pl> writes:
>
>> I would like to change gcc so AVR C++ port will use FLASH memory
>> instead of SRAM to store virtual function pointers. Does anyone try to
>> do it? I have no experience as gcc developer, so can you head me to
>> appropriate files/literature about this particular problem?
>
> This question would be more appropriate for the mailing list
> gcc-help@gcc.gnu.org than for gcc@gcc.gnu.org.  Please take any
> followups to gcc-help.  Thanks.
>
> Virtual tables will normally be placed in the .rodata section which
> holds read-only data.  All you should need to do it arrange for the
> .rodata section to be placed in FLASH rather than SRAM.  This would
> normally be done in your linker script.

No, no. movMODE insns for AVR don't support FLASH (PROGMEM), only SRAM.

Denis.

Re: AVR C++ - how to move vtables into FLASH memory

[Zoltán Kócsi]

> This question would be more appropriate for the mailing list
> gcc-help@gcc.gnu.org than for gcc@gcc.gnu.org.  Please take any
> followups to gcc-help.  Thanks.
> 
> Virtual tables will normally be placed in the .rodata section which
> holds read-only data.  All you should need to do it arrange for the
> .rodata section to be placed in FLASH rather than SRAM.  This would
> normally be done in your linker script.

No, it won't work. The AVR is a Harvard architecture and the FLASH
is not mapped into the data address space. You need to use special
instructions to fetch FLASH data into registers. You load the FLASH
address in a register pair, possibly set a peripheral register to
select which 64K block of the FLASH you want to address, since the
register pair is only 16 bit wide and there can be up to 128K FLASH,
then do a byte or word load into a register or register pair.

The compiler *must* be aware of where the data is, because it needs to
generate completely different code to access data in the FLASH. 

I haven't used the AVR for a while, but as far as I know, gcc does
not provide any support for constants to be stored in FLASH, let it be
const data, gcc generated tables or anything. It was a pain in the
neck, because there's precious little amount of RAM on these processors,
and all your strings and gcc generated internal data were wasting RAM
(without you having any control over that) and even placing your own
data into FLASH required a fairly convoluted use of the section
attribute and inline asm routines to access it.

So it is indeed a valid compiler issue, not an incompetent user issue.
Probably an improvement request would be the best.

Zoltan

Re: AVR C++ - how to move vtables into FLASH memory

[Ian Lance Taylor]

Zoltán Kócsi <zoltan@bendor.com.au> writes:

> So it is indeed a valid compiler issue, not an incompetent user issue.
> Probably an improvement request would be the best.

Thanks for the details on the AVR.

The question of gcc vs. gcc-help is not one of compiler issues
vs. incompetent user issues.  Many highly competent users post on
gcc-help.  The question is one of using gcc vs. modifying gcc.  A
discussion of how to modify gcc's AVR backend to support putting the
virtual table in FLASH would be appropriate for gcc@.  A message like
yours is appropriate for gcc-help@.  Thanks.

Ian