Les dll’s avant les dll’s








télécharger 59.55 Kb.
titreLes dll’s avant les dll’s
date de publication23.12.2016
taille59.55 Kb.
typeDocumentos
ar.21-bal.com > droit > Documentos
GENESE
Des
SHARABLE MODULES

(Les DLL’s avant les DLL’s)

GENESE

des

SHARABLE MODULES


En 1975, juste après avoir livré la deuxième version de l’Editeur de liens – pour lequel j’étais chef de projet –, Editeur de liens dont l’accouchement avait été si laborieux et dont le choix d’architecture (architecture « one-pass ») avait soulevé tant de controverses, je fus invité à une réunion organisée par Georges Lepicard et où participaient également Jean Bellec et Claude Carré.
Le sujet en était l’extension d’espace d’adressage du Processeur « Level 64 » (futur DPS7).

Rappelons que chaque processus du 64 comportait 7 tables de 4 « grands » segments (jusqu’à 4 mégabytes chaque), et 8 tables de 256 « petits » segments (jusqu’à 64 Kbytes chaque). Nous ne nous intéresserons pas aux grands segments, pour lesquels il n’y avait pas de pénurie, mais seulement aux petits segments, dont le nombre s’avéra très rapidement insuffisant. A l’origine, il avait été décidé qu’à chaque procédure au moins un segment « Code » serait affecté et, si la procédure était « impure », au moins un segment « Data ». Ceci avait l’avantage d’isoler les objets et donc de garantir une protection absolue, mais conduisait à une grande consommation de segments. On avait manifestement sous-estimé, à l’origine, l’ampleur que prendrait le Système.
Sur les 8 tables de petits segments, 6 étaient effectivement affectées, deux autres ayant judicieusement été réservées pour une future extension. L’idée initiale de cette extension était d’attacher « statiquement » 2 parmi n tables, chacune correspondant à un « module» de programme. Chaque table de segment était référencée à partir d’une entrée de la « Segment Table Word Array » (STWA), ces entrées étant numérotées successivement 8, 9, A, B, C, D, E, F (voir Annexe I). La STWA pour les petits segments était elle-même référencée à partir du « Process Control Block » (PCB), par l’ « Address Space Word 1 » (ASW1). Les entrées 8 à D étaient affectées – l’entrée 8 pour les segments « privés » à chaque processus d’un « Process-Group », l’entrée 9 pour les segments partagés par tous les processus du Process-Group (le Process-Group étant matérialisé par un « Load Module », représentant un programme complet résultant généralement du rassemblement d’un nombre plus ou moins grand de procédures individuelles, chacune correspondant à une Compile Unit (CU) ou Unité de Compilation), les entrées A à D étant affectées à des tables de segments partagées par tous les processus du système –, les entrées E et F avaient été réservées pour extension future.
Le n° d’entrée dans la STWA (0 à 6 pour les grands segments, 8 à F pour les petits segments) est appelé STN – Segment Table Number –. Il constitue, avec le STE (Segment Table Entry, n° de Segment dans la Table) et le SRA (Segment Relative Address) les 3 composantes d’une adresse segmentée matérialisée par un pointeur.
Dès avant la convocation de la réunion, l’idée d’attachement statique pour les tables d’extension avait déjà été abandonnée et la réunion commença dans l’optique d’un attachement dynamique. Il me fut demandé d’examiner la faisabilité d’une fonction « LINK and GO », tel qu’elle existait pour l’IBM 360. L’ordre LINK citait un module comportant un certain nombre de procédures, et

