Pourquoi l'arithmétique décimale a-t-elle ralenti VisiCalc?

Question

Il existe un excellent article sur VisiCalc qui donne tous les détails sur ce qui s'est passé et pourquoi, fortement recommandé si vous êtes intéressé par cette partie de l'histoire de l'informatique. Je lisais cette section:

En son cœur, VisiCalc est une question de chiffres. L'une des premières décisions que nous avons prises a été d'utiliser l'arithmétique décimale afin que les erreurs soient les mêmes que celles qu'un comptable verrait à l'aide d'une calculatrice décimale. Rétrospectivement, c'était une mauvaise décision parce que les gens s'en fichaient et que les calculs étaient beaucoup plus lents qu'ils ne l'auraient été en binaire.

Et en hochant la tête, oui, les successeurs de VisiCalc ont rétrogradé à cet égard; à ce jour, Internet regorge de questions et de réponses sur les raisons pour lesquelles Excel présente des anomalies avec des nombres tels que 0,1 et une virgule flottante binaire n'arrondissant pas les attentes des gens. VisiCalc aurait vraiment dû lancer une campagne publicitaire à l'époque soulignant le ...

... Attendez une minute. Logique du réfrigérateur.

Vous avez fait des calculs beaucoup plus lents?

VisiCalc a été écrit sur le 6502, qui prend en charge l'arithmétique BCD. Il vous suffit d'activer le mode décimal, et le processeur ajoutera des octets BCD exactement à la même vitesse qu'il ajouterait des octets binaires.

Mais la plupart des nombres dans une feuille de calcul sont simples lorsqu'ils sont exprimés en décimal. Un nombre comme 1234.56 prend trois octets en BCD alors qu'il aurait fallu huit octets en virgule flottante binaire double précision. Cela permet non seulement d'économiser de la mémoire mais, si vos routines de calcul (qui doivent être effectuées dans le logiciel - la machine n'avait pas de FPU) saisissent l'occasion d'une sortie anticipée, cela vous fera également gagner du temps. Ainsi, le calcul des nombres qui apparaissent généralement dans les feuilles de calcul devrait être plus rapide en décimal.

Et les petites feuilles de calcul passent beaucoup de temps à mettre à jour l'affichage. La conversion d'un nombre d'une représentation interne en ASCII pour l'affichage est un peu plus rapide lorsque la représentation interne était décimale.

Alors pourquoi a-t-il dit que la décimale rendait les calculs plus lents?

Answer 1

Un nombre comme 1234.56 prend trois octets en BCD alors qu'il aurait fallu huit octets en virgule flottante binaire double précision.

De manière générale, ce n'est pas le cas. Si vous avez une définition de champ de base de données de 6 chiffres au total, 4 avant la décimale, 2 après, des nombres positifs uniquement, alors oui, vous pouvez avoir 1234,56 représentés dans 3 octets BCD 8 bits. Mais si, comme c'est plus généralement le cas:

• Vous autorisez n'importe quel nombre à avoir beaucoup plus de chiffres - par exemple, 8 chiffres est un minimum juste pour permettre jusqu'à (mais non compris) 1 000 000 $ spécifié pour le centime. Plus typique serait 10 ou 12 ou plus.
• Vous autorisez un nombre variable de chiffres après la décimale dans différents champs - par exemple, 2 pour les valeurs monétaires américaines (et de nombreuses autres), mais 6 ou plus pour les coûts unitaires (par exemple, le coût du kWh pour les factures de services publics)
• Vous autorisez les nombres négatifs.

Ensuite, vous allez très vite au-delà de 3 octets. 8 octets devient un minimum raisonnable .

Même pour le stockage (en ignorant le calcul), 3 octets ne fonctionnent pas pour le nombre à 6 chiffres car quelque chose doit définir quelque part que cette cellule a un nombre positif de 3 octets avec la virgule décimale avant les 2 derniers chiffres. Cela prend un octet, donc maintenant nous sommes à 4 octets.

De plus, le code nécessaire pour les manipulations supplémentaires (coder / décoder des formats numériques de différentes longueurs) se nourrit du code 64k très limité + données disponibles sur les systèmes 8 bits typiques. Il se pourrait facilement que l'espace économisé pour les valeurs en faisant varier la taille (et, espérons-le, en moyenne beaucoup plus petite) des cellules numériques dans une feuille de calcul soit généralement compensé par le code supplémentaire nécessaire en mémoire pour prendre en charge l'affichage, la manipulation et le calcul de ces nombres. .

Answer 2

6502 pris en charge l'arithmétique SIMPLE BCD. Je parierais que les gars de VisiCalc à la fin n'ont même pas utilisé cette fonctionnalité et ont tout écrit à partir de zéro. Il n'y a pas que l'addition et la soustraction, il y a aussi la multiplication et la division, et VisiCalc était en virgule flottante (juste en virgule flottante décimale).

La raison pour laquelle le calcul décimal est plus lent est simplement la même raison que «personne» n'utilise le calcul décimal aujourd'hui, ils utilisent le calcul binaire. Avec les mathématiques binaires, chaque bit est un chiffre. Avec les mathématiques décimales, 4 bits est un chiffre. Plus de mémoire pour moins de précision, le calcul est juste plus lent, c'est juste beaucoup plus de travail pour l'ordinateur, même le 6502 avec un support naissant.

(Et, oui, les mathématiques décimales sont utilisées partout à différents endroits, mais c'est l'exception pas la règle.)

Answer 3

Parce que les opérations décimales sont plus lentes, même sur le 6502. Il existe un support de processeur pour l'addition et la soustraction de BCD 8 bits, mais c'est tout.

Le code pour la multiplication décimale, la division, le décalage, la normalisation en virgule flottante, et peut-être même la comparaison, sera un peu plus grand et plus lent qu'avec le binaire.

Par exemple, les routines de division de décalage et de soustraction nécessitent un sous-programme pour diviser par deux la valeur. En binaire, c'est trivial. En utilisant une valeur de 8 bits comme exemple:

        LSR

En mode décimal, ce sera quelque chose comme ça ( avec l'aimable autorisation de "Multiplier et diviser en mode décimal" ):

        ROR
N08     PHP
        BPL HALF2
        SEC
        SBC #$30
HALF2   BIT N08
        BEQ HALF3
        SEC
        SBC #3
HALF3   PLP

Un code comme celui-ci serait dans la boucle intérieure d'une routine de division décimale. La pénalité de vitesse est importante.