RR and RRN (also RL and RLN) discrepancy?

[Chris Jensen]

Hello,

I was playing around with some of the BASE functions added to Free42 & Plus42 and noticed behavior that doesn't seem to fit the documentation / expectations.

To start, my environment is set to WSIZE of 32 and BSIGNED is set.

If I change to HEXM and enter 12345678. I can RR 32 times (or RL 32 times) and I end up with 12345678 as expected.

I noticed that I get different behavior with RRN and the easiest way to see this is to simply use RRN with an N value of 1, which should be analogous to a single RR. However, it appears that if bit 31 is set, then the value shifted in from the left will always be set as well.

If I clear BSIGNED, then RRN with 1 for N behaves like RR (note: RR behaves the same regardless of the BSIGNED state).

I would expect RRN to also ignore the BSIGNED state.

Also, (with BSIGNED set) using RLN, if bit 31 is set and I perform an RLN with 1 for N, I get FFFFFFFF for the resulting value. So, for a value of 80000000, performing an RLN with 1 for N produces FFFFFFFF. With RL it rotates correctly, so, 80000000 becomes 00000001.

Thoughts?

Thanks.

[Thomas Okken]

Yes, you're right, the BSIGNED case is handled incorrectly by RLN and RRN.

Thank you for the bug report! I'm looking into it; I'll try to post a fix tomorrow.

[Thomas Okken]

I fixed the issue. I uploaded new releases, Free42 3.3.12 and Plus42 1.3.15; they are on my web site now.

The new Android and iOS versions should appear in their respective app stores today or tomorrow.

[Chris Jensen]

Wow, that was fast. Thank you Thomas!