> As there will be a need to verify the support for MIPS2, we should aim > for the platform that we can physically get at some point and use for > testing/verification and improvement of the model.
I agree. I'm not sure where I'm likely to find one though. > Untested support is not what you would benefit from, even if it is only > for the sake of checking whether the instructions belong to MIPS2 set or not. I don't completely agree with you here. Tested and verified support is obviously best but even if qemu's support isn't perfectly verified, having a second independent opinion on the correct behaviour is still valuable. In theory, we're unlikely to share the same bugs. > Speaking of which, if that is the main purpose you would like to use QEMU for, > bear in mind that successful execution of a program does not mean the > program is free of illegal instructions. Indeed. It only means that the execution trace is free of illegal instructions (in qemu's opinion). > -----Original Message----- > From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com] > Sent: 15 December 2014 14:59 > To: Daniel Sanders; Vasileios Kalintiris > Cc: qemu-devel@nongnu.org; Leon Alrae > Subject: RE: [PATCH] target-mips: add CPU definition for MIPS-II > > Attempt to add a real model is for sure better option than adding a > plain generic model. > > As there will be a need to verify the support for MIPS2, we should aim > for the platform that we can physically get at some point and use for > testing/verification and improvement of the model. Untested support is > not what you would benefit from, even if it is only for the sake of > checking whether the instructions belong to MIPS2 set or not. Speaking > of which, if that is the main purpose you would like to use QEMU for, > bear in mind that successful execution of a program does not mean the > program is free of illegal instructions. > > Regards, > Petar > > From: Daniel Sanders [mailto:daniel.sand...@imgtec.com] > Sent: Monday, December 15, 2014 3:03 PM > To: Vasileios Kalintiris; Petar Jovanovic > Cc: qemu-devel@nongnu.org; Leon Alrae > Subject: RE: [PATCH] target-mips: add CPU definition for MIPS-II > > Hi, > > FWIW, the R6000 was a MIPS-II processor but I understand there was never a > proper manual for it. http://www.linux-mips.org/wiki/R6000 has a small > amount of information but not enough to accurately fill in qemu's structure. > > > If this is really problematic for qemu, why don't we add an > > --enable-experimental-targets, --enable-generic-targets or something > > similar for generic/old CPU definitions? > > One other possibility is to use a real CPU name such as R6000 but use > reasonable guesses where information is unavailable. Is that a good > compromise? > > Daniel Sanders > Leading Software Design Engineer, MIPS Processor IP > Imagination Technologies Limited > www.imgtec.com > > From: Vasileios Kalintiris > Sent: 15 December 2014 10:09 > To: Petar Jovanovic > Cc: qemu-devel@nongnu.org; Leon Alrae; Daniel Sanders > Subject: RE: [PATCH] target-mips: add CPU definition for MIPS-II > > Hello Petar, > > I've seen some older threads in the mailing list and I'm aware that > adding generic CPU definitions is something that should be avoided. > However, I don't have any real MIPS-II machine readily available at > the moment. > > We need support for the MIPS-II ISA because we enabled the MIPS-II > target in the Clang/LLVM projects and we are running the LLVM > test-suite under QEMU. This allows us to verify that we are not > emitting invalid instructions or instructions that belong to another > version of the ISA. Also, Debian targets MIPS-II for compatibility > reasons and testing the code generation of the compiler for that ISA > is rather important. > > So there's an actual need for a MIPS-II definition and it wouldn't > be convenient to have to maintain out-of-tree support for MIPS-II > > If this is really problematic for qemu, why don't we add an > --enable-experimental-targets, --enable-generic-targets or something > similar for generic/old CPU definitions? > > Thanks, > Vasileios Kalintiris > ________________________________________ > From: Petar Jovanovic [petar.jovano...@rt-rk.com] > Sent: 01 December 2014 23:45 > To: Vasileios Kalintiris > Cc: qemu-devel@nongnu.org; Leon Alrae > Subject: RE: [PATCH] target-mips: add CPU definition for MIPS-II > Adding (another) generic model for an old ISA revision is rather > discouraged in QEMU trunk. Can you add a particular real CPU model? > > Regards, > Petar > ________________________________________ > From: Vasileios Kalintiris > Sent: 25 November 2014 11:04 > To: address@hidden > Cc: Leon Alrae; address@hidden > Subject: [PATCH] target-mips: add CPU definition for MIPS-II > > Add mips2-generic among CPU definitions for MIPS. > > Signed-off-by: Vasileios Kalintiris <address@hidden> > --- > target-mips/translate_init.c | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c > index 148b394..d4b1cd8 100644 > --- a/target-mips/translate_init.c > +++ b/target-mips/translate_init.c > @@ -108,6 +108,29 @@ struct mips_def_t { > static const mips_def_t mips_defs[] = > { > { > + /* A generic CPU providing MIPS-II features. > + FIXME: Eventually this should be replaced by a real CPU model. > */ > + .name = "mips2-generic", > + .CP0_PRid = 0x00018000, > + .CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_R4000 << CP0C0_MT), > + .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (15 << > CP0C1_MMU) | > + (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) | > + (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA) | > + (0 << CP0C1_CA), > + .CP0_Config2 = MIPS_CONFIG2, > + .CP0_Config3 = MIPS_CONFIG3, > + .CP0_LLAddr_rw_bitmask = 0, > + .CP0_LLAddr_shift = 4, > + .SYNCI_Step = 32, > + .CCRes = 2, > + .CP0_Status_rw_bitmask = 0x30000011, > + .CP1_fcr0 = (1 << FCR0_W) | (1 << FCR0_D) | (1 << FCR0_S), > + .SEGBITS = 32, > + .PABITS = 32, > + .insn_flags = CPU_MIPS2, > + .mmu_type = MMU_TYPE_R4000, > + }, > + { > .name = "4Kc", > .CP0_PRid = 0x00018000, > .CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_R4000 << CP0C0_MT), > -- > > ping >
