On Fri, May 15, 2015 at 10:17 AM, Richard Henderson <r...@twiddle.net> wrote: > On 05/15/2015 09:48 AM, Peter Crosthwaite wrote: >> On Fri, May 15, 2015 at 8:41 AM, Richard Henderson <r...@twiddle.net> 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~ >