l’ordre GO adressait un point d’entrée de l’un de ces procédures (en réalité, n’importe quelle instruction, car la notion de programme structuré, avec des « gates », points d’entrée obligés, n’existait pas). Si le module LINKé devait être attaché à une entrée de la STWA (E ou F) à laquelle un autre module était déjà attaché, ce dernier devait être implicitement « déLINKé ». Il fut décidé que les modules objet d’une opération LINK ne pourraient contenir que des procédures « pures », c-à-d ne comportant pas de segments data.
Je commençai donc à réfléchir au problème, mais le concept même de LINK and GO ne me plaisait pas, car il imposait au programmeur d’avoir la connaissance du « packaging » des modules de programme, chaque module constituant un « espace des noms », et d’exécuter une action spécifique pour obtenir l’attachement de ce module à l’espace des noms existant. Au contraire, et ceci de manière plus ou moins consciente, je rêvais d’une fonctionnalité dans laquelle on aurait cité directement le nom de l’objet cible, sans avoir à se préoccuper de packaging, et sans avoir a exécuter aucune action explicite. Le terme d’ « espace virtuel des noms » (virtual name space) décrit bien ce concept, qui rappelle le concept de mémoire virtuelle, dans lequel le programmeur référence une adresse, sans avoir à se préoccuper si l’objet référencé est situé dans la mémoire réelle ou dans la mémoire secondaire, l’ensemble constituant une « mémoire virtuelle ».
Dans toutes ces périodes où des problèmes techniques se posaient à moi, les insomnies nocturnes étaient source d’inspiration. Sur le coup de deux ou trois heures du matin, dans le silence et l’obscurité de la nuit, on a l’esprit étonnament clair.
C’est donc une nuit que j’eus le flash initial et que je bâtis dans ma tête toute la solution, qui répondait aux critères que je m’étais fixés. Ce fut un moment d’intense excitation, qui se prolongea la journée suivante, où je commençai à coucher quelques idées sur le papier.
La nuit suivante, je revis en imagination le scénario construit et m’aperçus que rien ne marchait, il fallut tout démolir. Je fus assez démoralisé et la journée ne fut pas bonne.
Mais la troisième nuit, je repris le problème à la base et me rendis compte que le flash initial avait quand même été le bon. Je reconstruisis une solution, qui ne serait pas la solution définitive, car bien des détails devaient encore « coincer » par la suite, mais les choses convergeaient.
Je pus dès lors formuler une ébauche de solution écrite que je livrai au Management.
L’idée de base était d’associer à chaque objet, à chaque nom de l’espace virtuel, un point de passage obligé, de telle sorte que si l’objet était dans l’espace réel, le passage était libre et le développement d’adresse à partir de l’instruction citant cet objet conduisait à l’objet « Hardware » correspondant – en fait un « descripteur de procédure » -, si par contre l’objet n’était pas dans l’espace réel, le passage devait être bloqué et le développement d’adresse provoquer un « déroutement » vers une procédure de l’Operating System.
La première idée fut d’utiliser un pointeur comme passage obligé pour chaque point d’entrée associé à un nom. Judicieusement, les architectes avaient prévu qu’un pointeur pouvait être dans l’un ou l’autre de deux états, « normal » ou « faute ». Un pointeur normal permet d’accéder, dans l’exécution de l’instruction – en l’occurrence une instruction ENTer – la cible – en l’occurrence un « Procedure Descriptor », un pointeur faute provoque une exception dont la « classe » et le « type » sont spécifiques, et qui provoque l’appel d’une procédure particulière de traitement d’exception, un « Exception Handler » réservé à cette classe et à ce type.
Tous les pointeurs référençant l’ensemble des points d’entrée – chacun correspondant à un nom – d’un module représenté par une Table de segments attachable à l’entrée E ou F de la STWA sont rassemblés dans un « Entry Segment » de ce module. Si le module est effectivement attaché à l’espace d’adresse du processus, tous les pointeurs de son Entry Segment sont dans l’état normal, et toute référence passant par eux est satisfaite. Si le module doit être détaché, alors tous les pointeurs sont mis à l’état faute, et toute référence ultérieure appellera l’Exception Handler spécifique. Celui-ci identifiera le module présentement attaché à l’entrée E ou F de la STWA à laquelle le module référencé doit être attaché, le détachera comme il a été dit plus haut, et attachera le module référencé en mettant tous les pointeurs de son Entry Segment à l’état normal, et en faisant pointer l’entrée E ou F de la STWA vers la Table de segments de ce module.
L’état d’attachement ou de détachement d’un module est toujours par rapport à un processus. Un module peut être attaché dans le processus A et détaché dans le processus B. L’état du contenu de son Entry Segment – l’état normal ou faute des pointeurs – est donc spécifique du processus. Il doit donc y avoir une copie, une instanciation – une « incarnation » – de l’Entry Segment dans chaque processus. L’Entry Segment est dit « privé » au processus. L’illustration de ce mécanisme apparaît dans le schéma n° 1 de l’Annexe I.
Après avoir documenté cette solution, je m’aperçus qu’il en existait une plus simple, qui ne nécessitait pas de modifier le contenu des Entry Segments.
Cette solution, illustrée par le schéma n° 2 de l’Annexe I, repose sur le fait, qu’en plus de pouvoir être dans l’un des deux états « Present » ou « Missing », un Descripteur de Segment peut être dans l’un des deux états « Available » ou « Unavailable ». L’exception résultant de l’état « Missing » est utilisée par l’Operating System pour gérer la mémoire virtuelle. Je décidai d’utiliser l’exception résultant de l’état « Unavailable » pour piéger les points d’entrée des modules dont la Table de Segments serait détachée du processus. De la sorte, il n’y avait plus à modifier un par un l’état des pointeurs à l’intérieur de l’Entry Segment, il suffisait de mettre à l’état « Unavailable » le descripteur de cet Entry Segment lors du détachement de la Table de Segments, et de le remettre à l’état « Available » lors du rattachement. Du coup, le contenu des Entry Segments devenant invariant, il n’était plus nécessaire d’en avoir une copie par processus, mais seulement un « Segment Descriptor » par processus, tous ces descripteurs pointant vers la même copie.
Ces deux solutions ci-dessus représentent un « multiplexage implicite de l’espace virtuel des noms », par opposition au « multiplexage explicite » que représente la solution par primitives LINK/UNLINK. L’ensemble des tables de segments ainsi attachables/détachables dynamiquement, allouées aux entrées E et F de la STWA, représente un espace commutable, par opposition à l’espace statique décrit par les tables 8 à D. L’origine des références vers l’espace commutable peut être quelconque, soit de l’espace statique vers l’espace commutable, soit de l’espace commutable vers l’espace commutable. Il est tout à fait possible qu’une procédure appartenant à une table de segments attachée à l’entrée F fasse référence à une autre procédure appartenant à une autre table de segment devant être attachée à la même entrée F. L’Exception Handler sait parfaitement gérer cette situation.
Nous avons vu jusqu’ici ce qui se passait lors de l’appel, sur instruction ENTer. Un problème similaire se pose lors du retour, sur instruction EXIT. J’imaginai d’utiliser pour résoudre ce problème une autre exception liée au « SAM » (Saving Area Mask), l’exception « Non-Zero SAM ». Le SAM est un mot de la cellule de liaison appartenant à un élément de la pile de procédure (Procedure Stack Frame). Là encore, les architectes avaient judicieusement prévu de piéger le retour vers une procédure : si les 4 bits de gauche du SAM étaient à zéro, le retour s’effectuait normalement, sinon un autre Exception Handler spécifique était appelé. Si la table de segment du module vers lequel s’effectuait le retour n’était pas attachée, alors il fallait l’attacher en en détachant une autre, éventuellement celle-là même dans laquelle s’exécutait l’instruction EXIT.
Tout ce que nous venons de voir concerne l’extension d’espace d’adresse du processus par multiplexage des Tables de Segments. Un autre problème se pose en amont ce celui-ci, à savoir la résolution dynamique des références symboliques. Ce problème avait été résolu auparavant pour répondre à une spécificité du cahier des charges du langage COBOL connue comme « COBOL CALL ‘data-name’ Statement », qui permet que le nom d’une procédure appelée ne soit pas connu à la création du programme, mais seulement à l’exécution. La Commission « Codasyl » de définition des standards du COBOL avait admis que la liste de tous les noms de procédures potentiellement appelables puisse être définie en extension lors de la création d’un module d’exécution – Load Module dans la terminologie GCOS64/GCOS7 –. Lors de l’édition de liens d’un tel Load Module, cette liste était fournie, l’Editeur de Liens Statique – Static Linker – incorporait toutes les procédures concernées et un catalogue de leurs points d’entrée était constitué dans le Load Module, où, à chaque nom symbolique était associée l’adresse segmentée du descripteur de procédure dans le Load Module. Lors de l’exécution d’un « CALL ‘data-name’ Statement », le nom symbolique était retrouvé dans le catalogue, et une instruction ENTer citant l’adresse segmentée associée etait exécutée. Le composant de l’Operating System en charge de cette fonction s’appellait « Dynamic Addresser », le terme de Dynamic Linker ne convenant pas, puisque les procédures devaient avoir déjà été « linkées » statiquement au Load Module.
S’agissant maintenant des modules appartenant à l’espace commutable, qui sont externes au Load Module, il faudra également pouvoir résoudre dynamiquement les références symboliques aux points d’entrée des procédures les composant. Comme il va falloir en plus attacher les modules à l’espace d’adresse du processus, il s’agira ici de véritable Edition Dynamique de Liens, et il aurait été légitime d’utiliser le terme de « Dynamic Linker » pour le composant système en charge de cette fonction, mais comme il continuera à supporter les fonctionnalités anciennes décrites plus haut, le nom de « Dynamic Addresser » sera conservé.
J’avais donc rempli mon contrat, et même au-delà, puisque je proposais une solution plus générale et plus puissante que ce qui était initialement prévu. Mais je voulus aller encore plus loin, car je connaissais les problèmes qui se posaient à l’équipe chargée du design du « Transaction Driven System » (TDS) pour la réalisation des User’s TPR’s (Transaction Processing Routines). Ces TPR’s étant essentiellement écrites dans le langage COBOL généraient systématiquement un code « impur », avec un « Data Segment » pour la Working Storage.

