HP 33S looping problem



#2

I just bought a 33s at my local Walmart (Louisville KY) and discovered a loop index problem when you decrement the loop index. In every BASIC I know, when you do a For Next loop like For i=10 to 1 step -1, it goes through the loop 10 times. On the 33s, it only goes through the loop 9 times. After the 9th iteration, it decrements the loop control variable to 1 and exits the loop.

Shouldn't DSE (decrement and skip if less than OR EQUAL) really be DSL (decrement and skip if less than)? Has anyone else been bothered by this or am I just picky?


#3

Hi, Don;

What are the contents of the control register in this case? Would it be 10.001? If so, when it reaches 1.001 (meaning the cccccc part of the number is actually equals to the fff part) the EQUAL part of the DSE is satisfied, so the loop may be resumed. In this case, from 10 to 1, right?

I remember I had some issues about this same subjetc when dealing with DSE and ISG by the first time: their behavior are not the same, as expected. To get a 10 times couting with ISG, I needed 1.010 as a control number because the integer part would count from 1 to 10 and when it was eleven (greater than), the loop would resume. To get a 10 times counting with DSE I needed 10.000 and not 10.001 as a control number because the integer part would count from 10 to 1 and when it was zero (equal to), the loop would resume. After reading what you wrote, I actually think that the behavior is correct. You wrote:

Quote:
After the 9th iteration, it decrements the loop control variable to 1 and exits the loop.
I hope I'm not missing any point here.

Best regards.

Luiz (Brazil)

Edited: 5 June 2005, 6:15 p.m. after one or more responses were posted


#4

Hi, Don;

instead of changing the subject of my prior post, I decided to post one example listing in another one:

X0001 LBL X
X0002 SF 10
X0003 10.001
X0004 STO A
A0001 LBL A
A0002 RCL A
A0003 IP
A0004 PSE
A0005 DSE A
A0006 GTO A
A0007 END LOOP
A0008 PSE
A0009 1.01
A0010 STO A
B0001 LBL B
B0002 RCL A
B0003 IP
B0004 PSE
B0005 ISG A
B0006 GTO B
B0007 END PRGM
PRGM TOP
When this program is ran with [XEQ][X], it counts from 10 to 2 and shows
END LOOP
then it counts from 1 to 10 and shows
END PRGM
I take this as a correct behavior.

Hope this helps understanding.

Luiz (Brazil)

Edited: 5 June 2005, 2:49 p.m.

#5

Don --

"DSE" means Decrement and Skip when less than or Equal to, as the HP-33S manual says. The function is unchanged from its implementation on numerous predecessor HP calc's, such as the 32SII, 32S, 42S, 11C, 15C, 41C, and 34C...

Executing the DSE statement with n.mmmkk (n = -9999999 to +9999999) stored in the "looping-variable" register will result in n being decremented by kk, and the instruction following DSE being skipped only if n <= mmm.

For n.mmmkk = 10.00101, if program execution is repeatedly returned to the DSE statement without any other operation changing the value of n.mmmkk, the instruction following DSE will be executed when n = 10, 9, 8, 7, 6, 5, 4, 3, and 2 -- a total of nine times.

It is noteworthy that DSE, ISG, DSZ and ISZ (both from the HP-16C) are operations that only modify a variable, check its value against the "goal", and dictate program execution on the result. These operations provide a convenient tool for automating looped processing, but they do not initiate a loop or determine the number of executions.

DSE and ISG are likened to a "FOR-NEXT loop" in the manuals for the 32S, 32SII, and 33S. However, they aren't functionally equivalent. Additional LBL and GTO instructions are usually needed to set up a conventional for-loop using DSE, ISG, DSZ or ISZ. A simple example:

(set up loop-control number)
STO I
LBL 0
("looped" instructions)
DSE I
GTO 0
(remainder of program)

Comment about quality of HP calculator manuals, starting with Pioneer models:

After seeing a few mistakes and misleading statements regarding DSE and ISG in the 32S and 32SII manuals, I looked at the 15C manual, which included no such gaffes on that topic (or any other topic, for that matter). I had previously noted that the writing in the manual of the 42S on a given topic wasn't as precise as that in the manuals of the HP-41 and the Voyager models (e.g., 15C). It's as though HP tried to simplify (read: "dumb down") the reference material, but degraded its quality in the process.

-- KS


Edited: 6 June 2005, 4:55 a.m. after one or more responses were posted


#6

Thanks Luiz and Karl. You are right, this behavior is documented in the manuals (I looked in my old 11c manual and it describes the same behavior).

