I'm trying to write a backend for a machine that has both byte and word instructions. Both varieties of instructions operate on the same set of general registers. A byte mode instruction on a general register always clears the upper bits. Register-to-register byte mode and work mode instructions set condition codes based on bytes and words and thus are not interchangeable. Do I need to have separate classes of registers for the work and byte instructions? If so, I assume the byte registers are declared as SubRegs? Also, this machine supports memory-to-memory operations in byte and word flavors. What do I need to look out for to support this. If have looked at the X86 *.td's, but that architecture is so complex it is hard to extract the information I need. Thanks, Bagel
On Mar 14, 2008, at 10:17 AM, Bagel wrote:> I'm trying to write a backend for a machine that has both byte and > word > instructions. Both varieties of instructions operate on the same > set of > general registers. A byte mode instruction on a general register > always clears > the upper bits. Register-to-register byte mode and work mode > instructions set > condition codes based on bytes and words and thus are not > interchangeable. > > Do I need to have separate classes of registers for the work and byte > instructions? If so, I assume the byte registers are declared as > SubRegs?Yes. Then you want to declare byte registers as sub-registers of the word-registers.> > > Also, this machine supports memory-to-memory operations in byte and > word > flavors. What do I need to look out for to support this.The instruction selector can be taught to *fold* loads and stores. X86 has many load + modify + write instructions. You can take a look their patterns in X86InstrInfo.td Does the target have operations that operate on multiple memory operands? In theory, it's possible to write patterns to select these as well.> > > If have looked at the X86 *.td's, but that architecture is so > complex it is > hard to extract the information I need.Unfortunately x86 is the only target that supports both of the features you described. If you want to get started by looking at existing examples, it's pretty much the only choice. Evan> > > Thanks, > Bagel > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Thanks, I seem to have gotten sub-registers to work. I can't seem to suppress the zero-extend sometimes. There is no need to explicitly zero extend bytes to words on this machine as all byte operations do that. I have also gotten some memory-to-memory to work. Bagel Evan Cheng wrote:> On Mar 14, 2008, at 10:17 AM, Bagel wrote: > >> I'm trying to write a backend for a machine that has both byte and >> word >> instructions. Both varieties of instructions operate on the same >> set of >> general registers. A byte mode instruction on a general register >> always clears >> the upper bits. Register-to-register byte mode and work mode >> instructions set >> condition codes based on bytes and words and thus are not >> interchangeable. >> >> Do I need to have separate classes of registers for the work and byte >> instructions? If so, I assume the byte registers are declared as >> SubRegs? > > Yes. Then you want to declare byte registers as sub-registers of the > word-registers. > >> >> Also, this machine supports memory-to-memory operations in byte and >> word >> flavors. What do I need to look out for to support this. > > The instruction selector can be taught to *fold* loads and stores. X86 > has many load + modify + write instructions. You can take a look their > patterns in X86InstrInfo.td Does the target have operations that > operate on multiple memory operands? In theory, it's possible to write > patterns to select these as well. > >> >> If have looked at the X86 *.td's, but that architecture is so >> complex it is >> hard to extract the information I need. > > Unfortunately x86 is the only target that supports both of the > features you described. If you want to get started by looking at > existing examples, it's pretty much the only choice. > > Evan > >> >> Thanks, >> Bagel >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >