Am 13.12.2011 17:26, schrieb Paul Brook:
> You've almost no chance of getting
> it right. In some cases the correct answer will be to use 32-bit
> arithmetic, then sign/zero extend the result. In other cases the
> correct answer will be to perform word size arithmetic. Blindly
>>>
> >>> You've almost no chance of getting
> >>> it right. In some cases the correct answer will be to use 32-bit
> >>> arithmetic, then sign/zero extend the result. In other cases the
> >>> correct answer will be to perform word size arithmetic. Blindly
> >>> picking one just makes the bugs harder
> Am 12.12.2011 16:58, schrieb Paul Brook:
> >> For me the most annoying issue was that tcg_gen_qemu_{ld,st}* needs
> >> TCGv.
> >
> > You mean the value transferred is always TCGv sized, so ld32u requires an
> > additional truncation before doing 32-bit arithmetic? Fixing that is
> > completely
Am 12.12.2011 16:58, schrieb Paul Brook:
>> For me the most annoying issue was that tcg_gen_qemu_{ld,st}* needs TCGv.
>
> You mean the value transferred is always TCGv sized, so ld32u requires an
> additional truncation before doing 32-bit arithmetic? Fixing that is
> completely independent of
Am 12.12.2011 16:58, schrieb Paul Brook:
>>> Trying to make a 32-bit target "64-bit safe" without actually
>>> implementing the 64-bit target is a complete waste of time.
>>
>> That's where we disagree. I rather do things right from the start than
>> leaving the cleanup work to someone else later o
> > Trying to make a 32-bit target "64-bit safe" without actually
> > implementing the 64-bit target is a complete waste of time.
>
> That's where we disagree. I rather do things right from the start than
> leaving the cleanup work to someone else later on.
>
> > You've almost no chance of getting
Am 12.12.2011 00:28, schrieb Paul Brook:
>>> What mismatches does this catch that the existing debug code doesn't?
>>
>> Cf. patch 4/4:
>>
>> TCGv tmp = tcg_temp_new_i32();
>> tcg_temp_free_i32(tmp);
>>
>> TCGv_i32 tmp2 = tcg_temp_new();
>> tcg_temp_free(tmp2);
>
> Why is this a problem? If TARGE
> > What mismatches does this catch that the existing debug code doesn't?
>
> Cf. patch 4/4:
>
> TCGv tmp = tcg_temp_new_i32();
> tcg_temp_free_i32(tmp);
>
> TCGv_i32 tmp2 = tcg_temp_new();
> tcg_temp_free(tmp2);
Why is this a problem? If TARGET_LONG_BITS==32 then tcg_temp_free and
tcg_temp_f
Am 10.12.2011 11:07, schrieb Peter Maydell:
> On 10 December 2011 09:02, Andreas Färber wrote:
>> Working on 16- and 20-bit targets using TARGET_LONG_BITS == 32, I found it
>> too
>> easy to accidentally use, e.g., tcg_temp_free() in place of
>> tcg_temp_free_i32().
>> In case of 78k0/rl78 it ma
On 10 December 2011 09:02, Andreas Färber wrote:
> Working on 16- and 20-bit targets using TARGET_LONG_BITS == 32, I found it too
> easy to accidentally use, e.g., tcg_temp_free() in place of
> tcg_temp_free_i32().
> In case of 78k0/rl78 it may not practically matter yet, but it complicates
> goi
Hello,
Working on 16- and 20-bit targets using TARGET_LONG_BITS == 32, I found it too
easy to accidentally use, e.g., tcg_temp_free() in place of tcg_temp_free_i32().
In case of 78k0/rl78 it may not practically matter yet, but it complicates
going from a 32-bit target to 64 bits, as in the case of
11 matches
Mail list logo