Maybe the HP programmers did it this way for some reason, but I tend to believe that they just goofed it, and then continued to goof it to be consistent. ISG and DSE are supposed to be aids to loop control, and doggone it, when I want to loop from 10 to 1 stepping by -1, I want to go through that loop 10 times, with the last one using index value 1. As I said, EVERY version of BASIC and FORTRAN I have ever used works this way. It just makes sense. Yes, we can adjust to it I guess, but think of how many programmers have been fooled by this behavior.

Don


#7

Hello, Don --

I added some detail to my earlier post.

Quote:
Maybe the HP programmers did it this way for some reason, but I tend to believe that they just goofed it, and then continued to goof it to be consistent.

I suspect that the reason for the difference is as follows:

When counting upward (ISG), the programmer generally starts at unity until a pre-determined count of executions have been performed. Hence, "skip" to jump out of the loop when the counter exceeds the goal.

When counting downward (DSE), the programmer generally wants to loop until no items remain to be processed. Hence, "skip" when the counter reaches (or goes past) the goal. This is the philosophy behind the HP-16C's DSZ and ISZ (decrement or increment, and skip when zero has been reached or passed).

DSE, ISG, DSZ, and ISZ are not meant to be fully-consistent, comprehensive, general-purpose looping commands. Sometimes workarounds are necessary, including adjustments to the looping variable to fit the problem.

Consider if the ending value is negative. This is easy to handle with a FOR or DO loop, but requires some thought with ISG or DSE.

-- KS

Edited: 5 June 2005, 10:52 p.m.


#8

Hi Karl, Don, guys;

I'd add, based on Karl's mentioning of

Quote:
DSE, ISG, DSZ, and ISZ are not meant to be fully-consistent, comprehensive, general-purpose looping commands. Sometimes workarounds are necessary, including adjustments to the looping variable to fit the problem.
that amongst other adjustments and workarounds, all of the arguments (n, mmmm and kkk) must be integers and, if indexed, should be explicitly adjusted. In these cases, the adjustments might take so much programming additional tasks that it might be hard to control everything. I added this just to corroborate Karl's thoughts that
Quote:
DSE and ISG are likened to a "FOR-NEXT loop" in the manuals for the 32S, 32SII, and 33S. However, they aren't functionally equivalent
as Don first thought they should be.

Just a few ¢ of contribution...

Luiz (Brazil)


#9

Thanks again, guys. Yes, Karl, I remember my frustration a few years ago when programming my 16c using DSZ. I always wanted it to process the loop when (I) reached zero, but of course it would not and, as you say, I had to do a workaround.

By the way Luiz and Karl, having just purchased the 33s yesterday and playing with it for one day, I really like the debugging stepping method where it shows the real command (like STO + A) as opposed to the Voyager keycodes.

Thanks for your feedback guys. As always it is appreciated.

Don


#10

Hi Don,

Quote:
By the way Luiz and Karl, having just purchased the 33s yesterday and playing with it for one day, I really like the debugging stepping method where it shows the real command (like STO + A) as opposed to the Voyager keycodes.

That is one of the most oustanding features on the 32s--as an evolutionary step--that made me very happy when I bought my 1st 32sii back in the mid-90's.

