I've ended up here while googling stuff related to BCD code on the 6502. I've seen a number of bits of code here for efficient processing of BCD, and that made me dream up a concept related to BCD floating point.

I'm trying to improve the loop performance of the infamously slow Atari BASIC, which used BCD FP math with leading excess-64 exponent and then 5 bytes of mantissa. Details here for the interested, page 8-45: https://archive.org/details/ataribooks-de-re-atari

My question:

Atari's OS has a FADD routine that adds two arbitrary FP numbers. In FOR/NEXT loops this is a significant performance hit. I am wondering if this might be improved by having a floating-point increment, FINC, for the 95% of loops that are step 1.

My thought was this: the general purpose FADD knows about things like non-64 exponents and carrying across digits and so forth. But if you're doing an increment you mostly don't need this - if the number has no decimal shift and the least significant byte is < 99 there isn't going to be a carry, so we can just add one to the LSB and exit? If it is 99, then just call FADD.

Is that right? Or am I (likely) missing something obvious here?

Sounds about right to me - if you can fast-path the common case, it's a win. We discussed elsewhere optimisation of the integer vs float case - this is the case of STEP 1 and it sounds like a good candidate.

Are you looking to speed up the FOR/NEXT loop in general or just speeding up the FADD routine in cases where the increment is only 1?

We can open a discussion up here on ways to replace the FOR/NEXT loop that offers way greater speed and uses less stack space. As far as diversity goes, any one can be the judge.

On incrementing the least-significant-digit:
I'm not intimately familiar with FADD, but here goes...

The least-significant-digit is probably not the 1's value digit; it depends on the exponent.
Incrementing LSD on 30 may give 30.0000001
Incrementing LSD on 3 may give 3.00000001
Incrementing LSD on 300000000 may give 300000001

Maybe something like:
Check sure the increment value is 1. If not, do FADD
Check the index exponent to determine the digit position to increment. if out of range, do FADD.
Check that it won't cause carrys we can't handle. If so, do FADD.
It'll work! do the increment & return.