Message ID | 20210709042608.883256-1-richard.henderson@linaro.org |
---|---|
Headers | show |
Series | target/riscv: Use tcg_constant_* | expand |
On 2021/7/9 下午12:25, Richard Henderson wrote: > Replace use of tcg_const_*, which makes a copy into a temp > which must be freed, with direct use of the constant. > > Reorg handling of $zero, with different accessors for > source and destination. > > Reorg handling of csrs, passing the actual write_mask > instead of a regno. > > Use more helpers for RVH expansion. Hi Richard, In patch 09-17 target/riscv: Reorg csr instruction, I think the parameter name 'rc' can be renamed to 'csrno'. Otherwise, Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Also on a side note, could you give me some advice for the following question? I have been supporting running 32bit application on qemu-riscv64. After this patch set, it is hard to define a method, such as gpr_dst_s or gpr_dst_u, to extend the destination register. I can only extend the destination register(ext32s or ext32u) in each instruction with scattered code. Can we just omit the extension of the destination register? Best Regards, Zhiwei > > r~ > > > Richard Henderson (17): > target/riscv: Use tcg_constant_* > target/riscv: Introduce gpr_src, gpr_dst > target/riscv: Use gpr_{src,dst} in shift operations > target/riscv: Use gpr_{src,dst} in word division operations > target/riscv: Use gpr_{src,dst} and tcg_constant_tl in gen_grevi > target/riscv: Use gpr_src in branches > target/riscv: Use gpr_{src,dst} for integer load/store > target/riscv: Use gpr_{src,dst} for word shift operations > target/riscv: Reorg csr instructions > target/riscv: Use gpr_{src,dst} for RVA > target/riscv: Use gpr_{src,dst} for RVB > target/riscv: Use gpr_{src,dst} for RVF > target/riscv: Use gpr_{src,dst} for RVD > target/riscv: Tidy trans_rvh.c.inc > target/riscv: Use gen_arith for mulh and mulhu > target/riscv: Use gpr_{src,dst} for RVV > target/riscv: Remove gen_get_gpr > > target/riscv/helper.h | 6 +- > target/riscv/insn32.decode | 1 + > target/riscv/op_helper.c | 18 +- > target/riscv/translate.c | 273 +++++++++----------- > target/riscv/insn_trans/trans_rva.c.inc | 42 ++-- > target/riscv/insn_trans/trans_rvb.c.inc | 11 +- > target/riscv/insn_trans/trans_rvd.c.inc | 116 ++++----- > target/riscv/insn_trans/trans_rvf.c.inc | 134 ++++------ > target/riscv/insn_trans/trans_rvh.c.inc | 264 ++++--------------- > target/riscv/insn_trans/trans_rvi.c.inc | 322 ++++++++++++++---------- > target/riscv/insn_trans/trans_rvm.c.inc | 24 +- > target/riscv/insn_trans/trans_rvv.c.inc | 144 ++++------- > 12 files changed, 534 insertions(+), 821 deletions(-) >
On 7/15/21 4:21 AM, LIU Zhiwei wrote: > Also on a side note, could you give me some advice for the following question? > > I have been supporting running 32bit application on qemu-riscv64. After this patch set, > it is hard to define a method, such as gpr_dst_s or gpr_dst_u, to extend the destination > register. I can only extend the destination register(ext32s or ext32u) in each instruction > with scattered code. > > Can we just omit the extension of the destination register? It's hard to give advice on code that I haven't seen. In general I would think that the destination register need not be extended for 32-bit mode, unless the architecture says otherwise. (What does the architecture say about the contents of the registers when transitioning from a 32-bit mode user program to a 64-bit mode kernel?) r~
On 2021/7/16 上午12:15, Richard Henderson wrote: > On 7/15/21 4:21 AM, LIU Zhiwei wrote: >> Also on a side note, could you give me some advice for the following >> question? >> >> I have been supporting running 32bit application on qemu-riscv64. >> After this patch set, >> it is hard to define a method, such as gpr_dst_s or gpr_dst_u, to >> extend the destination >> register. I can only extend the destination register(ext32s or >> ext32u) in each instruction >> with scattered code. >> >> Can we just omit the extension of the destination register? > > It's hard to give advice on code that I haven't seen. > > In general I would think that the destination register need not be > extended for 32-bit mode, unless the architecture says otherwise. > (What does the architecture say about the contents of the registers > when transitioning from a 32-bit mode user program to a 64-bit mode > kernel?) > As privileged specification says, "Whenever XLEN in any mode is set to a value less than the widest supported XLEN, all operations must ignore source operand register bits above the configured XLEN, and must sign-extend results to fill the entire widest supported XLEN in the destination register. Similarly, pc bits above XLEN are ignored, and when the pc is written, it is sign-extended to fill the widest supported XLEN." If we want to strictly obey the spec, we should 1) Ignore MSB 32bits for source register, and sign-extend the destination register. 2) Always use 32bit operation(TCG 32bit OP). I want to still use TCG 64bit OP and just extend the source to 64bit by ext32s or ext32u. Is is OK? Thanks, Zhiwei > > r~ <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p><br> </p> <div class="moz-cite-prefix">On 2021/7/16 上午12:15, Richard Henderson wrote:<br> </div> <blockquote type="cite" cite="mid:0b70aaf7-b337-3b73-cdbf-c5693a826204@linaro.org">On 7/15/21 4:21 AM, LIU Zhiwei wrote: <br> <blockquote type="cite">Also on a side note, could you give me some advice for the following question? <br> <br> I have been supporting running 32bit application on qemu-riscv64. After this patch set, <br> it is hard to define a method, such as gpr_dst_s or gpr_dst_u, to extend the destination <br> register. I can only extend the destination register(ext32s or ext32u) in each instruction <br> with scattered code. <br> <br> Can we just omit the extension of the destination register? <br> </blockquote> <br> It's hard to give advice on code that I haven't seen. <br> <br> In general I would think that the destination register need not be extended for 32-bit mode, unless the architecture says otherwise. (What does the architecture say about the contents of the registers when transitioning from a 32-bit mode user program to a 64-bit mode kernel?) <br> <br> </blockquote> <p>As privileged specification says,</p> <pre>"Whenever XLEN in any mode is set to a value less than the widest supported XLEN, all operations must ignore source operand register bits above the configured XLEN, and must sign-extend results to fill the entire widest supported XLEN in the destination register. Similarly, pc bits above XLEN are ignored, and when the pc is written, it is sign-extended to fill the widest supported XLEN." </pre> If we want to strictly obey the spec, we should <br> 1) Ignore MSB 32bits for source register, and sign-extend the destination register.<br> 2) Always use 32bit operation(TCG 32bit OP).<br> <br> I want to still use TCG 64bit OP and just extend the source to 64bit by ext32s or ext32u.<br> <br> Is is OK?<br> <br> Thanks,<br> Zhiwei<br> <blockquote type="cite" cite="mid:0b70aaf7-b337-3b73-cdbf-c5693a826204@linaro.org"> <br> r~ <br> </blockquote> </body> </html>
On 7/16/21 8:59 PM, LIU Zhiwei wrote: > If we want to strictly obey the spec, we should > 1) Ignore MSB 32bits for source register, and sign-extend the destination register. > 2) Always use 32bit operation(TCG 32bit OP). > > I want to still use TCG 64bit OP and just extend the source to 64bit by ext32s or ext32u. > > Is is OK? Yes, that sounds right. r~