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.