This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]