RE: [M16C] : 20 bit data access
Hi DJ,
By default all the constant variables will be stored in the far memory
('.frodata' section) and will be accessed using LDE instruction. The
non-initialized non-constant variables will be stored in near memory
('.nbss' section) and will be accessed using MOV instructions. The
initialized non-constant variables will be stored in near memory
('.ndata' section) and will be accessed using MOV instructions.
* By default, all the constant variables will be placed in the far
memory. They will be accessed using LDE instructions ('.frodata'
section)).
* New attribute near will be added. This attribute will be used for
the latest M16C targets that have 4K/8K flash in near Memory.
* Constant variables specified with the attribute near will be placed
in a section .nrodata (near memory) and will be accessed using MOV
instruction.
* By default, non-constant initialized variables will be placed in near
memory.
* By default, non-constant non-initialized variables will be placed in
near memory.
* New attribute far (to use external memory for non-constant data
storage) will be added.
* Non-constant non-initialized variables specified with the attribute
far will be placed in a section .fbss (far memory).
* Non-constant initialized variables specified with the attribute far
will be placed in a section .fdata (far memory).
* LDE/STE instructions will be used to access the non-constant variables
specified with the attribute far.
* MOV instructions will be used to access the constant variables
specified with the attribute near.
* Default linker script will be modified for placing the default section
'.nbss', '.ndata' and '.nrodata' in near memory and '.fbss', '.fdata'
and '.frodata' in far Memory.
* Separate libraries will be used for R8C and M16C targets.
* As the libraries will be built without any attribute, all the constant
data in library will be accessed using LDE instructions. Similarly,
non-constant non-initialised and non-constant initialised data in
library will be accessed using MOV instructions.
I'd prefer just one far attribute. GCC knows (usually better than
the user ;) what data is read-only and what data is not.
Done
- By default, LDE instructions will be used to access the entire
constant variables.
Perhaps with a compiler switch? Like -mcpu=m16c? ;-) I wouldn't want
to use LDE on an r8c which doesn't *have* far memory.
We'd need to add a new multilib for that if we did. If we do add an
m16c multilib, perhaps we should make the m16c 16 bit aligned
internally, to speed performance? Currently, it doesn't, because it's
more important to save space on the r8c, which has an 8 bit internal
bus.
- New attribute near_rodata will be added. This attribute will be
used for the latest M16C targets that have 4K/8K flash in near Memory.
Again, let's just add near and let gcc figure out if it's read-only
or not.
Please comment on above proposed solutions and also let us know the
possibility of acceptance of any of these by FSF.
From the above, I think I like this plan:
* Add both near and far attributes. If a variable has one of
these, it overrides whatever gcc's default is. GCC knows what's
read-only and what isn't, and which chips take advantage of which
attributes, but there's no reason to burden the user with that
decision.
* Add an m16c (vs r8c) multilib, and have it default to far
constants, near data. Pick up word-alignment too, maybe. This
makes the defaults for most chips close to ideal.
* Add .ndata, .nbss, .nrodata, .fdata, .fbss, .frodata to the linker
scripts. Stuff with near/far attributes goes into .n*/.f* sections.
Depending on the chip, these may just get merged with the usual
.data, .bss, .rodata sections (i.e. m32c and most r8c will always
merge them, most m16c won't merge .rodata, etc).
* If we add an m16c multilib, do we want to add an m32c (vs m32cm)
multilib at the same time? That would let us use the extra 32-bit
insns in libgcc. I'm just thinking, if we're going to change the
multilibs anyway, let's use that change to get some other stuff in
also.
Re: [M16C] : 20 bit data access
Hi DJ,
From the above, I think I like this plan:
Please ignore my earlier post on this topic. We have modified the
proposed solution to incorporate your suggestions. We would be glad if
you could verify it again.
By default all the constant variables will be stored in the far memory
('.frodata' section) and will be accessed using LDE instruction. The
non-initialized non-constant variables will be stored in near memory
('.nbss' section) and will be accessed using MOV instructions. The
initialized non-constant variables will be stored in near memory
('.ndata' section) and will be accessed using MOV instructions.
* By default, all the constant variables will be placed in the far
memory. They will be accessed using LDE instructions ('.frodata'
section)).
* New attribute near will be added. This attribute will be used for
the latest M16C targets that have 4K/8K flash in near Memory.
* Constant variables specified with the attribute near will be placed
in a section .nrodata (near memory) and will be accessed using MOV
instruction.
* By default, non-constant initialized variables will be placed in near
memory.
* By default, non-constant non-initialized variables will be placed in
near memory.
* New attribute far (to use external memory for non-constant data
storage) will be added.
* Non-constant non-initialized variables specified with the attribute
far will be placed in a section .fbss (far memory).
* Non-constant initialized variables specified with the attribute far
will be placed in a section .fdata (far memory).
* LDE/STE instructions will be used to access the non-constant variables
specified with the attribute far.
* MOV instructions will be used to access the constant variables
specified with the attribute near.
* Default linker script will be modified for placing the default section
'.nbss', '.ndata' and '.nrodata' in near memory and '.fbss', '.fdata'
and '.frodata' in far Memory.
* Separate libraries will be used for R8C and M16C targets.
* As the libraries will be built without any attribute, all the constant
data in library will be accessed using LDE instructions. Similarly,
non-constant non-initialised and non-constant initialised data in
library will be accessed using MOV instructions.
Please comment on the above proposed solution.
Regards,
Naveen.H.S.
KPIT Cummins Infosystems Ltd,
Pune (INDIA)
~~
Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C
and M32C Series. The following site also offers free technical support
to its users. Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on June 1, 2007.
~~
Re: [M16C] : 20 bit data access
By default all the constant variables will be stored in the far memory
('.frodata' section) and will be accessed using LDE instruction. The
non-initialized non-constant variables will be stored in near memory
('.nbss' section) and will be accessed using MOV instructions. The
initialized non-constant variables will be stored in near memory
('.ndata' section) and will be accessed using MOV instructions.
No, by default constants are in .rodata and non-constants are in
.data/.bss. Always. The big difference is that on the m16c, .rodata
is above 64k and LDE will be used to access it, but it's still called
.rodata.
ONLY if the user specifies near or far attributes will anything be
placed in .n* or .f*; this is an override. Those sections will always
be in near or far space (er, it's acceptable to put .f* in near memory
if the chip doesn't *have* far memory, of course).
Also, we need to support the user specifying both near/far *and* a
section override.
* By default, all the constant variables will be placed in the far
memory. They will be accessed using LDE instructions ('.frodata'
section)).
.rodata, but ok. Assumed m16c only for LDE to .rodata.
* New attribute near will be added. This attribute will be used for
the latest M16C targets that have 4K/8K flash in near Memory.
Any target can use near or far attributes. It's up to the linker
script to decide where they're mapped.
* Constant variables specified with the attribute near will be placed
in a section .nrodata (near memory) and will be accessed using MOV
instruction.
Ok.
* By default, non-constant initialized variables will be placed in near
memory.
Depends on the chip. m32c doesn't assume that.
* By default, non-constant non-initialized variables will be placed in
near memory.
Likewise.
* New attribute far (to use external memory for non-constant data
storage) will be added.
Ok, but for *any* data you want to force into far memory.
* Non-constant non-initialized variables specified with the attribute
far will be placed in a section .fbss (far memory).
Ok.
* Non-constant initialized variables specified with the attribute far
will be placed in a section .fdata (far memory).
Ok.
* LDE/STE instructions will be used to access the non-constant variables
specified with the attribute far.
Ok.
* MOV instructions will be used to access the constant variables
specified with the attribute near.
Ok.
* Default linker script will be modified for placing the default section
'.nbss', '.ndata' and '.nrodata' in near memory and '.fbss', '.fdata'
and '.frodata' in far Memory.
Ok. Also, .rodata can be in far memory on m16c. For most R8C, .f*
should be put in near memory, because that's all it has.
* Separate libraries will be used for R8C and M16C targets.
Ok.
* As the libraries will be built without any attribute, all the constant
data in library will be accessed using LDE instructions. Similarly,
non-constant non-initialised and non-constant initialised data in
library will be accessed using MOV instructions.
Ok, for m16c. For r8c, everything defaults to near(*), for m32c,
everything defaults to far, and the linker sorts it out.
(*) even the r8c/2d, which have far flash, have enough near flash to
handle .rodata, and near accesses are more optimal than far accesses
most of the time.
Re: [M16C] : 20 bit data access
- 2 new attributes far_data (to use external memory for data storage) and far_rodata will be added. I'd prefer just one far attribute. GCC knows (usually better than the user ;) what data is read-only and what data is not. - By default, LDE instructions will be used to access the entire constant variables. Perhaps with a compiler switch? Like -mcpu=m16c? ;-) I wouldn't want to use LDE on an r8c which doesn't *have* far memory. We'd need to add a new multilib for that if we did. If we do add an m16c multilib, perhaps we should make the m16c 16 bit aligned internally, to speed performance? Currently, it doesn't, because it's more important to save space on the r8c, which has an 8 bit internal bus. - New attribute near_rodata will be added. This attribute will be used for the latest M16C targets that have 4K/8K flash in near Memory. Again, let's just add near and let gcc figure out if it's read-only or not. Please comment on above proposed solutions and also let us know the possibility of acceptance of any of these by FSF. From the above, I think I like this plan: * Add both near and far attributes. If a variable has one of these, it overrides whatever gcc's default is. GCC knows what's read-only and what isn't, and which chips take advantage of which attributes, but there's no reason to burden the user with that decision. * Add an m16c (vs r8c) multilib, and have it default to far constants, near data. Pick up word-alignment too, maybe. This makes the defaults for most chips close to ideal. * Add .ndata, .nbss, .nrodata, .fdata, .fbss, .frodata to the linker scripts. Stuff with near/far attributes goes into .n*/.f* sections. Depending on the chip, these may just get merged with the usual .data, .bss, .rodata sections (i.e. m32c and most r8c will always merge them, most m16c won't merge .rodata, etc). * If we add an m16c multilib, do we want to add an m32c (vs m32cm) multilib at the same time? That would let us use the extra 32-bit insns in libgcc. I'm just thinking, if we're going to change the multilibs anyway, let's use that change to get some other stuff in also.
[M16C] : 20 bit data access
Hi, We have come up with two possible solutions to solve the 20 bit data access problem in m16c targets. We are very grateful for all the suggestions until now on this issue. Solution 1 is based on the discussion at the following link -: http://gcc.gnu.org/ml/gcc/2007-04/msg00402.html - 2 new attributes far_data (to use external memory for data storage) and far_rodata will be added. - Non-constant initialized variables specified with the attribute far_data will be placed in the section .fdata (far memory). - Constant variables specified with the attribute far_rodata will be placed in the section .frodata (far memory). - Default linker script will be modified for the addition of two new sections .fdata and frodata. - LDE/STE instructions will be used to access the variables specified with the attribute far_data and far_rodata. - Default constant strings (ex. strings in printf) and constant variable without the attribute far_rodata will be placed in Section '.rodata' (current implementation). - The section '.rodata' has to be still copied from ROM to RAM (current implementation for M16C devices that does not have Flash in near memory). Solution 2 based on the discussion at the following link -: http://sources.redhat.com/ml/binutils/2007-05/msg00381.html - By default, LDE instructions will be used to access the entire constant variables. - A new target specific option -mno-far-constdata will be added. - This option can be used to override default generation of LDE instructions. 'MOV' instruction will be used to access these variables instead (current implementation). - New attribute far_data (to use external memory for data storage) will be added. - Non-constant initialized variables specified with the attribute far_data will be placed in a section .fdata (far memory). - LDE/STE instructions will be used to access the non-constant variables specified with the attribute far_data. - New attribute near_rodata will be added. This attribute will be used for the latest M16C targets that have 4K/8K flash in near Memory. - Constant variables specified with the attribute near_rodata will be placed in a section .nrodata (near memory). - MOV instructions will be used to access the constant variables specified with the attribute near_rodata. - Default linker script will be modified for placing the default section '.rodata' in Far Memory. - Default linker script will be modified for the addition of a new section '.fdata' in far memory and nrodata in near memory. Please comment on above proposed solutions and also let us know the possibility of acceptance of any of these by FSF. Regards, Naveen.H.S. KPIT Cummins Infosystems Ltd, Pune (INDIA) ~~ Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on June 1, 2007. ~~
