Re: [Tack-devel] back-end tables, assemblers, and front-ends

[Gregory T. (t. K. <gt...@di...>]

At 8:28 AM -0400 7/20/06, David Given wrote:
>This is with opt (the global peephole optimiser), but without ego (the
>really heavyweight global optimisers) or top (the target peephole
>optimiser), so the generated code is pretty awful. Also, I suspect that
>the ARM code generator is rather poor. It appears to want to pass all
>parameters on the stack, which disturbs me a little.

I think there is something wrong with the ARM code generator.  I'm guessing=
 you got non-sensical answers when you ran this.  I can't figure out how the=
 passed arguments make it into the machine registers for calculation.

David's straightforward C code, which sums the numbers from min to max:

int count(int min, int max)
{
        int total =3D 0;
        int i;

        for (i=3Dmin; i<=3Dmax; i++)
                total +=3D i;

        return total;
}

Unoptimised ARM assembler:

---snip---
=2Esect .text
=2Esect .rom
=2Esect .data
=2Esect .bss
=2Eextern _count
=2Esect .text
_count:
STMFD R12<,{R13,R14}
MOV R13,R12
SUB R12,R12,#8
STMFD R12<,{R7,R6}
MOV R6,#0
LDR R7,[R13,#8]
I0016:
LDR R11,[R13,#12]
RSB.S R11,R11,R7
BLE I0015
BAL I0013
I0015:
ADD R6,R7,R6
ADD R7,R7,#1
BAL I0016
I0013:
MOV R0,R6
LDMFD R12<,{R7,R6}
MOV R12,R13
LDMFD R12<,{R13,R15}

I'm not fluent in ARM, so I am going to put some notes in the ARM assembler=
 output code; please correct me if I have mistakenly identified parts.

=46ile format information:

=2Esect .text
=2Esect .rom
=2Esect .data
=2Esect .bss

function name:

=2Eextern _count
=2Esect .text
_count:


set up local (machine) stack:

save off link register and stack register to r12 (decrements r12):

STMFD R12<,{R13,R14}=20

move the new stack pointer value into r13 (the stack pointer register):

MOV R13,R12=20

make room on the original stack:

SUB R12,R12,#8

save off non-volatile registers to original stack (decrements r12):

STMFD R12<,{R7,R6}

initialize total (and total is in r6)

MOV R6,#0

in theory, retrieve min from the stack and put it in r7, for i:

LDR R7,[R13,#8]



Except there's a piece missing - where are the arguments from r0-r4? =
 Shouldn't min be in r0 and max be in r1 (or vice-versa, I don't know the=
 specific calling convention)?  Looks to me like this code would pull in the=
 values in memory in the stack hole from the SUB R12, R12, #8 instruction=
 although I don't see anything stored to that location.



label the start of the loop:

I0016:

retrieve max from the stack and put it in r11:

LDR R11,[R13,#12]

compare r7 (i) to r11 (max):

RSB.S R11,R11,R7

branch ahead two instructions if r7 less than r11:

BLE I0015

break out of loop if r7 not less than r11:

BAL I0013

label the branch:

I0015:

add the current value of i (r7) to total (r6):

ADD R6,R7,R6

increment r7 (the growing value of i)

ADD R7,R7,#1

branch back to start of loop:

BAL I0016

label break out point:

I0013:

move total to the return register r0:

MOV R0,R6

restore the non-volatile registers:

LDMFD R12<,{R7,R6}

restore the stack:

MOV R12,R13
LDMFD R12<,{R13,R15}


Partially optimised em assembler:

Yeah, well, I'm not there yet. :-)  I can't tell if the mes instructions are=
 clear about the passed parameters.  If they are, then I'd guess the problem=
 was in the ARM assembler not properly locating the passed values from the=
 registers.  I think the assembler should have something like


STMFD R12<,{R13,R14}
STMFD R12<,{R0,R1}
MOV R13,R12
STMFD R12<,{R7,R6}
MOV R6,#0
LDR R7,[R13,#8]

since r13 is r12+8.  The whole stack reference isn't clean.  I don't know=
 why the assembler would save off the original stack to a register, create=
 space for a new stack frame, but then reference variables relative to the=
 original stack frame location.  That's why there's [r13,#8] and [r13,#12]=
 to refer to the min and max values as passed in.  The location of the=
 instruction I put in for saving r0 and r1 to the original stack should=
 preserve the rest of the stack offsets in the code and I also dropped the=
 instruction to subtract eight bytes from the original stack location.  I=
 think the additional STMFD will handle that.  All the same, I'm not fluent=
 in ARM and I might have some stack addition mistakes.  I just don't see=
 where the function call arguments are properly stored on any stack.  It's=
 possible the SUB instruction is incorrect and that's where the arguments=
 saving instruction is supposed to go.

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu