Is this another bug for the 35s?
#1

Hi all.

On the Learning Module entitled, Line Addressing, an example is given:

S001 LBL S

S002 INPUT A

S003 INPUT B

S004 INPUT C

S005 INPUT D

S006 RCL D

S007 RCL C

S008 RCL B

S009 RCL A

S010 X^2

S011 XEQ Q001

S012 XEQ Q001

S013 XEQ Q001

S014 SQRT

S015 RTN

Q001 LBL Q

Q002 X <> Y

Q003 X^2

Q004 +

Q005 RTN

And then it's said that the 35 automatically adjusts the line numbers of GTO and XEQ instructions when lines are added or deleted. So, if we delete the line Q001, in this pamphlet, it is said that the 35s automatically adjusts line numbers in GTO and XEQ statements so they reflect the modification. Then, if we delete line Q001, the program becomes:

S001 LBL S

S002 INPUT A

S003 INPUT B

S004 INPUT C

S005 INPUT D

S006 RCL D

S007 RCL C

S008 RCL B

S009 RCL A

S010 X^2

S011 XEQ S016

S012 XEQ S016

S013 XEQ S016

S014 SQRT

S015 RTN

S016 X <> Y

S017 X^2

S018 +

S019 RTN

But, when I tried this on my 35s, although the line numbers changed to reflect the new Snnn numbering, the branching statements still stated XEQ Q001?

Is this a bug or have I missed a step or is that Learning Module incorrect?


Edited: 2 Mar 2012, 2:06 a.m.

#2

Interesting, if the XEQ's referred to Q002, then it does automatically change it to the correct new line.

From the module:

The step pointed to by a GTO or XEQ instruction is deleted:

Any GTO or XEQ instructions continue to point to the
same instruction. The instruction that now fills the
previous step number is the destination of the transfer
instruction.

So it IS following the stated paradigm, but in the case where the GTO or XEQ point to the start of a Label, this philosophy fails, as they are now left pointing to a non-exitent program.

I will leave it to Pauli to decide if it goes into the bug list.
#3

Happy to add it if someone comes up with a smaller example and verifies it. This one is a little on the large size.

It sure seems like a bug to me.


- Pauli

#4

How about this:

K001 LBL K
K002 INPUT A
K003 XEQ L002
K004 VIEW B
K005 RTN
L001 LBL L
L002 B=pi*SQ(A)
L003 RTN
In this case deleting L001 correctly gives the following:
K001 LBL K
K002 INPUT A
K003 XEQ K006
K004 VIEW B
K005 RTN
K006 B=pi*SQ(A)
K007 RTN


But now try:
K001 LBL K
K002 INPUT A
K003 XEQ L001
K004 VIEW B
K005 RTN
L001 LBL L
L002 B=pi*SQ(A)
L003 RTN
Now deleting L001 gives the following:
K001 LBL K
K002 INPUT A
K003 XEQ L001
K004 VIEW B
K005 RTN
K006 B=pi*SQ(A)
K007 RTN
i.e. K003 is left pointing to a non-existent label.
#5

Hi Pauli, a more compact form:

The "Line Addressing" learning module states:

The step pointed to by a GTO or XEQ instruction is deleted:
Any GTO or XEQ instructions continue to point to the same instruction. The instruction
that now fills the previous step number is the destination of the transfer instruction.
But in the case where the GTO or XEQ point to the start of a Label, this philosophy fails, as they are left pointing to a non-exitent program.


Example A:
K001 LBL K                In this case             K001 LBL K
K002 INPUT A deleting K006 K002 INPUT A
K003 XEQ K006 correctly gives K003 XEQ K006
K004 VIEW B ------------> K004 VIEW B
K005 RTN K005 RTN
K006 RCL A K006 B=pi*SQ(A)
K007 B=pi*SQ(A) K007 RTN
K008 RTN
It works across labels too

Example B:
K001 LBL K                In this case             K001 LBL K
K002 INPUT A deleting L002 K002 INPUT A
K003 XEQ L002 correctly gives K003 XEQ K006
K004 VIEW B ------------> K004 VIEW B
K005 RTN K005 RTN
L001 LBL L L001 LBL L
L002 RCL A L002 B=pi*SQ(A)
L002 B=pi*SQ(A) L003 RTN
L003 RTN
But not if the line that is being pointed to and deleted is the first line (LBL) of a new label:

Example C:
K001 LBL K               Now deleting              K001 LBL K
K002 INPUT A L001 gives K002 INPUT A
K003 XEQ L001 ------------> K003 XEQ L001
K004 VIEW B K004 VIEW B
K005 RTN K005 RTN
L001 LBL L K006 B=pi*SQ(A)
L002 B=pi*SQ(A) K007 RTN
L003 RTN

