Convert ARM to C
Given, for example, the following ARM assembly code, are there any easy ways to convert it directly to C using any suitable variable names?
ADD $2 $0 #9
ADD $3 $0 #3
ADD $1 $0 $0
loop: ADD $1 $1 #1
ADD $3 $0 $3, LSL #1
SUB $2 $2 $1
CMP $2 $1
BNE loop
Also, since I'm still learning ARM, how many times will the loop execute, SUB or ADD? Are there easy ways to determine this?
Thanks for the help! Any other understanding not specifically meant to answer this question would be great too.
source to share
In short, BNE
Branch Not Equal can suggest either a cycle do{...}while
or another path while (...){...}
, even perhaps a cycle for( ...; ... < ....; ...){...}
that is as far away as possible.
As far as reading addition / subtraction from some registers (read, memory variables in a C context) is concerned, you will have to play around reading it and coming up with an almost equivalent.
The decompiler might not help you at this point, play around with a couple of C code to practice and compile it in assembly using a command parameter -S
passed to the C compiler and see what you get, mostly trial and error I'm afraid, that is, if you are looking for an exact copy of this code in the above question.
source to share
unsigned int r0,r1,r2,r3;
r2=r0+9;
r3=r0+3;
r1=r0+r0;
do
{
r1=r1+1;
r3=r0+(r3<<1);
r2=r2-r1;
} while(r2!=r1);
not knowing what is going on in the loop r0 can happen multiple times or many times (e.g. millions? billions?) r2 decreases, r1 increases, if they don't collide with equals the first time they pass, they will have to roll around. each cycle r1 gets bigger, so r2 gets much faster. it should be very easy to add printf and some test values for r0 and see what happens.
say for example r0 is 0 before entering this code. r2 is equal to r0 + 9 = 9; and r1 is double r0, which is 0.
First, so many loops will go the way it does with four variables r0, r1, r2, r3
00000000 00000001 00000008 00000006
00000000 00000002 00000007 0000000C
00000000 00000003 00000006 00000018
00000000 00000004 00000005 00000030
00000000 00000005 00000004 00000060
00000000 00000006 00000003 000000C0
00000000 00000007 00000002 00000180
00000000 00000008 00000001 00000300
00000000 00000009 00000000 00000600
00000000 0000000A FFFFFFFF 00000C00
00000000 0000000B FFFFFFFE 00001800
r2 and r1 will not collide.
but if r0 was equal to 1, then
00000001 00000003 00000009 00000009
00000001 00000004 00000008 00000013
00000001 00000005 00000007 00000027
00000001 00000006 00000006 0000004F
r0 = 3
00000003 00000007 0000000B 0000000F
00000003 00000008 0000000A 00000021
00000003 00000009 00000009 00000045
r0 is still odd. but when you do r0 a 9 then
00000009 00000013 00000011 00000021
00000009 00000014 00000010 0000004B
00000009 00000015 0000000F 0000009F
00000009 00000016 0000000E 00000147
00000009 00000017 0000000D 00000297
00000009 00000018 0000000C 00000537
00000009 00000019 0000000B 00000A77
00000009 0000001A 0000000A 000014F7
00000009 0000001B 00000009 000029F7
00000009 0000001C 00000008 000053F7
00000009 0000001D 00000007 0000A7F7
00000009 0000001E 00000006 00014FF7
00000009 0000001F 00000005 00029FF7
00000009 00000020 00000004 00053FF7
00000009 00000021 00000003 000A7FF7
00000009 00000022 00000002 0014FFF7
00000009 00000023 00000001 0029FFF7
00000009 00000024 00000000 0053FFF7
00000009 00000025 FFFFFFFF 00A7FFF7
00000009 00000026 FFFFFFFE 014FFFF7
it is mostly a little deterministic with some rules, but if no comparison occurs, the loop can run forever, or at least many loops.
source to share