qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] target-mips: add ERETNC instruction and Config5


From: Maciej W. Rozycki
Subject: Re: [Qemu-devel] [PATCH] target-mips: add ERETNC instruction and Config5.LLB bit
Date: Mon, 22 Jun 2015 19:03:21 +0100 (BST)
User-agent: Alpine 2.11 (LFD 23 2013-08-11)

On Fri, 5 Jun 2015, Leon Alrae wrote:

> > As a side note, I have seen that you have added a check for MIPS2 to the
> > ERET instruction. This is correct, but given in practice we don't
> > emulate any MIPS1 CPU, I do wonder if it's not the time to make MIPS2
> > the basic instruction set and remove all MIPS2 checks.
> 
> Yes, in current codebase the MIPS2 checks don't seem to have much value
> and the removal makes sense. On the other hand I'm wondering if there
> are QEMU users who maintain artificial MIPS1 CPU templates locally to
> test if their compiler doesn't emit any non-MIPS1 instructions.

 Actually ERET is an instruction that has been added with the MIPS III 
ISA.  Sort of, that is, as it was not treated a part of the ISA, but an 
implementation detail specific to the particular exception model, 
introduced with the R4000.  It was only accepted as a part of the 
instruction set with the MIPS32/MIPS64 (r1) architecture that made the 
privilege model a part of the ISA.  Either way real MIPS II hardware (the 
R6000 and some LSI ISA approximates) used RFE instead of ERET, just like 
the R3000.

 As to the removal of MIPS I checks, I think there is some value in 
keeping them for documentation purposes if nothing else.  There's the TLB 
and cache model missing for R3000 class processors, but adding it 
shouldn't be that difficult.  As I keep maintaining support for real MIPS 
I hardware still around I'd be happy to add the missing bits and the right 
templates for some MIPS I implementations sometime, however regrettably I 
can't promise any deadline.  Adding an actual system to emulate along the 
CPU would be another matter.

 It would make sense IMO however to define the minimum ISA level supported 
somehow at the `configure' stage, so that parts of the emulator to support 
older processor models can be optimised away at the compilation stage.  
This would be conceptually similar to what we do in the Linux kernel with 
some optional features, including the ISA level, that are hardcoded to 
specific settings for individual systems where we know from how the system 
has been built that are always present (or absent).

 NB MIPS I user-mode Linux emulation would not be a perfect model as we 
have some additions to the kernel extending the bare MIPS I ISA in the 
Reserved Instruction exception handler to make software's life easier.

  Maciej



reply via email to

[Prev in Thread] Current Thread [Next in Thread]