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 repor

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 ou

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 h

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 i

RE: -mfmovd enabled by default for SH2A but not for SH4

Hi, >> Have you got this error on the real SH2A-FPU hardware? Yes, we got this error on SH72513(SH2A) hardware. When the same code is run on simulator, the "address error" occurs on encountering the "fmov.d" instruction. >> couldn't find any description for 8-byte alignment restriction for >> dou

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

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 t

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 f

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 t

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 pr

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 ('.frodat

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 initialize

[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 at

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 tha