Commencez par quelque chose comme ceci :
http://www.cpu-world.com/info/Pinouts/8088.html
Vous apprenez les instructions pour une puce/architecture très ancienne. À l'époque où tout sauf le cœur du processeur était hors de la puce. Voyez les lignes d'adresse et les lignes de données et il y a une ligne de lecture RD et une ligne d'écriture WR et une ligne IO/M ?
Il y avait deux types d'instructions basées sur la mémoire et basées sur l'E/S car il y avait des espaces adressables, facilement décodés par l'E/S ou la mémoire.
Rappelez-vous que vous aviez de la logique de collage 74LSxx, beaucoup de fils et beaucoup de puces pour connecter une mémoire au processeur. Et la mémoire était juste ça, de la mémoire, de grandes et coûteuses puces. Si vous aviez un périphérique qui avait besoin de faire quelque chose d'utile, vous aviez également des registres de contrôle, la mémoire pouvait être des données pixel, mais quelque part vous deviez définir les limites des horloges de balayage horizontales et verticales, celles-ci pourraient être des verrous individuels 74LSxx, PAS de mémoires, avoir une E/S mappée en E/S sauvegardée à la fois sur la logique de collage et cela avait tout simplement beaucoup de sens du point de vue d'un programmeur, cela évitait également de changer vos registres de segment pour diriger votre fenêtre mémoire 64K, etc. L'espace d'adressage mémoire était une ressource sacrée, surtout lorsque vous vouliez limiter votre décodage d'adresse à quelques bits, car chaque bit vous coûtait un certain nombre de puces et de fils.
Comme pour les oppositions entre le big et le little endian et l'E/S mappée en mémoire contre l'E/S mappée en E/S, c'était une guerre religieuse. Et certaines des réponses que vous allez voir à votre question reflèteront les fortes opinions qui existent encore aujourd'hui chez les personnes qui l'ont vécue. La réalité est que chaque puce sur le marché aujourd'hui a plusieurs bus pour diverses choses, vous ne pouvez pas connecter votre horloge en temps réel sur le bus mémoire DDR avec un décodeur d'adresse. Certains ont même encore des bus d'instructions et de données complètement séparés. En un sens, Intel a remporté la bataille pour le concept de spaces adresses séparés pour différentes classes de choses même si le terme port d'E/S est maléfique et mauvais et ne doit pas être prononcé avant encore disons 20 à 30 ans. Il faut que des gens de mon âge qui l'ont vécu soient à la retraite ou partis avant que la guerre ne soit vraiment terminée. Même le terme mémoire mappée en E/S est une chose du passé.
C'était vraiment tout ce que c'était, un simple bit de décodage d'adresse à l'extérieur de la puce intel qui était contrôlé par l'utilisation d'instructions spécifiques. Utilisez un ensemble d'instructions, le bit était activé, utilisez un autre ensemble d'instructions, le bit était désactivé. Si vous voulez voir quelque chose d'intéressant, regardez l'ensemble d'instructions pour les processeurs xmos xcore, ils ont beaucoup de choses qui sont des instructions au lieu de registres mappés en mémoire, cela porte la mappée en E/S à un tout nouveau niveau.
Où cela était utilisé est comme je l'ai décrit ci-dessus, vous mettrez des choses qui ont du sens et pour lesquelles vous pouviez vous permettre de gaspiller de l'espace d'adresse mémoire comme des pixels vidéo, de la mémoire pour paquets réseau (peut-être), de la mémoire pour une carte son (enfin pas ça non plus mais vous auriez pu), etc. Et les registres de contrôle, l'espace d'adresse par rapport aux données était très petit, peut-être seulement quelques registres, étaient décodés et utilisés dans l'espace d'E/S. Les plus évidents sont/étaient les ports série et parallèle qui n'avaient presque pas de stockage, vous auriez pu avoir un petit fifo sur le port série, si quelque chose.
Comme l'espace d'adresse était rare, il n'était pas rare et est toujours visible aujourd'hui, de cacher de la mémoire derrière deux registres, un registre d'adresse et un registre de données, cette mémoire n'est disponible qu'à travers ces deux registres, elle n'est pas mappée en mémoire. donc vous écrivez le décalage dans cette mémoire cachée dans le registre d'adresse et vous lisez ou écrivez dans le registre de données pour accéder au contenu de la mémoire. Maintenant, parce qu'Intel avait l'instruction rep et que vous pouviez la combiner avec insb/w outsb/w le décodeur matériel allait (si vous aviez des gens sympas/amicaux travaillant avec vous) augmenter automatiquement l'adresse chaque fois que vous faisiez un cycle d'E/S. Ainsi, vous pouviez écrire l'adresse de départ dans le registre d'adresse et faire un rep outsw et sans brûler de cycles d'horloge de lecture et de décodage dans le processeur et sur le bus mémoire, vous pouviez déplacer des données assez rapidement dans ou hors du périphérique. Ce genre de chose est maintenant considéré comme un défaut de conception grâce aux processeurs super scalaires modernes avec des fetchs basés sur des prédictions de branchements, votre matériel peut expérimenter des lectures à tout moment qui n'ont rien à voir avec l'exécution du code, en conséquence, vous NE devriez JAMAIS incrémenter automatiquement une adresse ou effacer les bits dans un registre de statut ou modifier quoi que ce soit à la suite d'une lecture à une adresse. (Note de l'éditeur : en fait, assurez-vous simplement que vos registres E/S avec des effets secondaires pour la lecture sont dans des régions/pages mémoires non cacheables. La lecture spéculative de mémoire non cacheable n'est pas autorisée dans l'ISA x86. Et ne peut jamais arriver pour les accès à l'espace d'E/S. Mais in/out sont très lents et partiellement sérialisants, et l'espace d'adresse mémoire physique n'est plus rare, donc la mémoire de périphérique est normalement simplement mappée en mémoire pour un accès efficace avec des transactions PCIe de taille complète.)
Les mécanismes de protection intégrés dans le 386 et jusqu'à aujourd'hui rendent en fait très facile l'accès à l'E/S depuis l'espace utilisateur. En fonction de votre métier, de ce que votre entreprise produit, etc. Vous pouvez certainement utiliser la famille d'instructions in et out depuis l'espace utilisateur (programmes d'application sous Windows et Linux, etc.) ou depuis l'espace kernel/pilote, c'est à vous de choisir. Vous pouvez aussi faire des choses amusantes comme profiter de la machine virtuelle et utiliser des instructions E/S pour communiquer avec les pilotes, mais cela pourrait probablement froisser les gens dans les mondes Windows et Linux, ce pilote/application n'irait pas très loin. Les autres contributeurs ont raison de dire que vous n'allez probablement jamais avoir besoin d'utiliser ces instructions à moins que vous n'écriviez des pilotes, et vous n'allez probablement jamais écrire de pilotes pour des appareils utilisant l'E/S mappée en E/S parce que vous savez... les pilotes pour ces périphériques anciens ont déjà été écrits. Les conceptions modernes ont certainement de l'E/S mais c'est tout mappé en mémoire (du point de vue des programmeurs) et utilisent des instructions mémoire et non des instructions E/S. Maintenant, l'autre côté de la chose c'est que MS-DOS n'est certainement pas mort, en fonction de l'endroit où vous travaillez vous pouvez être en train de construire des machines de vote, des pompes à essence, des caisses enregistreuses ou une longue liste d'équipements basés sur DOS. En fait, si vous travaillez quelque part qui construit des PC ou des périphériques PC ou des cartes mères, les outils basés sur DOS sont toujours largement utilisés pour les tests et la distribution de mises à jour de BIOS et autres choses similaires. Je me retrouve encore dans des situations où je dois prendre du code d'un programme de test dos actuel pour écrire un pilote sous linux. Tout comme tout le monde qui sait lancer ou attraper une balle de football ne joue pas dans la NFL, un pourcentage très faible de personnes font un travail logiciel qui implique ce genre de choses. Il est donc toujours juste de dire que ces instructions que vous avez trouvées ne seront probablement pas plus pour vous qu'une leçon d'histoire.
]
