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

[David G. <dg...@co...>]

Gregory T. (tim) Kelly wrote:
> At 2:43 PM -0400 7/19/06, David Given wrote:
>> As for whether the optimiser's sufficiently smart to be able to cope w=
ith
>> complex pipelines --- beats me. I haven't gone into that part of the s=
ystem
>> yet, and am not terribly knowledgeable about the whole topic.
>=20
> What (if any) are your long term plans with ACK?

Long-term? I've been going at this for a year and a half, now, so I
suspect that simply producing a usable release counts as long term...

But I don't really have anything in the way of specific long-term
planning. I just want to get it usable enough to gain users. In its
current state, the 5.6 release is simply too hard to set up, and I'm
hoping to improve that. With luck, there'll be enough users to develop a
certain amount of maintenance momentum --- although I doubt the ACK will
topple gcc, I do think that it can fill a very valuable niche in the
compiler ecosystem.

Plus, it's an amazingly elegant design, and it would be a terrible shame
if all that work died due to bit rot.

[...]
> Ok. It occurs to me that ACK was written before there was extensive
> pipelining in CPUs. It also seems to me that a stack-based virtual
> machine isn't going to be aware of pipelining.

*nods*

There seems to be exactly one usage of the word 'pipeline' in the entire
source tree in the CPU sense, and it's the bit in the ARM assembler that
calculates branch offsets...

[...]
> Sounds good. I look forward to working with the new stuff, just to
> have a common base to work from.

The good news is I now have my work tree in sufficient state that I can
compile a C program into ARM assembler!

The bad news is that when I tell it to compile for i386, it still
generates ARM assembler... there's a bug in pm that's causing it to pick
the wrong file when installing each stage. So, everything *compiles*,
but it doesn't get put together correctly. I'm looking into this.
Hopefully once I've tracked that down I can declare the new build system
to be sufficiently working to be useful.

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.

Source code:

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

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

        return total;
}
---snip---

Partially optimised em assembler:

---snip---
 mes 2,4,4
 exp $count
 pro $count,8
 mes 3,4,4,0,1
 mes 3,0,4,0,1
 mes 3,-8,4,0,5
 mes 3,-4,4,0,4
 mes 3
 mes 9,8
 loc 0
 stl -4
 lol 0
 stl -8
6
 lol -8
 lol 4
 cmi 4
 zle *5
 bra *3
5
 lol -8
 lol -4
 adi 4
 stl -4
 lol -8
 loc 1
 adi 4
 stl -8
 bra *6
3
 lol -4
 ret 4
 end 8
 mes 4,10,'test.c\000'
---snip---

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}
---snip---

Unoptimised i386 assembler (after manual hacking to get the code
generator in place):

---snip---
=2Esect .text; .sect .rom; .sect .data; .sect .bss
=2Eextern _count
=2Esect .text
_count:
push ebp
mov ebp,esp
push esi
push edi
xor edi,edi
mov esi,8(ebp)
I1_6:
xor eax,eax
cmp esi,12(ebp)
je 2f
jg 1f
inc eax
jmp 2f
1:
dec eax
2:
! kill cc
test eax,eax
jle I1_5
jmp I1_3
I1_5:
add edi,esi
add esi,1
jmp I1_6
I1_3:
mov eax,edi
pop edi
pop esi
leave
ret
---snip---

There's something very odd going on in that loop.

--=20
+- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_
|  dg...@co...    | until you have read it in the original Klingon."
| (dg...@ta...) | --- Sea Wasp on r.a.sf.w
+- www.cowlark.com --+