On Mon, Nov 25, 2019 at 05:52:29PM -0500, Michael Meissner wrote: > On Fri, Nov 22, 2019 at 06:52:42PM -0600, Segher Boessenkool wrote: > > On Thu, Nov 14, 2019 at 05:51:14PM -0500, Michael Meissner wrote: > > > In some of my previous work, I had make a mistake forgetting that the > > > PADDI > > > instruction did not allow adding a PC-relative reference to a register > > > (you can > > > either load up a PC-relative address without adding a register, or you > > > can add > > > a register to a constant). The assembler allowed the instruction, but it > > > didn't do what I expected. > > > > So, what was the instruction? > > If you write: > > paddi 10,9,foo@pcrel > > The assembler will interpret this as: > > paddi 10,9,(.-foo),0 > > I.e. it will add the difference from current instruction to foo and register 2 > and place it in register 10. But it will not add the current location for the > paddi. > > Of course it might make sense if the assembler could flag the first line as an > error, and if you really wanted to write that, you should use: > > paddi 10,9,foo@pcrel,0
Does it ever make sense to allow @pcrel on anything that is not prefixed and R=1? (Cc: Alan). > > Can you fix this in the caller? > > Since the code was invalid, the add insn modification to allow adding an > address has been removed. It was a suggestion after I made the mistake to > make > sure that nobody else would make that mistake. > > As I said, this is an optional patch. The idea was to be helpful to other > people in the future, in that if they try to generate an add between a > register > and a PC-relative label, that the assembler would give a warnging (due to > (0),1 > present). > > If you don't think it is important to do that protection, I can leave it out. That isn't what I said. I'm not happy with how you implemented this, that's all. Segher
