Quelle est la différence entre le BCD emballé et le BCD non emballé?


Réponse 1:

Environ 4 bits. Ou un octet selon la façon dont vous le regardez.

Pour vraiment comprendre emballé et déballé, nous devons d'abord comprendre BCD. Vous avez peut-être entendu dire que BCD est essentiellement une représentation de caractère (c'est-à-dire une chaîne) d'un nombre. Et ce serait plus ou moins correct. Mais ce n'est pas toute l'histoire.

Voyons comment les nombres 0 - 9 sont codés dans le schéma de codage EBCDIC:

11110000 (0xF0) - 0 11110001 (0xF1) - 1 11110010 (0xF2) - 2 11110011 (0xF3) - 3 11110100 (0xF4) - 4 11110101 (0xF5) - 5 11110110 (0xF6) - 6 11110111 (0xF7) - 7 11111000 ( 0xF8) - 8 11111001 (0xF9) - 9

Avec un peu de chance, il n'a pas échappé à votre attention que le quartet bas de l'octet code les nombres 0 à 9 en binaire. Le quartet supérieur (F en hexadécimal) n'est que la partie de la plage dans laquelle EBCDIC a décidé de coder les nombres. Pour effectuer des calculs ou d'autres choses, nous pouvons effectivement ignorer le quartet supérieur.

ASCII est de la même manière, en stockant ses numéros dans la plage 0x30 - 0x39. Les deux sont considérés comme un codage BCD car les quatre bits inférieurs représentent les nombres 0–9.

Et c'est tout l'encodage BCD. Chaque unité d'information représente les nombres de 0 à 9 sous forme binaire.

Alors, d'où vient le formulaire emballé?

Tout ingénieur qui regarde l'encodage BCD en détail va s'énerver avec tout l'espace perdu. Seuls les 4 bits inférieurs sont significatifs. Le reste peut être jeté! En fait, il ne sert qu'à imprimer correctement sur l'écran!

Regardons le nombre 12345678 dans l'encodage BCD décompressé:

11110001 11110010 11110011 11110100 (0xF1F2F3F4) 11110101 11110110 11110111 11111000 (0xF5F6F7F4)

Beurk. Beurk. Nous avons utilisé 64 bits pour représenter un nombre qui ne nécessite que 24 bits en numérotation en base 2! (Plus à ce sujet plus tard.)

La solution que les premiers concepteurs d'ordinateurs ont trouvée était d'utiliser ce quartet supérieur inutile pour ajouter plus de nombres. Ainsi, le nombre 12 serait représenté par un seul octet au lieu de 2 octets. C'est ce qu'on appelle l'encodage compressé. Regardons 12345678 dans l'encodage compressé:

00010010 00110100 01010110 01111000 (0x12345678)

Regarde ça! Nous avons réduit 64 bits à 32 bits! Une économie massive. Si nous devons imprimer les données, il est facile de masquer les bits et de déplacer chaque quartet pour recréer l'octet d'origine. Ce qui fait de cet encodage un support de stockage très efficace.

«Mais pourquoi ne codent-ils pas simplement les données en nombres de base 2», vous entends-je vous demander?

Eh bien, il y a plusieurs raisons à cela. Mis à part le fait que le BCD est souvent un moyen facile de piloter des affichages à un chiffre (pensez comme une calculatrice LCD), nous avions également le souci de la précision décimale.

Encodons le numéro 12345678 dans un nombre binaire de 48 bits. (Pourquoi 48 bits? Parce que le dernier mainframe sur lequel j'ai travaillé était une machine 48 bits avec des nombres 48 bits.: P)

00000000 00000000 00000000 10111100 01100001 01001110 (0x000000BC614E)

C'est génial! Fonctionne assez bien, même si nous avons perdu environ 3 octets. Il est plus grand que notre nombre emballé, mais ce n'est pas déraisonnable. Si nous avons beaucoup de grands nombres, cela pourrait s'avérer beaucoup plus efficace. (Les grands nombres sont très efficaces dans le codage base-2.)

Choisissons donc un nombre avec beaucoup de chiffres comme 12.34567890.

Euh… attends. Est-ce que quelqu'un sait comment encoder 12.34567890 en base-2? Nous avons appris à coder des nombres entiers, mais pas des quantités fractionnaires!

Les premiers concepteurs informatiques étaient confrontés au même problème. Ils avaient de nombreuses solutions, dont les nombres à virgule flottante que nous utilisons aujourd'hui. Pourtant, quiconque sait quelque chose a appris que vous n'utilisez pas de nombres à virgule flottante pour de l'argent en raison du manque de précision. Les concepteurs d'ordinateurs ont donc trouvé d'autres solutions.

L'une de ces solutions était les nombres à virgule fixe. Dans le codage à virgule fixe, vous supposez essentiellement où se trouve le point décimal. Donc, si j'ai toujours 8 points de précision fractionnaire, je peux coder 12,34567890 comme valeur entière 1,234,567,890 et supposer simplement que la décimale est entre le 2 et le 3. Cela fonctionne, mais cela signifie également qu'un 12 pair va être codé comme 1 200 000 000!

Encore une fois, nous gaspillons un peu.

Une autre solution consiste à utiliser l'encodage BCD avec un point décimal. Par exemple, 12.3 pourrait être représenté dans EBCDIC comme:

11110001 11110010 01001011 11110100 (0xF1 = 1) (0xF2 = 2) (0x4B =.) (0xF3 = 3)

Attendez, n'est-ce pas juste du texte?

Hé bien oui. Oui, ça l'est. C'est vraiment du texte, mais il code où se trouve notre point décimal et nous permet toujours de décoder les nombres BCD.

Malheureusement, ce schéma ne fonctionne pas si vous emballez les chiffres. Donc, si vous voulez les emballer, vous êtes de retour à une solution à virgule fixe où vous supposez où se trouve le point décimal. Ce qui se révèle… pas si mal.

Dans les systèmes où vous traitez principalement de l'argent, il est peu probable que vos enregistrements individuels deviennent très volumineux. Vous pouvez donc prendre 4 octets (rappelez-vous, nous obtenons deux chiffres par octet), supposons que les deux derniers chiffres sont les centimes, puis encoder des nombres monétaires qui sont juste timides d'un million de dollars. (999 999,99 $ pour être exact.)

Pas un mauvais compromis. Et aussi simple en termes de calcul. Et c'est pourquoi les encodages compacts étaient si courants dans les anciens systèmes mainframe.


Réponse 2:

Le BCD (décimal codé binaire) est un type dans lequel chaque chiffre décimal est représenté par 4 bits (1 quartet).

Par exemple: 14 sera affiché comme 0001 0100 sous forme BCD emballée.

Le BCD décompressé est un type dans lequel chaque chiffre décimal est représenté par 8 bits (1 octet).

Par exemple: 14 sera affiché comme 00000001 00000100 sous forme BCD non emballé.