I found here, like to share it with you... Hope you find it useful.

While programming my (warning: teaser....) USB stack (end teaser) I needed to substract AC from a value in a memory location, of course with as little code as possible.

The code transfers a data packet in. The memory location contains the number of bytes that were scheduled to be received, while AC is the number of bytes still to transfer after the transfer (that value is what the SL811H gives you after the transfer).

I need to compute the number of bytes transferred. That would be

which of course is difficult with the 6502 if you cannot or don't want to store AC into some immediate memory location. But you can do this:

which can be done as

The CLC might be left out if you know your value range.
But you can do it much shorter, which is the trick I found:

This folds the ADC #1 into the SBC by using CLC instead of SEC, i.e. it substracts one more than mem contains, which is the same as adding one after the one's complement (EOR #$FF)

Hope you like it
André

-AC+mem

Yes, that's what I thought of after posting here :-)

Incidently, IIRC, that is how the 6502 internally implements SBC, by inverting (EOR #$FF) the operand (mem, not AC as in the example here) and using the carry flag as a borrow (that is why SBC requires SEC and not CLC like ADC)

André

Am I right in thinking that both code sequences are correct, and take the same time, and leave all four flags in the same state?

Yes. As long as you do SEC with ADD or CLC with SBC, either preceeded or followed by the EOR #$FF, you will get the same result.

Lee.

Not having too much time to consider this very carefully, does this also leave the carry flag set up appropriately for a 16-bit subtraction?

e.g. would the following work?



If so, that's a very useful little trick! Thanks for sharing it.

Now I've had a moment to think about it, I think the above code won't work, because the carry flag will always be incorrect for the MSB subtraction. But it should work if you use the EOR/SEC/ADC trick, like this:



So, I don't think the two methods are exactly equivalent. For 8-bit arithmetic though, if you already know the state of the carry flag, it's good to have the option to use either method. For 16-bit arithmetic, I think you have to do it this way.

Just wrote a little test program, and can confirm that this is true.

Of course it makes sense: inverting the input to the add works because it's a simple 8-bit value; inverting the output from the subtract doesn't work, because it's a 9-bit (including the C flag) value.

well put!

Here's another nice arithmetic trick I used recently. It's not especially clever, but I never saw it mentioned anywhere before, so here's as good a place as any.

I needed to divide the accumulator by 64, to yield a value between 0-3.

The obvious way to do this is

which obviously works, but takes 12 cycles.

You could use a 256 byte lookup table, but this is a horrible waste of memory. In the end, I realised the best way was this:

which saves 4 cycles and 1 byte.

Anyone have any more little tricks like this to share which have barely ever been touched upon?

I could mention the quiz from an old Apple Assembly line issue... although it was only a couple of months ago that I posted it.

Hmmmm... tricks? Off the top of my head, here's a little snippet I find very interesting... a modest example, perhaps, but it doesn't take much to amuse some people!

In some programming scenarios it's necessary to take a one-bit value and copy it into all the bits of a register -- in other words, to load the register with a word containing either all 1s or all 0s, based on the 1-bit input value. Although you're essentially creating redundancy, the word-wide all-1s or all-0s format can be handy if you plan to subsequently perform masking operations involving another word-wide value.

Here are some code sequences to accomplish this. The input value is taken from the Carry Flag.

Ho, hum -- boring! But you get the idea.

Huhh?? That can't be right! It looks incomplete! Don't we need an instruction to initialize the A reg first ?!
No, we do not; the strange thing about this code is that it works regardless of what's initially in A.

This is a less provocative alternative. No Z-Pg reference is required, saving 2 cycles.


But, looking back at the wacky approach, we find that "subtracting a value from itself" works really well on the x86 family!
(or other chips featuring register-to-register arithmetic)

With apologies for mentioning that other architecture,

Jeff