|From:||Bruno Piazera Larsen|
|Subject:||RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg|
|Date:||Wed, 14 Apr 2021 20:07:23 +0000|
> > 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
> 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
|[Prev in Thread]||Current Thread||[Next in Thread]|