From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtJEw-0006TU-Gc for qemu-devel@nongnu.org; Fri, 15 May 2015 13:17:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtJEu-0001nx-Pm for qemu-devel@nongnu.org; Fri, 15 May 2015 13:17:38 -0400 Received: from mail-qk0-x22f.google.com ([2607:f8b0:400d:c09::22f]:34543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtJEu-0001no-KV for qemu-devel@nongnu.org; Fri, 15 May 2015 13:17:36 -0400 Received: by qkgx75 with SMTP id x75so74639349qkg.1 for ; Fri, 15 May 2015 10:17:36 -0700 (PDT) Sender: Richard Henderson Message-ID: <55562A2C.9080005@twiddle.net> Date: Fri, 15 May 2015 10:17:32 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1431665391-2389-1-git-send-email-crosthwaite.peter@gmail.com> <555613BC.4070408@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] microblaze: Remove uses of TCGv and target_ulong List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Peter Crosthwaite , Peter Crosthwaite , "qemu-devel@nongnu.org Developers" , Edgar Iglesias , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 05/15/2015 09:48 AM, Peter Crosthwaite wrote: > On Fri, May 15, 2015 at 8:41 AM, Richard Henderson 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? 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... r~