[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Support for ATtiny416/417/816/817 ?

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Support for ATtiny416/417/816/817 ?
Date: Mon, 08 May 2017 19:34:28 +0200
User-agent: Thunderbird (Windows/20100228)

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__ : 0x4000;


  .text :
  }  > text

  .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
  } AT> text

  .data :
    PROVIDE (__data_start = .) ;
    . = ALIGN(2);
    _edata = . ;
    PROVIDE (__data_end = .) ;
  } > data AT> text

whereas avrxmega2 reads:

  .text :
  }  > text

  .data :
     PROVIDE (__data_start = .) ;
    *(.rodata)  /* We need to include .rodata here if gcc is used */
    *(.rodata*) /* with -fdata-sections.  */
    . = 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)?
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.


  to mapped region
  similar to the change you made in avrtiny.sc.

Analyzing if it is possible to implement.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]