[Coco] Mod10 Suggestions

[Brett Gordon]

Hmm...  can't this mod10 be done in 16 bit chunks?  You're doing one thing
with odds and another with evens... so do the same with A(even) and B(odd)?
Then you dont have to deside each time through the loop.

   Ldy #num     y points to beg of number
   Ldx #0           x is an 16 bit accumulator
loop:
   ldd ,y++      get next word
   lslb             shift odd byte
   abx            accum the odd byte
   tfr a,b            no aax ;(
  abx            accum even byte
   cmpy #num+16
   bne loop
* find mod
   tfr x,d        full bit tests only in D :(
again
   subd #10   subtract 10 until we go neg
   bpl again
   addd #10  went too far! Add back last 10
* result in D (0= good cksum)

I have no idea if any of the above code is correct to the algorithm... but
the idea may need (mathematical) double checking.  It smells of a one's
compliment sum.  one loop to add it all, and one to divide by 10.  Your
finding the mod after each byte, where you *might* be able to check easier
(and less times) for negative...maybe. (dubious)

brett
On Feb 17, 2017 6:34 PM, "William Mikrut" <wmikrut72 at gmail.com> wrote:

> The code has been reduced to 63 bytes... 45 actually if I don't count the
> variable space.
>
> 45 Program Bytes.... and a whole mod10 is performed.
> That's absolutely insane.
>
> The program to handle this in RPG is over 50 lines of code... most
> certainly way, way more than 45 bytes.
>
>
>
> On Fri, Feb 17, 2017 at 5:12 PM, William Mikrut <wmikrut72 at gmail.com>
> wrote:
>
> > I see the math there... I am processing 16 numbers -- and I keep thinking
> > 16.
> > However, the actual memory range populated is 1200 - 120F
> >
> > Let me give it a try!
> >
> >
> > On Fri, Feb 17, 2017 at 5:04 PM, William Astle <lost at l-w.ca> wrote:
> >
> >> On 2017-02-17 03:50 PM, William Mikrut wrote:
> >>
> >>> The reason being I am actually reading the number from right to left.
> >>> So I need that A,x   (16,X) then (15,X) and so on offset to process the
> >>> numbers.
> >>>
> >>> I don't know of another way to maintain that index while counting down.
> >>>
> >>
> >> Actually, I did make an error in my description. It should be BPL to
> >> branch when not negative so it keeps looping until DECA results in 255
> (or
> >> -1). That's what I get for being distracted when I wrote the message.
> >>
> >> However, if you do exactly what I wrote (modulo the BMI/BPL error), you
> >> will have *exactly* the same result. That's because you're doing the
> DECA
> >> at the start of the loop so it doesn't change the conditions inside the
> >> loop if you start with A at 15 and do the decrementing at the end of the
> >> loop or start with A at 16 and do the decrementing at the start of the
> >> loop. Either way, A is still in the range of 0...15 during the loop.
> >>
> >> Basically, you have "LDA #15" at the start. Remove the DECA at
> "LOOP.00".
> >> Replace CMPA #0 (or TSTA) with "DECA" and change the "BNE LOOP.00" to
> "BPL
> >> LOOP.00". Unless I'm miscalculating that will save you one additional
> byte.
> >>
> >>
> >> --
> >> Coco mailing list
> >> Coco at maltedmedia.com
> >> https://pairlist5.pair.net/mailman/listinfo/coco
> >>
> >
> >
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
>