The problem is that everything about the mips32 and micro mips 16 instruction is the same, aside from the encoding in to binary. Seems like maybe we need to extend the notion of an instruction so that it can have alternate encodings depending on subtarget. On 09/05/2012 08:28 PM, Jim Grosbach wrote:> The instructions are defined by their encodings, not the assembly syntax. You want separate instruction definitions for the different encodings and select. Between them in the assembler via sub target features. See ARM handling of thumb vs thumb2 vs arm for examples of how to do this. > > On Sep 5, 2012, at 6:59 PM, reed kotler<rkotler at mips.com> wrote: > >> The micro mips processor assembly language is basically 100% the same as mips32/mips64. >> There are some assembler directives you add but for a base port, but that is all you need to do. >> >> However, the binary instruction encoding is entirely different. There are a combination of 16 and 32 bit instruction encodings. >> >> The question is, what's the best way to handle this? >> >> Extending tablegen ? >> >> You would want a single instruction to have multiple encodings dependent on the current mode we are compiler for. >> >> Thoughts? >> >> reed >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
My understanding was that micro mips was similar to Thumb2, in that the smaller encodings have constraints on which registers can be read/written, because of the narrowing of the register fields in the encoding. If that's the case, then it definitely makes sense to model the micro mips instruction set as distinct from the mips32 instruction set, in basically the same way that Thumb2 is done. The reason for this is this: in micro mips mode, you're going to need to split each opcode with a 16-bit variant (say, ADD) into two versions: the 16-bit version with constrained input/output registers, and the 32-bit version with unconstrained registers. Since this distinction doesn't exist in mips32, you'll want to have them entirely guarded under a micromips subtarget. This really is almost exactly the same situation as Thumb2 on ARM. I strongly suggest you look at how it's implemented there. --Owen On Sep 5, 2012, at 9:45 PM, reed kotler <rkotler at mips.com> wrote:> The problem is that everything about the mips32 and micro mips 16 instruction is the same, aside from the encoding in to binary. > > Seems like maybe we need to extend the notion of an instruction so that it can have alternate encodings depending on subtarget. > > On 09/05/2012 08:28 PM, Jim Grosbach wrote: >> The instructions are defined by their encodings, not the assembly syntax. You want separate instruction definitions for the different encodings and select. Between them in the assembler via sub target features. See ARM handling of thumb vs thumb2 vs arm for examples of how to do this. >> >> On Sep 5, 2012, at 6:59 PM, reed kotler<rkotler at mips.com> wrote: >> >>> The micro mips processor assembly language is basically 100% the same as mips32/mips64. >>> There are some assembler directives you add but for a base port, but that is all you need to do. >>> >>> However, the binary instruction encoding is entirely different. There are a combination of 16 and 32 bit instruction encodings. >>> >>> The question is, what's the best way to handle this? >>> >>> Extending tablegen ? >>> >>> You would want a single instruction to have multiple encodings dependent on the current mode we are compiler for. >>> >>> Thoughts? >>> >>> reed >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Micro mips is really 100% .s compatible with mips32. There are no register field size constraints and such. It's a strict superset of mips32. For the gcc port, the assembler is basically the only thing we changed. The gcc port was just adding the ".micromips" directive to the .s file and maybe some tiny driver work. That is the quandary. The entire .td file would have to be duplicated and just the instruction binary encoding changed. Mips16 ,which is what I am almost finished with (base port), is more different and has a lot of restrictions and we followed some of the ideas in the Arm port as you describe. There are some micro mips optimizations that can be done to make smaller code size but it's not needed for any kind of base port. So, I'm thinking that maybe tablegen could be extended to allow for alternate instruction encoding. We could also make some kind of tablegen front end macros. I'm floating this email to elicit ideas on how we could approach the direct object emission problem. The basic port to micro mips producing .s files is probably one weeks work at most. On 09/06/2012 12:16 AM, Owen Anderson wrote:> My understanding was that micro mips was similar to Thumb2, in that the smaller encodings have constraints on which registers can be read/written, because of the narrowing of the register fields in the encoding. > > If that's the case, then it definitely makes sense to model the micro mips instruction set as distinct from the mips32 instruction set, in basically the same way that Thumb2 is done. The reason for this is this: in micro mips mode, you're going to need to split each opcode with a 16-bit variant (say, ADD) into two versions: the 16-bit version with constrained input/output registers, and the 32-bit version with unconstrained registers. Since this distinction doesn't exist in mips32, you'll want to have them entirely guarded under a micromips subtarget. > > This really is almost exactly the same situation as Thumb2 on ARM. I strongly suggest you look at how it's implemented there. > > --Owen > > > On Sep 5, 2012, at 9:45 PM, reed kotler <rkotler at mips.com> wrote: > >> The problem is that everything about the mips32 and micro mips 16 instruction is the same, aside from the encoding in to binary. >> >> Seems like maybe we need to extend the notion of an instruction so that it can have alternate encodings depending on subtarget. >> >> On 09/05/2012 08:28 PM, Jim Grosbach wrote: >>> The instructions are defined by their encodings, not the assembly syntax. You want separate instruction definitions for the different encodings and select. Between them in the assembler via sub target features. See ARM handling of thumb vs thumb2 vs arm for examples of how to do this. >>> >>> On Sep 5, 2012, at 6:59 PM, reed kotler<rkotler at mips.com> wrote: >>> >>>> The micro mips processor assembly language is basically 100% the same as mips32/mips64. >>>> There are some assembler directives you add but for a base port, but that is all you need to do. >>>> >>>> However, the binary instruction encoding is entirely different. There are a combination of 16 and 32 bit instruction encodings. >>>> >>>> The question is, what's the best way to handle this? >>>> >>>> Extending tablegen ? >>>> >>>> You would want a single instruction to have multiple encodings dependent on the current mode we are compiler for. >>>> >>>> Thoughts? >>>> >>>> reed >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev