Pourquoi le processeur est-il impliqué pendant l'écho du clavier?

J'étudie actuellement pour un examen d'informatique et je suis tombé sur un concept qui m'a quelque peu déconcerté.

Quand on tape une touche sur le clavier, un caractère ASCII est transmis au CPU. Lors de la réception de ce caractère, la CPU émet le même caractère à l'écran. Ce processus est appelé écho. Au lieu d'avoir le CPU impliqué, pourquoi ne faisons-nous pas simplement ce processus d'écho dans l'unité clavier / écran afin que le CPU soit libre de faire d'autres travaux utiles?

Maintenant, intuitivement, j'ai l'impression que c'est parce qu'il n'y a pas d'unité clavier / écran définie, et le CPU est l'appareil qui est responsable de la communication entre l'écran et le clavier, via le réseau d'interconnexion. Cependant, je pense que le fait qu'une unité clavier / écran soit mentionnée peut signifier que je manque un concept important. Est-ce le cas? Pourquoi impliquons-nous le CPU dans le processus d'écho?

Laisser l'ordinateur voir chaque caractère au fur et à mesure qu'il est tapé permet aux programmeurs de rendre l'interface utilisateur plus dynamique.

À l'époque où un ordinateur sérieux avait la taille de plusieurs réfrigérateurs verticaux et d'ordinateurs fonctionnant sur l'entrée utilisateur une ligne à la fois, l'entrée du terminal était gérée comme vous l'avez décrit. Vous avez tapé une ligne de texte sur un terminal qui l'affichait localement (souvent sur papier). Ce n'est que lorsque vous avez appuyé sur la touche ENTRÉE ou RETOUR que le texte a été envoyé à l'ordinateur central ou au mini-ordinateur pour être traité.

Mais même à l'époque, les ingénieurs de l'époque avaient réalisé l'avantage de permettre à l'ordinateur de voir rapidement les informations de l'utilisateur. L'achèvement de commande, où vous tapez les premières lettres d'une commande et l'ordinateur remplit le reste, a été inventé au milieu des années 1960. Cette fonctionnalité a été copiée et améliorée au fil des ans jusqu'à ce qu'elle est aujourd'hui, disponible dans tous les shells UNIX modernes et sous Windows également.

Permettre au CPU de voir chaque caractère tel qu'il est saisi permet également aux shells d'offrir des fonctionnalités d'édition et d'historique de ligne de commande bien au-delà de ce qu'un terminal stupide pourrait fournir. Une clé peut vous permettre de revenir en arrière dans une liste de commandes que vous avez précédemment tapées, d'en choisir une, puis de la modifier légèrement avant d'appuyer sur RETOUR pour l'exécuter. Le texte peut être coupé et collé entre les lignes de commande, possible parce que le CPU a accès aux commandes précédentes alors que le terminal ne le fait pas. Les noms de fichiers ainsi que les commandes peuvent être complétés sur la base d'une entrée partielle, encore une fois possible car le CPU a accès aux noms des fichiers dans le système de fichiers et le terminal ne le fait pas.

Il n'est PAS NÉCESSAIREMENT nécessaire de laisser l'ordinateur voir chaque caractère pendant sa saisie pour rendre l'interface utilisateur plus dynamique.

Les anciens terminaux ASCII se présentaient généralement sous la forme d'un ensemble clavier + écran, ou clavier + tête d'impression (appelé alors souvent télétype). L'écho local était donc possible. L'entrée a été envoyée sous forme de lignes entières, et c'est à cela que servait la touche Entrée (elle était également appelée retour chariot). Cela était pratique lorsque votre terminal était connecté via des lignes téléphoniques lentes à un ordinateur distant. J'ai encore un modem de 300 bauds que j'ai utilisé alors, ce qui est un peu moins de 300 bits / seconde. Et ce n'était pas le plus lent que j'ai utilisé. Vous ne vouliez pas attendre l'écho.

