1

So I am currently learning ARM assembly (and absolutely LOVE IT!) doing a school assignment where we use subroutines to calculate a particular value. I know school questions are frowned upon, but I have tried everything in my (very limited) ARM toolbox to get this program to work.

The one issue I am having is that my program kept going back too far from coming back from a branch statement and overwriting a value in a register that I was about to use. However, the weird thing is it keeps going back to the same MOV statement, no matter what I do. I can put a few dummy MOV statements after that MOV and before the entry for the branch and it will go right back up to that top MOV statement, and process everything below it.

Desperately, I used the command "MOV lr, pc" to "force" the link register to update right after that mysterious MOV statement before the branch, and lo-and-behold, it worked! However, this feels hack-y, as it is very static, similar to hard coding an array size or something like that.

But I am not really sure how else to fix it, if this isn't accepted in industry or I cannot argue it as valid for ARM7 (big endian), then I will probably post my code looking for help. So, is this normal or should I look elsewhere? I would like to avoid that if possible however, the assignment isn't due until later this week.

Thanks in advance!

TheN00bBuilder
  • 94
  • 1
  • 11
  • 2
    Normally you just use `bl funcname` to call and `bx lr` to return to the instruction after `bl`. But yes, `mov lr, pc` is a valid instruction. It assembles, and you can see that it executes if you single-step it in a debugger. Perhaps you'd be interested in knowing that reading PC on ARM gives you the address of 2 instructions after this one ([for historical reasons](https://stackoverflow.com/questions/24091566/why-does-the-arm-pc-register-point-to-the-instruction-after-the-next-one-to-be-e)). – Peter Cordes Mar 03 '20 at 02:27
  • 3
    Your problem isn't fixed until you understand why it's fixed. So rather than wondering whether this is "accepted", you should try to understand what it actually does, why it fixes your problem, what the problem actually was in the first place, whether your solution was a sensible way to solve it, or whether there is a better way. If you want help with any of that, post the code (or better, a [mcve]). – Nate Eldredge Mar 03 '20 at 02:47
  • I'm not saying I didn't want to know "why" it was fixed. I enjoy ARM because you control every aspect of it, and I want to learn all I can about it. What it does is that it forces the PC to update. After reading Peter's link, it makes sense on why it was wrong (even going back historically, unless I missed the point). Once the assignment is over (to prevent plagiarism) I will post the code and ask for clarification. I could make a minimal reproducible example but it'll be pseudo ARM and may/may not have the issue. I haven't experienced it anywhere else. – TheN00bBuilder Mar 03 '20 at 03:18
  • @TheN00bBuilder It does not “force the PC to update.” In fact, `mov lr, pc` does not affect the value of `pc` in any special way. Only `lr` is updated. – fuz Jun 05 '21 at 10:59

0 Answers0