[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] xtensa: new target architecture for qemu
From: |
Max Filippov |
Subject: |
Re: [Qemu-devel] xtensa: new target architecture for qemu |
Date: |
Sat, 30 Apr 2011 16:47:54 +0400 |
>>> 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