From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QG9aW-0002C1-8O for qemu-devel@nongnu.org; Sat, 30 Apr 2011 08:47:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QG9aU-0002Dt-Qs for qemu-devel@nongnu.org; Sat, 30 Apr 2011 08:47:56 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:34219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QG9aU-0002Do-Mu for qemu-devel@nongnu.org; Sat, 30 Apr 2011 08:47:54 -0400 Received: by qwj8 with SMTP id 8so2451571qwj.4 for ; Sat, 30 Apr 2011 05:47:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 30 Apr 2011 16:47:54 +0400 Message-ID: From: Max Filippov Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] xtensa: new target architecture for qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , qemu-devel@nongnu.org >>> 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