On Mon, 29 Jul 2013, Richard Sandiford wrote: > > I believe the only legacy MIPS processors that implemented the MIPS16 ASE > > in its original variation (i.e. with no compact jumps, no SAVE/RESTORE, > > and no extend instructions) were the LSI's TinyRISC cores. > > Ah, hadn't realised that the original version had no EXTEND instruction. > Which TinyRISC iteration was that? The LR4102 had it AFAIK. > > FWIW GCC and binutils always assume that EXTEND is available and just > make a distinction between "original MIPS16" (which sounds like it might > not be as original as I'd thought) and "MIPS16e". The VR4121 and VR4131 > were also in the "original MIPS16" category (no compact jumps, SAVE/RESTORE, > etc.). But they also had no FPU.
I meant the sign- and zero-extend instructions indeed, not the EXTEND opcode (not really a distinct instruction, more like a prefix), sorry for not being clear enough. Thanks for the reminder of the NEC silicon. > > These stubs are I believe not really covered in our testing, because they > > require a mixed standard-MIPS/MIPS16 environment. > > What's the barrier to testing a mixed environment? The normal *-linux-gnu > configurations have no MIPS16 multilibs, so you should be able to test it > on a plain mips-linux-gnu configuration using --target_flags unix/-mips16. > FWIW I've been using the mips64-linux-gnu equivalent > (--target_flags unix/-mabi=32/-mips16) without problems. > > Or if you don't want to test on GNU/Linux, you should be able to use something > like mips64-elf configured with whichever --with-arch= you like (and an > appropriate simulator). Long time since I tried that though. I prefer > testing on GNU/Linux because it also covers libgcc.so symbol visibility > and has better libgfortran support. We don't have specific coverage, but something in the testsuite might happen to pull one or more of these thunks indeed. > > libgcc/ > > * config/mips/mips16.S (DELAYf): Alias to DELAYt for the MIPS IV > > ISA and up. > > OK, thanks, but please do run it through the testsuite first. I'll see if I can do it -- the MIPS/Linux tree I used for recent MIPS32r2 MADD.fmt testing has no MIPS16 multilibs configured, so it might happen to just work with -mips16 passed as an extra option (otherwise MIPS16 libs would be automagically picked instead). I'll check if binaries executeed really pulled any of the thunks concerned. Maciej
