15c: "GSB I" bug?


The 15c supports indirect branching, by storing either a label index in I, or a line number (as a negative number) in I, then calling GTO/GSB I.

When I do this with GTO I and a negative number in I, it seems to work fine. Execution transfers to the line specified by I.

However, after I do GSB I with a negative number in I, as I'm stepping through the program, the line numbers are displayed as one higher than they actually are. Then when the program hits RTN it actually returns to line -1 * I + 1, rather than back to the instruction that called GSB I. Then the program keeps going until it hits RTN a second time, and moves up another level in the call stack. The end result is if LBL A calls GSB B, and LBL B calls GSB I, then the LBL B execution stops after the GSB I target returns (twice, mysteriously), and goes back to LBL A.

Am I missing something obvious, or is this actually a bug? This is a 15c LE, but I'm guessing this would be present in the original model.

Are there any good workarounds that won't increase the size of the program by more than 4 bytes? That's all I've got to work with at the moment. :)


Here's a sample program that demonstrates it concisely. Note that this has to start at line 001 in order to line up properly with the GSB I target.

001- LBL A
002- 3
003- GSB B
004- RTN

005- LBL B
006- 1
007- 4
008- CHS
009- STO I
010- RDown
011- GSB I
012- x^2
013- RTN

014- 1
015- -
016- RTN

Obviously, this program should return 4. What you actually get is -2.

The execution sequence goes like this:

001- LBL A
002- 3
003- GSB B

005- LBL B
006- 1
007- 4
008- CHS
009- STO I
010- RDown
011- GSB I

014- 1 (Displays as line 015)
015- - (Displays as line 016)
016- RTN (Displays as line 017)

015- - (Should have returned to 012- x^2)
016- RTN

004- RTN



This example works exactly the same way on the original HP 15c.


On my 11c it does return 4. Serial is USA 22...

Edited: 20 Sept 2011, 8:06 a.m.


Does it really go to the wrong line number, or is it a byte location? What I'm getting at is whether this opens the door to a type of synthetic programming on the 15C. Is it possible to make it go to the middle of a two-byte instruction?


It appears to go to the correct instruction but the line is numbered incorrectly. I have not tried GSB I to a 2 byte instruction.


This looks like a bug in the original HP 15C!

I enter the following:

001 LBL A
002 1
003 2
004 3
005 4
006 5
007 6
008 7
009 8
010 RTN
011 LBL B
012 GSB I
013 1
014 2
015 R/S

If I put -9 in the I register and hit GTO B, pressing SST shows:

011 LBL B
012 GSB I
010 8 <-- ???? SB: 009 8 !!
011 RTN
010 RTN

Again, this is on an original HP 15c.





I guess this is what happens when you give a CS major a 29 year old computer. :)

I noticed on page 109 of the 15c LE manual, it mentions you can use GTO I and GSB I with a positive number to branch to a label, or GTO I with a negative number to branch to a specific line. Note that it makes no mention of GSB I with a negative number. Hmm. I wonder if it was never intended to work that way in the first place, or they didn't get it to work in time for release (or found a bug in late testing) and just amended the manual.

In any case, it appears to weird out consistently, so there may be some insane practical use for it.


GTO I with a negative number works fine.


It seems perfectly logical, because line numbers are absolute addresses, but subroutines are based on labels, which are relative addresses. So, in effect you have moved into the program area and overwritten it.


Either way, you're just pushing the return address onto the call stack, then branching off to your subroutine, so there's no reason it couldn't work (unless the implementation happens to be broken, which appears to be the case here).


Sorry, I don't follow. Wouldn't that mean that GTO I should also not work right?


No, because a simple GTO can reference either an absolute address (line number) or a relative address (label), whereas a subroutine can only be based on a label. Otherwise, if you add or delete program lines prior to the location of the subroutine start point, then you could not call it based on a line number, since it would have moved.


If line numbers above the one targeted by GTO change, then the GTO will go awry too. I don't see the distinction with GSB.


The difference is that a GTO can transfer to a label or to a line number, but a subroutine is defined by a label so that a return point can be established. I'll bet you'd have the same problem if you tried to do this on an 11c or 34c or 29c. None of the manuals for those calcs show GSB calls with negative I values either.


Programs on the 15c aren't able to modify themselves while running, so I don't see how the target could change mid-execution. You don't have to worry about your return target moving a few bytes up or down in memory during execution.

