From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJuTy-0008CM-DL for qemu-devel@nongnu.org; Tue, 10 May 2011 17:28:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QJuTx-0007TI-BI for qemu-devel@nongnu.org; Tue, 10 May 2011 17:28:42 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:46949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJuTx-0007TC-1w for qemu-devel@nongnu.org; Tue, 10 May 2011 17:28:41 -0400 From: Paul Brook Date: Tue, 10 May 2011 22:28:37 +0100 References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105102228.37340.paul@codesourcery.com> Subject: Re: [Qemu-devel] TCG: AREG0 removal planning List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel > TCG uses a fixed global register (AREG0) to which points to currently > used CPUState, also known as 'env'. Using a fixed register has the > downsides that the register must be reserved by TCG for generated code > and by the compiler for compiling a few critical files (op_helper.c > etc.). The latter also means that any calls to C library may be unsafe > from those files. > > Here are my sketches about transition to AREG0-less world. > ... > Translators/op helpers > ... > Comments? There are a few blank spots too. I think a useful, and incremental goal is elimination of global cpu_env state in C code (i.e eliminate HELPER_CFLAGS and dyngen-exec.h). We already have much of the infrastructure for this - op_helper v.s. helper.c and code_gen_prologue for transition in/out of "generated code" state. In practice generated code probably accesses CPUState often enough that a dedicated register isn't a bad idea. My guess is that eliminating it from C code gets us almost all of the useful benefit. Removing it from the code generator (i.e. TCG_AREG0) may be more pain that it's worth. For changes to the TCG side we want to consider how we can provide useful aliasing information, rather than a naive replacement of TCG_AREG0 with a variable. Paul