HP-25 Subroutines possible?

[Matt Agajanian]

Given the tech advances from Classics to Woodstocks, would it have been possible to include three-levels of subroutine branching in the HP-25?

[PANAMATIK]

(06-20-2017 06:16 PM)Matt Agajanian Wrote:  Given the tech advances from Classics to Woodstocks, would it have been possible to include three-levels of subroutine branching in the HP-25?

Theoretically yes, but I see three reasons why this was not possible.

First the ROM code of 2k instructions did not leave space for additional features like subroutines. It was squeezed until the last bit.

Second the HP-25 has only 49 program steps and for such small programs subroutines would not really have been an advantage with their overhead of LBL and RTN instructions.

Third, the development of the firmware with programmable subroutines was introduced with the HP-29C with 4k ROM code and 98 program steps, it was not finished when the HP-25 came into market.

Bernhard

[Matt Agajanian]

(06-20-2017 07:21 PM)PANAMATIK Wrote:  

(06-20-2017 06:16 PM)Matt Agajanian Wrote:  Given the tech advances from Classics to Woodstocks, would it have been possible to include three-levels of subroutine branching in the HP-25?

Theoretically yes, but I see three reasons why this was not possible.

First the ROM code of 2k instructions did not leave space for additional features like subroutines. It was squeezed until the last bit.

Second the HP-25 has only 49 program steps and for such small programs subroutines would not really have been an advantage with their overhead of LBL and RTN instructions.

Third, the development of the firmware with programmable subroutines was introduced with the HP-29C with 4k ROM code and 98 program steps, it was not finished when the HP-25 came into market.

Bernhard

Ah! Your second and third points make the case clear. But, given this second point, why does a 33E/C with its own three subroutine level/49 step program memory seem logical?

[PANAMATIK]

(06-20-2017 07:32 PM)Matt Agajanian Wrote:  Ah! Your second and third points make the case clear. But, given this second point, why does a 33E/C with its own three subroutine level/49 step program memory seem logical?

I admit my second point is weak

Bernhard

[Gene]

And although labels make things easier, they could have simply added a GSB and RTN using line addressing. No labels.

I think the rom was full. Much stronger point as you suggest. :-)

X=Y?
GSB 23

at step 23
Do this
Do that
RTN

[Paul Dale]

Did the 25 have enough opcodes left to encode the extra fifty instructions (49 GSB + RTN)?


Pauli

[Matt Agajanian]

(06-20-2017 09:19 PM)Gene Wrote:  And although labels make things easier, they could have simply added a GSB and RTN using line addressing. No labels.

I think the rom was full. Much stronger point as you suggest. :-)

X=Y?
GSB 23

at step 23
Do this
Do that
RTN

I know, Portokalos & Miller (Apple and Oranges), even the SR-56 had line number addressing for its subroutine branching. Although, maybe engineering the 25 did face ROM space limitations.

[PANAMATIK]

(06-20-2017 09:23 PM)Paul Dale Wrote:  Did the 25 have enough opcodes left to encode the extra fifty instructions (49 GSB + RTN)?

Pauli

Theoretically yes, but spread over the table and thus difficult to decode. No way with a full 2k ROM.

Here is the opcode map

Bernhard

[Matt Agajanian]

As a famous Vulcan says, "Fascinating."

[Dave Britten]

They could have gotten away with only having GSB 01, GSB 02, and GSB 03, with the programmer expected to place an appropriate GTO in those three locations (and another GTO at step 00 to branch to the proper entry point). But as others have pointed out, it would have been of limited use with only 49 program steps to work with.

[Dieter]

(06-23-2017 06:13 PM)Dave Britten Wrote:  They could have gotten away with only having GSB 01, GSB 02, and GSB 03, with the programmer expected to place an appropriate GTO in those three locations (and another GTO at step 00 to branch to the proper entry point). But as others have pointed out, it would have been of limited use with only 49 program steps to work with.

I beg to differ. I think subroutines even make sense with 49 (merged) steps, just as they do on the SR56 with 99 unmerged ones. There are essentially two reasons.

1. Subroutines can make programs shorter. Program parts that occur multiple times need to be coded only once. With line addressing even a short sequence of five steps that appears twice in a program would require ten steps regularly and eight with subroutine calls. With only 49 available steps this can make a difference.
2. A substantial number of programs for programmable calculators handles user defined functions, e.g. root solvers, integration programs, differential equations and many more. Doing this without subroutines is quite cumbersome and requires some tricks – as well as additional memory for implementing these instead of a simple subroutine call.
   

That's why I think that subroutines would have been very useful on the HP25. Just as they were later on the 49 step HP33E/C or the 50 step TI57. There would have been enough space for the required 50 additional opcodes, but since memory was limited this feature had to be omitted.

Dieter

[Dave Britten]

