HP-35 Div By 0

[teenix]

(08-07-2023 07:33 PM)Thomas Klemm Wrote:  

(08-07-2023 12:24 PM)teenix Wrote:  It was only a small code change, but if anyone has had a fiddle with the code in the Classics, then you may have some sort of appreciation for what effort that a modification like this would have presented to the engineers.

Another example is Fixing the CHS and Stack Lift Bug.

Nice :-)

A big problem with the Classics is when it executes a [Select ROM n] instruction.

[n] would be 0 to 2 for the HP-35 as there are only 3 ROMs. As all code operates only within a single ROM (256 words), this instruction allows the code to jump into a different ROM and continue execution there.

If (say) this was the buggy div by 0 code in ROM 1,

1 25 select ROM 0
1 26 0 -> C[W]

These 2 lines were added to fix it.

1 25 if c[m] >= 1
1 26 then go to $B0
1 27 select ROM 0
1 28 0 -> C[W]

The select ROM 0 instruction will now cause a code execution failure.

When the Select ROM 0 instruction executes, the program counter will increment to $28, ROM 1 is disabled, and ROM 0 is enabled, and that is where code execution will continue from.

If this was the original code in ROM 0,

0 26 C -> A[W]
0 27 0 -> C[W]
0 28 A -> B[W]
0 29 Select ROM 2

Before the fix, the instruction C -> A[W] would have executed. After the fix the instruction A -> B[W] will execute which is wrong. Further, the Select ROM 2 instruction will cause the PC to jump to another invalid address in ROM 2.

Every Select ROM n instruction above ROM address $26 in any ROM page will have to be checked. As these are moved around, new checks need to be made - a coding nightmare. A compiler can handle changing goto and call instructions to new addresses, but it can't handle rearranging instructions across all the ROM pages, especially, I would imagine, with the tightly packed code of the 35.

The [Delayed Select ROM n] instruction in future models helped overcome this problem by allowing a following [go to] to jump into any ROM address in the selected ROM.

A further improvement was to use a 10 bit instruction as a ROM address which greatly expanded the range of addresses a [go to] could target.

Of course, coding problems of this type are generally trivial these days. I can sort of imagine the amount of effort that went in to producing these early programs. Years ago, I created an ignition timing controller for early points engines, 1 - 8 cylinders, up to about 7000rpm, storage for 2 timing sets, with keyboard and display, all squashed into 1K of ROM. Lousy by today's standards though ;-)

Tony