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

[Bruno Piazera Larsen]

> > 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

Departamento Computação Embarcada

Analista de Software Trainee

Aviso Legal - Disclaimer