When returning from a subroutine in most languages, you only care about where you came from. For most HP calculators, this will always be an absolute line number (RTN can bring you anywhere, not just to a LBL instruction, in other words). The only way I could see this failing is if the original developers messed up the routine that pushes the return address onto the call stack before carrying out the branching during GSB I with a negative number.

I'd definitely be interested in finding out what happens when you try this on other models. Everything I have is newer than the 15c, though.


I don't own an 11C, but I do have a 34C. I looked this up in the 34C manual (bottom of page 151), and you appear be correct on this, because it states that you can do a GSB I with a negative number in the I-register to transfer to a line number that is the absolute value of the number in I. It further states that the RTN instruction transfers back to the line following the GSB instruction. However, neither the 11C or 15C manuals make any mention of this capability, so it's probably not implemented in them. It's really not very useful, though, once you begin nesting subroutine calls.


In my 11C French manual rev C from August 1985, GTO I and GSB I are documented as working with negative values in I, and transferring execution to the line number specified by the absolute value of I.

When I try the above program in my 11C it works fine: GSB I transfers execution to line 14 (displayed as line 14) and upon return it returns to line 12 as expected. The final result is 4.

EDIT: I've checked my 15C French manual dated September 1982 and it also says that for negative values of I, GTO I and GSB I transfer execution to the line number:

"Si le contenu de RI est négatif, GTO I et GSB I transfèrent l'exécution à la ligne identifiée par ce nombre. Le calculateur utilise la valeur absolue de la partie entière du contenu de RI."

Edited: 19 Sept 2011, 7:04 p.m.


Tres interessant. However, the English language manuals for the 11C and 15C do not state that a negative value can be used with GSB I to transfer to a line number. Do you have a French labelled 15C ?


Which revision of the 11C and 15C English manuals are you consulting?


11C - November 1985

15C - June 1987

Page 109, third paragraph, To Line Numbers. If the RI value is negative, GTO I ...

No mention of GSB I.


In this 11C English manual (November 1985 - Rev. G) page 131, GSB I is clearly documented as working the same way than GTO I for labels and line numbers:

"Indirect Subroutine Label or Line Number. In a running
program, [GSB][I] indirectly transfers execution to a subroutine in
the same way that [GTO][I] indirectly transfers execution to a

(Thanks to Gerson for the link to the HP-11C manual on the HP web site)


In my 15C Japanese manual Rev.B-3/86 p.110

It's mentioned as a note that you cannot use [GSB][I] if the value of the RI is negative.


edit: add link to the online manual.

Edited: 20 Sept 2011, 2:47 a.m. after one or more responses were posted


So far Japanese manual is the only one that explicitly states GSB with negative I will not work. Shall I say, um, very Japanese?


Hi Masaki,

IMHO, the difference is that it had been sold as a product of

Yokogawa-Hewlett-Packard, with additional Yokogawa's quality control.


Edited: 21 Sept 2011, 12:06 a.m.


and, how interesting that the 15c LE faithfully emulates this NEWLY discovered bug in the original 15c.

If that ain't proof that the 15c LE is running the original 15c rom (and we had already been told it was by HP here), then I don't know what is. :-)



You are in a position to know, Gene, but it seems incredible nobody tumbled to this one in the early days. The manual, by omission, says that GSB I for I<0 isn't supported. For someone a lot smarter than me, it seems like that should have stood out. I also think GSB to a line number would be incredibly useful for saving labels in a large program, so someone might have tried it regardless of what the manual says.

Edited: 19 Sept 2011, 5:56 p.m.


Nowhere in either the original HP15 manual nor the reprinted one does it mention that GSB I with I being negative should work.

Thus, while 'we've' stumbled into an interesting quirk in the internal architecture of the HP15, this is not a documented function working improperly, therefore NOT a bug (and it IS an interesting insight into the internal architecture of this machine).

ps: One can get some crazy and unexpected results by using other well documented and used systems (such as the computer language C)by sending functions unsupported data types!


Yup, check my 4:15 post above.

It's probably one of two things.

1. This wasn't meant to work in the first place, and they forgot/didn't bother to make GSB throw an error when you try it.

2. It was meant to work this way, but for whatever reason, wasn't working in time for manufacturing, so it was simply stricken from the manual. This feature is unimportant enough that it would be better NOT to fix it in a later revision, since you could end up with some 15c units mysteriously unable to run some programs correctly.

I think 2 is more likely, but that's just an educated guess.


I also think 2. is more likely as GSB I with a negative value in I is described as working in my 15C French manual from September 1982.
It would be interesting to check an early version of the 15C English manual to see if this was also initially included and then removed in later editions.


