On Tue, 2 Dec 2014, Leon Alrae wrote:

> > @@ -19276,6 +19276,10 @@ void mips_cpu_dump_state(CPUState *cs, F
> >                  env->CP0_Status, env->CP0_Cause, env->CP0_EPC);
> >      cpu_fprintf(f, "    Config0 0x%08x Config1 0x%08x LLAddr 0x" 
> > TARGET_FMT_lx "\n",
> >                  env->CP0_Config0, env->CP0_Config1, env->lladdr);
> > +    cpu_fprintf(f, "    Config2 0x%08x Config3 0x%08x\n",
> > +                env->CP0_Config2, env->CP0_Config3);
> > +    cpu_fprintf(f, "    Config4 0x%08x Config5 0x%08x\n",
> > +                env->CP0_Config4, env->CP0_Config5);
> 
> Wouldn't it be better to order these registers for example by CP0
> Register and Select number rather than putting them at the end? I think
> it doesn't matter at the moment as there are just few registers printed
> out, but once we start adding more then probably we would like to avoid
> having them placed arbitrarily in the output.

 I placed the registers such that output renders in a well-formatted 
readable way.  Please note that we print 64-bit registers at the right 
side and I avoided intermixing 32-bit registers with 64-bit registers.

 I agree we might reformat output according to CP0 Register and Select 
numbers as for example our (Mentor's) GDB does in `info registers' (the 
change to dump all available CP0 registers in GDB hasn't made its way 
upstream yet, partially due to the XML register description issue I 
mentioned previously).  Hovewer we need to think how to format output in a 
readable way as the receiver will most often be a human being.

 I think deciding on a uniform register width, i.e. the native machine 
word size of the CPU, might help here, after all in the execution stream 
you can access them with DMFC0 on 64-bit processors and get the expected 
result (with "don't-care's" in the upper 32 bits).  The drawback is more 
screen space is used for data which can make it all harder to comprehend.  
For example I find the output of `info registers' produced by GDB on a 
64-bit target more difficult to process in my head than the corresponding 
output on a 32-bit target.  Maybe we can leave the upper 32 bits padded 
with spaces rather than zeros though.

  Maciej

Reply via email to