Re: [PATCH v3] c++: parser - Support for target address spaces in C++

[Georg-Johann Lay <avr@gjlay.de>]

Am 10.11.22 um 15:08 schrieb Paul Iannetta:
> On Thu, Nov 03, 2022 at 02:38:39PM +0100, Georg-Johann Lay wrote:
>>> [PATCH v3] c++: parser - Support for target address spaces in C++
>> 2. Will it work with compound literals?
>> =======================================
>>
>> Currently, the following C code works for target avr:
>>
>> const __flash char *pHallo = (const __flash char[]) { "Hallo" };
>>
>> This is a pointer in RAM (AS0) that holds the address of a string in flash
>> (AS1) and is initialized with that address. Unfortunately, this does not
>> work locally:
>>
>> const __flash char* get_hallo (void)
>> {
>>      [static] const __flash char *p2 = (const __flash char[]) { "Hallo2" };
>>      return p2;
>> }
>>
>> foo.c: In function 'get_hallo':
>> foo.c: error: compound literal qualified by address-space qualifier
>>
>> Is there any way to make this work now? Would be great!
>>
> 
> Currently, I implement the same restrictions as the C front-end, but I
> think that this restriction could be lifted.

Hi Paul,

this would be great.  FYI, due to AVR quirks, .rodata is located in RAM.
Reason behind this is that in functions like

char get_letter (const char *c)
{
     return *c;
}

there is no means to determine whether get_letter was called with a 
const char* or a char*.  Accessing flash vs. RAM would require different 
instructions, thus .rodata is part of RAM, so that RAM accesses will 
work in either case.

The obvious problem is that this wastes RAM. One way out is to define 
address space in flash and to pass const __flash char*, where respective 
objects are located in flash (.progmem.data in case of avr).

This is fine for objects which the application creates, but there are 
also artificial objects like vtables or cswtch tables.

>> 3. Will TARGET_ADDR_SPACE_DIAGNOSE_USAGE still work?
>> ====================================================
>>
>> Currently there is target hook TARGET_ADDR_SPACE_DIAGNOSE_USAGE.
>> I did not see it in your patches, so maybe I just missed it? See
>> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/Named-Address-Spaces.html#index-TARGET_005fADDR_005fSPACE_005fDIAGNOSE_005fUSAGE
> 
> That was a point I overlooked in my previous patch.  This will be in
> my new revision where I also add implicit conversion between
> address spaces and also expose TARGET_ADDR_SPACE_CONVERT.
> 
>> 4. Will it be possible to put C++ virtual tables in ASs, and how?
>> =================================================================
> 
> Currently, I do not allow the declaration of instances of classes in
> an address space, mainly to not have to cope with the handling of the
> this pointer.  That is,
> 
>    __flash Myclass *t;
> 
> does not work.  Nevertheless, I admit that this is would be nice to
> have.
> 
>> One big complaint about avr-g++ is that there is no way to put vtables in
>> flash (address-space 1) and to access them accordingly.  How can this be
>> achieved with C++ address spaces?
> 
> Do you want only the vtables in the flash address space or do you want
> to be able to have the whole class content.

My question is about vtables, not the bits that represent some object.
vtables are stored independently of objects, usually in .rodata + 
comdat.  Notice that vtables are read-only and in static storage, even 
if objects are neither.

The problem with vtables is that the user has no handle to specify where 
to locate them -- and even if, due to AVR quirks, the right instruction 
must be used.  Thus just putting vtables in flash by means of some 
section attribute won't work, only address-spaces can do the trick.

> 1. If you only want the vtables, I think that a target hook called
> at vtable creation would do the trick.

Yes, that would be enough, see https://gcc.gnu.org/PR43745

Johann

> 2. If you want to be able to have pointer to classes in __flash, I
> will need to further the support I have currently implemented to
> support the pointer this qualified with an address space.
> Retrospectively, I think this have to be implemented.
> 
> Paul

Would be great if this would work, but I think this can be really 
tricky, because it's already tricky for non-class objects.

A user has to specify __flash explicitly, which is quite different to 
plain objects.  For example, a const int can live in .rodata, but in 
cases like

extern int func();
extern const int ival;
const int ival = func();

ival would live in .bss and be initialized at runtime by a static 
constructor. Consequently,

const __flash int ival = func();

is invalid code that has to be diagnosed [1], because in the avr case, 
__flash means non-volatile memory, which contradicts initialization at 
runtime.

So only objects that are TREE_READONLY can go into AS __flash, 
TREE_CONST is not enough.

How is this problem addressed?  Does this require a new target hook to 
diagnose such cases, and does the compiler know at that stage that an 
object will be TREE_READONLY?

[1] Notice that in C it's enough to check that __flash is always 
accompanied by const, but in C++ this is not more enough as shown in the 
example above.

Johann


p.s: I just checked clang v16, it doesn't complain and accepts 
nonsensical code like:

extern int func();

extern const __flash int cval;
const __flash int cval = func();

int get_cval()
{
     return cval;
}

(clang puts cval into .bss and initializes at startup, but get_cval will 
read from flash due to __flash.)