Yeah, I wonder if somebody has an English 1982 manual sitting around that they could check. The plot thickens!


Feb 1983 Owner's Handbook

"To Line Numbers. If the R1 value is negative, GTO I and GSB I cause branching to that line number (using the absolute value of the interger portion of the value in R1).

For instance, if R1 contains -20.00500, then a GTO I instruction will transfer program execution to program line 020."

Third and forth paragraph - Page 109


Translating from my Portuguese Manual from September 1982:

"Indirect Branching to Numbered Lines. If the content of RI is negative then [GTO] [I] and [GSB] [I] will transfer the execution to the line whose number is the integer part of the absolute value of the content of RI.

For instance, if RI contains -20.00500, an instruction [GTO] [I] would transfer the execution the program line 020."


Interesting! That's quite different from the English text starting on p. 108 of both the newly reprinted manual and my classic manual with a print date of 1/85. Comparing your translated text with what I have, it seems plausible that yours is from an earlier draft. The later text expands the explanation quite a bit, and removes any reference to GSB I with I<0.

If that's so, it would lend credence to the idea that the feature was dropped at some point after development of the HP-15C started.


Just a correction to the second paragraph:

"For instance, if RI contains -20.00500, a [GTO] [I] instruction would transfer the execution to program line 020."

Your manual probably reads:

"To Line numbers. If the RI value is negative, [GTO] [I] causes
branching to that line number (using the absolute value of the integer
portion of the value in RI).

For instance, if RI contains -20.00500, then a [GTO] [I] instruction
will transfer program execution to program line 020."

(From the HP-15C Manual in the Museum DVD)

Edited: 19 Sept 2011, 8:50 p.m.


From my original HP-15C Owner's Handbook, having "Printed in U.S.A 1/85" on the back:

Indirect Branching With [I]

The [I] key--but not the [(i)] key--can be used for indirect branching
([GTO][I]) and subroutine calls ([GSB][I]). (Only the integer portion
of the number in RI is used.) ([(i)] is only used for indirect
addressing of storage registers.)

To Labels. If the RI value is positive, [GTO][I] and [GSB][I] will
transfer execution to the label which corresponds to the number in
the Index register (see the above table).

For instance, if the Index register contains 20.00500, then a [GTO][I]
instruction will transfer program execution to [f][LBL][A]. See the
chart on page 107.

To Line Numbers. If the RI value is negative, [GTO][I] causes
branching to that line number (using the absolute value of the in-
teger portion of the value in RI).

For instance, if RI contains -20.00500, then a [GTO][I] instruction
will transfer program execution to program line 020.

This text is identical to that in the newly released HP-15C Owner's Handbook. Having different text in earlier versions of the Handbook seems to me to be a smoking gun indicating that [GSB][I] was intended to work as you would expect when the HP-15C was released. It also means that this bug was known to HP at least by 1985 and they did nothing to fix it back then but simply changed the documentation. So perhaps the HP of 1985 had clay feet, like every other human enterprise ever undertaken?

If HP knew about the bug, surely many users of the calculator must have known about it too. Is there any indication in the historical record that would confirm or deny this?

Edited: 20 Sept 2011, 12:56 a.m.


My German HP-15C Benutzerhandbuch, printed in Singapore 10/82, states on page 109:

"Verzweigung zu einer Zeilennummer. Wenn RI eine negativeZahl enthält, bewirken die Anweisungen [GTO][I] und [GSB][I] einen Sprung zu derjenigen Zeilennummer, die durch den Betrag des ganzzahligen Anteils des Wertes in RI spezifiziert wird."

Also, my USA made 15c with serial 23.... replicates the "bug".


I would think a non-working minor feature like this is better left unfixed after that much time. Otherwise you'll start getting all the support calls about why newly published programs that use the feature aren't working properly on older units.

Since GSB I can be emulated using a spare label and two bytes of program memory, it seems like this would be the the most likely case.


this is better left unfixed ...start getting all the support calls about...older units.

I opt for fixing the 15c LE firmware.

If it is fixed HP might get a few calls from owner's of old units about new programs not working on them (very unlikely; those guys are all here and know why these programs wouldn't work).

If HP does not fix it, they will get many calls from new owner's of machines under warranty who found the feature in their handbook and complain about it not working!

Edited: 20 Sept 2011, 7:46 a.m.


Alexander, do you really think HP has the resources to fix the old code? I doubt it.


It's not fixing the old code at this point, but .using a hex editor on a binary and hoping something else doesn't break . . .



