TCG op for 32 bit only cpu on qemu-riscv64

TCG op for 32 bit only cpu on qemu-riscv64

[LIU Zhiwei]

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?
I see some API such as gen_get_gpr that are using the tcg_*_tl. But I am 
not sure if it is
right for 32bit cpu.

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

Best Regards,
Zhiwei

TCG op for 32 bit only cpu on qemu-riscv64

[LIU Zhiwei]

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?
I see some API such as gen_get_gpr that are using the tcg_*_tl. But I am 
not sure if it is
right for 32bit cpu.

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

Best Regards,
Zhiwei

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

[Alistair Francis]

On Mon, Jun 7, 2021 at 1:09 PM LIU Zhiwei <zhiwei_liu@c-sky.com> 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?
> I see some API such as gen_get_gpr that are using the tcg_*_tl. But I am
> not sure if it is
> right for 32bit cpu.

Do you mean for an instruction that only runs on a 32-bit CPU (and not RV64)?

If the instruction only supports a 32-bit value then tcg_*_i32
otherwise tcg_*_tl is probably the best bet.

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

I'm not clear what you mean. Can you point to a spec that you are
trying to implement?

Alistair

>
> Best Regards,
> Zhiwei
>
>

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

[Alistair Francis]

On Mon, Jun 7, 2021 at 1:09 PM LIU Zhiwei <zhiwei_liu@c-sky.com> 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?
> I see some API such as gen_get_gpr that are using the tcg_*_tl. But I am
> not sure if it is
> right for 32bit cpu.

Do you mean for an instruction that only runs on a 32-bit CPU (and not RV64)?

If the instruction only supports a 32-bit value then tcg_*_i32
otherwise tcg_*_tl is probably the best bet.

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

I'm not clear what you mean. Can you point to a spec that you are
trying to implement?

Alistair

>
> Best Regards,
> Zhiwei
>
>

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

[LIU Zhiwei]

On 6/7/21 2:22 PM, Alistair Francis wrote:
> On Mon, Jun 7, 2021 at 1:09 PM LIU Zhiwei <zhiwei_liu@c-sky.com> 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?
>> I see some API such as gen_get_gpr that are using the tcg_*_tl. But I am
>> not sure if it is
>> right for 32bit cpu.
> Do you mean for an instruction that only runs on a 32-bit CPU (and not RV64)?
>
> If the instruction only supports a 32-bit value then tcg_*_i32
> otherwise tcg_*_tl is probably the best bet.

Thanks. I think you are right.

>
>> 2) Do we should have a sign-extend 64 bit register(bit 31 as the sign
>> bit)  for 32 bit cpu?
> I'm not clear what you mean. Can you point to a spec that you are
> trying to implement?

I am implementing RVP to get rid of TARGET_RISCV64. After we have 
recognized an instruction only used by a 32-bit CPU,

1) Should we only use the lowest 32bits of the 64bits register in RV64?

TCGv s;
TCGv_i32 s32;
s = tcg_new_temp();
s32 = tcg_new_temp_i32();
gen_get_gpr(src1, a->rs1);
tcg_gen_trunc_tl_i32(s32, s);

Then we can use TCGv_i32 s32  to stand for rs1 register.

2) After some tcg ops(tcg_*_i32), when we write back to destination 
register, should we sign-extend
the 32 bit register before call get_set_gpr()?

Best Regards,
Zhiwei

>
> Alistair
>
>> Best Regards,
>> Zhiwei
>>
>>

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

[LIU Zhiwei]

On 6/7/21 2:22 PM, Alistair Francis wrote:
> On Mon, Jun 7, 2021 at 1:09 PM LIU Zhiwei <zhiwei_liu@c-sky.com> 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?
>> I see some API such as gen_get_gpr that are using the tcg_*_tl. But I am
>> not sure if it is
>> right for 32bit cpu.
> Do you mean for an instruction that only runs on a 32-bit CPU (and not RV64)?
>
> If the instruction only supports a 32-bit value then tcg_*_i32
> otherwise tcg_*_tl is probably the best bet.

Thanks. I think you are right.

>
>> 2) Do we should have a sign-extend 64 bit register(bit 31 as the sign
>> bit)  for 32 bit cpu?
> I'm not clear what you mean. Can you point to a spec that you are
> trying to implement?

I am implementing RVP to get rid of TARGET_RISCV64. After we have 
recognized an instruction only used by a 32-bit CPU,

1) Should we only use the lowest 32bits of the 64bits register in RV64?

TCGv s;
TCGv_i32 s32;
s = tcg_new_temp();
s32 = tcg_new_temp_i32();
gen_get_gpr(src1, a->rs1);
tcg_gen_trunc_tl_i32(s32, s);

Then we can use TCGv_i32 s32  to stand for rs1 register.

2) After some tcg ops(tcg_*_i32), when we write back to destination 
register, should we sign-extend
the 32 bit register before call get_set_gpr()?

Best Regards,
Zhiwei

>
> Alistair
>
>> Best Regards,
>> Zhiwei
>>
>>

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

[Richard Henderson]

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.

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


