[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] microblaze: Remove uses of TCGv and target_ulon
Re: [Qemu-devel] [PATCH] microblaze: Remove uses of TCGv and target_ulong
Fri, 15 May 2015 13:52:04 -0700
On Fri, May 15, 2015 at 10:17 AM, Richard Henderson <address@hidden> wrote:
> On 05/15/2015 09:48 AM, Peter Crosthwaite wrote:
>> On Fri, May 15, 2015 at 8:41 AM, Richard Henderson <address@hidden> wrote:
>>> On 05/14/2015 09:49 PM, Peter Crosthwaite wrote:
>>>> To prepare support for conversion of Microblaze TARGET_LONG to 64 bits.
>>>> This in turn will then allow support for multi-arch QEMU including both
>>>> Microblaze and 64-bit CPU targets (notably AArch64).
>>> I don't understand why multi-arch requires all of the arches
>>> to have the same width. This seems like a major failure to me.
>>> I'm not particularly keen on this at all.
>> What is the alternative? What is the def of the global symbols TCGv
>> and TARGET_LONG in the multi-arch cases?
> Different for every file? Not relevant for "multi-arch" itself?
So TCGv if generally localized to target-foo so it makes sense to
per-target'ify that one. Core code (or worse, device land code), does
make liberal use of target_ulong though so that is relavant to
multi-arch. Multi-arch needs to make the decision on what that length
is and currently that is 64.
Multiple choice quiz time again :) We have three choices that I can see:
1: We can undef-redefine the (global) target_ulong type set by
multi-arch for target-foo code. target_ulong then is different for
every file. Some explicit casts may be needed around core-API
interfaces, not sure yet.
2: Core code is converted to not use "target_ulong" (tcg_core_ulong?)
and target_ulong becomes a target-specific code concept.
3: Remove target_ulong usage from target-foo code for multi-arch
capable platfroms. The TCGv remains onconverted however, greatly
minmising this diff.
> I dunno. Where does stuff break down first?
> I would expect 80% of it to be private to target-foo, and /mostly/
> in the tcg ops that are produced.
> I realize there's a problem of how addresses are treated inside the tcg
> backend, but that should be surmountable. Perhaps all we need are 4 new
> opcodes so that both 32-bit and 64-bit addresses can be represented within the
> opcode stream simultaneously.
> I assume we're not still talking about multi-arch linux-user, but are really
> only talking about softmmu here...
Yes. Linux-user needs major refactorings (getting rid of the #ifdef
TARGET_FOO for one) before we can think about that.