From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qa3Jt-0001nZ-LM for qemu-devel@nongnu.org; Fri, 24 Jun 2011 06:09:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qa3Js-0000B6-Ea for qemu-devel@nongnu.org; Fri, 24 Jun 2011 06:09:01 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:58710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qa3Jr-0000Ax-W1 for qemu-devel@nongnu.org; Fri, 24 Jun 2011 06:09:00 -0400 Received: by gyg10 with SMTP id 10so1346654gyg.4 for ; Fri, 24 Jun 2011 03:08:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <201106240644.02325.jcmvbkbc@gmail.com> <201106241234.19282.jcmvbkbc@gmail.com> Date: Fri, 24 Jun 2011 14:08:57 +0400 Message-ID: From: Max Filippov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Actual TB code doesn't look like what was intended (TCG issue)? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org > Here are my rules of thumb for generating code where the code > generated might change based on some bit of CPU state: > > When you are generating code, if the code you generate will > change based on the contents of something in the CPUState struct, > then the bit of CPUState you are looking at has to be one of: > =A0(1) encoded in the TB flags (or tb->pc or tb->cs_base) > =A0 =A0 =A0(and gen_intermediate_code_internal() must read and > =A0 =A0 =A0use the value in tb->tb_flags, not the one in env) So if changing a bit of context does not cause TB invalidation then it must be captured in cpu_get_tb_cpu_state and gen_intermediate_code_internal must use that captured value? > =A0(2) always constant for the life of the simulation > =A0 =A0 =A0(eg env->features if you have some sort of > =A0 =A0 =A0"target feature support" flags) > =A0(3) specially handled so that when it changes then > =A0 =A0 =A0all TBs or at least all affected TBs are flushed > =A0 =A0 =A0(env->breakpoints is in this category), and also > =A0 =A0 =A0if the change is the result of some instruction then > =A0 =A0 =A0you must terminate the TB after that instruction. > =A0 =A0 =A0This is often used for things that rarely change and/or > =A0 =A0 =A0where you can't fit the whole value into tb_flags. > The reason for this is that the CPUState you're passed in > is not guaranteed to be the state of the CPU at the PC > which you are starting translation from. > > This is the xtensa port at > http://jcmvbkbc.spb.ru/git/?p=3Ddumb/qemu-xtensa.git;a=3Dshortlog;h=3Dref= s/heads/xtensa > right? Yes. > It looks like you're breaking these rules with a lot of > the fields in your DisasContext. (Most obviously, you > need to translate code from tb->pc, not env->pc, and > xtensa_get_ring() and xtensa_get_cring() should not read > from env->sregs[PS]. But you should be clear for every > field in DisasContext which category it falls into.) Thank you Peter. Will go rearrange that mess. --=20 Thanks. -- Max