Converting ARM to C - c

Question

Given, for example, the following ARM assembly code, are there any straightforward ways to convert it directly to C, using whatever appropriate 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, as I'm still learning ARM, how many times will the loop execute say, SUB or ADD? Are there straightforward ways to determine this?
Thanks for the help! Any other insight not particularly aimed at answering the question would also be great.

Answer 1

In short, BNE - Branch Not Equal, could suggest either a do{...}while loop or the other way while (...){...}, even possibly a for( ...; ... < ....; ...){...} loop, that's about far as it can go.
As for reading the addition/subtraction from some registers (read, memory variables in the context of C), you will have to play by reading it and come up with a near equivalent.
A decompiler may not help you at this stage, play with a couple of C code to practice and compile it to assembler language using the -S command parameter passed to the C compiler and see what you get, mostly trial and error am afraid, that is, if you're looking for the exact replica of that code in the above question.

Answer 2

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 r0 is going in the loop can happen a few times or many times (like millions? billions?) r2 is decreasing, r1 is increasing if they dont collide with an equals the first time they pass they will have to roll around. every loop r1 gets bigger so r2 gets smaller that much faster. should be very easy to add a printf and some test values for r0 and see what happens.
say for example r0 is a 0 before entering this code. r2 is r0+9 = 9; and r1 is double r0 which is 0.
The first so many loops would go like this with the 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 are not going to collide.
but if r0 was a 1 going in 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 needs to be odd so far. but when you make 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
basically it is a little deterministic with some rules, but if the comparison doesnt happen then the loop may run forever or at least many many cycles.