r~

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

[Richard Henderson]

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.

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


r~

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

[Richard Henderson]

On 6/7/21 2:22 AM, LIU Zhiwei wrote:
> 
> I am implementing RVP to get rid of TARGET_RISCV64. After we have recognized an 
> instruction only used by a 32-bit CPU,
> 
> 1) Should we only use the lowest 32bits of the 64bits register in RV64?
> 
> TCGv s;
> TCGv_i32 s32;
> s = tcg_new_temp();
> s32 = tcg_new_temp_i32();
> gen_get_gpr(src1, a->rs1);
> tcg_gen_trunc_tl_i32(s32, s);
> 
> Then we can use TCGv_i32 s32  to stand for rs1 register.

Changing from _tl to _i32 is wrong for most things, because you'll just have to 
convert back in order to store the result.

Most often you'll get the correct results by just using _tl as is.  One 
operation I can think of right away which probably requires extra attention is 
right-shift.  In which case just sign- or zero-extend the input first.


r~

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

[Richard Henderson]

On 6/7/21 2:22 AM, LIU Zhiwei wrote:
> 
> I am implementing RVP to get rid of TARGET_RISCV64. After we have recognized an 
> instruction only used by a 32-bit CPU,
> 
> 1) Should we only use the lowest 32bits of the 64bits register in RV64?
> 
> TCGv s;
> TCGv_i32 s32;
> s = tcg_new_temp();
> s32 = tcg_new_temp_i32();
> gen_get_gpr(src1, a->rs1);
> tcg_gen_trunc_tl_i32(s32, s);
> 
> Then we can use TCGv_i32 s32  to stand for rs1 register.

Changing from _tl to _i32 is wrong for most things, because you'll just have to 
convert back in order to store the result.

Most often you'll get the correct results by just using _tl as is.  One 
operation I can think of right away which probably requires extra attention is 
right-shift.  In which case just sign- or zero-extend the input first.


r~

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

[LIU Zhiwei]

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,
Zhiwei

>
>> 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).
>
>
> r~

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

[LIU Zhiwei]

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,
Zhiwei

>
>> 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).
>
>
> r~

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

[Richard Henderson]

On 6/9/21 6:43 PM, LIU Zhiwei wrote:
> 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.

Multiply is fine.  Input bits outside the low 32 cannot appear in the low 32 of 
the output.  Multiply-high-part on the other hand will require sign- or 
zero-extension of inputs.

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

Yes, division requires extension too.

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

I said some operations will require extra work -- I gave right-shift as an example.

You just have to be careful about deciding what extra work to do.  I am 
suggesting that truncation to *_i32 is almost always not the correct answer.

Perhaps make it easier by changing gen_get_gpr and gen_set_gpr:

/* Return sign-extended version of gpr. */
static void get_gpr_s(DisasContext *ctx, TCGv t, int reg_num)
{
     if (reg_num == 0) {
         tcg_gen_movi_tl(t, 0);
     } else if (is_32bit(ctx)) {
         tcg_gen_ext32s_tl(t, cpu_gpr[reg_num]);
     } else {
         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
     }
}

/* Return zero-extended version of gpr. */
static void get_gpr_u(DisasContext *ctx, TCGv t, int reg_num);
{
     if (reg_num == 0) {
         tcg_gen_movi_tl(t, 0);
     } else if (is_32bit(ctx)) {
         tcg_gen_ext32u_tl(t, cpu_gpr[reg_num]);
     } else {
         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
     }
}

/* Return gpr with undefined high bits (which will be ignored). */
static void get_gpr_x(TCGv t, int reg_num);
{
     if (reg_num == 0) {
         tcg_gen_movi_tl(t, 0);
     } else {
         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
     }
}

And similarly for set.


r~

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

[Richard Henderson]

On 6/9/21 6:43 PM, LIU Zhiwei wrote:
> 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.

Multiply is fine.  Input bits outside the low 32 cannot appear in the low 32 of 
the output.  Multiply-high-part on the other hand will require sign- or 
zero-extension of inputs.

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

Yes, division requires extension too.

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

I said some operations will require extra work -- I gave right-shift as an example.

You just have to be careful about deciding what extra work to do.  I am 
suggesting that truncation to *_i32 is almost always not the correct answer.

Perhaps make it easier by changing gen_get_gpr and gen_set_gpr:

/* Return sign-extended version of gpr. */
static void get_gpr_s(DisasContext *ctx, TCGv t, int reg_num)
{
     if (reg_num == 0) {
         tcg_gen_movi_tl(t, 0);
     } else if (is_32bit(ctx)) {
         tcg_gen_ext32s_tl(t, cpu_gpr[reg_num]);
     } else {
         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
     }
}

/* Return zero-extended version of gpr. */
static void get_gpr_u(DisasContext *ctx, TCGv t, int reg_num);
{
     if (reg_num == 0) {
         tcg_gen_movi_tl(t, 0);
     } else if (is_32bit(ctx)) {
         tcg_gen_ext32u_tl(t, cpu_gpr[reg_num]);
     } else {
         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
     }
}

