[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TCG op for 32 bit only cpu on qemu-riscv64

From: LIU Zhiwei
Subject: Re: TCG op for 32 bit only cpu on qemu-riscv64
Date: Thu, 10 Jun 2021 09:43:19 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 6/7/21 11:52 PM, Richard Henderson wrote:
On 6/6/21 8:07 PM, LIU Zhiwei wrote:
Hi Alistair,

As I see,  we are moving  on to remove TARGET_RISCV64 macro.

I have some questions:

1) Which tcg op should use when translate an instruction for 32bit cpu. The tcg_*_i64, tcg_*_i32 or tcg_*_tl?

You use *_tl, because that's the size of the field in CPURISCVState.

Hi Richard,

If we want to run 32-bit program on qemu-riscv64, I think use *_tl is not enough. In semantics, we should only use the LSW 32-bit.

For example,

1)First a multiply instruction, if the source value big enough, it will return a result with some bits not zero in MSW 32-bit.

2)If next instruction is a divide instruction,  the MSW 32-bit will influence the divide instruction result.

So I think use *_tl can't satisfy the need to run 32-bit program on qemu-riscv64.

Now we are forwarding to run a 32-bit cpu on qemu-riscv64. In the near future, I want to support dynamical change  of XLEN.

Could you give some advice? Thanks very much.

Best Regards,

2) Do we should have a sign-extend 64 bit register(bit 31 as the sign bit)  for 32 bit cpu?

If the value must be sign-extended for RV64, then leave it sign-extended for RV32.  There's no point in adding extra code to distinguish between them.

If the instruction does not exist for RV64, then you can probably leave the high bits unspecified (sign, zero, or pure garbage).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]