Post by: Halifax on March 23, 2007, 10:46:00 am
Optimization 1 - Loading 0 into A
----------------------------------
Unoptimized
c1-->
| CODE |
| ec1 ld a,0 c2 |
ec2
to
c1
-->to
c1
| CODE |
| ec1 xor a or sub a,a c2 |
ec2
ld a,0 is unoptimized because it takes more bytes and tstates than both "xor a" and "sub a,a". They both do the same as ld a,0
------------------------------------
Optimization 2 - Comparing the value 0
------------------------------------
Unoptimized
c1
-->ld a,0 is unoptimized because it takes more bytes and tstates than both "xor a" and "sub a,a". They both do the same as ld a,0
------------------------------------
Optimization 2 - Comparing the value 0
------------------------------------
Unoptimized
c1
| CODE |
| ec1 cp 0 c2 |
ec2
to
c1
-->to
c1
| CODE |
| ec1 or a c2 |
ec2
same with above. "or a" takes less space and tstates than "cp 0" and does the same thing.
-------------------------------------
Optimization 3 - Loading numbers into register pairs
-------------------------------------
Unoptimized
c1
-->same with above. "or a" takes less space and tstates than "cp 0" and does the same thing.
-------------------------------------
Optimization 3 - Loading numbers into register pairs
-------------------------------------
Unoptimized
c1
| CODE |
| ec1 ld b,$88 ld c,$45 c2 |
ec2
to
c1
-->to
c1
| CODE |
| ec1 ld bc,$8845 c2 |
ec2
the first one takes 14 tstates while "ld bc,$8845" only takes 10 tstates. It is self-explanatory that what goes in B comes first and C comes after.
---------------------------------------
Optimization 4 - Loading a Pic onto the screen (SPEED OPTIMIZATION)
---------------------------------------
Unoptimized
c1
-->the first one takes 14 tstates while "ld bc,$8845" only takes 10 tstates. It is self-explanatory that what goes in B comes first and C comes after.
---------------------------------------
Optimization 4 - Loading a Pic onto the screen (SPEED OPTIMIZATION)
---------------------------------------
Unoptimized
c1
| CODE |
| ec1 ld hl,gbuf ld de,pic ld bc,768 ldir c2 |
ec2
to
c1
-->to
c1
| CODE | ||||||||||||||||||||||||||||||||
| ec1 ld hl,gbuf ld de,pic ld bc,768 copyfast: Post by: Fallen Ghost on March 24, 2007, 06:13:00 am Why should interrupts be enabled? If an interrupt triggers, it will return correctly (lets suppose) and let the stack at the same value, therefore not modifying the bytes you are going to have when you push, so the result is the same. But as we know, interrupts can trigger anytime. If it happens that the interrupt is triggered when b=1 and there is only a couple pushes to do, then if in the interrupt routine, there are more pushes than the number remaining in your routine, then whatever data was before the buffer will be erased/modified, so it is no a good idea, therefore interrupts disabled. Post by: Halifax on March 24, 2007, 11:22:00 am
Post by: calc84maniac on March 25, 2007, 08:48:00 am Post by: Jon on March 25, 2007, 04:44:00 pm Instead of: c1-->
ec2 -->Use: c1
ec2
LD A,(DE) creates the same delay as 2 NOP's, but it takes 1 byte instead of 2 Post by: Halifax on March 26, 2007, 09:44:00 am EDIT: I just gained (with this post here) post number 666! Post by: Iambian on April 10, 2007, 10:16:00 am If you make an unconditional CALL prior to a RET, you can replace that CALL with a JP instruction (since you're then going to be using that calling routine's RET). This won't work if the calling routine doesn't exit out using a RET, but that's up to you to decide. But if it works, that's one byte saved by not having to use a RET. If the calling routine is local enough, you can save another byte by using the JR instruction instead. i.e. c1-->
ec2 -->can be condensed to this: c1
ec2
If you can rearrange the code to make "SomeRoutine" appear right after the calling routine, you can save two more bytes by omitting JR altogether. In this respect, it may do you some good to rearrange your ASM code to take advantage of this kind of optimization. Of course, you're going to have to be wary about errors resulting in the use of JR. Oh, and as a response to the previous post that made a size optimization using a "LD A,(DE)", it's not exactly the same as using two NOPs. The "LD A,(DE)" is faster by one clockcycle. I understand that this is negligible, but I just wanted to point that out. Post by: Jon on April 12, 2007, 11:56:00 am  7<8 heh
Post by: Iambian on April 16, 2007, 09:21:00 am Instead of, say, "CALL C,0038h" or "JP C,0038h", you could do "JR C,$FF". Conditions will vary, all of which will do the same thing. This works because the "$FF" is an offset to make a relative jump one byte behind the already-executed instruction ( JR C,$+1). The part of the argument for JR, "$FF", is the opcode for RST 38h. In that sense, you're combining two instructions in one. For what you'd use this for, I'd have no idea. Perhaps someone that wanted to call the interrupt service routine while the interrupts were off? Perhaps it might be a way to keep romcalls like _getCSC and _getKey working while the interrupts are gone. Post by: Jon on April 16, 2007, 04:09:00 pm Although, wouldn't the command be jr c,$-1 ? I believe tasm will interpret jr c,$ff to mean jr c,$00ff, and hence give you a range of relative branch error. Post by: Iambian on April 17, 2007, 04:28:00 am In TASM, JR (condition),$+2 gives you the instruction after it, and JR (condition),$-1 gives you the instruction behind it. To make it continuously loop on itself (jump back to the beginning of the instruction), you'd do JR (condition),$+0, so it's natural to then believe that JR (condition),$+1 would give you one byte within the instruction. Also, no errors will happen since TASM already recognizes the instruction to take a single byte argument. Believe me; I've tried a similar stunt before (though not as memory-efficient), especially if you read up on my unreadable Z80 source :) Also, to keep on topic: For a speed optimization when working with a list of two-byte values, you can abuse the stack to quickly address these values. That is, set SP to the start of the list. Then you can repeatedly POP values off the table. The values are not destroyed, but only read. If you need to edit a value, say, for updating, you can just PUSH the value back in and use some instructions like INC SP (twice) to move the pointer back to where you were (although just POP-ing the value will save two clockcycles as opposed to using INC SP twice, except if you're trying to POP to an index register). Accessing values in this fashion will save you many clockcycles, especially compared to the standard "LD E,(HL) \ INC HL \ LD D,(HL) \ INC HL" sequence that eats up a hefty 26 clockcycles. Simply POP-ing the value will use up only ten clockcycles. This is especially useful for bubble-sorting or perhaps grabbing the largest and smallest value on the table. Remember to disable interrupts and to save SP prior to editing SP to read the table. ------------------ Another optimization trick is first of all, when you want to, say, stop the program to output an error message, you could, instead of loading in HL the address of the string, do the following instead: c1-->
ec2
That works because when the CALL is made, the address in the stack will point to the string thereafter, since it would've been the next address to execute from then. The ErrorCode will have a jump to a place that will restore SP prior to exiting, so this will only work if you have code to restore the stack or something. If all your error messages are of a fixed size, you could save more space by cutting out that null-terminator and editing your text output routine to cope with a fixed-size. For further optimization (in case you don't want to have code to jump over all that CALL and text), all ASCII alphabet characters are within the code block for loads. If you do not have any special characters, spaces, or numbers, you could actually have the call a conditional one and have your little Z80 run the text as if it was code. This is a dangerous practice, especially if you were going to change your text, but in this case, you'd be looking at an opcode table to determine which registers get destroyed in the various loads. The reason why I say that you cannot use the space character is because its opcode refers to a JR instruction. If you were especially savvy about the placement of your code, you could use this feature to your advantage. Take care with the use of that optimization. It certainly isn't a speed optimization, but it most certainly is a size optimization, especially if you're CALLing on a condition that JR doesn't take (like M or P, for instance). Post by: Fallen Ghost on April 24, 2007, 02:29:00 pm instead of doing this (22T states, 3 bytes)c1-->
ec2 -->One could do (19/20T states, 4 bytes)c1
|
