RE: H8SX: Bit instructions for review
Hi Jeff, create a GCC 4.5 pending patches PR and attach the updated patch to that PR Thanks a lot for your valuable suggestions and support. GCC-4.5 pending patches PR is already created at the following link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37515 The bug report H8SX enhancement is created (PR38091) and linked to metabug GCC 4.5 pending patches PR. Regards, Naveen.H.S. KPIT Cummins Infosystems Ltd, Pune ( INDIA ) www.kpitgnutools.com
RE: H8SX: Bit instructions for review
Hi Jeff, Don't forget to include the ChangeLog. Thanks a lot for verifying the patch and useful suggestions. causing the branch to be based on the output of the bit op rather than whatever was in cc0 from some previous operation Yes, the peepholes cause the branch to be based on the output of bit. However, the peepholes were implemented as they generate new conditional bit instructions. We realize that they do not help in any optimization. Hence, peepholes will be removed as per the suggestion and patch will be reposted when GCC returns to stage1. Regards, Naveen.H.S. KPIT Cummins Infosystems Ltd, Pune ( INDIA ) www.kpitgnutools.com
H8SX: Bit instructions for review
Hi, H8SX target supports generation of bit instructions in memory addressing mode. However, these instructions are not getting generated and the bits in memory are operated using other instructions which consume more memory. The attached patch h8sx.patch generates these bit instructions and hence generates optimized code. We are aware that currently GCC is in stage-3. However, this patch is just for review so that it can be modified according to the review comments. The modified patch will then be posted to the gcc-patches mailing list once it returns to stage-1. Regards, Naveen.H.S. KPIT Cummins Infosystems Ltd, Pune ( INDIA ) www.kpitgnutools.com h8sx.patch Description: h8sx.patch
RE: -mfmovd enabled by default for SH2A but not for SH4
Hi, Although one can explicitly provide his own fpscr setting as Christian said and can use appropriate options, defaulting -mdalign . for TARGET_SH2A_DOUBLE might be more robust for users. Yes, we completely agree that using the option -mdalign would solve the address error problem in the present testcase. We had tried the similar way to solve the problem. However, we observed that -mdlaign option would not guarantee the stack variables to be 8 byte aligned. Please refer the following link which explains the same. http://gcc.gnu.org/ml/gcc/2008-02/msg00508.html 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 February 4, 2008. ~~
-mfmovd enabled by default for SH2A but not for SH4
Hi,
SH2A, SH4 and SH4A FPU targets support mode switching i.e. switching
between single precision and double precision. Double-precision FPU
is also available for the above mentioned targets.
The option -mfmovd is enabled by default for SH2A which generates
fmov.d instruction by default. However, SH4 and SH4A targets
generates fmov.d instruction only after passing the option -mfmovd.
Can somebody clarify the reason behind above implementation?
The instruction fmov.d may generate address error exception in
some cases as the address involved in fmov.d instruction is not
always 8 byte aligned. This problem can be easily resolved by passing
option -mdalign(aligns double on 8 byte boundary).
The option -mfmovd is enabled by default for SH2A but option
-mdalign is not enabled by default. In case of SH4, SH4A neither of
the options are enabled by default.
Can we enable option -mdalign by default for SH2A target?
The following testcase results in address error at fmov.d instruction.
void a (void);
void a()
{
double b;
b = b + 526;
}
int main(void)
{
a();
return 0;
}
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 February 4, 2008.
~~
Target specific attributes to variables
Hi, We are implementing attributes to variables. The attribute of the operand is checked and the respective instructions are emitted based on the attributes. We have added the attribute to one addressing mode in which the operand is absolute memory (SYMBOL_REF). This was implemented by checking the tree value using the macro SYMBOL_REF_DECL. Even though the other 2 addressing modes are implemented, the attributes could not be checked in the other 2 modes. These 2 modes are disp with register and register indirect addressing modes. The tree structure in these addressing modes could not be checked for attributes using the RTX of the operand. We were unable to get any information from other target specific attributes. Any help/suggestions in solving the problem will be highly appreciated. 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 October 1, 2007. ~~
RE: SH2A: RTV/N Rn implementation
Hi, This is actually what I had in mind. You just need to also modify the epilogue expander to use that insn: sh_expand_epilogue (0); if (HAVE_return_rtv) emit_jump_insn (gen_return_rtv (gen_rtx_REG (SImode, R0_REG))); else emit_jump_insn (gen_return ()); Thanks for your valuable suggestion. We modified the epilogue as per your suggestions. RTV/N Rn instruction was generated with the operand as R0 in most of the case. The redundant transfer of register Rn to R0 before the epilogue is still generated. So RTV/N does not lead to any optimization in the code size. We masked this transfer when return type of the function is INTEGER_TYPE in the function expand_value_return (rtx val) in gcc/stmt.c. This resulted in some regression FAIL. RTV/N Rn is generated only when return type of the function is INTEGER_TYPE. How to avoid redundant move without any regression failures? We tried to get the register Rn from the function expand_value_return (rtx val) in gcc/stmt.c. The register Rn can be used as the operand in return_rtv. The Rn register obtained from the above function is a PSEUDO register. Kindly suggest a way to get HARD register instead of a PSEUDO register? 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: SH2A: RTV/N Rn implementation
Hi, My first shot at this would be to emit RTV/N in a dummy form as part of the epilogue and leave the usual Rn---R0 setup as it is, producing (set (reg R0) (reg Rn)) ... (parallel [ (set (reg R0) (reg R0)) (return) ]) and hope that the rnreg pass changes this to (set (reg R0) (reg Rn)) ... (parallel [ (set (reg R0) (reg Rn)) (return) ]) Thanks for your valuable suggestion. We had implemented an insn as:- (define_insn return_rtv [(parallel [ (set (reg:SI R0_REG) (match_operand:SI register_operand r)) (return)])] We modified the implementation after the suggestion as:- (define_insn return_rtv [(parallel [ (set (reg:SI R0_REG) (reg:SI R0_REG)) (return)])] The complier still did not recognize the RTL pattern and the RTV/N Rn instruction was not generated. Can you please comment on the above modifications? 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. ~~
SH2A: RTV/N Rn implementation
Hi, RTV/N instruction is one of the new instructions added in the SH2A target. Description : RTV/N instruction performs a return from a subroutine procedure after a transfer from specified general register Rn to R0. That is, after the Rn value is stored in R0, the PC is restored from PR, and processing is resumed from the address indicated by the PC. RTV/N Rn = Rn---R0 + RTS/N So RTV/N instruction can be used as an optimized return instruction in case of the functions having the return type as INTEGER_TYPE. This instruction moves the return argument of the function from register Rn---R0 along with RETURN. So there is no need to exclusively transfer the RETURN value of the function to RETURN_REG (R0) before RETURN. We implemented the direct RTL for RTV/N instruction and found that the RTL is not recognized by the GNUSH compiler. It was because the return value is moved from the register Rn---R0 before the epilogue sequence and RETURN is performed after the epilogue sequence. As the observation goes, all the architectures as incorporated in GCC transfers the RETURN value of a function to RETURN_REG (Rn---R0) before the epilogue sequence followed by RETURN. We investigated and found that the register transfer Rn---R0 is done in the top level file gcc/stmt.c. The function where this transfer is done is expand_value_return (rtx val). RTV/N instruction requires this transfer to be suppressed and using the register Rn in RETURN pattern as RTV/N Rn. Implementation : We tried to get the register (Rn) transferred to RETURN_REG(R0) from the function expand_value_return (rtx val). This register Rn needs to be used as the operand in RTV/N Rn instruction. However register (Rn) in the function expand_value_return (rtx val) is a PSEUDO REGISTER instead of a HARD REGISTER. RTV/N Rn expects the register Rn to be a hard register. Any help in implementing this instruction would be highly appreciated. 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
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.
~~
[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. ~~
FW: [M16C] : 20 bit data pointer
Hi, M16C has 20 bit physical address bus, but the address registers are only 16 bit. It has a 16 bit data pointer. ROM memory region starts at memory location 0x000A (i.e. 20 bit address). As the pointer size for GCC M16C is two bytes, it fails to access the memory region that is greater than 16 bits. So there is problem while accessing the const data and hard-coded strings which by default get placed in section .rodata section. Currently the complete .rodata section is copied from load address (ROM) to RAM, that is by treating it similar to .data section. We went through the discussion in the following link and realized that there should not be 2 pointers for the same data type as of now. http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01129.html Can the size of data pointer be increased to 20 bit? If yes, please guide me in implementing the same. 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 February 6, 2007. ~~