i.e. K003 is left pointing to a non-existent label.


Edit: hopefully to illustrate the problem more clearly


Edited: 2 Mar 2012, 2:41 p.m. after one or more responses were posted

#6

Quote:
The step pointed to by a GTO or XEQ instruction is deleted...

Your first example is a case where a step between the XEQ and the step pointed to by the XEQ is deleted. If we delete the actual target of the jump, your example would be as follows:
K001 LBL K                In this case             K001 LBL K
K002 INPUT A deleting L002 K002 INPUT A
K003 XEQ L002 correctly gives K003 XEQ L002
K004 VIEW B ------------> K004 VIEW B
K005 RTN K005 RTN
L001 LBL L L001 LBL L
L002 B=pi*SQ(A) L002 RTN
L003 RTN

It is still inconsistent with the learning module information, as you say:

K001 LBL K               Deleting                  K001 LBL K
K002 INPUT A L001 gives K002 INPUT A
K003 XEQ L001 ------------> K003 XEQ L001
K004 VIEW B K004 VIEW B
K005 RTN K005 RTN
L001 LBL L K006 B=pi*SQ(A)
L002 B=pi*SQ(A) K007 RTN
L003 RTN

when we would need the following to adhere to the rule:

K001 LBL K               Deleting L001             K001 LBL K
K002 INPUT A should give K002 INPUT A
K003 XEQ L001 ------------> K003 XEQ K006
K004 VIEW B K004 VIEW B
K005 RTN K005 RTN
L001 LBL L K006 B=pi*SQ(A)
L002 B=pi*SQ(A) K007 RTN
L003 RTN

But this may actually be on purpose - the way it actually works preserves your intention to jump to a different label. That way if you accidentally deleted your label while editing, you would not have to go back and find all places where you meant to jump there and fix them. (It has been a while since I did much programming on the 35s, so forgive me if the above suffers from some logical flaw.) Either way, deleting the target of a jump must be handled with care, wouldn't you say?

Edited: 2 Mar 2012, 1:16 p.m.

#7

Hi Jeff,


What the module information says is that if the step pointed to is deleted, then the GTO or XEQ does not change and the program will continue at the step that followed the deleted line (as it has now taken the place of the deleted line), which is fine when applied within a label. But this philosophy fails when the jump is to the first line of a new label, and that first line is deleted (as in their example in the module - quoted by the OP).

I hope I have explained the problem a bit better now.

#8

So, it seems Bart and I are on to something. I Just tried my original example by replacing the original 'XEQ Q001' commands with 'XEQ Q002' and all is as it should be. The line numbers corrected themselves after I deleted the 'LBL Q' instruction.

Thus, in order for the editing to work, XEQ commands should call instructions 002 instead of 001. It does follow that deleting a LBL statement leaves all GTO n001 and XEQ n001 statements unchanged (thus referring to a non-existent location). Although, logically you would address n001 to call a label's start point, perhaps the habit should be to avoid calling a subroutine at the 001 point but rather another step number.

#9

The bug list is updated with just the failure case.


- Pauli



Possibly Related Threads…
Thread Author Replies Views Last Post
  Is the HP-35S bug free? Matt Agajanian 22 6,190 07-01-2013, 04:03 PM
Last Post: Andrés C. Rodríguez (Argentina)
  Bad News for 33S: a bug shared with 35s bill platt 20 5,323 03-25-2012, 03:57 AM
Last Post: Paul Dale
  HP-35s that does not exhibit LOCKUP DEMO bug NateB 5 1,701 07-27-2010, 06:51 PM
Last Post: Gerson W. Barbosa
  HP 35S --- 2*2 lin. solve bug Maarten Ambaum (Reading, UK) 17 3,920 01-22-2010, 09:50 PM
Last Post: Palmer O. Hanson, Jr.
  Bug in article 893? (HP 35s Triangle solver) Dave Britten 0 729 05-13-2009, 09:09 PM
Last Post: Dave Britten
  where is 35s cos bug Andrew Nikitin 3 1,217 10-06-2008, 01:41 AM
Last Post: Karl Schneider
  A serious bug on HP 35s Marcel Pelletier 5 1,591 10-16-2007, 12:33 AM
Last Post: Seth Morabito
  New version of the 35s vector bug. Arne Halvorsen (Norway) 1 934 09-27-2007, 01:11 PM
Last Post: Arne Halvorsen (Norway)
  HP-35s bug list Daniel Diggelmann 33 8,365 08-27-2007, 09:42 PM
Last Post: Gerson W. Barbosa
  HP 35s, keyboard buffer, bug, feature or what? Patrick Rendulic 3 1,168 08-27-2007, 12:16 PM
Last Post: Bruce Bergman

Forum Jump: