> > The trivial path is to: > > * rename translate_init.c.inc to cpu_init.c (since it has to do with > > initial definitions for CPUs, and it's not related to translating > > anymore); > > Anymore? You mean after you've moved out everything related to > create_ppc_opcodes? Sure.
yeah, that. Also after removing every to destroy the opcode table (which isn't packaged in a neat function for some reason, it's loose in the ppc_cpu_unrealize). > > * move gen_write_xer and gen_read_xer into cpu_init.c, as they're > > used for some sprs, and whatever needs to be moved with it > > Well, gen_* things are specifically translation related, since they emit tcg > opcodes. But I see it's used as part of a callback from the SPRs. > > I think it would be worth moving all of the SPR code out to a separate file, > apart from cpu_init.c. There's a lot of it. And, yes, I would move > everything > that you can that is related out of translate.c. Yeah, now that I look at the SPR code, I'm starting to think it's easier I think it's what fabiano had in mind too, but we'll probably have 3 files, spr_common.c, spr_tcg.c and spr_kvm.c. It's a bit of surgery, but it's probably worth it, to avoid a mess of ifdefs. > > * move opcodes and invalid_handler into cpu_init.c, because they > > are only used by stuff in this file. > You could move the opcodes to a new file of its own, including > invalid_handler. > Moving them to cpu_init.c does not seem helpful. While waiting for a reply I tried this. It's really not, it creates about 6k errors. I ended up moving everything that used it from cpu_init.c into translate.c. create_ppc_opcodes and destroy_ppc_opcodes ended up going there, and I added prototypes to internal.h to call them in the realize and unrealize functions. > However, I think the surgery required to disentangle the legacy decoder and > all >its macros is probably not worth the effort. > What will be worth the effort is completing the decodetree conversion so that > the legacy decoder goes away entirely. Yeah, I wanted to do that, but at this point I'm just following what the client ordered. Maybe once we compile with tcg, it could be suggested, but I wouldn't count on it. Anyway, I don't think the disentangling I'm doing now would make that process harder in the future. Let me know if it is Bruno Piazera Larsen Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch> Departamento Computação Embarcada Analista de Software Trainee Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>
