> 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