Procédures impures

Les segments data des TPR’s devant être non pas partagés comme les segments code, mais avoir une instanciation dans chacun des processus – la modification de leur contenu dépend d’événements se produisant dans le déroulement du processus et donc spécifiques de celui-ci –, ils ne pouvaient donc pas appartenir à l’espace de l’un des modules commutables regroupant les TPR’s, mais devaient appartenir à l’espace du Load Module « TDS Monitor ». Tout au plus, si un segment data devait avoir une valeur initiale, l’image de cette valeur initiale – la « Fresh Copy » –, pouvait être contenue dans un segment du module commutable. Pour créer ces segments data dans l’espace du Load Module, il fallait donc disposer d’un certain nombre d’entrées vacantes – « Vacant Entries » – dans la ST-8 de ce Load Module.
Je me proposai de décrire deux solutions, l’une très performante mais assez contraignante, l’autre plus souple mais entraînant un certain « overhead » d’exécution. Dans la première le n° de segment (STE) dans la table 8 était fixé à l’origine, dans l’autre il était affecté dynamiquement à l’exécution à partir d’une réserve d’entrées vacantes. La contrainte de la première solution s’imposant non pas à l’utilisateur final développant les User’s TPR’s – le client –, mais aux développeurs de TDS, elle pourrait être jugée acceptable.
Ayant ainsi réalisé la synthèse de tous mes objectifs, je rédigeai un document complet, spécification d’un produit dont les utilisations allaient bien au-delà de ce qui avait été demandé à l’origine.
J’intitulai ce produit « Switchable Sharable Linked Librairies (SSLL) ». Switchable – commutable – parce que les tables de segments représentant les modules d’exécution étaient dynamiquement attachées/détachées, Sharable – partageable – parce que ces modules ne contenant que des segments code – pur – n’avaient pas à être modifiés et donc une copie unique pouvait être partagées par tous les processus du Système, Linked – avec liens édités – parce que les références internes entre les composants de chacun ces modules pouvaient être résolues à la construction.
Je remis ce document au Management qui en donna connaissance aux différents chefs de projet potentiellement concernés.