Unlike Tom C. I believe this is a bug. However, I agree it should not be fixed. As it is the current manual (and later original manuals) do not mention that GSB I should work for negative values in RI anyway. It would be bad enough trying to trace it with original (possibly undocumented) source code, but having only the binary - forget it, it's not worth the effort & risk.


Make a programming challenge out of it at HHC!


one could always trap it in the emulation and turn it into something 'harmless'. like, for instance, causing the sign of I to be ignored. but even that would be tricky...


Yeah, it really wouldn't be worth the trouble and risk. It would be much more practical to mention in the manual that GSB I with negative values does not behave as expected, and show how to code around it:


Only costs you one label and two bytes (or three bytes plus one extra byte per invocation if you have no choice but to use one of the "high" labels). You only need a single one of these two-line wrapper functions in memory to cover all use of GSB I.


Alexander, do you really think HP has the resources to fix the old code? I doubt it.

For 100 bucks apiece I expect it to be fixed. But not having mine delivered yet, I only assumed from the OP's first post that the feature in question was actually mentioned in the LE's manual. If this is not the case, I will also opt for not fixing it.

Nowhere in either the original HP15 manual nor the reprinted one does it mention that GSB I with I being negative should work.

From posts here, it was stated in the manual in 1982 & 1983:
"To Line Numbers. If the R1 value is negative, GTO I and GSB I cause branching to that line number (using the absolute value of the interger portion of the value in R1)."

We've all read about Dave Packard's reply about the HP-35 2.02 ln ex bug. So, by the time this 15c bug was discovered, the man that responded "don't tell" to Dave Packard had been put in charge and decided to quietly alter the manual and pretend it wasn't supposed to work anyway ("oh, and tell customer support to reply 'misprint in the original manual' when costomers query it"). But the give-away is that it works on the 11C (as per the 1985 Rev. G manual linked by Didier Lachieze p137/138 states: "When an indirect branch or subroutine instruction is executed with a negative nnnnn value in RI..." ). Why would this feature work in a lower spec calc. and be deliberately dropped in the top model of the voyager line-up?

Edit: to TomC: I am just stating my feelings on the case, no intention to argue or flame. I respect your view, but just think that the evidence points the other way.

Edited: 20 Sept 2011, 10:42 a.m.


I think this is a very unimportant "bug", because there are an abundance of labels available in the HP 25C to identify the start points of subroutines. This is a much more reliable way to program multiple programs / subroutines, and to edit programs with addition and deletion of lines. The HP 11C has 15 labels, whereas the HP 15C has 25 (A-E, 0-9, .0-.9), as well as more than twice the memory so conservation of memory by eliminating labels is less of an issue.


I think this is a very unimportant "bug"

Agreed, see my response to Tim's post.

I agree that the bug is minor. I'm just fascinated with the sociology of it all.


I don't know. GSB I to a line number is a very basic form of self-modifying code. There may be some interesting things that someone could do with that ability.


I actually tested and confirmed it on a real 11c.


This aspect is what interests me from a historical perspective. From today's perspective, Dave Packard's edict that "it would be better to never make a dime of profit than to have a product out there with a problem" is nothing short of astonishing. I suspect it was unusual back in 1972. By 1985 at least* we have evidence of a more "normal" corporate outlook at HP.

It still bothers me that nobody in the user community knew about this bug back then. The fact that the manual changed is another fact that should have tipped off an observant user.

*Challenge: what is the earliest manual version that includes the altered description? Mine is dated on the back at 1/85.


I have to admit that I share your point of view.

And considering that users have only discovered this issue after more than 26 years, let me think that the “corporate” decision to leave it uncorrected it was a good one.
Why, may they have spent any time and involve any resources to fix an issue that nobody will discover before several decades?

At the time, every one receives only one manual. Who can have compare two version and discover the change? A few.

During the last 30 years, how many people use a HP-15c? Many.

How many of the many user of an Hp-15c have never program it ? A majority.
But, how many of these users have program the HP-15c for something else that entering the function to be root finding, solving or integrating? A fraction.

How many people from this fraction have used HP-15c to make advance and complex program code? A bunch. Since the great advantage of the HP-15c is complex, matrix, root finding, numerical integrating, etc… It is not especially dedicated to advanced programming tool – even if it is a capable advanced unit –

From this bunch of advanced programming coders, how many have used any of the two indirect branching instruction GTO I or GSB I ? A few, since most of the problems needs conditional branching and a few algorithms need indirect branching.

