Am 06.07.2013 21:54, schrieb Max Filippov: > On Sat, Jul 6, 2013 at 11:12 PM, Andreas Färber <afaer...@suse.de> wrote: >> Am 06.07.2013 20:39, schrieb Max Filippov: >>> ...and maybe a stupid question, but why moving configuration pointer away >>> from env and then changing every place that used to access it? >> >> Xtensa is the only target trying to implicitly access an "env" variable >> through a macro to obtain the number of registers for gdbstub. That's >> what I'm trying to fix with 40/41 in order to get rid of the #ifdeffery. >> >> The number of registers is not accessed by TCG, so it could go into >> XtensaCPU instead of CPUXtensaState. >> Further it does not change during vCPU runtime, so it no longer belongs >> in CPUXtensaState nor XtensaCPU but in XtensaCPUClass, which is shared >> among CPU cores and can be accessed statically. > > I'm concerned about two things here: adding boilerplate code to access > CPU class and doing more work at runtime than just following a pointer. > I mean that env->config is almost always used together with env itself, > could we consider env->config to be a cache for xcc->config?
xtensa_env_get_cpu() after the recent patch in my queue no longer does a cast, thus it's dirt cheap to switch between CPUXtensaState and XtensaCPU (and back via ->env). The ObjectClass is a pointer in Object, just like your XtensaConfig in CPUXtensaState. Anthony has added a cast cache for v1.5 and Paolo a configure option to turn cast checks off. That leaves declaring an extra variable. But since this is orthogonal to my gdbstub cleanups, v2 just initializes env->config in XtensaCPU's instance_init, to keep the patch small while keeping cpu_init() free of non-QOM initializations. Anything else can be done later in an xtensa-only series. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
