WP-34s negative shifts

[Andrew Nikitin]

Currently when r00=-3, SDL[->] 00 multiplies rX by 1000, I think it should
handle this case and divide it by thousand. As in "negative shift left is shift
right". Same for SDR.

I would also argue that ASR,SL,SR,RL,RLC,RR,RRC should handle negative numbers
whenever selected sub-mode implements negative numbers.

[Paul Dale]

The way arguments to commands are implemented mean positive (or zero) values only.

It would be possible to change this of course but I'm not going to do it. The source is available and open and we accept patches....

- Pauli

[Andrew Nikitin]

Yes, that could actually be a reasonable training change to make myself.
However, I am not at the stage where I can make patches yet. I checked out the source with svn and tried to look at it and it is pretty overwhelming.

I understand, everything in root of wp34s folder and in atmel subfolder and in decNumber subfolder goes into the calculator. The rest is different platform emulator code, right?

[Marcus von Cube, Germany]

The definitive source for knowing what goes into the calculator is the Makefile.

The argument handling is a bit limited in the sense that the commands accepting arguments have no knowledge of the source of the argument. It's just an 8 bit number. Indirect arguments may use the full 8 bits while direct arguments are limited to 7 bits. The limit checking is done before the command is called and the sign of the register contents is lost. It would be tricky to allow arguments between -10 and 10 this way because the range is not contiguous if interpreted as unsigned values.

[Andrew Nikitin]

Interesting. I just checked that
SDR ->00 works for r00=255, but fails with an error with r00=256. So it is 8 bits in a sense.

I am trying to figure out what is doing the preprocessing. I traced it to CMD macro which seems to be defined differently depending on who knows what. It looks like this specific op_shift_digit goes into argcmds_ct which is packed into command_info at which point I am lost, it is not apparent who is accessing the command_info. Do you have any words of wisdom for me?

[Marcus von Cube, Germany]

A warning: Don't mess with the command tables unless you really, really know how the whole build process works! We added some very tricky space saving logic (a post processing step on the compiled file) which can easily be messed up. The C preprocessor creates environment dependent versions of these tables (real build, emulator) because the latter does not use the space saving tricks.

The logic you want to interface to is all in xeq.c in the routine rargs().