I'm working on some software (R&D for the Kestrel, basically), and realized a serious shortcoming of the 65xx instruction set -- no arithmetic shifts.

Yeah, you have the "arithmetic" shift left instruction, but let's face it, there is no difference between an arithmetic and logical shift left. The only time "arithmetic" vs. "logical" comes into play is when shifting to the right.

The difference is as follows: arithmetic shifts preserve the sign bit (so that -4/2 = -2, etc), while logical shifts don't.

Right now, the best code my brain can come up with to implement an arithmetic shift is as follows:



Does anyone have anything better? Any tricks for handling multi-bit arithmetic shifts?

Thanks.

6502 Forth does it this way for a two-byte cell on the ZP data stack:

Arithmetic shift right:

HEY, that's pretty slick! I don't know why I didn't think of that. Let me see if I have the theory of operation right.

CMP #$80 will compute A-$80. If A>=$80, carry flag will be set. Otherwise, it'll be clear. Basically, normal rules for SEC;SBC. I like it!

Garth, you may want to update your Forth implementation. It looks like this approach will be much faster -- at least for single bit shifts, and especially for the 65816.

> Garth, you may want to update your Forth implementation. It
> looks like this approach will be much faster -- at least for single
> bit shifts, and especially for the 65816.

I like it too, and I'm sure I'll find uses for it when the number is in A to start with. Thankyou Thowllly.

Its benefit is does not extend to the case where the number was not in A however. Re-writing the 2/ primitive this way, it becomes:

which takes the same number of clocks but one more byte. For the '816, you get:

which takes one more clock and two more bytes than

If you cache the top of stack in A itself, you eliminate most of the above overhead.

> If you cache the top of stack in A itself, you eliminate most of
> the above overhead.

I might try that someday, but I guess it will require STC. In IDC, NEXT needs A.

That is true. However, if A is already in use for something else, you can use LDY/CPY instead of saving/restoring Aand then it's a win in both size and speed. But I guess that scenario won't come up very often.

Possibly..

In this case the V flag is valid as it should be for a proper arithmetic shift.

Lee.

Except you're shifting in the wrong direction. Remember, arithmetic shifts don't necessarily touch the V flag as such -- their defining element is the preservation of the *sign* of the number. I AND #$40 only to get the status of bit 6, which *used* to be bit 7, so that I can copy its value and put it back into bit 7.

Solutions to the right shift problem had been provided but no one had bothered with the left shift case. Just thought you'd like both.

Lee.

Just change the #$F8 depending on how many bits you shifted.

Lee.

Ahh, that wasn't made clear, so I was thinking of the arithmetic shift right case. Sorry.

It's a little bit off-topic, but I guess I'll finally say it anyway. Any Forth primitive can use A any way you want and with no obligation to save it (like by using the TAY...TYA above), but the primitive's final value in A will get overwritten by NEXT before the next primitive in indirect-threaded Forth (ITC). For this reason, the top data stack cell cannot be kept in A as kc5tja was saying, since it would be lost between primitives. NEXT could be made to save it, but that would slow things down even more since NEXT gets used over 12,000 times per second per MHz on a 6502. Going to subroutine-threaded code (STC) Forth would eliminate NEXT, and then A would be untouched between primitives since the maximum overhead between them is RTS, JSR (to end one primitive and call the next one). Then, with the 65816, the 16-bit top data stack cell could just be kept in A with no worries of it getting stepped on between primitives.