+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: HP-35 Div By 0 (/thread-20279.html)
HP-35 Div By 0 - teenix - 08-07-2023 12:24 PM
I was just watching Dave Cochran on UTube and his reminiscing of the HP-35 development.
He mentioned that one of the privileged few who got to use the calculator before its public release tried it out and managed to do a divide by zero and the calculator subsequently crashed. Dave said it made him a tad embarrassed because he had not allowed for that possibility in the new algorithms.
There must be countless times that this has happened when a new project is given to someone to try out and they do something totally unexpected, and of course, it fails. It has surely happened to me.
Anyway, I decided to see what the code would do if I bypassed the "new" snippet in the HP-35 Red Dot. I found the few lines of code, which just checks for a zero mantissa, and if so, branches to the error display flash routine. The denominator is in the C register at this point, and the code line is [if c[m] >= 1] (then go to the division routine, else go to the error routine) This same test is performed in later models as well.
The P register = 12 at this point, so I changed that line of code for the [if P = 12] instruction and recompiled. This will now allow the following [go to] instruction regardless of the C value.
In the next few instructions, the A and B registers both equal zero when a subtraction is performed and as there is no carry generated, the following [go to] is executed and loops back and does the subtract again, and it will do this adfinitum. This is probably the "crash" that Dave saw on the HP-35 with a blank display and a blank stare on a prospective customers face :-)
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. It can be a mammoth task to modify code in the Classic architecture, even single line changes, as it causes a horrible butterfly effect for the other parts and can break code all over the place.
cheers
Tony
RE: HP-35 Div By 0 - John Garza (3665) - 08-07-2023 02:31 PM
Like most engineering on the edge, it's all about balance. And requires top engineering talent.
When the tech evolves enough, you can brute force it and not worry about consequences.
But then, I've seen the spaghetti code that ensues when you give a software engineering task to a hardware guy. =:O
-J
RE: HP-35 Div By 0 - Thomas Klemm - 08-07-2023 07:33 PM
(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.
RE: HP-35 Div By 0 - teenix - 08-08-2023 01:15 AM
(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