Product Review/Design Review
Les premiers intéressés par la proposition furent naturellement les designers du « Transaction Driven System ». Ils trouvèrent que le mécanisme proposé fournissait une solution élégante à la réalisation des User’s TPR’s, et comme en plus il permettait de partager une copie unique du TDS Monitor par plusieurs sessions TDS s’exécutant en parallèle, ils soutinrent le projet « SSLL ».
Le projet TDS étant un projet « chaud » (les hauts responsables du produit Level 64/GCOS64 misaient beaucoup – et l’avenir allait leur donner raison – sur ce projet), il avait donc la plus haute priorité dans le programme de développement du département logiciel, et il fut décidé d’organiser une « Product Review/Design Review » pour les SSLL’s, sur la base du document que j’avais rédigé.
Le terme « Switchable Sharable Linked Library » fut jugé trop compliqué, et fut remplacé par celui de « Sharable Module » (SM), sous lequel il est encore utilisé aujourd’hui dans GCOS7 dont les SM’s sont devenus un composant majeur. L’urgence maximale pesant sur la livraison de TDS, le Management décida de ne pas prendre en compte toutes les autres possibilités offertes par l’application des SM’s, et ce n’est que dans les versions suivantes du système qu’ils furent utilisés d’abord pour réaliser les « Run-time Packages » des compilateurs, puis de nombreux utilitaires, et enfin une grande partie du système lui-même fut reconvertie sous forme de SM’s.
La forme la plus évoluée, dépourvue de contraintes, et qui aurait permis de rendre le produit visible aux utilisateurs ordinaires, ne fut pas retenue et il fut décidé de n’implémenter que la forme dite « System SM », réservée aux constructeurs du système, et qui satisfaisait les besoins de TDS, les contraintes de pré-assignation des segments data ne posant pas de problème dans ce cadre. Quelques années plus tard, je tentai de relancer les « User SM’s », en proposant même un support Hardware de l’adressage des SM’s sous forme d’un nouveau type de pointeur. L’équipe de développement Hardware avait accepté cette modification, mais, pour des raisons de priorité de développement des produits, elle ne fut pas implémentée. (Voir Annexe II).

