Kann es sein, dass beim Übergang von 32-Bit-Real-Speicherformat mit 3 Bytes Mantisse auf 4 Bytes Mantisse (9-digit-Basic) hier etwas schiefgegangen ist bzw. übersehen wurde?
Scheint ja fast mit Händen greifbar:
Der Programmierer dachte sich möglicherweise, sind beide übrigen Folgebytes = 0, also das zweite und dritte = letzte (bei deiser Implementierung!) ist in dieser Schleife nichts mehr zu tun und man kann vorzeitig den RTS anspringen. (Optimierung?) Auf dem 8080-Prozessor wäre das vermutlich mit einer einzigen Vergleichs-/Test-Instruktion abzuhandeln gewesen. (16 bit breit)Und dann kam aus dem Nichts ein 4. Byte daher für die Mantisse.
Dann hätte man entweder die letzten 3 Bytes auf Null abprüfen müssen, oder nur die letzten beiden. Aber halt nicht die mittleren beiden ...
Wie der Fehler zustande kommt, habe ich in dem genannten Thread in Bitte melde dich an, um diesen Link zu sehen. exakt erläutert.
Die den Fehler auslösende Bedingung, daß zwei Mantissenbytes hintereinander 0 sind, kann auch im 3-Byte-Mantissen-Format vorkommen - nur befindet sich zu diesem Zeitpunkt kein nicht-0 Wert in dem Puffer der die Zwischenergebnisse der Multiplikation aufsammelt. Genausowenig ist es auffällig, wenn die untersten zwei Bytes der 4-Byte-Mantisse oder gar die untersten 3 Bytes Null sind. Das Zwischenergebnis ist in den drei genannten Fällen vor der Ausführung der fehlerhaften Schieberoutine komplett mit Nullen gefüllt und da macht es dann auch nichts aus, wenn (versehentlich) noch ein Bit weiter geschoben wird.
Kritisch ist eben jener Fall, wo bei einer 4-Byte-Mantisse im untersten Byte ein nicht-0 Wert drin steht, also in der Folge dann ein nicht-0 Wert im Zwischenergebnis da ist. Kommen dann zwei 0-Bytes in der Mantisse des anderen Faktors rein, wird das Zwischenergebnis auch um ein zusätzliches Bit weiter geschoben und ab da ist das Ergebnis falsch.
...
Die obskure Bedingung hatte ja auch bei mir 30 Jahre gebraucht, bis mir die fehlerhafte Multiplikation aufgefallen war. CBM hat den Fehler vor dem Release von BASIC V7 dann auch bemerkt, als "Double-0 Bug" bezeichnet und gefixt - indem die Optimierung auf Nullbytes in der Mantisse gleich ganz deaktiviert wurde und damit die Multiplikation nun generell langsamer ist. ![]()
Mein Fix führt hingegen einen Rucksack ein, der einfach die vorgesehene Aktion der Optimierung ausführt (Zwischenergebnis um ein ganzes Byte nach rechts schieben) ohne eine andere Routine wiederzubenutzen, die zwar meistens auch das tut was sie soll - aber eben nicht immer.