Comment l'interface indépendante de la machine (MI) facilite-t-elle l'intégration des langages sur un ordinateur ?

L'interface indépendante de la machine (MI) joue un rôle central dans la simplification de l'intégration de nouveaux langages de programmation sur les systèmes informatiques, notamment sur la plateforme AS/400. À un niveau fondamental, l'ensemble d'instructions MI se rapproche de la forme intermédiaire couramment utilisée dans les compilateurs, une représentation commune qui permet une gestion plus fluide de la traduction des langages de haut niveau en instructions machine. En effet, un compilateur de langage de haut niveau génère la forme MI du programme, laquelle est ensuite transformée en instructions spécifiques à la machine par un traducteur situé sous le MI, opérant des optimisations avant de produire les instructions IMPI ou PowerPC.

Le processus de compilation dans ce modèle comprend plusieurs étapes. Premièrement, le compilateur génère un code de représentation intermédiaire (IRP) à partir des instructions source du langage de haut niveau. Ce code IRP correspond à une forme assembleur des instructions MI. Ensuite, le Moniteur de Résolution de Programme (PRM) convertit ce code IRP en instructions MI, créant ainsi un modèle de programme contenant le flux d'instructions MI et d'autres données. Ce modèle sert à créer des objets MI, qui sont ensuite transformés en objets de programme par le traducteur.

Il est important de noter que, bien que ce processus comporte plusieurs étapes, l’utilisateur ne perçoit généralement qu'une seule opération lorsqu'il lance une compilation sur l'AS/400. L'ajout de nouveaux langages, comme C/400 ou Pascal, a nécessité des extensions au modèle OPM, créant ainsi le Modèle de Programme Étendu (EPM). Dans ce modèle, les compilateurs sont dotés de structures distinctes pour l'avant et l'arrière, et la forme intermédiaire commune utilisée est appelée U-code. Le processus de compilation sous EPM, bien que similaire à celui de l'OPM, introduit des optimisations supplémentaires.