Kyles Jones vous a donné quelques bonnes raisons de faire contrôler l'écho par l'ordinateur. Tels que l'historique et l'édition en ligne de commande. Mais même ces raisons pourraient être surmontées avec un écho local. Mon ancien terminal à écran ascii (acheté en 1980 et que je n'ose plus connecter à une prise car les condensateurs doivent être dans un état désolant) avait (a toujours) environ 12 écrans (un écran est de 24 lignes de 80 caractères) d'une valeur historique , et des installations d'édition locales: le terminal avait son propre processeur local ... Je ne suis pas sûr que ce soit ce que vous aviez en tête. Tout cela est de mémoire, donc j'espère que c'est proche de la vérité, mais la recherche du manuel me prendrait un certain temps.

Donc, fondamentalement, j'avais un ordinateur d'interface utilisateur connecté à un autre ordinateur. En fait, il y aura toujours du matériel pour gérer l'écho, donc votre question est plus de savoir s'il est approprié d'avoir du matériel sophistiqué pour le faire avec un CPU ou avec du matériel plus simple (pas capable de faire un travail sophistiqué). Les constructeurs de mon terminal ont pensé qu'il était approprié, et en ont fait un terminal sophistiqué, avec le protocole de communication stupide avec l'ordinateur qui était alors standard.

J'ai d'abord pensé à dire qu'une bonne raison de passer par le CPU serait que les applications utilisent maintenant des fenêtres avec toutes sortes de fonctionnalités et différentes polices, et que cela nécessite la puissance de l'ordinateur pour obtenir la flexibilité appropriée, qu'un simple écran- le clavier ne peut pas offrir.

Mais j'ai rappelé à temps (la mémoire est difficile à retenir) que c'est faux. Au début des années 1980, les gens développaient des graphiques bitmap (c'était le nom du type d'écran que vous utilisez maintenant, bien que ce soit CRT plutôt que LCD). Une partie du travail a suivi la vue de terminal traditionnelle, créant des terminaux graphiques très sophistiqués avec plusieurs windoes et polices, etc. L'un d'eux était le BLIT , qui a fait l'objet de nombreuses expériences, comme les fameux crabes de Cardelli .

Cela ne signifie pas nécessairement que le processeur exécutant l'application n'a pas vu les caractères. Mais ce n'était pas nécessaire. Le terminal était suffisamment puissant pour effectuer seul un travail très complexe.

L'architecture informatique a testé de nombreuses solutions, en particulier lorsque des réseaux plus rapides sont devenus disponibles. Vous êtes préoccupé par le terminal, mais à certains moments, c'est le disque qui posait problème (principalement le prix, je pense, et aussi la gestion). Nous avions donc pour un temps un poste de travail sans disque (c'est -à- dire des ordinateurs personnels). Ils incluraient le CPU, l'écran, le clavier et la RAM, mais pas de disque. L'espace disque était sur le réseau et vous venez de demander de l'espace fichier sur le réseau. Même l'échange de mémoire virtuelle a été effectué via le réseau.

La conslusion est donc: une interface sophistiquée (par exemple), utilisant des fenêtres, diverses polices, des touches programmables, l'édition en ligne de commande, la synchronisation entre l'entrée et la sortie, et ce qui ne nécessite pas une réelle puissance de traitement. Même avec des capacités très faibles, du matériel est nécessaire. Ensuite, cette puissance de calcul peut être attachée à l'ordinateur et à son CPU, ou peut en être indépendante et connectée plus ou moins à distance. La même chose peut être vraie pour d'autres ressources.

Mais tout est très relatif.

Dernière remarque. Le premier terminal à écran alphanumérique que j'ai jamais utilisé était un Tektronix en 1974, fourni avec son clavier. L'écran et le clavier étaient si étroitement connectés, que nous avons dû payer quelqu'un pour le modifier en changeant les circuits avec un fer à souder afin qu'il se comporte au besoin. Mais je devrais arrêter mon flot ininterrompu d'histoires.

Comment le CPU pourrait-il ne pas être impliqué? Comment l'ordinateur peut-il savoir s'il faut imprimer quoi que ce soit sur l'écran sans que le processeur soit impliqué? Comment pourrait-il savoir où imprimer le personnage? Comment savoir quelle police utiliser? Comment pourrait-il savoir comment rendre cette police?