From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgblX-0008Ql-Fi for qemu-devel@nongnu.org; Fri, 30 Dec 2011 07:40:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgblW-0003nO-8P for qemu-devel@nongnu.org; Fri, 30 Dec 2011 07:40:55 -0500 Received: from mout.web.de ([212.227.15.4]:61212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgblV-0003nC-OC for qemu-devel@nongnu.org; Fri, 30 Dec 2011 07:40:54 -0500 Message-ID: <4EFDB106.50805@web.de> Date: Fri, 30 Dec 2011 13:39:34 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <4EFC4C65.5090503@web.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 2/3] target-mips:enabling of 64 bit user mode and floating point operations MIPS_HFLAG_UX is included in env->hflags so that the address computation for LD instruction does not treated as 32 bit code see gen_op_addr_add() in t List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel@nongnu.org [cc'ing list] Am 30.12.2011 08:52, schrieb Khansa Butt: > On Thu, Dec 29, 2011 at 4:17 PM, Andreas Färber wrote: >> Also, given your observation, does it even make sense for >> cpu_mips_init() to call fpu_init() when all CPUState members it >> initializes get cleared in cpu_reset()? Maybe just move that call into >> cpu_reset() and rename it to fpu_reset()? mmu_init() and mvp_init() seem >> okay by contrast. > > why cpu_reset() calls memset? it does not reset all the members of CPUState only > those which are in the range of offsetof(CPUMIPSState, breakpoints). > what if I remove > memset line? I agree that the memset() line is bad as-is. My suggestion on some other threads about having multiple CPUStates and/or ARM reset was to at least define a macro than to copy this knowledge everywhere. QOM may help to improve that in the future with better Object Orientation. Today, the convention is that all struct members before 'breakpoints' are zeroed on reset. Things that come after 'CPU_COMMON' are therefore not reset. Things before CPU_COMMON, like in your case, need to be saved before the memset() and restored afterwards (if their value is to be preserved over reset) or initialized to some value (if different from zero). I would strongly suggest to live with memset() for now as it's already quite complicated to get *anything* done on mips as you've noticed. :) Regards, Andreas