Résumé des différences entre les versions

Le système p-System de l'UCSD (le dernier de ses noms) a connu un certain nombre d'incarnations depuis sa première publication au public. Les noms qu'il a portés sont : I.3, I.4, I.5, II.0, II.1, III.0 et IV.0. La plupart des modifications apportées au système ont étendu ses capacités. L'environnement de microprocesseur mono-utilisateur, le code portable et le système d'exploitation hiérarchique sont des caractéristiques de la conception n'ayant pas changé. L'augmentation des capacités a conduit à une prolifération et une diversification des fonctionnalités - cette tendance a été contrée par les efforts de normalisation et de code portable. La dernière version, IV.0, a été conçue pour incorporer les capacités de II.0, III.1 et III.0, tout en nettoyant certains aspects difficiles de l'interface utilisateur, du code UCSD Pascal et des composantes internes du système.

La version IV.0 offre une compatibilité ascendante au niveau du code source, introduit le multitâche dans les implémentations basées sur l'interpréteur de UCSD Pascal et fournit des techniques de gestion de la mémoire plus flexibles et plus propres que les versions précédentes. Avant de détailler les nouveaux changements, voici un peu d'histoire (peut être ignoré par les plus impatients) :

Après une série de versions internes à l'UCSD et à son programme d'informatique, la version I.3 a été mise à la disposition du grand public. C'était une version très simple et très stable du système. Bien qu'un éditeur orienté écran ait existé depuis un certain temps, l'éditeur système de la version I.3 était YALOE. La version I.3 fonctionnait sur les PDP-11 et les LSI-11.

La version 1.4 a été la première à être disponible sur d'autres microprocesseurs, y compris les 8080 et les Z80 exécutant CP/M 80. La version 1.4 a également introduit l'éditeur orienté écran complet. La version 1.5 a introduit la compilation et l'assemblage séparés. Les routines et les UNIT externes pouvaient être liées aux programmes hôtes avec le Linker. D'autres microprocesseurs étaient encore pris en charge.

La version I.0 était essentiellement une version plus stable de la version I.5. Il a été publié par UCSD peu avant que SofTech Microsystems n'assume la responsabilité de sa licence et de son support. II.1 est la variante de II.0 distribuée par Apple Computer Corp. Il possède la fonction intrinsic UNIT et un certain nombre de différences mineures.

III.0 est distribué par Western Digital Corp. Pour exécuter UCSD Pascal sur une P-machine émulée au niveau matériel, de nombreux changements, principalement internes, ont été nécessaires. Au niveau du code objet Pascal, III.0 a introduit des procédures concurrentes appelées processus.

IV.0 est la plus récente et rassemble les fonctionnalités de niveau utilisateur des trois dernières versions.

Version IV.0