My question would be, how many lines of program space were lost, in order to have this convenience. (I don't know harware architecture so my question may be very ignorant and I accept that :)

Regards,

Bill


#11

You either wanted a simple RPN calculator, or if you really needed some programming room, bought an Hp42s. Therefore, the question of programming room given up by this feature is moot. The programming space left was better (somewhat) than the 11c it was meant to supercede.


#12

Hi Ron,

When I bought the 32sii, the 42s was no longer available.

I am curios nevertheless whether my question is ridiculous from an architecture/firmware standpoint. IOW does the coding of the command labels waste chip space to the detriment of memory?

Regards,

Bill


#13

Probably not, as Paul explains below.

The real culprit is Hp's product differentiation philosphy of that period (or others, Hp has shown on many occasions of poking their heads deeply into the sand, sometimes all the way up to their toes, deep!).

The Hp32sii could have and should have had 2+K RAM, pure and simple. Instead, it was merely better than an 11c, when it should have stepped over the Hp15c. The 42s should have been the 42sx (really, it was on the board, just that IT would have ROBBED sales from the casterated Hp48G, which was later upgraded to a G+, which it should have been from day one but wasn't, so as to not rob sales from the 48GX). Sorry to rant, but Hp's marketing decisions are sometimes hard to understand (really hard, from my point of view anyway).

In todays market place, 2nd place can often be last place and everyone else is gone. Sometimes last is still pretty good, sometimes it aint.

Hp has the only real pocket scientific calculator left on the market (the Hp33s). And it is the only RPN pocket scientific. It has two markets all to itself, and it is still only a moderate seller. However (and thankfully, I guess???) its huge mark up will keep Hp turning it out for years. And it has the Hp tactile feel and if they continue to improve it, it's growth in sales may increase by simple word of mouth if no other product emerges onto the market place (which ironically, may happen as everyone else is so enamored with PDA's or graphics calculators).

#14

I don't think it was a simple trade-off.

The mnemonics are no doubt coded as a look-up table in ROM (along with and lookup/display routines), while the program lines themselves are stored in RAM. It's unlikely that a mnemonic display directly impacts program size.

#15

Hi, Bill;

just to add a few info to the one posted by Paul right here. The building of the display as dot-matrix, ALPHAnumeric characters instead of seven-segment, number-only (plus a few restricted ALPHA-like codes) resides mainly in ROM. When you get a Voyager in program mode and read, say:

[001-    36]
this means that the code found in program step #1 was the one for the [ENTER] function/command and, whatever code is used inside the calculator for [ENTER], the number [36] is shown in the display so you can locate the key and give this keycode the [ENTER] label yourself, right? On the other hand, when this code is found during the execution of a program, the internal routine equivalent to [ENTER] is executed and the only thing you see is a flashing [running] in the display.

In the HP41, the internal code for [ENTER] (I don't remember it by heart, now... but I used to, when dealing with SYNTH programming) also generates a code in the display when the calculator is in PRGM mode, but now the word [ENTER] is visible instead of a keycode, so you do not need to 'decode' it and give it a label yourself.

We all (or many of us) know that in both cases a single byte encodes the [ENTER] function/command in program memory, but the (we can call it as) 'operating system' of each calculator gives this byte a particular representation in the display. In the HP32S/32SII, because of the processor characteristics, the least space occupied by each program step is 1½ byte, or 12 bits. Also, memory address is based on pointers instead of sequenced references, so you can use [STO][Z] without the need of having [A] to [Y] registers as existing and having 0.000 stored on them (in fact, any register with a 'zero' stored on it is just referenced to; when anything but 0.0000 is stored on it, a bunch of bytes is separated for it). These differences and the faster operation are both due to the processor structure and related 'operating system' characteristics, that now builds messages and numbers in dot-matrix characters, so ALPHA-numeric characters can be built.

Of course, as the calculator OS needs part of the RAM used by the system (four registers to ALPHA, the always needed five registers to the stack registers, in the HP15C the five extra registers for imaginary stack and the 8 or 23 to root finding and/or numeric integration, etc), so the new ones have their OS using RAM as well, but I guess that, in this case, the system RAM is already separated and is not exactly in a fixed-address basis, but this is another story...

Hope I did not forget any link up here, and also hope this gives you a glimpsy of what happens inside these little wonders. And if we go hardware, man... there is a universe inside there, believe me.

Cheers.

Luiz (Brazil)


Edited: 6 June 2005, 5:50 p.m.

#16

It might make more sense if you look at it from the viewpoint of an assembly language programmer, rather than a FORTRAN or BASIC programmer. For example, a very common way to do a loop is as follows:

        MOV #10.,R0
CLR R1

10$: ADD R0,R1
SOB R0,10$

HLT

SOB is subtract one from register and branch if not equal to zero. The loop variable is in R0. The code sums the integers 10..1.

The code takes advantage of the fact that decrementing a register will set the Z (zero) flag if the result is zero.

The long and slow way of doing the same thing:

        MOV #10.,R0
CLR R1
MOV #1,R2

10$: ADD R0,R1
DEC R0
CMP R0,R2
BGE 10$

HLT

Or:
        MOV #10.,R0
CLR R1
MOV #1,R2

10$: CMP R0,R2
BLT 20$
ADD R0,R1
DEC R0
BRA 10$

20$: HLT


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP 33s (Fixed decimal point size problem) Grant 3 1,092 02-17-2007, 10:44 AM
Last Post: Bruce Bergman
  33S key press problem kc 10 2,524 02-05-2007, 12:42 AM
Last Post: Forrest Switzer
  Integration Times "Old" 33s vs "New" 33s John Smitherman 21 5,379 12-14-2005, 12:04 AM
Last Post: Karl Schneider
  HP 33s low battery warning problem kc 0 690 08-31-2005, 02:46 AM
Last Post: KC
  looping or something like that patman 3 1,099 05-19-2002, 09:28 AM
Last Post: Chris Randle
  97 Card Reader Problem (NOT gummy problem) Peter Khor 5 1,691 10-04-2000, 11:03 AM
Last Post: ErikWahlin

Forum Jump: