Most of the platforms in the IDE that are powerful enough to support a C compiler are Z80-based. The Z80 isn’t the easiest target for C, but at least it has a lot of registers.

While the 6502 only has three 8-bit registers, the 6502 has strengths the Z80 doesn’t, as we’ll see here.

Let’s compare the two dominant C compilers for these CPUs. We’ll compile a function with the CC65 C compiler for the 6502, and then with the SDCC (Small Device C Compiler) for the Z80. We’ll call the function getValue():

int arr16[128];

int getValue(int index) {
    return (arr16[index & 0x7f] & 0xff) >> 1;
}

This function just looks up a value in a array of 16-bit ints, truncates the result to 8 bits, then divides it by 2.

We’ll first compile it with the default flags for both compilers:

	6502 VERSION (cc65)		Z80 VERSION (sdcc)

        jsr     pushax		        push    ix
        ldy     #$01                    ld      ix,#0
        jsr     ldaxysp                 add     ix,sp
        ldx     #$00                    ld      bc, #_arr16+0
        and     #$7F                    ld      l, 4 (ix)
        jsr     aslax1                  res     7, l
        clc                             ld      h, #0x00
        adc     #<(_arr16)              add     hl, hl
        tay                             add     hl, bc
        txa                             ld      c, (hl)
        adc     #>(_arr16)              ld      h, #0x00
        tax                             sra     h
        tya                             rr      c
        ldy     #$01                    ld      l, c
        jsr     ldaxidx                 pop     ix
        ldx     #$00
        jsr     asrax1
        jmp     L0004
L0004:  jsr     incsp2
        rts

The 6502 version is a little more verbose here, compiling to 41 bytes vs. 31 bytes for Z80. One big difference: SDCC turns on most optimizations by default. That’s not fair, so let’s see what optimizations we can activate for CC65.

We’ll compile it again, but this time we’ll pass the -O flag to CC65. We’ll try to get the Z80 version even smaller by passing --opt-code-size to SDCC:

        6502 VERSION (cc65 -O)          Z80 VERSION (sdcc --opt-code-size)

        jsr     pushax		        call    ___sdcc_enter_ix
        ldy     #$00                    ld      bc, #_arr16+0        
        lda     (sp),y                  ld      l, 4 (ix)            
        asl     a                       res     7, l                 
        tay                             ld      h, #0x00             
        lda     _arr16,y                add     hl, hl               
        ldx     #$00                    add     hl, bc               
        lsr     a                       ld      c, (hl)              
        jmp     incsp2                  ld      h, #0x00             
                                        sra     h                    
                                        rr      c                    
                                        ld      l, c                 
                                        pop     ix                   
                                        ret

The 6502 version is a lot smaller, down to 18 bytes! The Z80 version is only a little smaller due to the replacement of the stack frame setup with a function call.

What happened here to make the 6502 version so small?

The pedigree of CC65 goes back to 1980 and the Small C compiler. As a result, its optimization methods depend highly on peephole optimization. This is a method of scanning code linearly to look for patterns, then rewriting those patterns to be more efficient.

One such pattern is one I recently added in my own branch. It looks for 16-bit array lookups of the form:

array16[index & 0x7f]	// or index < 0x7f

CC65 defers most optimization until after code generation. The pseudocode before optimization looks more-or-less like this:

AX = index
AX = AX & 0x7f
AX = AX << 1
AX = AX + address(arr16)
AX = read16(AX)
AX = AX >> 1
return AX

This may not look like a lot of code, but AX is a 16-bit value (actually the AX register pair) and manipulating 16-bit values is expensive on the 6502. We need to find a way to reduce it to an 8-bit problem.

The key here is the index & 0x7f mask. This guarantees that the array index will be less than 128. Each array element takes two bytes, so we only have to index up to 256 bytes of data – enough for 8 bits.

Instead of computing a 16-bit offset for the array, we can use the 6502’s indexed addressing mode, i.e. LDA address,Y. The pseudocode now looks like this:

		// jsr pushax
		// ldy #$00
A = index	// lda (sp),y
A = A << 1	// asl a
Y = A		// tay
A = arr16[Y]	// lda _arr16,y
		// ldx #$00
A = A >> 1	// lsr a
return A	// jmp incsp2

Because we’re dealing mainly with 8-bit values, this code becomes much smaller and faster. Note that we don’t even need the index & 0x7f mask anymore, because the asl a instruction takes off that high bit for us.

Let’s compare the non-optimized 6502 output with the optimized version:

        ORIGINAL VERSION                OPTIMIZED VERSION

        jsr     pushax		        jsr     pushax
        ldy     #$01			ldy     #$00
        jsr     ldaxysp		        lda     (sp),y
        ldx     #$00
        and     #$7F
        jsr     aslax1		        asl     a
        clc
        adc     #<(_arr16)
        tay
        txa
        adc     #>(_arr16)
        tax
        tya
        ldy     #$01		        tay
        jsr     ldaxidx		        lda     _arr16,y
        ldx     #$00		        ldx     #$00
        jsr     asrax1		        lsr     a
        jmp     L0004
L0004:  jsr     incsp2		        jmp     incsp2
        rts

The Z80 doesn’t have a equivalent addressing mode. To do a fast 8-bit table lookup, we have to align our table to a 256-byte page. Then we can stuff the index in the lower 8 bits of a 16-bit register pair. The result would look sort of like this:

        ld      h, #>(_arr16)    ; H = MSB of table (constant)
        ld      a, 4 (ix)        ; index parameter
        sla     a                ; shift left
        ld      l, a		 ; L = LSB of table (computed)
        ld      a, (hl)          ; look up 8-bit value in HL

The 6502 doesn’t require page alignment, so it has the edge here in optimizing this case. The Z80 is better at other things, like dealing with structs.

Thanks for reading! If you want to play with the CC65 C compiler, you can do so right now in the 8bitworkshop IDE using the venerable Apple II platform (with maybe more coming in the future!)