[16C] why are some commands entered before their arguments?

[cdmackay]

I keep getting tripped up on my DM16, when using FLOAT, WINDOW & CF, since they seem unique in that their arguments are entered directly after pressing the command key.

Whereas the related WSIZE, and of course most other commands, for example, takes its argument from the stack.

Is there any logical, or historical reason for this?

I can understand programming-only commands, e.g. LBL & GTO/GSB taking a suffix directly, rather than reading its arg from the stack, but for commands that are also used manually, like the three I mention in the first paragraph, it just seems confusing (to me).

Hmm, I suppose I need to include STO/RCL, too.

It would also seem to bar them from using calculated arguments, too (except for STO/RCL which can use indexed registers), which might have been useful for some of them?

[Carsen]

Say you had SQRT(2) in the X register and you currently have the display at FLOAT 2. But you want to see the SQRT(2) with FLOAT 4. All that has to be done is f FLOAT 4 & then the display shows the 1.4142.

If a 4 was put in the X register before FLOAT is executed, then the stack would lose a number in the T register & an extra keystroke would have to be used to display that 1.4142 (because a 4 would be in the X register).

It is much more convenient & logical to not disturb the stack simply to change a setting of the calculator.

RCL, STO, CF, FLOAT, & WINDOW are all prefix keys, which is why they need additional keystrokes before being executed. Read Ch. 1 in the owner's manual to learn about prefix keys and see Appendix B for a list of prefix keys. Get the owner's manual on the SwissMicros site or from the MOHPC jump drive.

[cdmackay]

(03-24-2019 11:50 PM)Carsen Wrote:  It is much more convenient & logical to not disturb the stack simply to change a setting of the calculator.

…

Thanks very much Carsen; yes, I was familiar with the manual's prefix keys list; my question was more about why there are prefix keys.

In some cases it does seem a bit arbitrary, e.g. why isn't WSIZE a prefix key? OK, you might want to use a stack/calculated value for WSIZE, but the same could be set of SF/CF too, perhaps, yet those are prefix keys.

Your point about FLOAT is a good one, thanks. And perhaps that explains it: WSIZE isn't likely to be used that way, so doesn't need to be a prefix. But in terms of not disturbing the stack to make a config change…

And I had somehow missed the fact that CLEAR PREFIX works for all prefix keys, not just f & g

thanks again, makes more sense now.

[Thomas Okken]

(03-25-2019 12:52 AM)cdmackay Wrote:  my question was more about why there are prefix keys.

A big reason for inconsistency in that area is limited opcode space.

Programmable calculators have to store instructions somehow, and it makes things easier for the user if each instruction is exactly one line in a program, and it makes things easier for the calculator if each program line takes up the same amount of space. Many HP programmable calculators, starting with the HP-25, achieved both goals, and did so using one byte per program line.

One byte per line means 256 possible instructions... and prefix instructions take a big bite out of that space. Take the HP-25, for example: GTO is a prefix instruction, and its argument is a line number, so it takes up 50 opcodes of the possible 256, for GTO 00 through GTO 49. The storage instructions take up 48: STO, STO-, STO+, STO×, STO÷, and RCL, each with register numbers from 0 through 7. And then there's FIX 0-9, SCI 0-9, and ENG 0-9, another 30 instructions.

You can see the compromises that the shortage of available opcodes leads to in the HP-19C/29C, where registers 16-29 can't be addressed directly, and the HP-67/97, where registers 10-19 can't be addressed directly, and registers A-E and I can, but without storage arithmetic, and where setting the display mode and the number of digits was separated (FIX 0-9 plus SCI 0-9 plus ENG 0-9 would require 30 opcodes; FIX, SCI, and ENG, plus DSP 0-9, require only 13).

So, WSIZE in the HP-16C is postfix, probably because not enough opcodes were available to make it prefix, and not because it made more sense from a human factors perspective.

[cdmackay]

(03-25-2019 11:57 AM)Thomas Okken Wrote:  So, WSIZE in the HP-16C is postfix, probably because not enough opcodes were available to make it prefix, and not because it made more sense from a human factors perspective.

thanks very much Thomas, very interesting. And perhaps that's also why the 16C doesn't have storage arithmetic, whereas the 15C does, given the 16C has lots of other new opcodes.

I found the prefix business frustrating at first, as I couldn't remember which were which, especially with WSIZE, WINDOW & SF/CF, but I'm doing it less so now so I must be getting used to it

