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

[Andreas Färber]

[cc'ing list]

Am 30.12.2011 08:52, schrieb Khansa Butt:
> On Thu, Dec 29, 2011 at 4:17 PM, Andreas Färber <address@hidden> 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