search for: haflword

Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are some places where we use C++ code that I think we could use just td files or maybe in some cases add some small extensions to tablegen. Rig...

...e load/store word instructions, there are forms which implicitly take SP. However, for store/load byte and store/load halfword, there is no such instruction. In such cases, if I were writing assembly language code, I would move SP to a mips 16 register and then use it to do the store/load byte/haflword. It also then becomes a common subexpression because there may be multiple such accesses. It's like a temporary register alias. Add, Sub also have a way to reference memory using mips16 registers as a base address, so various operators on stack data are simplified. Any thoughts? Many way...

...11:44 PM, Reed Kotler <rkotler at mips.com> wrote: > >> Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. >> > > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. &...

...instructions, there are forms which implicitly take SP. > > However, for store/load byte and store/load halfword, there is no such instruction. > > In such cases, if I were writing assembly language code, I would move SP to a mips 16 register and then use it to do the store/load byte/haflword. > > It also then becomes a common subexpression because there may be multiple such accesses. > > It's like a temporary register alias. > > Add, Sub also have a way to reference memory using mips16 registers as a base address, so various operators on stack data are simplifi...

...012, at 11:44 PM, Reed Kotler <rkotler at mips.com> wrote: > Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. If you'r...

...Reed Kotler <rkotler at mips.com> wrote: >> >>> Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. >>> >> >> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLower...

...otler <rkotler at mips.com> wrote: >>> >>>> Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. >>>> >>> >>> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the...