Assembler Optimizer

Here are 3 more. As the other example, sdcc-code is commented out. Oriented towards speed.

;game.c:1106: if( g_nViewPortY < g_nMinViewportY )
	; 92 cycles
	; ld	hl, #_g_nMinViewportY
	; ld	iy, #_g_nViewPortY
	; ld	a, 0 (iy)
	; sub	a, (hl)
	; ld	a, 1 (iy)
	; inc	hl
	; sbc	a, (hl)

	; 56 cycles
	ld	de, (#_g_nMinViewportY)
	ld	hl, (#_g_nViewPortY)
	sbc hl, de

and this one:

;game.c:1119: g_nViewPortXSprites = g_nViewPortX+SPRITE_WIDTH;
	; 108 cycles
	; ld	hl, #_g_nViewPortXSprites
	; ld	iy, #_g_nViewPortX
	; ld	a, 0 (iy)
	; add	a, #0x10
	; ld	(hl), a
	; ld	a, 1 (iy)
	; adc	a, #0x00
	; inc	hl
	; ld	(hl), a

	; 57 cycles
	ld 	de, #0x10	; SPRITE_WIDTH
	ld 	hl, ( #_API_g_nViewPortX )
	add hl, de
	ld  ( #_g_nViewPortXSprites ), hl

;game.c:1120: g_nViewPortYSprites = g_nViewPortY+SPRITE_HEIGHT;

	; 108 cycles
	; ld	hl, #_g_nViewPortYSprites
	; ld	iy, #_g_nViewPortY
	; ld	a, 0 (iy)
	; add	a, #0x10
	; ld	(hl), a
	; ld	a, 1 (iy)
	; adc	a, #0x00
	; inc	hl
	; ld	(hl), a

	; 47 cycles - cheating a bit here, I know that SPRITE_HEIGHT always ==SPRITE_WIDTH,
	; so DE remains as is (MDL would have detected this today, I think)
	ld 	hl, ( #_g_nViewPortY )
	add hl, de
	ld  ( #_g_nViewPortYSprites ), hl

In many cases, SDCC always uses hl, bc, de first. It's just that it seems like there's no threshold using iy after those others have been in use. Just as iy is equivalent to the others. It's isn't of course. Index-registers shine in some areas, but not in all.

At some point, this all points to sdcc code generation, and should ideally be addressed there I think. But if some pattern can be deduced from this, and which could be useful in general in MDL, it might be something to pursue. That said, how often is this kind of pattern seen in other asm-files? What is the cost/benefit solving this?

Could be that I should drop a line in the SDCC-forums and ask for thoughts on the current sdcc-code-gen. Just speculating, but I would assume that performance isn't their first priority. I'm guessing that correctness, compatibility and compliance to the standard are first priorities, and that we are years away from getting an even more "delicate" index-register-treatment.

I recall this post from... *shiver* 36 pages ago.

;app.c:12: while(1) {
00102$:
;app.c:13: p->x += p->dx;
	push	bc
	pop	iy
	inc	iy
	inc	iy
	ld	e, 0 (iy)
	ld	d, 1 (iy)
	ld	l, c
	ld	h, b
	ld	a, (hl)
	inc	hl
	ld	h, (hl)
	ld	l, a
	add	hl, de
	ld	0 (iy), l
	ld	1 (iy), h
	jr	00102$
;app.c:15: }
--
199 cycles

Artrag posted a very optimized version of this specific code, but a more general approach would be to perform the 16-bit additions in 8-bit sections (add + adc). Can't post the optimized example right now, because I'm in a hurry, but hopefully you know what I mean.

It would be important to check the latest version of the compiler, to avoid doing work that will no longer be necessary.

Cool!

The c-example is a bit special in that it is an endless loop. If I read this right, ARTRAG’s version runs well in one run/loop. But it trashes bc, so next run/loop won’t be correct. Unless I’m missing something of course

Sweeet! I get this now:

INFO: Pattern-based optimization in Debug\objs\game.asm#16285: Replace ld iy,_g_uPowerup; ld (iy+0),0x08 with ld hl,_g_uPowerup+0; ld (hl),0x08 (3 bytes, 15 t-states saved)

I'll move the hand fixed asm code back to C again (from my examples), to test if MDL catches them too.

Great work!

What does this mean exactly? Variables? You mean 16-bit/8bit, signed/unsigned, bool, etc?

Another thing, I have found that there is a detection like this:

INFO: Pattern-based optimization in Debug\objs\game.asm#3859: Remove unused ld d,a (1 bytes, 5 t-states saved)

(I placed it there for test)

I also placed this: "ld a,h", which in a way, also was unused. The thing here was probably that there was a command later "cp a". But cp a does not "work on A", only on F Clear C-flag and sets Z-flag (and maybe more?). So I guess ideally, that line should have been removed too.

(BTW: These two unused values/commands were present in code from SDCC 4.0. Not sure about 4.1)