Université Lille1 - Sciences et Technologies MAD : une machine virtuelle vectorielle conséquences sur l'architecture des machines vectorielles MAD 004.35 Traitement vectoriel Text Electronic Thesis or Dissertation fr Cette thèse s'insère dans un projet de recherches visant l'informatique vectorielle, tant du point de vue programmation que du point de vue architecture des machines. Les aspects programmation du projet étudient une alternative à l'approche classique utilisant un langage scalaire associé à un vectoriseur. Nous nous intéressons à la définition d'outils autorisant l'expression d'algorithmes vectoriels de manière explicite, de manière indépendante de toute cible matérielle particulière. Cette approche résout les problèmes de portabilité d'une manière simple, les programmes ne faisant aucune référence à l'architecture sous-jacente. Pour que les programmes puissent être compilés d'une manière optimale, le langage donne la possibilité au programmeur d'exprimer la connaissance dont il dispose sur son algorithme, ainsi que sur les données traitées. Ces informations n'ont plus à être extraites des sources par un outil d'analyse (vectoriseur dans l'approche classique). La compilation repose sur l'utilisation d'une couche virtuelle (machine abstraite MAD et son langage Devil). Celle-ci est décrite dans ce document. A côté de ces aspects langages, nous nous intéressons aux aspects matériels des machines vectorielles. La définition dans notre langage de vecteurs originaux (autres que de simples tableaux) nous a mené à étudier la prise en compte des vecteurs au niveau matériel. Aussi, nous avons défini une mémoire contenant des vecteurs en tant que tels et y autorisant l'accès. Les définitions de cette mémoire et d'un processeur associé sont données. Enfin, en marge de ces travaux, face aux problèmes dus aux conflits d'accès aux données dans la mémoire des supercalculateurs, nous introduisons un modèle d'exécution des opérations vectorielles pipelinées dénommé traitement vectoriel désordonné (tvd). Dans ce modèle un conflit mémoire ne bloque pas nécessairement le port mémoire, et donc les pipelines qui y sont chaînés. Nous montrons l intérêt de ce modèle selon le taux de conflits. Par ailleurs, nous montrons que ce modèle est implantable assez facilement sur un processeur de type Cray application/pdf 1 : 1 Mo https://pepite-depot.univ-lille.fr/LIBRE/Th_Num/1991/50376-1991-80.pdf Preux Philippe 1900-01-01 059896353 1991LIL10030 1991-01-01 Informatique Université Lille1 - Sciences et Technologies 026404184 Doctorat non oui Dekeyser Jean-Luc 030972930 ddc:004 ASCII PDF 9999