Re: [M16C] : 20 bit data access

[DJ Delorie <dj at redhat dot com>]

> - 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.