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.