(06-24-2017 10:01 AM)Dieter Wrote:  I beg to differ. I think subroutines even make sense with 49 (merged) steps, just as they do on the SR56 with 99 unmerged ones. There are essentially two reasons.

Note I said limited use, not no use. I can think of a few situations where a small subroutine or two might benefit such a short program, but I'd have a hard time coming up with one that could use more than three and still fit in 49 steps. I'm not sure how tight the 25 ROM is, but the added instructions would only have to push a return address, then jump to the appropriate GTO routine. RTN would just pop an address, and GTO. You'd probably need one extra register to hold the return stack and a stack pointer.

[PANAMATIK]

(06-24-2017 12:51 PM)Dave Britten Wrote:  ... I'm not sure how tight the 25 ROM is, but the added instructions would only have to push a return address, then jump to the appropriate GTO routine. RTN would just pop an address, and GTO. You'd probably need one extra register to hold the return stack and a stack pointer.

Very very tight! No byte left. Here is the HP-25 ROM Code

Bernhard

[teenix]

This simple method is not practical, but it does create a "subroutine" which adds 1 to memory 2 (3 times).

// INITIALISE
00 1
01 STO 1
02 0
03 STO 2
// CALL THE SUBROUTINE 3 TIMES
04 2
05 GTO 12
06 1
07 GTO 12
08 0
09 GTO 12
// DISPLAY RESULT
10 RCL 2
11 R/S
// SUBROUTINE
12 RCL 2
13 1
14 +
15 STO 2
16 RLDN
17 RCL 1
18 X<Y?
19 GTO 06
20 X=Y?
21 GTO 08
22 GTO 10


cheers

Tony

[Dieter]

(06-25-2017 02:42 AM)teenix Wrote:  This simple method is not practical, but it does create a "subroutine" which adds 1 to memory 2 (3 times).

This illustrates nicely the second point in my previous post: "Doing this without subroutines is quite cumbersome and requires some tricks – as well as additional memory for implementing these instead of a simple subroutine call."

Compare that 23 step version with a simple subroutine solution:

Code:

01 CLX
02 STO 2
03 GSB 08
04 GSB 08
05 GSB 08
06 RCL 2
07 GTO 00
08 1
09 STO+2
10 RTN

Doing this without subroutines requires a substantial overhead that fills up valuable memory. With merely 49 steps this is much more relevant than on a calculator with less limited resources. So it's good to see that HP included subroutines on the 33E/C.

Dieter

[PANAMATIK]

(06-25-2017 02:42 AM)teenix Wrote:  This simple method is not practical, but it does create a "subroutine" which adds 1 to memory 2 (3 times).

Hello teenix

As Dieter showed this method is indeed not practical. But you are the only person I know with enough skills who could add subroutines to the HP-25 machine code. You can exceed the 2k program code limit, because in an emulator there is no limit.

However not practical either, because the HP-29C code is already there.

Bernhard

[teenix]

(06-25-2017 10:58 AM)PANAMATIK Wrote:  However not practical either, because the HP-29C code is already there.

That's progress for you :-)

As Bones once said on Star Trek - "I know engineers, they love to change things"

cheers
Tony

[Paul Dale]

(06-25-2017 10:58 AM)PANAMATIK Wrote:  But you are the only person I know with enough skills who could add subroutines to the HP-25 machine code. You can exceed the 2k program code limit, because in an emulator there is no limit.

Subroutines wouldn't have to be implemented as HP-25 machine code. The emulator could accept the keystrokes to insert unused op codes into a program and then intercept the op codes to do the GSB and RTN (and change the code to a NOP or a GTO nn). I'm not sure about displaying entered key codes.

Something that modifies the calculator's state (e.g. RCL arithmetic) might be more difficult to do.


Pauli

[bshoring]

The HP-38C, like the HP-25, & the HP-12C does not offer subroutines. However, in simulators, it is possible. In the latest update of RPN-38 CX for iPhone, Willy Kunz added 4 levels of subroutines, as well as flags and ISG/DSE looping, and these can considerably shorten programs or allow far more complex programs than before. No labels are used, simply line addressing. It works quite well. He did the same with the programmable simulator for the HP-32E. If it can be done here, I would think it could be done with an HP-25 simulator.

[teenix]

(06-26-2017 09:16 PM)bshoring Wrote:  The HP-38C, like the HP-25, & the HP-12C does not offer subroutines. However, in simulators, it is possible. In the latest update of RPN-38 CX for iPhone, Willy Kunz added 4 levels of subroutines, as well as flags and ISG/DSE looping, and these can considerably shorten programs or allow far more complex programs than before. No labels are used, simply line addressing. It works quite well. He did the same with the programmable simulator for the HP-32E. If it can be done here, I would think it could be done with an HP-25 simulator.

HP25 or indeed any simulators can have any amount of additional options, only limited by imagination and resources.

I prefer to stick with the original functionality though

cheers

Tony