Re: Support for ATtiny416/417/816/817 ?

Pitchumani Sivanupandi schrieb:
> On Friday 05 May 2017 06:02 PM, Georg-Johann Lay wrote:
>> On 05.05.2017 12:07, Pitchumani Sivanupandi wrote:
>>> On Friday 05 May 2017 02:42 PM, Georg-Johann Lay wrote:
>>>> On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
>>>>> On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
>>>>>> Hi, the devices in $subject are not yet supported by the tools, 
>>>>>> mainly
>>>>>> because of missing Binutils support.
>>>>>>
>>>>>> Are there plans to add the needed emulation to Binutils?
>>>>>
>>>>> These devices are belongs to existing avrxmega2 family.
>>>>
>>>> This emulation might be used but will result in suboptimal code.
>>>>
>>>> For the mentioned devices, we want .rodata to be *not* a part of
>>>> data because just like avrtiny, what's definitely preferred is
>>>>
>>>> From avrtiny.x:
>>>>
>>>> __RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ?
>>>> __RODATA_PM_OFFSET__ : 0x4000;
>>>>
>>>> ...
>>>>
>>>>   .text :
>>>>   {
>>>>     ...
>>>>   }  > text
>>>>
>>>>   .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
>>>>   {
>>>>     *(.rodata)
>>>>     *(.rodata*)
>>>>     *(.gnu.linkonce.r*)
>>>>   } AT> text
>>>>
>>>>   .data :
>>>>   {
>>>>     PROVIDE (__data_start = .) ;
>>>>     *(.data)
>>>>     *(.data*)
>>>>     *(.gnu.linkonce.d*)
>>>>     . = ALIGN(2);
>>>>     _edata = . ;
>>>>     PROVIDE (__data_end = .) ;
>>>>   } > data AT> text
>>>>
>>>>
>>>> whereas avrxmega2 reads:
>>>>
>>>>
>>>>   .text :
>>>>   {
>>>>     ...
>>>>   }  > text
>>>>
>>>>   .data :
>>>>   {
>>>>      PROVIDE (__data_start = .) ;
>>>>     *(.data)
>>>>     *(.data*)
>>>>     *(.rodata)  /* We need to include .rodata here if gcc is used */
>>>>     *(.rodata*) /* with -fdata-sections.  */
>>>>     *(.gnu.linkonce.d*)
>>>>     . = ALIGN(2);
>>>>     _edata = . ;
>>>>     PROVIDE (__data_end = .) ;
>>>>   } > data AT> text
>>>>
>>>>
>>>> This part of avrtiny.x is what we also want to use for ATtiny816 and
>>>> friends, and the canonical way to provide it is to supply a new
>>>> emulation for "avrxmega2 + .rodata in flash".
>>>>
>>>>
>>>> Or are you saying that avrxmega2 like ATXmega16A4 also come with a
>>>> linear memory?  I skimmed the data sheet but I found no reference
>>>> to that feature.  Maybe the data sheets are outdated or bogus?
>>>
>>> No, linear memory is not common for all avrxmega2 devices.
>>> IMHO, instead splitting ISA emulation because of linear memory,
>>> we could try splitting/ parameterizing linker script to have .rodata
>>> in flash if possible.
>>
>> You have some proposal of how such a linker description file would
>> look like?  As far as I know there is no support for conditional
>> portions of scripts, just DEFINED, which is not powerful enough
>> to express what is needed.
>>
>> Moreover the compiler might start generating different code, for
>> example we could identify __flash address space with generic address
>> space.  The advantage is that generic space allow more instructions.
>>
>>
>> Just consider
>>
>> extern const char __flash data[];
>>
>> char get_data (int i)
>> {
>>     return data[i+1] + data[i+3];
>> }
>>
>> this could use LDD Ra,Z+1 and LDD Rb,Z+3.
>>
>>
>> Moreover the code will be different w.r.t. referencing __do_copy_data,
>> hence we start generating different code which is a strong indication
>> that we need a new multilib variant anyway.
>>
> Don't have any idea to implement conditional in linker script yet.
> But thinking of different solution than splitting emulation as number of
> emulations grow if new such device comes from other emulations.
> 
> How about having rodata in flash based on flag/ feature (avr-mcus.def 
> and specs file)?
> E.g.
>   Compiler puts rodata in section .flash.rodata if device has unified 
>   memory map
>   else puts in .ram.rodata. Linker script aggregates the .flash.rodata 

Then the new option must be a multilib option, hence we need a new 
multilib version anyways.  It's just much clearer if we add yet another 
-mmcu= as multilib option, for example -mmcu=avrxmega3.  There are 
currently no devices in that multilib set and Binutils already features 
avrxmega3.

And as I already mentioned, we'd like to adjust more of the code 
generation then where we put .rodata.

Johann

>   to mapped region
>   similar to the change you made in avrtiny.sc.
> 
> Analyzing if it is possible to implement.
> 
> Regards,
> Pitchumani