On Mon, Sep 17, 2012 at 03:36:46PM +0200, Laurent Desnogues wrote:
> On Mon, Sep 17, 2012 at 11:43 AM, Peter Maydell
> wrote:
> > On 17 September 2012 10:30, Laurent Desnogues
> > wrote:
> >> On Mon, Sep 17, 2012 at 1:08 AM, Aurelien Jarno
> >> wrote:
> >>> +#define GEN_SHIFT(name)
On Mon, Sep 17, 2012 at 11:47:05AM -0700, Richard Henderson wrote:
> On 09/17/2012 11:09 AM, Aurelien Jarno wrote:
> > If you insist, maybe we can just add a movcond op that uses setcond, so
> > it makes the code more readable?
>
> Well, that's certainly a good first step. And an easy fall back f
On 09/17/2012 11:09 AM, Aurelien Jarno wrote:
> If you insist, maybe we can just add a movcond op that uses setcond, so
> it makes the code more readable?
Well, that's certainly a good first step. And an easy fall back for
hosts that choose not to implement the full conditional move. But at
leas
On Mon, Sep 17, 2012 at 08:36:31AM -0700, Richard Henderson wrote:
> On 09/16/2012 04:08 PM, Aurelien Jarno wrote:
> > +tcg_gen_setcondi_i32(TCG_COND_GE, tmp2, tmp1, 32); \
> > +tcg_gen_andi_i32(tmp1, tmp1, 0x1f);\
> > +tcg_gen_##name##_i32(dest, t0, tmp1);
On 09/17/2012 08:41 AM, Peter Maydell wrote:
> Of these, the first is the most significant. If you want to wade
> through architecture manuals for 8 architectures, be my guest :-)
I think that's probably easier than auditing all of our guests now. ;-)
r~
On 17 September 2012 16:34, Richard Henderson wrote:
> On 09/17/2012 02:43 AM, Peter Maydell wrote:
>> The TCG shift operations are undefined behaviour (not merely
>> undefined result) if the shift is >= 32, so we must avoid
>> doing that even if we're going to throw away the answer.
>
> I don't t
On 09/16/2012 04:08 PM, Aurelien Jarno wrote:
> +tcg_gen_setcondi_i32(TCG_COND_GE, tmp2, tmp1, 32); \
> +tcg_gen_andi_i32(tmp1, tmp1, 0x1f);\
> +tcg_gen_##name##_i32(dest, t0, tmp1); \
> +tcg_temp_free_i32(tmp1); \
> +tcg_ge
On 09/17/2012 02:43 AM, Peter Maydell wrote:
> The TCG shift operations are undefined behaviour (not merely
> undefined result) if the shift is >= 32, so we must avoid
> doing that even if we're going to throw away the answer.
I don't think that ought to be true.
In particular, I've just posted a
On 17 September 2012 14:36, Laurent Desnogues
wrote:
> On Mon, Sep 17, 2012 at 11:43 AM, Peter Maydell
> wrote:
>> The TCG shift operations are undefined behaviour (not merely
>> undefined result) if the shift is >= 32, so we must avoid
>> doing that even if we're going to throw away the answer.
On Mon, Sep 17, 2012 at 11:43 AM, Peter Maydell
wrote:
> On 17 September 2012 10:30, Laurent Desnogues
> wrote:
>> On Mon, Sep 17, 2012 at 1:08 AM, Aurelien Jarno wrote:
>>> +#define GEN_SHIFT(name)\
>>> +static void gen_##name(TCGv dest, TCGv t0, TCGv t1)\
>>
On 17 September 2012 10:30, Laurent Desnogues
wrote:
> On Mon, Sep 17, 2012 at 1:08 AM, Aurelien Jarno wrote:
>> +#define GEN_SHIFT(name)\
>> +static void gen_##name(TCGv dest, TCGv t0, TCGv t1)\
>> +{ \
>> +
On Mon, Sep 17, 2012 at 1:08 AM, Aurelien Jarno wrote:
> Now that the setcond TCG op is available, it's possible to replace
> shl and shr helpers by TCG code. The code generated by TCG is slightly
> longer than the code generated by GCC for the helper but is still worth
> it as this avoid all the
Now that the setcond TCG op is available, it's possible to replace
shl and shr helpers by TCG code. The code generated by TCG is slightly
longer than the code generated by GCC for the helper but is still worth
it as this avoid all the consequences of using an helper: globals saved
back to memory, n
13 matches
Mail list logo