/* Return gpr with undefined high bits (which will be ignored). */
static void get_gpr_x(TCGv t, int reg_num);
{
     if (reg_num == 0) {
         tcg_gen_movi_tl(t, 0);
     } else {
         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
     }
}

And similarly for set.


r~

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

[LIU Zhiwei]

On 6/10/21 9:29 PM, Richard Henderson wrote:
> On 6/9/21 6:43 PM, LIU Zhiwei wrote:
>> 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.
>
> Multiply is fine.  Input bits outside the low 32 cannot appear in the 
> low 32 of the output.  Multiply-high-part on the other hand will 
> require sign- or zero-extension of inputs.
>
>> 2)If next instruction is a divide instruction,  the MSW 32-bit will 
>> influence the divide instruction result.
>
> Yes, division requires extension too.
>
>> So I think use *_tl can't satisfy the need to run 32-bit program on 
>> qemu-riscv64.
>
> I said some operations will require extra work -- I gave right-shift 
> as an example.
>
> You just have to be careful about deciding what extra work to do. I am 
> suggesting that truncation to *_i32 is almost always not the correct 
> answer.
>
> Perhaps make it easier by changing gen_get_gpr and gen_set_gpr:
>
> /* Return sign-extended version of gpr. */
> static void get_gpr_s(DisasContext *ctx, TCGv t, int reg_num)
> {
>     if (reg_num == 0) {
>         tcg_gen_movi_tl(t, 0);
>     } else if (is_32bit(ctx)) {
>         tcg_gen_ext32s_tl(t, cpu_gpr[reg_num]);
>     } else {
>         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
>     }
> }
>
> /* Return zero-extended version of gpr. */
> static void get_gpr_u(DisasContext *ctx, TCGv t, int reg_num);
> {
>     if (reg_num == 0) {
>         tcg_gen_movi_tl(t, 0);
>     } else if (is_32bit(ctx)) {
>         tcg_gen_ext32u_tl(t, cpu_gpr[reg_num]);
>     } else {
>         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
>     }
> }
>
> /* Return gpr with undefined high bits (which will be ignored). */
> static void get_gpr_x(TCGv t, int reg_num);
> {
>     if (reg_num == 0) {
>         tcg_gen_movi_tl(t, 0);
>     } else {
>         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
>     }
> }
>
> And similarly for set.
>
It's very instructive. Thanks.

I once thought we have to split the registers in CPURISCVSTATE into two 
parts, gpr32 or gpr64.
Now I think we can still use most currently work with  a small 
cost(tcg_gen_ext32s_i64 has more cost than tcg_gen_mov_i32)

I will have a try later. Thanks again.

Best Regards,
Zhiwei

>
> r~

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

[LIU Zhiwei]

On 6/10/21 9:29 PM, Richard Henderson wrote:
> On 6/9/21 6:43 PM, LIU Zhiwei wrote:
>> 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.
>
> Multiply is fine.  Input bits outside the low 32 cannot appear in the 
> low 32 of the output.  Multiply-high-part on the other hand will 
> require sign- or zero-extension of inputs.
>
>> 2)If next instruction is a divide instruction,  the MSW 32-bit will 
>> influence the divide instruction result.
>
> Yes, division requires extension too.
>
>> So I think use *_tl can't satisfy the need to run 32-bit program on 
>> qemu-riscv64.
>
> I said some operations will require extra work -- I gave right-shift 
> as an example.
>
> You just have to be careful about deciding what extra work to do. I am 
> suggesting that truncation to *_i32 is almost always not the correct 
> answer.
>
> Perhaps make it easier by changing gen_get_gpr and gen_set_gpr:
>
> /* Return sign-extended version of gpr. */
> static void get_gpr_s(DisasContext *ctx, TCGv t, int reg_num)
> {
>     if (reg_num == 0) {
>         tcg_gen_movi_tl(t, 0);
>     } else if (is_32bit(ctx)) {
>         tcg_gen_ext32s_tl(t, cpu_gpr[reg_num]);
>     } else {
>         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
>     }
> }
>
> /* Return zero-extended version of gpr. */
> static void get_gpr_u(DisasContext *ctx, TCGv t, int reg_num);
> {
>     if (reg_num == 0) {
>         tcg_gen_movi_tl(t, 0);
>     } else if (is_32bit(ctx)) {
>         tcg_gen_ext32u_tl(t, cpu_gpr[reg_num]);
>     } else {
>         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
>     }
> }
>
> /* Return gpr with undefined high bits (which will be ignored). */
> static void get_gpr_x(TCGv t, int reg_num);
> {
>     if (reg_num == 0) {
>         tcg_gen_movi_tl(t, 0);
>     } else {
>         tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
>     }
> }
>
> And similarly for set.
>
It's very instructive. Thanks.

I once thought we have to split the registers in CPURISCVSTATE into two 
parts, gpr32 or gpr64.
Now I think we can still use most currently work with  a small 
cost(tcg_gen_ext32s_i64 has more cost than tcg_gen_mov_i32)

I will have a try later. Thanks again.

Best Regards,
Zhiwei

>
> r~