Re: [Qemu-devel] best way to implement emulation of AArch64 tagged addresses

[Thomas Hanson]

Looking at tcg_out_tlb_load():

If I'm reading the pseudo-assembler of the function names correctly, it looks like in the i386 code we're already masking the address being checked: 

    tgen_arithi(s, ARITH_AND + trexw, r1, TARGET_PAGE_MASK | (aligned ? s_mask : 0), 0);

where  TARGET_PAGE_MASK is a simple all-1's mask in the appropriate upper bits.

Can we just poke some 0's into that mask in the tag locations?  And, of course, do the same when creating the TLB entry.

Unless of course we're in the case of (TARGET_LONG_BITS > TCG_TARGET_REG_BITS) (that would be 64 bit on 32 bit right?) when addrhi gets tested separately. Then we'd have to do the shift as above.

MIPS logic appears similar on a quick read.  In the sparc code I'm not seeing a pre-existing mask  but it's getting late and my eyes are giving out.  Those are the only tcg_out_tlb_load() versions I can find.

As to frequency I'm assuming that there are far fewer tagged pointers than untagged.  But then again I haven't seen a good use case for tagged pointers.  Would love to hear one.

On 8 April 2016 at 12:10, Richard Henderson <address@hidden> wrote:

On 04/08/2016 10:20 AM, Tom Hanson wrote:
> Is it an option to mask off the tag bits in all cases? Is there any case
> it which those bits are valid address bits?

It's not impossible to mask off bits in the address -- we do that for running
32-bit on 64-bit all of the time.  It's all a question of how well the average
program will perform, I suppose.

For instance.  Are there more tagged addresses than non-tagged addresses?  If
we mask off bits, that will affect *every* memory operation.  If tagged
addresses are rare, then that is a waste.  If tagged addresses are common,
however, then we may well spend too much time ping-ponging in the TLB.

The fastest method I can think of to ignore high order bits is to shift the
address comparator left.  The TLB comparator would be stored pre-shifted, so
this would add only one insn on the fast path.  Or perhaps zero in the case of
an arm/aarch64 host, where the compare insn itself can perform the shift.

Of course, a double-word shift would be completely out of the question when
doing 64-bit on 32-bit emulation.  But we don't need that -- just shift the
high part of the address left to discard bits, leaving a funny looking hole in
the middle of the comparator.

This is simple enough that it should be relatively easy to patch up all of the
tcg backends to match, if we decide to go with it.


r~