[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