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