Le principal objectif de l'EPM était d'améliorer la gestion des langages à structure modulaire comme C ou Pascal, qui permettent une approche de programmation par blocs. Dans ces langages, un programme est divisé en plusieurs blocs de code indépendants, chacun pouvant être appelé de manière dynamique. Cependant, cette approche entraîne une certaine pénalité en termes de performances, car les appels dynamiques (résolus au moment de l'exécution) peuvent être plus lents. L'OPM ne supportait que les appels externes dynamiques, ce qui limitait les performances des programmes modulaires.

Afin d'améliorer cette situation et de favoriser la programmation modulaire dans tous les langages, une amélioration architecturale a été introduite en 1993 sous le nom d'Environnement de Langage Intégré (ILE). ILE a introduit de nouveaux compilateurs de langage, un traducteur optimisé et un nouveau système de liaison pour créer des programmes empaquetés. L'une des principales innovations de l'ILE réside dans l'introduction du concept de liaison à la compilation, appelée liaison précoce (early binding). Cette approche réduit l'overhead associé aux appels externes dynamiques, rendant ainsi ces appels plus rapides.

Dans le contexte d'ILE, un programme n'est plus un simple objet de programme, mais un module, un objet qui contient le code produit par un compilateur ILE et qui n'est pas exécutable seul. Un programme, quant à lui, est constitué de plusieurs modules, qui peuvent avoir été produits par différents compilateurs de langages. Un service programme est similaire à un programme, mais il est traité comme une collection de procédures appelées de manière statique. Ces innovations ont été conçues pour maximiser la flexibilité des programmes tout en optimisant les performances, en particulier pour les langages de programmation modulaire.

L'introduction de l'ILE a permis de surmonter les limites de l'OPM et a offert une prise en charge améliorée de la programmation modulaire dans un environnement AS/400. Les appels statiques, obtenus par la liaison à la compilation, offrent une exécution plus rapide que les appels dynamiques. La possibilité de combiner plusieurs langages au sein du même programme via des modules distincts est également un atout majeur, permettant aux développeurs de tirer parti des avantages de différents langages tout en maintenant une performance optimale.

Cette évolution technologique dans la gestion des compilateurs et des langages sur l'AS/400 n'est pas simplement une question de performance mais aussi de flexibilité et de modularité accrues, éléments cruciaux pour répondre aux besoins des systèmes complexes actuels. Les outils fournis par ILE, bien qu'initialement conçus pour améliorer l'intégration de nouveaux langages, ont permis une refonte en profondeur de la manière dont les programmes sont construits et exécutés sur la plateforme AS/400, ce qui a eu un impact direct sur l'efficacité du développement logiciel.

L’évolution de la technologie des systèmes d’exploitation : De la programmation orientée objet à la gestion des personnalités système

Chris Jones, aux côtés de Bill Berg et Mike Tomashek, a été à l'origine du plan logiciel initial permettant de migrer vers les processeurs PowerPC. Un défi majeur consistait à former les développeurs afin qu'ils puissent maîtriser les nouvelles technologies nécessaires. Chris a résolu ce problème en faisant appel à un consultant externe, spécialiste des technologies orientées objet (OO) et du langage C++. C'était une démarche inédite pour IBM, une entreprise qui privilégiait la formation interne. Cependant, après persévérance, il a réussi à convaincre la direction de recruter ce consultant, qui forma les équipes pendant six semaines intensives. Un espace de formation spécialement conçu fut même aménagé au cœur de la zone de développement, afin d'assurer une immersion totale dans cette nouvelle approche.

Les résultats furent impressionnants : au cours du développement du SLIC, les programmeurs utilisant la programmation orientée objet virent leur productivité multiplier par quatre par rapport aux méthodes traditionnelles. Le projet SLIC, lancé en juin 1992, généra plus d’un million de lignes de code C++ et plus de 7 000 classes. En comptabilisant le code porté, ce sont plus de 2,5 millions de lignes de code du système d’exploitation qui furent générées sous la MI (Micro-Architecture). L’objectif initial de la méthode OO était donc atteint : un gain significatif en productivité, et la promesse d’une plus grande souplesse de développement était pleinement réalisée.

À partir du début des années 1980, la vision des noyaux d’exploitation (kernels) a commencé à évoluer, marquée par l’émergence du micro-noyau Mach, développé par l'université Carnegie-Mellon. Ce micro-noyau constitue un sous-ensemble d’un noyau classique, incluant uniquement les fonctions communes nécessaires à la majorité des systèmes d’exploitation. L'idée fondamentale était de permettre à plusieurs systèmes d’exploitation de partager un même micro-noyau, rendant possible leur exécution simultanée sur un même processeur. Cette approche permettait une gestion partagée des ressources et une communication efficace entre les systèmes.

Dans un contexte où la compatibilité et la migration des systèmes étaient au cœur des préoccupations, il est apparu pertinent d'intégrer dans le SLIC le support d'autres systèmes d’exploitation. Cela soulevait cependant la question de savoir quel autre système serait pertinent de supporter. La réponse s’est rapidement dessinée : le SLIC devait, en plus de l’OS/400, intégrer une personnalité pour le système System/36. Le groupe des développeurs de System/36, bien que de plus en plus réduit, restait attaché à ce système et à sa pérennité. En 1993, à l'apogée du développement du SLIC, deux membres clés du groupe System/36, Dick Mustain et Steve Dahl, proposèrent de créer une nouvelle version de System/36, cette fois sur la plateforme RISC. Leurs efforts ont permis de démontrer qu’il était possible d'intégrer ce système dans l’architecture du RISC tout en préservant ses fonctionnalités essentielles.

Le développement de ce prototype a été mené dans le cadre d’un projet informel, ou "skunkworks", une petite équipe de développeurs dédiés, isolée des circuits traditionnels de financement et de gestion. Ce type d’organisation est bien connu à Rochester, où plusieurs innovations majeures ont vu le jour, telles que l’AS/400 lui-même. En quelques mois seulement, ce groupe restreint réussit à faire fonctionner le système d’exploitation de System/36 sur la nouvelle architecture RISC, insufflant une nouvelle vie dans cette ancienne ligne de produits.

Ce projet illustre bien l’approche flexible et innovante qui a caractérisé de nombreuses évolutions technologiques chez IBM. Il est essentiel de comprendre que ces projets de mise à jour de systèmes anciens ne sont pas simplement une question de compatibilité matérielle ou logicielle, mais aussi une réflexion stratégique sur la manière de répondre aux besoins d'un marché en constante évolution. Les développeurs ne se contentent pas de maintenir l’existant : ils anticipent, adaptent et transforment des technologies héritées pour les adapter aux défis modernes.

Comment la gestion des disques s'intègre-t-elle dans le stockage à un seul niveau ?

Lors de la conception du système, l'idée était d'isoler toute connaissance relative aux disques du logiciel au-dessus du niveau MI (Machine Interface), une décision fondée sur l'hypothèse que les disques n’avaient pas un avenir pérenne. Cette vision était soutenue par des croyances technologiques selon lesquelles les mémoires à semi-conducteurs pourraient rapidement remplacer les disques magnétiques. Cependant, malgré ces spéculations, la technologie du disque dur est restée présente, et l’évolution des dispositifs a conduit à l’introduction des ASP dans le système. Un ASP offre ainsi plusieurs avantages, notamment l'isolement des pannes de disque, permettant de réduire considérablement le temps nécessaire pour restaurer des données après un incident.

Les groupes d’accès viennent compléter ce système en offrant une méthode pour améliorer l’efficacité des opérations de lecture et d’écriture des segments temporaires associés aux travaux utilisateurs. Dans un environnement de travail, un utilisateur peut générer une multitude de segments temporaires qui, si elles étaient traitées individuellement, entraîneraient une surcharge de performance importante. Grâce à l’utilisation de groupes d’accès, il est possible de regrouper plusieurs segments petits en un seul segment plus grand, facilitant ainsi l'accès aux données et optimisant les entrées/sorties nécessaires pour déplacer ces données entre la mémoire et le disque.

Un autre aspect important de la gestion des disques dans un environnement AS/400 est la façon dont le système assure la sécurité et la performance. Par exemple, la séparation des types d’objets dans différents ASP permet non seulement d’isoler les pannes de disque, mais aussi de garantir que les objets critiques du système, comme les récepteurs de journaux, ne soient pas affectés par des pannes dans d'autres parties du système. Cette approche permet un rétablissement plus rapide des services après un incident, rendant le système plus résilient.

Pourquoi la structure de tâches du système AS/400 est-elle si fondamentale dans l’architecture des systèmes d’exploitation ?

Dans le développement de tout nouveau produit technologique, les idées essentielles sont systématiquement protégées par des brevets. Ces brevets confèrent à l’entreprise détentrice des droits exclusifs sur des innovations précises, lui assurant un avantage stratégique sur ses concurrents — à condition que ces idées soient suffisamment significatives. La valeur de tels brevets réside également dans leur transférabilité : ils peuvent être cédés ou concédés sous licence à d’autres entités, ce qui en fait un actif commercial à part entière. Pour le système AS/400, le brevet fondamental est le numéro 4,177,513 des États-Unis, déposé en 1977 et délivré en 1979, qui couvre la structure de traitement des tâches du System/38, cœur même de l’AS/400.

La structure de tâches constitue le socle architectural sur lequel repose l’ensemble du système d’exploitation. Le composant de gestion des processus de SLIC (System Licensed Internal Code) et le module de gestion des travaux de l’OS/400 s’appuient tous deux sur ce mécanisme. Contrairement à la démarche habituelle d’analyse des systèmes, qui procède du plus haut niveau vers le plus bas, l’étude de la gestion des processus dans l’AS/400 exige de commencer par la base, tant cette structure est fondatrice.

Traditionnellement, des systèmes comme Unix ont adopté une architecture en couches. Chaque couche du système d’exploitation – qu’il s’agisse de la gestion des fichiers, du contrôle des processus ou de l’entrée/sortie – n’interagit qu’avec les couches immédiatement adjacentes. Ce modèle, bien qu’élégant dans sa simplicité et éprouvé par sa large adoption, révèle ses limites dès lors qu’il s’agit de modifier ou d’étendre le système. Les interdépendances complexes entre couches rendent toute intervention risquée et chronophage, d’autant plus que les interfaces sont souvent mal documentées.

Le micro-noyau propose une rupture conceptuelle en remplaçant la hiérarchie verticale des appels fonctionnels par une structure