Bruno Piazera Larsen <bruno.lar...@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.
