Difference between revisions of "Z80 Good Programming Practices"
(improved) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | |||
| + | = Programming Techniques = | ||
| + | |||
== Lookup table == | == Lookup table == | ||
| Line 146: | Line 149: | ||
</table> | </table> | ||
| − | = | + | = Source Code = |
| − | + | Some advices to take into consideration: | |
| + | * split into various files in a logical way (header, main, subroutines, data) when it turns many pages long. | ||
| + | * document every routine with input, output, destroyed registers and a short description when appropriate. | ||
| + | * document well ugly and difficult parts of code | ||
| − | + | = Related topics = | |
| + | * [http://www.unitedti.org/forum/index.php?showtopic=8461 Common Mistakes and Good techniques] | ||
Latest revision as of 11:53, 17 November 2010
Programming Techniques
Lookup table
If you have a place in your code where a value is tested to choose between a lot of things, like subroutines or data, it can be a good idea to use lookup tables instead of a series of tests. It makes the code more readable, concise and extensible.
In terms optimisation though it should be used when the data is not sequentially ordered or when the objects being pointed to are not the same size. For example, using LUTs (Look Up Tables) to find a tile in a block of memory that is only tiles would both slower and cost more memory. Using LUTs to find a particular string would be quicker but would waste more memory than a linear search. Using LUTs as a jump table to different code blocks located through out a program would be faster and smaller compared to the alternative.
However, if there aren't many jumps and many of the values of a are sequential, it would be more efficient to do something like:
ld a,(Number) or a jp z,A_is_0 dec a jp z,A_is_1 dec a jp z,A_is_2 sub 2 jp z,A_is_4 dec a jp z,A_is_5
Examples:
| Without | With |
|---|---|
ld a,(SpriteNumber) cp 0 jp z,ChooseSprite0 cp 1 jp z,ChooseSprite1 cp 2 jp z,ChooseSprite2 cp 3 jp z,ChooseSprite3 cp 4 jp z,ChooseSprite4 cp 5 jp z,ChooseSprite5 ... ChooseSprite0 ld hl,Sprite0 jp DisplaySprite ChooseSprite1 ld hl,Sprite1 jp DisplaySprite ChooseSprite2 ld hl,Sprite2 jp DisplaySprite ChooseSprite3 ld hl,Sprite3 jp DisplaySprite ChooseSprite4 ld hl,Sprite4 jp DisplaySprite ChooseSprite5 ld hl,Sprite5 jp DisplaySprite ... DisplaySprite ld bc,(coordinates) call SpriteRoutine |
ld a,(SpriteNumber) add a,a ; a*2 (limits SpriteNumber to 128) ld h,0 ld l,a ld de,SpriteAddressLUT add hl,de ld a,(hl) inc hl ld h,(hl) ld l,a ld bc,(coordinates) jp SpriteRoutine ... SpriteAddressLUT .dw Sprite0 .dw Sprite1 .dw Sprite2 .dw Sprite3 .dw Sprite4 .dw Sprite5 |
And this one :
| Without | With |
|---|---|
ld a,(MenuChoice) cp 0 jp z,Choice0 cp 1 jp z,Choice1 cp 2 jp z,Choice2 cp 3 jp z,Choice3 cp 4 jp z,Choice4 cp 5 jp z,Choice5 cp 6 jp z,Choice6 cp 7 jp z,Choice7 ... |
ld a,(MenuChoice) add a,a ; a*2 ld h,0 ld l,a ld de,CodeBranchLUT add hl,de ld a,(hl) inc hl ld h,(hl) ld l,a jp (hl) ... CodeBranchLUT: .dw Choice0 .dw Choice1 .dw Choice2 .dw Choice3 .dw Choice4 .dw Choice5 .dw Choice6 .dw Choice7 |
Source Code
Some advices to take into consideration:
- split into various files in a logical way (header, main, subroutines, data) when it turns many pages long.
- document every routine with input, output, destroyed registers and a short description when appropriate.
- document well ugly and difficult parts of code
