Données générales du MV / 8000 sur les «bits sans mode»

Je lis "L'âme d'une nouvelle machine" de Tracy Kidder où une équipe de Data General conçoit une nouvelle machine (nom de code "Eagle", plus tard nommé MV / 8000). Il s'agit d'une extension 32 bits d'une architecture précédente (Eclipse 16 bits). Un des thèmes tournants semble être qu'ils ne veulent pas créer une machine avec un bit de mode et qu'ils y sont parvenus.

Cependant, il ignore comment cela est techniquement réalisé, et il ne explique pas pourquoi il était si attrayant de créer une machine sans bit de mode. Le livre n'est pas un livre technique, il se pourrait donc que les détails aient été en quelque sorte déformés. Cependant, vous avez le sentiment en lisant ce livre qu'une solution de "mode bit" était courante (et donc réalisable) à l'époque, mais a été jugée peu attrayante par les ingénieurs peut-être pour des raisons esthétiques. Le livre fait également apparaître comme une tâche extrêmement difficile de créer un design sans bit de mode, qui a été en quelque sorte surmonté par cette équipe particulière.

J'ai trouvé cette description de la façon dont cela a été réalisé:

http://people.cs.clemson.edu/~mark/330/kidder/no_mode_bit.txt

Il semble s'agir essentiellement d'utiliser une partie précédemment inutilisée de l'espace opcode pour les nouvelles instructions. Je dois admettre que j'étais un peu déçu que ce soit "juste ça". Je pense également que cela laisse encore des questions sans réponse:

Premièrement, comment les processus 16 bits ont-ils vécu dans l'espace d'adressage 32 bits? Parce que je pense que c'est le principal défi de faire une extension 32 bits "sans bit de mode". Par contre, l'extension du jeu d'instructions est une entreprise relativement courante. Comme il n'y a pas de description de la façon dont cela s'est produit, on pourrait supposer que le code 16 bits accède simplement à la mémoire comme il l'a toujours fait, peut-être qu'il voit un certain type de vue virtualisée / mise en banque de la mémoire (avec de nouveaux registres CPU contrôlant où se trouve la première adresse) ou quelque chose comme ca. Mais je ne sais pas s'il y a plus que ça. Dans ce cas, on pourrait affirmer qu'il s'agissait en quelque sorte d'une solution "bit de mode". Les processus en mode 16 bits pourraient fonctionner en parallèle avec les autres processus grâce à des fonctionnalités spéciales ajoutées au processeur.