Les projets similaires

chez d’autres constructeurs

Au début des années 80, j’eus entre les mains un document technique de DEC (Digital Equipment Company), société aujourd’hui disparue, concernant un produit nommé « Sharable Image », appartenant, si je me souviens bien, au système VAX/VMS.
Contrairement aux SM’s de Bull qui appartenaient à un espace multi-dimensionnel et dans lequel des objets discrets, individuellement protégés – les segments –, représentaient les éléments constitutifs des programmes, les Sharable Images appartenaient à un espace linéaire, uni-dimensionnel. Là où, dans GCOS64, il avait été nécessaire de multiplexer des tables de segments car on ne savait pas nommer un nombre suffisamment grand de segments, le problème ne se posait pas dans un espace linéaire, mais autant que je me souvienne, l’édition dynamique de liens n’était pas disponible, et le système souffrait de nombreuses contraintes.
Au début des années 90, un autre système très voisin des SM’s apparut : les « Dynamic Linked Libraries » (DLL’s) proposées par Microsoft pour la première livraison de Windows 3.0. Comme dans GCOS64, le système, construit sur l’architecture Intel 386, était fondé sur un espace segmenté, mais le nombre de segments disponibles était beaucoup plus important et le multiplexage n’était pas prévu. Il aurait de toute façon été très difficile à réaliser, car l’architecture 386, avatar simplifié du Level 64, ne disposait que de deux tables de 8192 segments chacune, l’une privée au processus, l’autre partagée au niveau système. Mais rapidement, en raison de la prolifération des DLL’s, le nombre de segments s’avéra insuffisant et le système arriva à saturation. Quand Microsoft développa le système Windows NT, il abandonna l’espace segmenté pour revenir à un espace linéaire, perdant ainsi toutes les capacités de protection fournies par la segmentation.


Genèse des Sharable Modules

Annexe I

Schéma n°1



Schéma n°2

Genèse des Sharable Modules

Annexe II
ET SI ON REFAISAIT L'HISTOIRE ...?
GCOS7, une occasion manquée :

le développement des User SM's

_______