they should have listed them on the back!

thanks again, both.

[Valentin Albillo]

.
Hi,

(03-25-2019 06:51 PM)cdmackay Wrote:  And perhaps that's also why the 16C doesn't have storage arithmetic, whereas the 15C does, given the 16C has lots of other new opcodes.

You can remove the "perhaps", that's exactly the very reason for the lack of storage arithmetic in the HP-16C and the other examples mentioned (HP-29C, HP-67, etc).

Also, the HP-15C has both one- and two-byte instructions so no lack of opcodes whatsoever, the number of possible opcodes vastly outnumbers the existing instructions by about two orders of magnitude.

V.
.

[cdmackay]

(03-25-2019 11:44 PM)Valentin Albillo Wrote:  You can remove the "perhaps", that's exactly the very reason for the lack of storage arithmetic in the HP-16C and the other examples mentioned (HP-29C, HP-67, etc).

Also, the HP-15C has both one- and two-byte instructions so no lack of opcodes whatsoever, the number of possible opcodes vastly outnumbers the existing instructions by about two orders of magnitude.

thanks Valentin; shame they didn't add the 16C operations to the 15C, if they could have crammed in all the key-labels. Still, it gave me an excuse to order a 15L from Michael this week

[hth]

This WSIZE is a bit inconsistent in the HP-16C. I am not sure if they ran out of opcode space or what limitation caused it, but I do not think it was designed that on purpose, unless they thought it would be a good idea to be able to calculate the word size.

This is why I did not do it the same way in my Ladybug module for the HP-41 where it is a prefix WSIZE, which of course can be turned into WSIZE IND using the shift key (WSIZE IND X gives same behaviour as the HP-16C WSIZE).

[cdmackay]

thanks! that reminds me to give your module a try

[wynen]

IMHO it was a good idea to make the WSIZE "programmable" (i.e. posfix). Here a sample program, which reverses the byte order for 16bit and 32 bit word size.

The progran first determines the actual word size by shifting a 1 by 16 bits to the left. A carry will indicate 16bit word size.

For 32 bit, the two 16 bit integers are swaped by rotating the 32bit word 16 times. Now the word size is changed to 16 bit and the two bytes are swaped by rotating the 16 bits 8 times. Finally the word size is changed back to 32 bits and the two 16 bit words are combined.

These are the features, which make the HP-16C unique.

Hartmut

Code:


43,22, A : ->LBL A     // start
       1 :   [1]       // determine word size (16Bit/32Bit)
      36 :   ENTER
       8 :   [8]
   42  A :   f SL      // 10hex = 16dec
   42  E :   f RLn     // shift 1 by 16 to left
      33 :   Rdown     // x = entered value
43, 6, 4 :   F? 4      // carry set (from shift operation)?
   22  2 :   GTO 2     // If carry set, it must be 16 bit word size
      36 :   ENTER     // otherwise continue assuming 32 bit word size
      36 :   ENTER
       8 :   [8]
   42  A :   SL        // 10hex = 16dec
   42  F :   RRn       // swap 16bit words
   43 36 :   LSTx      // 10hex = 16dec
   42 44 :   WSIZE     // 16 bit word size
   21  2 :   GSB 2     // swap bytes in 16 bit word
      34 :   x<->y     // the other part
   21  2 :   GSB 2     // swap bytes in 16 bit word
       8 :   [8]
   42  A :   SL        // 10hex = 16dec
   42  A :   SL        // 20hex = 32dec
   42 44 :   WSIZE     // 32 bit word size
       8 :   [8]
   42  A :   SL        // 10hex = 16dec
   42  E :   RLn       // shift low word to high word
   42 40 :   OR        // add both parts
   43 21 :   RTN       // and return
43,22, 2 : ->LBL 2     // swap bytes of a word
       8 :   [8]
   42  F :   RRn
   43 21 :   RTN

[mfleming]

Neat program! I've added it to my library of useful functions.

One minor typo to point out. The RLn instruction is keycode (42 E) which is correct on the first appearance but wrong (43 E) on the second (sixth line from bottom).

Thanks for posting!

[wynen]

Quote:One minor typo to point out. The RLn instruction is keycode (42 E) which is correct on the first appearance but wrong (43 E) on the second (sixth line from bottom).

Hups. Corrected.