Re: [Qemu-devel] xtensa: new target architecture for qemu

[Max Filippov <jcmvbkbc@gmail.com>]

>>> What is the reason for that? DisasContext itself has a pointer to env.
>>> Can it be used instead?
>>
>> DisasContext shouldn't have that pointer. Some of the decisions during
>> translation are made based on CPU model/features which don't change
>> during execution. Other decisions should be made based on the current
>> CPU state, however usually here we should not rely on env but on
>> tb_flags. Not using env during disas_insn tries to enforce that.
>> Please take a look at other targets how this should be handled.
>
> Some targets are better choices to copy than others. target-arm
> passes CPUState around way too much still (it only relies on things
> it is OK to, but it would be nicer not to have CPUState quite so
> conveniently available.) I think the ideal is that none of the
> functions implementing decode logic (in your case disas_xtensa_insn())
> are directly passed a CPUState pointer.
>
> The reason for all this is that the CPUState you get during
> translation may not be the state of the CPU at the start
> of the code you are translating, so if you rely on bits of
> it that can change you'll run into problems.

That I understand. Ok, it seems that CPUState references may be
avoided quite easily.

>> I'd put CPU doc pointers to translate.c and chipset pointers to
>> corresponding device file.
>
> We also have a wiki page for CPU docs:
> http://wiki.qemu.org/Documentation/ISAManuals

Updated that.

Thanks for the hints, guys. Will patchbomb you soon.

Thanks.
-- Max