Le design des SM's prévoyait dès l'origine deux types de SM's : les System SM's tels qu'ils ont été développés, assurant avec le maximum de performance un certain nombre de fonctions système et permettant l'implémentation du transactionnel, mais en imposant des contraintes qui rendaient impraticable la mise à disposition de cet outil à des utilisateurs clients, fussent-ils des clients avertis; les User SM's qui visaient à supprimer ces contraintes aux prix d'un overhead un peu plus lourd, pour rendre accessible au client à la fois l'extension de l'espace d'adresse et le partage de code.
Le design des User SM's était fondé sur l'existence d'un Linkage Segment privé au process, ce qui d'une part supprimait la contrainte de ne pouvoir passer de constantes en argument, et d'autre part permettait d'assigner librement les segments data privés.
Une autre proposition avait été faite, qui avait été acceptée par les responsables du développement hardware : introduire le concept "d'ITS – ou pointeur - Flottant", STN relatif, qui garantissait qu'à condition d'avoir au moins deux STN's affectés aux SM's, on évitait le phénomène oscillatoire causé par deux SM's attachés au même STN et s'appelant dans une boucle serrée. Les ITS's flottants supportaient les références internes à chaque SM, ce qui permettait d'attacher un SM à un STN quelconque sans avoir à recalculer les références internes, et donc de ne ne jamais attacher au même STN deux SM's s'appelant mutuellement. Ce concept d'ITS flottant constituait l'embryon de ce que je propose aujourd'hui sous le nom de "Dynamic Logical Address Relocation Mechanism".
Si on ajoute à cela l'apparition de la pagination, on serait arrivé à une solution extrêmement performante, permettant de vivre confortablement pendant de longues années avec des pointeurs à 32 bits :
- La pagination permettait de réaliser le Linkage Segment sous forme d'un grand

segment de Type 3* (au lieu de la concaténation de petits segments, telle que prévue à

l'origine)
- l'existence du linkage segment de Type 3 relaxait la contrainte du passage des

constantes en argument et celle de l'assignation fixe des data segments privés
- l'existence des ITS flottants permettait de réduire drastiquement le taux de

switching de SM. (Le temps de switching aurait été légèrement augmenté parce qu’il aurait

fallu mettre à jour le STN de chacun des pointeurs à l’intérieur de l’Entry Segment)

* Les segments sont classés en types :


  • Les segments de Type 0 sont des segments partagés au niveau système, décrits par les Tables de Segments attachées de façon permanente aux entrées A, B, C, D de la STWA1.

  • Les segments de Type 1 sont les segments des SM’s, appartenant à l’espace commutable, également partageables au niveau système, décrits par les Tables de Segments attachées de façon dynamique aux entrées E et F de la STWA1.

  • Les segments de Type 2 sont des segments partagés au niveau Process-Group, à l’intérieur d’un Load Module, décrits par la Table de Segments attachée à l’entrée 9 de la STWA1.

  • Les segments de type 3 sont des segments privés au processus, à l’intérieur d’un Load Module, décrits par la Table de Segments attachée à l’entrée 8 de la STWA1. (Il existe aussi des grands segments de type 0, type 2 et Type 3, attachés à la STWA0, mais leur affectation n’est pas figée)


Il n'y aurait plus eu de distinction entre System SM's et User SM's, mais entre SM's pré-assignés et SM's non pré-assignés. Les SM's pré-assignés se voyaient affecter de façon définitive un Entry Segment, ce qui permettait que leur référence soit résolue une fois pour toutes et qu'ils soient appelables y compris depuis les Type 0 (équivalent SYSDEF). A l'inverse les SM's non pré-assignés se voyaient attribuer pour Entry Segment n'importe quel segment de Type 3, en général différent pour chaque process.
Une seule table de segments aurait été nécessaire pour les vrais Type 0 et une pour les Type 2 (nous ne considérons ici que les petits segments), 6 tables restant disponibles pour l'ensemble Type 3 / Type 1, ceux-ci se concurrençant :

- En début de session d'une application, une seule table de Type 3 est utilisée pour les Entry Segments

pré-assignés et les segments data privés, 5 tables de segment sont disponibles pour les Type 1,

d'où un taux de switching quasi-nul
- Au fur et à mesure du déroulement de la session, plus de tables sont utilisées pour les

segments data privés, moins pour les Type 1
- En fin de session, jusqu'à 4 tables de Type 3 peuvent être utilisées pour les Entry Segments

préassignés et pour les segments data privés, 2 restant disponibles pour les Type 1, ce qui

assure encore un taux de switching raisonnable, puisqu'il faut traverser 3 couches de SM

pour qu'un switching se produise.
En admettant qu'une table de segments complète puisse être consacrée aux Entry Segments préassignés, on obtient un pseudo-espace virtuel de 4 Giga-bytes pour les segments code, et il reste 3 tables pour les segments data privés, soit 768 segments. Il s'agit ici des segments simultanément adressables, sachant que dans l'univers transactionnel, les segments data privés sont récupérés en fin de transaction.
Notons que l’on aurait pu économiser les descripteurs d’Entry Segments en transformant les Entry Segments en pseudo-segments, c-à-d des zones contiguës d’un grand segment, par exemple, en recourant à la solution présentée dans le schéma 1 de l’Annexe 1, à savoir la modification individuelle des pointeurs de points d’entrée, faisant passer ceux-ci de l’état « normal » à l’état « faute ». Comme il fallait de toute façon modifier le STN de chaque pointeur de point d’entrée du SM attaché, on pouvait en plus mettre à l’état « faute » chaque pointeur de point d’entrée du SM détaché, cela n’aurait ajouté que quelques pourcents d’overhead supplémentaire. Chaque SM pré-assigné aurait eu son pseudo Entry Segment à un emplacement prédéfini et immuable dans son conteneur, l’ensemble des pseudo Entry Segments des SM’s pré-assignés occupant le début de celui-ci, et les pseudo Entry Segments des SM’s non pré-assignés auraient été implantés dynamiquement à la suite, en fonction des références.
L'introduction de la pagination permettait également de dépasser la limite de 256 Méga-bytes de la mémoire physique, les segments non paginés et les tables de page étant astreints, eux, à résider dans les premiers 256 Méga-bytes, ce qui devait pas vraiment poser de problème.
L'échec dans GCOS7 des diverses tentatives d'introduire d'autres modes de linkage dynamique et l'introduction par Microsoft dans Windows 3, vers 1990, des DLL's (qui, semble-t-il, présentent encore plus de contraintes que les System SM's sans avoir la capacité d'étendre l'espace virtuel), justifient à posteriori les choix faits dans la conception des SM's.
Quand la décision d'implémenter les User SM's a été rejetée par le management, leur design était terminé. Il n'aurait fallu que très peu d'efforts, tant dans l'Extended Machine que dans la Program Preparation, pour l'adapter aux ITS flottants et à la pagination. L'effort de développement, en termes de nombre de lignes de programme, eût été très modéré.
Je pense vraiment que ce fut une occasion manquée.