Deuxièmement, pourquoi était-il si attrayant de créer une machine sans bit de mode? Beaucoup des avantages présentés dans le livre sont que les clients voulaient exécuter de vieux logiciels. Mais cela ne semble pas parler contre un bit de mode, car le but de l'utilisation d'un bit de mode est d'avoir une compatibilité descendante. Quand AMD a étendu x86 à 64 bits, du moins d'après ma compréhension du mot "mode bit", ils ont exactement ajouté un bit de mode. Un bit spécial qui ferait du CPU en mode 64 bits. Et un autre bit qui ferait exécuter un processus dans un "sous-mode" du mode 64 bits (pour permettre la compatibilité avec les applications 32 bits). L'essence du sous-mode est que le CPU interprète le flux d'instructions comme les anciennes instructions 32 bits mais que les accès à la mémoire 32 bits effectués sont résolus en utilisant le nouveau format de tables de pages (configuré par le système d'exploitation 64 bits) et finalement mappé à l'espace d'adressage physique complet. En outre, le code 32 bits peut être préempté par du code 64 bits. Comme la solution Data General, cela a également permis à un programme 32 bits de s'exécuter sous des programmes 64 bits (16 bits vs 32 bits dans le cas DG). Du point de vue du client, il ne semble donc pas y avoir de différence du tout. Par conséquent, le seul avantage aurait pu être dans la mise en œuvre, simplifiant la conception, mais le livre ne donne pas l'impression que c'est le problème, car le bit de mode semblait commun même à cette époque (et il semble que les architectures ultérieures aient également utilisé comme le montre le cas x64).

Je suis sûr qu'il y a quelque chose qui m'a manqué, donc ce serait génial si quelqu'un pouvait discuter plus sur les détails techniques et les vertus de cette conception "sans mode".

La réponse est qu'Ed deCastro, président de Data General Management, avait mis en place une équipe d'ingénieurs en Caroline du Nord spécialement pour concevoir le CPU de prochaine génération. Il nous a confié la tâche du support et des améliorations incrémentielles, l'équipe du Massachusetts. Trois fois, nous avons proposé une nouvelle architecture majeure, à chaque fois avec un bit de mode très sensible, et l'avons décrite comme une amélioration incrémentielle modeste. À chaque fois, Ed a vu notre déguisement et a rejeté la proposition, s'attendant à ce que l'équipe de Caroline du Nord réussisse. Ed croyait que quelle que soit la façon dont nous tentions de dissimuler nos propositions, il saurait que c'était une architecture de nouvelle génération si elle avait un bit de mode. Nous avons donc dû proposer une architecture de nouvelle génération sans bit de mode, même si cela la rendait moins efficace. C'est ainsi que nous l'avons dépassé Ed deCastro. Voir l'âme d'une nouvelle machine,

En théorie, "aucun mode bit" ne vous permettrait d'utiliser l'ancien système d'exploitation 16 bits sans aucune modification, et ce système d'exploitation pourrait lancer des applications 32 bits, bien que les nouvelles applications 32 bits soient bloquées avec 16 bits d'adresse virtuelle, serait donc en mesure d'utiliser les registres 32 bits et les nouvelles instructions, mais se comporterait mal s'ils accédaient à des adresses virtuelles supérieures à .$2^{16}$

Avec un bit de mode, l'ancien système d'exploitation 16 bits aurait dû être modifié pour déterminer si le programme était 16 bits ou 32 bits, puis régler le bit de mode de manière appropriée avant de lancer le programme.

En pratique, il semble que le MV / 8000 ait en fait un bit de mode. Ailleurs sur la page Web de Mark Smotherman à Clemson, il a publié les données générales, ECLIPSE MV / 8000 Principles of Operation , 1980 . Si vous regardez dans l'annexe E (à partir de la page 369), vous verrez que le MV / 8000 avait deux mécanismes de table de pages complètement différents. La machine spécifique avec laquelle le MV / 8000 était rétrocompatible était le C / 350, et le C / 350 avait une unité de protection et d'allocation de mémoire 16 bits spécifique, avec des moyens spécifiques de contrôler cette unité. Pour un fonctionnement logique à physique 32 bits, vous devez plutôt activer l'unité de traduction d'adresse (décrite au chapitre 3, à partir de la page 31).

En pratique, cela signifie que lorsque vous exécutez une instruction 16 bits en mode 32 bits, il est spécifié que les 16 bits les plus élevés de l'adresse logique sont définis sur 0. Il doit également y avoir une spécification sur ce qui arrive à la haute 16 bits d'une adresse lorsque vous exécutez une instruction 32 bits en mode 16 bits, mais je n'ai pas pu la trouver lors de ma brève lecture du manuel.

Il s'agit donc moins de savoir si un bit de mode est une bonne ou une mauvaise chose. C'est plus qu'il n'y avait pas de raison particulièrement bonne d'utiliser un bit de mode pour différencier les instructions 16 bits et 32 ​​bits. Les instructions 16 bits utilisent 16 bits d'adresse logique (avec les 16 bits les plus élevés réglés sur 0) et des registres 16 bits, et les instructions 32 bits utilisent 32 bits d'adresse logique et des registres 32 bits. L'ancien système d'exploitation "ne fonctionne que" sur la nouvelle machine, mais vous pouvez également essayer les nouvelles instructions en exécutant un nouveau programme sous l'ancien système d'exploitation.