From this few of indirect branching advanced program coders, how many have used branching to label (I >0 ) compare to line number (i<0)? A rare, since using label is far easier to program since you to worry about exact line counts. Correct line addressing is a serious challenge.

From this rare indirect line branching advanced program coders using I<0, how many have used GTO I compare to GSB I ? A half.

Conclusion, during the last 30 years, people who have used GSB I (with i<0) on an HP-15c in program are certainly a rare half of a few bunch from a fraction of the minority of the many HP-15c users.

I am not surprise nobody discover this issue before we have many people sharing manual, documentation and experiences on Internet, own several models and collectors, compare versions and survey serial numbers, compare original material performance with new release, play and try to use modern program paradigm on vintage systems.

A last question, just to survey and infirm/confirm my statistics:

During these last 30 years, how many of you people reading this post have already used or program the GSB I instruction with I<0 on an Hp-15C ?

Please! Hand up ! Don’t be scared !



Conclusion, during the last 30 years, people who have used GSB I (with i<0) on an HP-15c in program are certainly a rare half of a few bunch from a fraction of the minority of the many HP-15c users.

That's why this bug is minor, one might even say microscopic. I think the obvious time GSB to a line number might be needed is if you have run out of labels in a program, or are trying to minimize memory when it is extremely tight. Clearly, as you state, this situation doesn't come up very often. Dave Brittan is to be congratulated not only for finding this bug, but for trying to milk the most out of the 15C's resources. :)

During these last 30 years, how many of you people reading this post have already used or program the GSB I instruction with I<0 on an Hp-15C ?

You'll have to exclude the last few days from the "last 30 years." :)


...a rare half of a few bunch from a fraction of the minority of the many...

You nailed it.

Yup. Unless I am miss-reading the original manual this *should* work. It doesn't. It goes to the correct *instruction* initially (but that instruction has the wrong line number) and executes correctly until the first return. At this point (in the example I am trying) it returns to the line number *after* the initial call.


001  LBL 8    I have no other labels abailable
002 7
003 CHS
004 STO I
005 GSB I
006 RTN
007 1
009 1
010 +
011 RTN

When run it proceeds to the GSB and then:

008 1
010 1
011 _
012 RTN
009 ...



EDIT: Just tried GTO in place of GSB. That works fine.

Edited: 19 Sept 2011, 4:25 p.m.


Seems like the obvious solution would be to create a "wrapper function" that calls GTO I instead. This version of the sample program works perfectly. Change line 11, and add lines 17 and 18.

001- LBL A
002- 3
003- GSB B
004- RTN

005- LBL B
006- 1
007- 4
008- CHS
009- STO I
010- RDown
011- GSB C
012- x^2
013- RTN

014- 1
015- -
016- RTN

017- LBL C
018- GTO I

But the program I've got is already using all labels A-E and 0-9, so those two lines would take an extra 3 bytes, and the call to the new label will be 2 bytes. I've got 4 bytes free, so I'm going to have to clear out an extra byte or two somewhere to make this fit. :)

Possibly Related Threads...
Thread Author Replies Views Last Post
  New 15C LE bug? Paul Dale 3 104 02-05-2013, 09:27 PM
Last Post: Mike Morrow
  HP-15C LE (Limted Edition) Bug Reports Addition Dirk E. 0 42 08-02-2012, 05:49 PM
Last Post: Dirk E.
  Documentation bug in original 15C manual BruceH 6 132 05-01-2012, 05:37 PM
Last Post: Mike Morrow
  15C LE bug: p124: momentarily display the imaginary part of the number Rich Messeder (US) 8 158 04-05-2012, 09:48 AM
Last Post: Bart (UK)
  HP-15C Bug with MATRIX 5 Thomas Klemm 17 339 02-04-2012, 05:07 PM
Last Post: Paul Dale
  [HP 15C LE] Prophecy on bug fix? Alexander Oestert 94 689 12-03-2011, 10:57 AM
Last Post: Walter B
  XEQ vs GSB - what am I missing? Thomas Radtke 9 145 11-30-2011, 10:25 AM
Last Post: Gerson W. Barbosa
  15C emulator display bug Thomas Radtke 9 173 11-22-2011, 11:48 AM
Last Post: Thomas Radtke
  Another HP-15C LE bug? Benoit Maag 58 724 10-03-2011, 05:26 PM
Last Post: Steve Simpkin
  Original 15C Keyboard Test Works With 15C LE!!! DigiGal 5 139 09-26-2011, 07:33 PM
Last Post: M. Joury

Forum Jump: