RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg

[Bruno Piazera Larsen]

> > What I was doing was to only register the spr once, and use the
> > accel-specific functions to set the relevant attributes, so spr_common
> > wouldn't need to where (and if) spr_read_* exists or not.
> > Would this work?
> >
> > Just ignoring the read and write functions means we still need
> > to compile them, or at least stub them, otherwise we'd get linker
> > problems.
>
> Not if you use a macro which will simply elide the references in the
> !TCG case.  Actually I think even an inline wrapper will do it, I'm
> pretty sure the compiler is smart enough to optimize the references

> out in that case.

You are correct! I've just tweaked the code that defines spr_register and

it should be working now. I'm still working in splitting the SPR functions

from translate_init, since I think it would make it easier to prepare the

!TCG case and for adding new architectures in the future, and I found a

few more problems:

1. Global variables being defined in translate.c and used both there and

in spr functions. The variables in question are: cpu_gpr, cpu_so, cpu_ov,

cpu_ca, cpu_ov32, cpu_ca32, cpu_xer, cpu_lr and cpu_ctr. The easy way

out is to have global "getters" and "setters" for those, but I'm not sure

it's a good solution.

2. Static functions defined in translate.c, used there and TCG-related

spr functions. They are: gen_load_spr, gen_store_spr, gen_stop_exception,

gen_inval_exception. The easy solution is adding a prototype to internal.h

and removing the static, but again, not sure it's a good solution

3. gen_read_xer (currently in spr_common) calls is_isa300, defined in

include/disas/disas.h, which is a macro that dereferences DisasContext.

However, the struct is defined in translate.c. This one is pretty easy, I think,

it's just turning the macro into a function, but since I'm already e-mailing,

I figured I might as weel ask.

Finally, since most read and write functions are static, I added them to

spr_tcg.c.inc to be included only with TCG, as a quick fix, but I would really

prefer some other solution if there is anything better. Any thoughts on this?

IIRC, this is the last thing holding me back from an RFC with this motion

patch

Bruno Piazera Larsen

Instituto de Pesquisas ELDORADO

Departamento Computação Embarcada

Analista de Software Trainee

Aviso Legal - Disclaimer