Hi,

I need to add a signed 8 bit number (in zero page location TEMP1) to a stored 16 bit number (in zero page locations LVALL,H). Below is my current method. I was wondering if anyone had any suggestions or improvements.

Thanks,

Ken

This should work ..


Lee.

Nice - thanks. Not only short and clear, but also avoids using X, so you've saved me quite a few bytes there.

Ken

I would say that the task simply is not appropriately formulated in the first place!

If the two byte value should be the sum of many one byte "signed" values you should consider it as a signed value too. If you for some reason know from the start that the sum is positive you kind of miss the most significant bit, i.e. you only have 15 bits fo the end sum. But what do you otherwise do if some "partial sum" should be negative? With absolutely standard signed arithmetic you then have

If now the final sum in LVALL,LVALH stays positive at all times, fine! If not, also fine!

This is the straight-forward approach in the spirit of the chip design! Rock solid! No "tricks" needed!

Strange; I understood the problem as written perfectly.



The poster of the question is adding a signed 8-bit value to a signed 16-bit quantity. This mandates that the 8-bit value be sign-extended first. The code above works if and only if the signed value is guaranteed to be positive at all times.

I'm not a fan of unnecessary tricks except where performance counts (see my thread on arithmetic shifts). I would start off by writing this instead:



That would be my initial solution. It takes more memory, and MAY even take more time to execute, but it'll work. Then, from there, I'd optimize as required.

update -- I did a preliminary timing analysis of my code versus lee's with the assumption that everything is stored in zero-page, and it looks like mine is only 3 cycles slower than his in the case of a negative number. Not bad at all, I'd say.

You are perfectly right. But "basically" I think I was right that the straightforward way to do this absolutely standard task is to

Step 1:

Extend the signed one byte variable to a build a signed 2 byte variable by "prolonging" the sign bit, i.e. (for example)

80 => FF80
7F => 007F

Then do 2 byte signed arithmetic!

This is exactly what you (correctly) did! I wrote my thing a bit to quickly! Sorry for that!

This could also be seen as 8 "ASR" (division by 256) of 8000 and 7F00 , respectively, where "ASR" would be the non-existing operation "Arithmetic Shift Right" copying the value of the sign bit to the second most significant bit, i.e division with 2

Yes -- provided performance or tight memory size isn't an issue. Lee's approach is 'straight forward' in the sense that it exploits the logic of 2's compliment math, but it does require a bit of algebra to see how it works.

The "trick" is that, should you have a negative number N, you can break it up such that N = $FF00 + N', where N' is between $80 and $FF inclusive.

Thus, LVAL + $FF00 + N' is what's being computed, and since addition is commutative, and since $FF is -1, and therefore $FF00 is -256, the initial DEC instruction on the high byte is precisely correct to compute (LVAL+$FF00) + N'. The middle code computes the final sum, with the BCS/INC easily handling any carry that may need to be propegated.



Not a problem; without a clearly written message it was kind of hard to get, but everyone does it. I do too.