• Média : le format logique des répertoires et des fichiers du disque n'a pas changé, donc aucune conversion de texte ou de données n'est requise.
• Code source : les sources Pascal et FORTRAN des versions II.0, II.1 et III.0 seront compilées sous IV.0. Les programmes tv10st pourront alors s'exécuter. Ceux qui ne le seront pas sont des programmes dépendants d'anciennes implémentations des structures de données et de la gestion de la mémoire du système, ou éventuellement des besoins en mémoire d'une machine donnée (c'est-à-dire des programmes "à ajustement serré").
• Code objet : les anciens programmes doivent être recompilés. Le sens d'un octet d'un processeur hôte n'a plus d'importance -- il est détecté et correctement traité par le système d'exploitation. FLIPCODE et FLIPDIR ne sont plus nécessaires.
• Pascal : a été étendu avec la construction PROCESS pour la concurrence. Les SEPARATE UNIT et les INTRINSIC UNIT ne sont plus, bien qu'elles soient toujours compilées comme des UNIT régulières. Les UNIT n'ont pas besoin d'être liées par un Linker et peuvent donc être partagées (c'est-à-dire qu'elles se comportent comme des INTRINSIC UNIT II.1 mais ne sont pas liées à un seul numéro de segment). La partie IMPLEMENTATION d'une UNIT peut contenir des SEGMENT PROCEDURE. Un programme peut référencer jusqu'à 256 unités de compilation, une unité de compilation peut référencer jusqu'à 256 segments et peut contenir jusqu'à 16 segments.
• FORTRAN et BASIC font désormais partie du système.
• Les éditeurs : dans YALOE, la commande E(rase a disparu ; sinon elle est inchangée. L'éditeur orienté écran reste à peu près le même; eX(change est plus flexible et une commande K(olumn a été ajoutée.
• Les assembleurs : aucun paramètre macro n'est autorisé dans les chaînes de caractères ASCII, les caractères de commutation de base ont changé, des alternatives alphabétiques à certains caractères spéciaux sont fournies, des procédures relocalisables ont été ajoutées. Les anciennes procédures en langage assembleur utilisant le type STRING et les anciennes fonctions en langage assembleur nécessitent quelques modifications pour fonctionner sous IV.0.
• Gestion de la mémoire : les routines SEGMENT peuvent être déclarées (comme avant). Un module de compilation (programme ou UNIT) peut contenir jusqu'à 16 segments. Les corps de toutes les routines de segment doivent être déclarés avant les corps de toutes les routines non segmentées. Les intrinsèques Pascal standard NEW et DISPOSE sont maintenant implémentés. Les intrinsèques MEMLOCK et MEMSWAP du UCSD, et VARAVAIL, VARNEW et des VARDISPOSE ont été ajoutés.
• Compilation externe : il n'y a maintenant qu'un seul type de UNIT. Les unités intrinsèques et séparées existant dans les anciens programmes seront compilées en UNIT IV.0 normales. Un UNIT IV.0 est comme une ancienne unité intrinsèque II.1 en ce sens qu'elle n'a pas besoin d'être liée et peut être partagée, mais contrairement à une unité intrinsèque en ce sens qu'elle n'a pas de numéro de segment fixe. Les unités peuvent maintenant contenir des routines SEGMENT (elles doivent être déclarées dans la partie IMPLEMENTATION).
• Concurrence : c'est comme dans la version III.0. L'utilisateur peut déclarer un PROCESS étant déclaré comme une procédure, mais étant démarré par le START intrinsèque de l'UCSD. Une fois qu'un processus est démarré, il semble s'exécuter simultanément avec le programme hôte et (éventuellement) d'autres processus, jusqu'à ce qu'il soit terminé. Le type prédéclaré SEMAPHORE a été introduit pour faciliter la synchronisation des processus ; Les SEMAPHORES peuvent être manipulés avec les intrinsèques SIGNAL et WAIT.

• Internes : les P-code ont été légèrement modifiés et la gestion de la mémoire d'exécution a changé. Plutôt que d'être placé sur la pile, le code de procédure réside maintenant dans un «bassin de codes» résidant entre la pile et la mémoire de tas et est relocalisable. Le bassin de codes est une structure très flexible et permet de nombreux échanges d'exécution. De plus, les intrinsèques UCSD suivants ont été créés pour aider à la gestion de la mémoire au niveau du système : MEMLOCK, MEMSWAP, VARAVAIL, VARNEW, VARDISPOSE.
• Échange de disques : étant donné que le code est échangé plus fréquemment dans IV.0, un certain nombre de prompts ont été ajoutées demandant à l'utilisateur d'insérer un volume nécessaire.
• Incompatibilités : les pratiques suivantes (s'exécutant sous II.0, II.1 ou III.0) nécessitent une modification avant qu'un programme puisse s'exécuter sous la version IV.0 :
  • Dépendances de la structure des données système : De nombreuses structures de données système ont changé. Par conséquent, les programmes accédant directement à des éléments tels que SYSCOM, SIB,..., devront être modifiés - reportez-vous à la documentation interne.
  • Utilisation de l'entreposage de la mémoire de tas : Un programme ne peut pas supposer que la mémoire suivant immédiatement celle obtenue par un NEW est inoccupée et disponible.
  • De même, les appels consécutifs à NEW ne génèrent pas nécessairement une zone de mémoire contiguë. La pratique d'indexation au-delà de la limite séparant l'entreposage obtenu par des appels consécutifs à NEW échouera sous la version IV.0.
  • Les appels à MARK et RELEASE doivent être appariés correctement. La valeur du pointeur obtenue en appelant MARK ne doit pas être modifiée avant l'appel RELEASE. De plus, le pointeur obtenu à partir de MARK ne peut pas être utilisé comme pointeur de base pour les références d'entreposage.
  • Programmes étroitement ajustés : IV.0 utilise en général plus de mémoire lors de l'exécution que les versions précédentes, donc les programmes ayant été adaptés pour tenir dans la mémoire principale devront probablement être encore plus adaptés. La gestion améliorée de la mémoire dans IV.0 devrait rendre cette tâche plus facile que par le passé.