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

[Fabiano Rosas <farosas@linux.ibm.com>]

Bruno Piazera Larsen <bruno.larsen@eldorado.org.br> writes:

>> > 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:
>>
>> Actually looking at the stuff below, I suspect that separating our
>> "spr" logic specifically might be a bad idea.  At least some of the
>> SPRs control pretty fundamental things about how the processor
>> operates, and I suspect separating it from the main translation logic
>> may be more trouble than it's worth.

I disagree with the code proximity argument. Having TCG code clearly
separate from common code seems more important to me than having the SPR
callbacks close to the init_proc functions.

But maybe we should take a look at this RFC before we start discussing
personal preference too much.

> Well, all the errors that I got were related to to read/write functions, which
> I was already separating into a spr_tcg file. The solutions I can see are to
> include this file in translate.c, and either have the read/write functions not be
> static, or include the spr_common.c in translate as well, but only for TCG
> builds. Both solutions sound pretty bad imo, but the first sounds less bad,
> because it's a bit less complexity in the build process.

It would be helpful if we could apply these patches and do some
experimentation before recommending a solution. So I would pick the less
bad for now. Mention it in the cover letter and then we can discuss
looking at something more concrete.