On 09/28/2011 03:07 PM, Jan Kiszka wrote:
> On 2011-09-28 17:19, Richard Henderson wrote:
>> On 09/28/2011 07:33 AM, Jan Kiszka wrote:
I don't particularly care for the 3 different opcodes. Perhaps
we'd be better off with an inline predicate for when the deposit
opcode is "valid"?
>
On 2011-09-28 17:19, Richard Henderson wrote:
> On 09/28/2011 07:33 AM, Jan Kiszka wrote:
>>> I don't particularly care for the 3 different opcodes. Perhaps
>>> we'd be better off with an inline predicate for when the deposit
>>> opcode is "valid"?
>>
>> We still need to dispatch at tcg generation
On 09/28/2011 07:33 AM, Jan Kiszka wrote:
>> I don't particularly care for the 3 different opcodes. Perhaps
>> we'd be better off with an inline predicate for when the deposit
>> opcode is "valid"?
>
> We still need to dispatch at tcg generation time which variant is valid. Or
> what do you have
On 2011-09-28 16:26, Richard Henderson wrote:
On 09/28/2011 05:28 AM, Jan Kiszka wrote:
+#if TCG_TARGET_REG_BITS == 64
+{ INDEX_op_deposit8l_i32, { "r", "0", "r" } },
+#else
+{ INDEX_op_deposit8l_i32, { "abcd", "0", "abcd" } },
+#endif
At minimum, abcd is spelled "q".
Ah, perfect.
On 09/28/2011 05:28 AM, Jan Kiszka wrote:
> +#if TCG_TARGET_REG_BITS == 64
> +{ INDEX_op_deposit8l_i32, { "r", "0", "r" } },
> +#else
> +{ INDEX_op_deposit8l_i32, { "abcd", "0", "abcd" } },
> +#endif
At minimum, abcd is spelled "q".
I don't particularly care for the 3 different opcodes.
x86 cannot provide an optimized generic deposit implementation. But at
least for a few special cases, namely for writing bits 0..7, 8..15, and
0..15, a version using only a single instruction is feasible.
Introducing such helpers improves emulating 16-bit x86 code on x86, but
also rarer cases where
