Apple-2-SW/apple2_hgr_font_tutorial
1
0
Fork 0
mirror of https://github.com/Michaelangel007/apple2_hgr_font_tutorial.git synced 2024-06-16 20:29:31 +00:00
Code Issues Projects Releases Wiki Activity

Cleanup carry flag notes

Browse Source
This commit is contained in:
michaelangel007 2016-01-11 11:06:44 -08:00
parent bc6450a94f
commit f12f1b4b13
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
README.md
View File

@ -1,6 +1,6 @@
#Apple ]\[ HGR Font Tutorial
Revision: 21, Jan 11, 2016.
Revision: 22, Jan 11, 2016.
# Table of Contents
@ -741,13 +741,16 @@ Enter in:
### Introduction to Optimization
One tip for beginner 6502 assembly programmers. It is tempting just to always clear the carry before do any addition or subtraction. Unfortunately, for subtraction we'll have an off-by-one bug so we need to subtract 1 less then the value. This makes reading the code a little unintuitive. The `Rule of Thumb` is to change the carry before we do the operation depending on whether we are `adding` or `subtracting`:
One tip for beginner 6502 assembly programmers. It is tempting just to always clear the carry flag `CLC` before doing any addition or subtraction. Unfortunately, for subtraction we'll have an off-by-one bug (fencepost error) so we need to subtract _ONE less then the value._ This makes reading the code a little unintuitive. Is there a way to remedy this? Yes.
| Op | Carry | Opcode |
|----|:-----:|:------:|
| + | Clear | CLC |
| - | Set | SEC |
We change the carry flag state _before_ we do the operation depending on whether we are `adding` or `subtracting`.
The `Rule of Thumb` is `CLC before ADD` and `SEC before SUB`. A mnemonic to help you remember is that both `SEC` and `SUB` start with `S`.
```assembly
; FUNC: IncCursorCol()
; OUTPUT: Y-Register (column) is incremented
@ -825,7 +828,7 @@ Nope. Bummer. :-(
The lessons?
* Verify our assumptions and Profile!
* Even though we "failed" _this_ time, we shouldn't be afraid to experiment with "out-the-box" thinking using the 6502 instructions; sometimes there are clear "wins". It isn't always exactly clear if we should optimize to minimize space (with the potential to run slower) or to optimize for higher performance (at the cost of more code.)
* Even though we "failed" _this_ time, we shouldn't be afraid to experiment with "out-the-box" thinking using the 6502 instructions; sometimes there are clear "wins" but you won't know unless you try! Also, it isn't always obvious if we should optimize to minimize space (with the potential to run slower) or to optimize for higher performance (at the cost of more code.) The "proper" solutiond depends on the context of your needs. With 8-bit CPU's we tend to focus on `code density` -- cram as much code in as little space as possible. Graphics / Rendering unfortunately "needs" to run as fast as possible so this means unrolling loops, etc., to run "flat out" even though we lose valuable memory.
We'll briefly touch upon this topic of optimization again with `bit-shifts` and `memcpy()`.