Re: [Qemu-devel] [PATCH] microblaze: Remove uses of TCGv and target_ulong

[Peter Crosthwaite]

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/ 
> encapsulated
> 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.

Regards,
Peter

>
> r~
>