(Voir schéma page suivante)




Claude Massuard – Genèse des Sharable Modules – Page

similaire:

Les dll’s avant les dll’s iconImportant : Nous vous remercions de bien vouloir contacter Madame...

Les dll’s avant les dll’s iconL'internationale situationniste
«avant-gardes» nous éclairent sur les préoccupations de l'homme face à la nécessité de l'expression comme accoucheur des névroses...

Les dll’s avant les dll’s iconExit câbles, fils et cordons! Les données jouent les filles de l'air....

Les dll’s avant les dll’s iconAvant que les systèmes modernes d’arpentage et d’enregistrement cadastral...

Les dll’s avant les dll’s iconNous attendons la visite d'Huguette demain. Je prépare la couchette...

Les dll’s avant les dll’s iconAvant-propos
«Dictionnaire français-anglais de l’architecture vernaculaire», dont on chercherait en vain les équivalents ou concurrents dans les...

Les dll’s avant les dll’s iconAvant-propos
«Dictionnaire français-anglais de l’architecture vernaculaire», dont on chercherait en vain les équivalents ou concurrents dans les...

Les dll’s avant les dll’s iconTout commence en 58 avant Jésus-Christ date à laquelle les Romains...

Les dll’s avant les dll’s icon«L’enceinte servienne dans l’histoire urbaine de Rome»1
«servienne» est un ouvrage architectural construit et retouché du vie jusqu’au Ier siècle avant jc. La majeure partie de l’œuvre...

Les dll’s avant les dll’s iconA pré Saint Gervais, le 22 février 2017 a paris, le 3 mars 201 a paris, le 3 mars 20
«Nous aimons dessiner les projets avec humour, créer des mises en scène, et soigner avant tout le détail dans un dialogue continu...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com