Assembler Optimizer

Page 47/58
40 | 41 | 42 | 43 | 44 | 45 | 46 | | 48 | 49 | 50 | 51 | 52

Par thegeps

Paragon (1251)

Portrait de thegeps

27-05-2021, 23:48

Actually I use TED (Text EDitor), so I'll redirect output to a file ????
And I'll try new version as soon as it will be available ????

Par santiontanon

Paragon (1831)

Portrait de santiontanon

28-05-2021, 00:41

Ok! Let me know if that works. Apologies if this is inconvenient to run in Windows, I haven't seen a Windows machine for so long that sometimes I forget they even exist! hahaha sorry about that! But any suggestion to make it more convenient in Windows is appreciated! Smile

Par thegeps

Paragon (1251)

Portrait de thegeps

28-05-2021, 02:14

thegeps wrote:

Actually I use TED (Text EDitor), so I'll redirect output to a file ????
And I'll try new version as soon as it will be available ????

Oh, I'm sorry about those "????" that give to the message an urgency and/or a disappointment that there really isn't...
I'm writing from the smartphone and it automatically issued an emoticon instead of "Wink" and those emoticons weren't recognized by the forum engine, I suppose...

Par santiontanon

Paragon (1831)

Portrait de santiontanon

28-05-2021, 03:05

haha, no problem! I hope it worked Smile

Par thegeps

Paragon (1251)

Portrait de thegeps

28-05-2021, 17:41

I'm trying it right now. I'm curious about this (I don't get how it works):

INFO: Pattern-based optimization in ffplet.asm#263: Replace ld hl,304 with ld l,(304) & #00ff (1 bytes, 3 t-states saved)

can you explain it to me? seems to be a smart trick

Par ToriHino

Paladin (925)

Portrait de ToriHino

28-05-2021, 17:54

It looks like it sees that the h register already contains 0x01, so only l needs an update ?

Par santiontanon

Paragon (1831)

Portrait de santiontanon

28-05-2021, 18:05

Exactly! This optimization can only happen in two different situations:
1) MDL has determined that H already contains 0x01, as ToriHino says
2) or, MDL has determined that the value of H will never be used later on, and hence only L needs to be set.

Par thegeps

Paragon (1251)

Portrait de thegeps

28-05-2021, 18:15

so this is another similar case, right?

INFO: Pattern-based optimization in ffplet.asm#1265: Replace ld hl,-128 with ld h,(-128) >> 8 (1 bytes, 3 t-states saved)

Par thegeps

Paragon (1251)

Portrait de thegeps

28-05-2021, 18:28

I'm applying manually all the optimizations, discarding those not necessary...

For example, in non-critical parts of code I replaced (time ago) all the direct JP with JR, to save some bytes. So I'm not applying the opposite replacement (I don't need speed, in title screen).

I have not reached critical zone, yet. But I haven't encountered optimizations in all the need-for-speed parts till now

Par thegeps

Paragon (1251)

Portrait de thegeps

28-05-2021, 19:33

wow, found an optimization that MDL hasn't found (same kind of one it spotted)

I have two labels that have same Hi byte

ramspttbl:		equ	0e700h		;this is the SAT in RAM
respawn_time:		equ	0e78eh

they are both used inside the ISR in my "putsprite" routine. to move inside the SAT normally I do:

ld hl,ramspttbl

and point to desired byte using l

ld l,0-127

now I have this piece of code:

update_respawn_y:
	ld	l,0
	ld	a,(hl)			;and add -2 to ypos until it reaches 130
	add	a,-3		
	cp	130
	jp	nz,continue_respawn	;if y>130 continue respawn
	ld	a,2
	ld	(dead_flag),a
respawn_y_updated:
;	ld	hl,respawn_time
	ld	l,8eh                   ; <--- inspired by MDL
	dec	(hl)
	jp	nz,still_invisible
Page 47/58
40 | 41 | 42 | 43 | 44 | 45 | 46 | | 48 | 49 | 50 | 51 | 52