On Tue, 15 Jan 2013, David Daney wrote: > > I'm not understanding why mips16 and nomips16 are not simple inheritable > > attributes. > > The mips16ness of a function must be known by the caller so that the > appropriate version of the JAL/JALX instruction can be emitted
Not really, the issue of JAL vs JALX is sorted out by the linker, for both instruction encodings. It is the use of tail/sibling calls that is more of a problem (there's no JX instruction to relax J to; of course this applies to standard MIPS code only, as there's no MIPS16 J instruction), but that is generally controlled with the -minterlink-mips16 option. The same applies to mixing standard MIPS and microMIPS code as far as the linker is concerned (there are some additional restrictions due to a short delay slot a jump instruction may have; such instructions cannot be relaxed to cross-mode jumps). > > i..e you should be able to say: > > > > void foo(); > > void __attribute((nomips16)) foo(); > > > > > > or > > > > void goo(); > > Any call here would assume nomips16 > > > void __attribute((mips16)) goo(); > > A call here would assume mips16. > > Which is it? If you allow it to change, one case will always be incorrect. You can still provide a prototype with neither attribute applied and then build the actual function as either standard MIPS or MIPS16 code by using the -mips16 or -mno-mips16 command line option. Maciej
