FR3074931A1 - Architectures de processeur - Google Patents
Architectures de processeur Download PDFInfo
- Publication number
- FR3074931A1 FR3074931A1 FR1762068A FR1762068A FR3074931A1 FR 3074931 A1 FR3074931 A1 FR 3074931A1 FR 1762068 A FR1762068 A FR 1762068A FR 1762068 A FR1762068 A FR 1762068A FR 3074931 A1 FR3074931 A1 FR 3074931A1
- Authority
- FR
- France
- Prior art keywords
- architecture
- processor
- data
- instructions
- source code
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
- G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
- G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
- G06F15/7867—Architectures of general purpose stored program computers comprising a single central processing unit with reconfigurable architecture
- G06F15/7871—Reconfiguration support, e.g. configuration loading, configuration switching, or hardware OS
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/447—Target code generation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/47—Retargetable compilers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Advance Control (AREA)
- Executing Machine-Instructions (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
Un processeur (1) comprenant une unité de contrôle (3) et une pluralité d'unités de traitement (5) interagissant selon une architecture de fonctionnement imposée dynamiquement par l'uni té de contrôle parmi au moins deux des architectures suivantes et des combinaisons d'architectures suivantes : - une architecture à unique flux d'instructions et multiples flux de données (SIMD), - une architecture à multiples flux d'instructions et unique flux de données (MISD), - une architecture à multiples flux d'instructions et multiples flux de données (MIMD). L'architecture de fonctionnement est imposée dynamiquement par l'unité de contrôle selon : - des fonctions de configuration incluses dans un code machine, et/ou - des données à traiter et d'instructions de traitement courantes reçues en entrée du processeur.
Description
L’invention relève du domaine des processeurs, en particulier de leur fonctionnement intrinsèque.
Classiquement, les processeurs présentent une architecture définie lors de leur conception. L’architecture est au moins en partie définie par l’implémentation d’un jeu d’instructions machines que le processeur peut exécuter (ou ISA pour « Instruction Set Architecture »). Il est généralement admis que chaque structure connue peut être classée dans l’un des types (ou classes) suivants, définis selon la taxonomie de Flynn :
- Unique flux d’instructions et unique flux de données, ou SISD pour « Single Instruction Single Data » ;
- Unique flux d’instructions et multiples flux de données, ou SIMD pour « Single Instruction Multiple Data » ;
- Multiples flux d’instructions et unique flux de données, ou MISD pour « Multiple Instructions Single Data » ;
- Multiples flux d’instructions et multiples flux de données, ou MIMD pour «Multiple Instructions Multiple Data ».
Chacun de ces types d’architecture présente des avantages et des inconvénients connus. En fonction des applications prévues, le niveau de parallélisme entre les calculs diffère. Le choix d’une architecture rend généralement le processeur sur lequel elle est implémentée particulièrement efficace (rapide) pour certains calculs et lents pour d’autres. La sélection du type de processeur implique des compromis dans l’usage du processeur. Chaque type de processeur tend à être spécialisé dans certains calculs au détriment d’autres calculs pour lesquels il est moins performant.
L’invention vient améliorer la situation.
Il est proposé un processeur comprenant une unité de contrôle et une pluralité d’unités de traitement. Les unités de traitement interagissant selon une architecture de fonctionnement imposée dynamiquement par l’unité de contrôle parmi au moins deux des architectures suivantes et des combinaisons d’architectures suivantes :
- une architecture à unique flux d’instructions et multiples flux de données (SIMD),
- une architecture à multiples flux d’instructions et unique flux de données (MISD),
- une architecture à multiples flux d’instructions et multiples flux de données (MIMD). L’architecture de fonctionnement étant imposée dynamiquement par l’unité de contrôle selon :
- des fonctions de configuration incluses dans un code machine, et/ou
- des données à traiter et d’instructions de traitement courantes reçues en entrée du processeur.
Un tel processeur permet une adaptation dynamique et contextuelle de son fonctionnement interne. Lorsque les calculs à effectuer sont indépendants les uns des autres, ils peuvent être traités en parallèle, donc en même temps, par des unités de calculs distinctes les unes des autres. Le traitement de l’ensemble des calculs est accéléré. Lorsque les calculs à effectuer sont dépendants les uns des autres, alors un traitement en parallèle n’est pas adapté. Les calculs récursifs sont un exemple de calculs peu adaptés au traitement en parallèle : pour effectuer un calcul, le résultat d’un calcul précédent est nécessaire. Une ou plusieurs unités de calcul doivent exécuter des calculs de manière séquentielle, un cycle après l’autre. Un tel processeur est polyvalent. Un tel processeur présente une architecture variante au cours de l’exécution des calculs en fonction des calculs eux-mêmes.
Selon un autre aspect, il est proposé un procédé de compilation d’un code source, mis en œuvre par des moyens informatiques, comprenant les étapes suivantes :
- recevoir un code source en entrée,
- rechercher dans le code source :
- des données de configuration imposant une architecture de fonctionnement d’un processeur,
- des premières parties du code source correspondant à des instructions de traitement de données incluant des séquences d’opérations élémentaires en cascade, et
- des secondes parties du code source correspondant à des instructions de traitement de données incluant des opérations élémentaires indépendantes les unes des autres.
Ue procédé comprend en outre l’étape suivante :
- compiler le code source en un code machine.
Dans le cas où au moins une donnée de configuration imposant une architecture de fonctionnement d’un processeur a été identifiée et/ou dans le cas où au moins une première partie du code source et au moins une seconde partie du code source ont été identifiées, la compilation comprend l’inclusion dans le code machine de fonctions de configuration. Ues fonctions de configuration sont agencées pour imposer dynamiquement à un processeur exécutant le code machine une architecture parmi au moins deux des architectures suivantes et des combinaisons d’architectures suivantes :
- une architecture à unique flux d’instructions et multiples flux de données (SIMD),
- une architecture à multiples flux d’instructions et unique flux de données (MISD),
- une architecture à multiples flux d’instructions et multiples flux de données (MIMD).
Optionnellement, le procédé de compilation d’un code source comprend en outre la vérification du respect d’un ensemble de règles préétablies dans les instructions de traitement en entrée, les fonctions de configuration incluses dans le code machine au cours de la compilation étant en outre sélectionnées en fonction du respect ou du non-respect desdites règles.
Selon un autre aspect, il est proposé un procédé de gestion d’architecture d’un processeur, mis en œuvre par des moyens informatiques, comprenant les étapes suivantes :
- recevoir des données à traiter et des instructions de traitement en entrée du processeur, et
- imposer dynamiquement à au moins une unité de traitement du processeur une architecture de fonctionnement en fonction desdites données à traiter et des instructions de traitement reçues, les architectures de fonctionnement étant sélectionnées parmi au moins deux des architectures suivantes et combinaison des architectures suivantes :
- une architecture à unique flux d’instructions et multiples flux de données (SIMD),
- une architecture à multiples flux d’instructions et unique flux de données (MISD),
- une architecture à multiples flux d’instructions et multiples flux de données (MIMD).
Selon encore un autre aspect, il est proposé un support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un programme de compilation comprenant des instructions pour la mise en œuvre du procédé ci-avant. Selon encore un autre aspect, il est proposé un programme informatique de compilation comportant des instructions pour la mise en œuvre du procédé de compilation, lorsque ce programme est exécuté par un processeur.
Selon encore un autre aspect, il est proposé un support d’enregistrement non transitoire lisible par une unité de contrôle d’un processeur sur lequel est enregistré un jeu d’instructions machines pour la mise en œuvre d’un procédé de gestion d’architecture tel que ceux définis dans les présentes. Selon encore un autre aspect, il est proposé un jeu d’instructions machine pour la mise en œuvre du procédé de gestion d’architecture, lorsque ce jeu d’instructions machine est exécuté par l’unité de contrôle d’un processeur.
D’autres caractéristiques, détails et avantages de l’invention apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :
- la figure 1 montre partiellement une architecture d’un processeur selon l’invention,
- la figure 2 montre un mode de fonctionnement d’un processeur selon l’invention,
- la figure 3 montre un mode de fonctionnement d’un processeur selon l’invention, et
- la figure 4 montre un détail de fonctionnement d’un processeur selon l’invention.
Les dessins et la description ci-après contiennent, pour l’essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.
La figure 1 montre un processeur 1, parfois appelé unité centrale de traitement ou CPU pour « Central Processing Unit ». Le processeur 1 comprend :
- une unité de contrôle 3,
- une partie de calcul incluant une pluralité d’unités de traitement 5,
- une unité d’entrée-sortie 7, ou interface, et
- une unité mémoire 9.
De manière connue en soit, le processeur 1 reçoit par l’intermédiaire de l’unité d’entrée-sortie 7 des données à traiter (« data ») et des instructions de traitement (« instructions »). Les données et instructions sont stockées dans l’unité de mémoire 9. L’unité de mémoire 9 peut être divisée en plusieurs parties. Par exemple, l’unité de mémoire 9 comprend une partie données (ou « Data pool ») et une partie instructions (ou « Instruction pool »).
Chaque unité de traitement 5 effectue les calculs sur des données et selon des instructions issues de celles stockées dans l’unité de mémoire 9. L’unité de contrôle 3 impose à chaque unité de traitement 5 la manière d’effectuer les calculs élémentaires, notamment leur ordre, et attribut à chaque organe de calcul de l’unité de traitement 5 les opérations à exécuter.
Dans les exemples décrits ici, chaque unité de traitement 5, ou PU pour «Processing Unit», comprend plusieurs organes de calcul : les unités arithmétiques et logiques, ou AUU pour « Arithmetic-Logic Unit ». Chaque unité de traitement 5 comprend au moins une AUU et au moins un jeu de registres associé REG. Dans la suite et conformément aux figures, chaque unité de traitement 5 est numérotée de PU 0 à PU N. Chaque AUU est numérotée A.B, où « A » identifie l’unité de traitement PU A à laquelle l’AUU appartient et « B » est un identifiant de l’AUU parmi les autres AUU de l’unité de traitement PU A.
Le processeur 1 comprend au moins deux ALU réparties dans deux unités de traitement 5. Par exemple, chaque unité de traitement 5 comprend une unique ALU ou une pluralité d’AUU. Dans les exemples des figures 1 à 3, chaque unité de traitement 5 comprend quatre AUU numérotées 0 à 3. Uorsqu’une unité de traitement 5 comprend une pluralité d’AUU, l’unité de traitement 5 est dite multi-cœur.
Chaque AUU peut effectuer :
- des opérations arithmétiques sur des données entières (addition, soustraction, multiplication, division, etc.) ;
- des opérations arithmétiques sur des données flottantes (addition, soustraction, multiplication, division, inversion, racine carrée, logarithmes, trigonométrie, etc.) ;
- des opérations logiques (compléments à deux, « ET », « OU », « OU exclusif », etc.).
Ues unités de traitement 5 et l’unité de mémoire 9 interagissent selon l’une et/ou l’autre des trois architectures suivantes :
- une architecture à unique flux d’instructions et multiples flux de données (SIMD),
- une architecture à multiples flux d’instructions et unique flux de données (MISD),
- une architecture à multiples flux d’instructions et multiples flux de données (MIMD).
Un exemple d’une architecture SIMD est représentée en figure 2. Dans cet exemple, les unités de traitement 5 interagissent selon l’architecture SIMD. Ues données à traiter sont copiées (chargées) depuis l’unité de mémoire 9 sur chacun des jeux de registres REGO, REG 1, ..., REG N de l’unité de traitement 5 correspondante. Les ALU effectuent les calculs. Ues résultats sont écrits dans le jeu de registres REG 0, REG 1, ..., REG N. Puis, les résultats sont copiés depuis les jeux de registres REG 0, REG 1, ..., REG N dans l’unité de mémoire 9.
Dans cet exemple, les unités de traitement 5 n’échangent pas directement de données les unes avec les autres. Les ALU de chaque unité de traitement 5 traitent les données et effectuent des calculs indépendamment d’une unité de traitement 5 à une autre. Ue fonctionnement du processeur 1 est parallélisé au niveau des unités de traitement 5.
Dans l’exemple de la figure 2, les interactions entre les AUU ne sont pas représentées. Ainsi, alors que les unités de traitement 5 interagissent entre elles selon une architecture SIMD, les AUU d’une même unité de traitement interagissent selon l’architecture SIMD, comme cela est décrit ci-après relativement à la figure 4.
Un exemple de l’architecture MISD est représentée en figure 3. Dans cet exemple, les unités de traitement 5 interagissent selon l’architecture MISD. Les données sont copiées (chargées) depuis l’unité de mémoire 9 sur le jeu de registres d’une unique unité de traitement 5, ici le jeu de registres REG 0 de l’unité de traitement PU 0. Les ALU 0.0, 0.1, 0.2 et 0.3 effectuent des calculs. Les résultats sont écrits dans le jeu de registres REG 0. Puis, les résultats sont copiés depuis le jeu de registres REG 0 sur un jeu de registres d’une autre unité de traitement 5, ici sur le jeu de registres REG 1 de l’unité de traitement PU 1. A leur tour, les ALU 1.0, 1.1, 1.2 et 1.3 effectuent des calculs et les résultats sont écrits dans le jeu de registres REG 1. Ces opérations sont reproduites les unes à la suite des autres par chacune des unités de traitement 5 jusqu’à ce que les résultats soient écrits dans le jeu de registres de la dernière unité de traitement 5, soit ici le jeu de registres REG N de l’unité de traitement PU N. Puis, les résultats sont copiés depuis le dernier jeu de registres REG N dans l’unité de mémoire 9.
Dans cet exemple, les unités de traitement 5 échangent directement des données les unes avec les autres. Les ALU de chaque unité de traitement 5 effectuent des calculs sur des données qui sont elles-mêmes des résultats des calculs mis en œuvre par les autres unités de traitement 5. Le fonctionnement du processeur 1 n’est pas parallélisé au niveau des unités de traitement 5. Au contraire, les unités de traitement 5 présentent un fonctionnement en série, ou en cascade. Ce type de fonctionnement est par exemple adapté aux calculs dits récursifs. Les opérations mises en œuvre par les unités de traitement 5 peuvent être les mêmes mais sont appliquées à des données qui sont chaque fois différentes. En variante, les instructions pourraient aussi être différentes les unes des autres et les données être, elles-aussi, différentes les unes des autres.
Dans l’exemple de la figure 3, comme dans celui de la figure 2, les interactions entre les ALU ne sont pas représentées.
En figure 4, les fonctionnements de deux PU sont représentés.
L’unité de traitement PU X comprend quatre ALU. Les ALU de l’unité de traitement PU X interagissent entre elles. Les données sont chargées depuis le jeu de registres REGX sur chacune des ALU X.0, X.l, X.2, X.3 de l’unité de traitement PUX. Les ALU effectuent les calculs. Les résultats sont ensuite écrits dans le jeu de registres REG X.
Les ALU n’échangent pas directement de données les unes avec les autres.
Dans l’exemple de la figure 4, les architectures au niveau des unités de traitement 5 ne sont pas représentées. Ainsi, les unités de traitement 5 peuvent interagir selon l’une et/ou l’autre des architectures SIMD, MISD et MIMD, comme cela est décrit ci-avant relativement aux figures 2 et 3. Autrement dit, l’exemple de la PU X est compatible avec l’exemple de la figure 2 et avec l’exemple de la figure 3.
Les architectures de fonctionnement peuvent être imposées dynamiquement par l’unité de contrôle 3 en fonction des données à traiter et des instructions courantes reçues en entrée du processeur 1. Une telle adaptation dynamique des architectures peut être mise en œuvre dès le stade de la compilation, en adaptant les instructions machines générées par le compilateur en fonction du type de données à traiter et des instructions lorsque le type de données à traiter et les instructions peuvent être déduites du code source. Une telle adaptation peut aussi être mise en œuvre seulement au niveau du processeur lorsqu’il exécute un code machine classique lorsque ce processeur est programmé pour mettre en œuvre un ensemble d’instructions de configuration fonction des données à traiter et des instructions courantes reçues.
Ci-dessous est reproduit un exemple de code informatique des calculs à effectuer. Cet extrait de code correspond par exemple à des instructions d’un code source à mettre en œuvre par le processeur 1.
void processingO {
matrix A(4,4);
matrix B(4,4);
matrix C(4,4);
C=A *B;//(1)
C = C + B; // (2) matrix D (4,4);
D =inv(A); //(3) }
Dans l’exemple, le processeur comprend quatre unités de traitement PU, chaque unité de traitement PU comprend quatre unités arithmétiques et logiques ALU. Dans l’exemple, la multiplication matricielle est traitée en premier lieu tandis que l’addition matricielle est traitée en second lieu. Le compilateur est capable de traiter des opérations matricielles en les décomposant en opérations élémentaires. Pour chaque opération matricielle, les opérations élémentaires qui la compose sont indépendantes les unes des autres. Autrement dit, le résultat d’une opération élémentaire est inutile pour mettre en œuvre une autre opération élémentaire. Les opérations élémentaires peuvent donc être mises en œuvre en parallèle les unes des autres. L’addition de deux matrices de dimensions 4 par 4 nécessite 16 opérations élémentaires (addition). Cette addition matricielle, soit les 16 opérations élémentaires, peuvent être exécutées en un seul cycle. La multiplication des deux matrices de dimensions 4 par 4 nécessite 64 opérations élémentaires (multiplication + accumulation). Cette multiplication matricielle, soit les 64 opérations élémentaires, sont donc exécutées au minimum en quatre cycles.
L’opération référencée « (3) » (inversion matricielle) comprend des opérations élémentaires dépendantes les unes des autres. Les résultats de certaines opérations élémentaires sont nécessaires à la mise en œuvre d’autres opérations élémentaires. Un traitement en parallèle n’est pas adapté. L’algorithme d’inversion doit donc être décomposé en N étapes de traitement. Chaque étape peut être effectuée sur une ALU en un cycle, mais avec des données distinctes les unes des autres et des traitements distincts les uns des autres.
étape_l —> étape_2 —> étape_3 —> étape_4 —> étape_5 —> .... —» étape_N
Pour la mise en œuvre des opérations « (1) » et « (2) », le processeur 1 adopte une architecture
SIMD. Pour la mise en œuvre de l’opération « (3) », le processeur 1 adopte une architecture MISD.
Par exemple, l’opération « (3) » comprend neuf étapes (N = 9). Trois itérations, ou trois cycles, sont donc nécessaires. Chaque cycle est mis en œuvre par une unité de traitement PU. U’affectation des N étapes d’un cycle aux AUU de l’unité de traitement PU se fait, par exemple, de la manière suivante :
Cycle 1 :
AUU 0 étape_l
AUU 1 étape_2
AUU 2 étape_3
AUU 3 étape_4
Cycle 2 :
AUU 0 étape_5
ALU 1 —> étape_6
ALU 2 —> étape_7
ALU 3 étape_8
Cycle 3 :
ALU 0 —> étape_9
Au cours du cycle 3, les ALU 1, ALU 2 et ALU 3 sont inutilisées.
Comme indiqué précédemment, les architectures de fonctionnement peuvent être imposées dynamiquement par l’unité de contrôle 3 en fonction des données et instructions courantes reçues en entrée du processeur 1. Cela couvre deux cas.
Dans un premier cas, l’architecture et l’affectation des ressources sont fixées lors de la compilation. Autrement dit, un développeur d’un programme tiers (autre que ceux régissant le fonctionnement intrinsèque du processeur) peut inclure dans le code source des instructions de configuration spécifiques. Les instructions spécifiques sont transcrites en langage cible (lors de la compilation) en instructions spécifiques (code machine) reconnues par l’unité de contrôle 3. A réception, sur le processeur 1, l’unité de contrôle 3 impose des architectures aux unités de traitement 5 de manière prédéfinie par les instructions. Dans ce cas, la responsabilité de l’optimisation du fonctionnement du processeur peut être laissée au créateur du programme tiers. En fonction dudit programme, le programmeur est libre d’imposer ou non un fonctionnement particulier du processeur, c’est-à-dire ici une architecture choisie parmi SISD, MISD, MIMD ou une combinaison de celles-ci.
Dans un deuxième cas, l’architecture et l’affectation des ressources sont fixées de manière préétablie en fonction d’un jeu d’instructions machines implémenté dans le processeur. Un tel jeu d’instructions est généralement implémenté avant commercialisation et utilisation du processeur. Le jeu d’instructions machine n’est pas destiné à être modifié par les utilisateurs du processeur. Dans ce deuxième cas, à réception des instructions sur le processeur 1, l’unité de contrôle 3 met en œuvre un procédé de gestion d’architecture, ou de configuration des architectures, préalablement à la mise en œuvre des instructions reçues en entrée. Par exemple, l’unité de contrôle 3 transmet au préalable à chaque unité de traitement PU des données de configuration propres à chaque unité de traitement PU. Chacun des jeux de données de configuration est stocké dans un registre de configuration accessible à l’unité de traitement correspondante. Ensuite, les unités de traitement PU reçoivent des instructions de traitement génériques (communes à toutes les PU) d’un bus d’instruction. Chaque PU met en œuvre les instructions de traitement d’une manière qui varie en fonction des données de configuration préalablement reçues et stockées dans le registre de configuration. Autrement dit, chaque PU interprète les instructions de traitement génériques au moyen des données de configuration pour adapter le traitement à mettre en œuvre. Ue deuxième cas permet d’introduire une flexibilité dans le contrôle. Des instructions génériques peuvent être transmises à toutes les PU, quelle que soit l’architecture à adopter (SIMD, MISD, MIMD). Ua transmission au préalable des données de configuration permet de sélectionner l’architecture adoptée effectivement par les PU à réception d’instructions génériques.
Dans les deux cas, les architectures peuvent être dynamiques, c’est-à-dire évoluer au fil des étapes d’exécution des instructions reçues, notamment en fonction de la nature des calculs à effectuer. Par exemple, une architecture SIMD peut être imposée par défaut et une architecture MISD être imposée pour les calculs récursifs. Ues deux cas sont compatibles : le processeur 1 peut être agencé pour mettre en œuvre un procédé de gestion des architectures en fonction d’instructions de configuration spécifiques reçues (contenues dans le code machine issu de la compilation) et pour mettre en œuvre un procédé de gestion des architectures selon un jeu d’instructions machines en l’absence ou en complément d’instructions de configuration spécifiques parmi les instructions reçues en entrée.
Selon un autre point de vue, il peut être considéré qu’en mettant en œuvre des instructions de configuration destinées à adapter à la volée l’architecture du processeur 1, l’unité de contrôle 3 transforme les instructions de traitement reçues de manière usuelle en entrée en instructions adaptées ou « macro-instructions » (ou « custom instructions »). Ues instructions adaptées contiennent à la fois des instructions de traitement et des instructions de configuration. Uorsque les instructions adaptées transmises à chacune des unités de traitement 5 sont toutes identiques, le processeur fonctionne en mode SIMD. Ues unités de traitement 5 effectuent toutes les mêmes opérations sur des données à traiter différentes. Uorsque les instructions adaptées transmises à chacune des unités de traitement 5 sont différentes les unes des autres, le processeur fonctionne en mode MISD ou MIMD. Ues unités de traitement 5 effectuent des opérations distinctes les unes des autres sur des données à traiter identiques (MISD) ou différentes (MIMD).
Ci-dessous est reproduit un deuxième exemple de code informatique de calculs à effectuer : void processingO {
matrix A(4,4) [2];
matrix D (4,4) [2];
D = inv(A); //(3) }
Dans l’exemple est défini un tableau de matrices, chaque matrice étant de dimension 4 par 4, le tableau étant de taille 2 (comprenant deux matrices). La fonction notée « inv » sur un tableau de matrices consiste à inverser chaque élément du tableau, c’est-à-dire inverser chacune des deux matrices de dimension 4 par 4. Comme dans l’exemple précédent, le processeur comprend quatre ALU.
L’affectation des N étapes aux ALU se fait, par exemple, de la manière suivante : cycle 1 : étapes 1 à 4 pour la matrice A[0];
cycle 2 : étapes 1 à 4 pour la matrice A[ 1];
cycle 3 : étapes 5 à 8 pour la matrice A[0];
cycle 4 : étapes 5 à 8 pour la matrice A[ 1];
cycle 5 : étape 9 pour la matrice A [0] ;
cycle 6 : étape 9 pour la matrice A[l].
On peut également optimiser l’exécution de la fonction « inv » en regroupant les cycles 5 et 6 en un cycle commun. Ainsi, une unique PU est nécessaire pour mettre en œuvre l’étape 9 sur les deux matrices. En variante, l’ALU 0 peut être affectée aux calculs relatifs à la matrice A[0] tandis que l’ALU 1 est affectée aux calculs relatifs à la matrice A[ 1].
L’attribution de chaque ALU à des opérations peut être prévue dès la compilation si au moins une partie des données est connue à ce stade, notamment la taille des matrices et la taille du tableau. L’attribution peut être réalisée de manière dynamique. Par exemple, l’attribution peut être imposée par l’unité de contrôle 3 en fonction d’un jeu d’instructions machines implémenté sur le processeur 1. Dans ce cas, le jeu d’instructions machines, est enregistré sur un support d’enregistrement non transitoire (par exemple une partie de l’unité mémoire 9) lisible par l’unité de contrôle 3 pour mettre en œuvre un procédé de gestion de l’architecture du processeur 1.
Par exemple, l’unité de contrôle 3 est agencée pour imposer à une unité de traitement 5 la mise en œuvre d’un premier ensemble d’opérations par l’ensemble des ALU, puis le premier ensemble d’opérations est réitéré sur chacun des éléments du tableau (chacune des matrices dans l’exemple précédent). Ensuite, le nombre d’opérations réalisables en parallèle (non interdépendantes) est estimé. Par exemple, le nombre de ressources (le nombre d’ALU) est divisé par le nombre d’opérations à mettre en œuvre. Enfin, l’attribution des opérations à chaque ALU est effectuée de sorte que certaines au moins des opérations soient réalisées en parallèle les unes des autres par des AUU distinctes d’unités de traitement 5 distinctes.
Ainsi, l’architecture des unités de traitement 5 peut varier au cours du temps. Au cours d’un traitement, l’architecture des unités de traitement 5 peut alterner entre SIMD, MISD et MIMD.
U’invention ne se limite pas aux exemples de processeurs décrits ci-avant, seulement à titre 10 d’exemple, mais elle englobe toutes les variantes que pourra envisager l’homme de l’art dans le cadre de la protection recherchée. U’invention concerne aussi un jeu d’instructions machines implémentable dans un processeur pour obtenir un tel processeur, l’implémentation d’un tel jeu d’instructions machines sur un processeur, le procédé de gestion d’architecture de processeur mis en œuvre par le processeur, le programme informatique comprenant le jeu d’instructions 15 machines correspondant, ainsi que le support d’enregistrement sur lequel est enregistré informatiquement un tel jeu d’instructions machines.
Claims (8)
- Revendications1. Processeur (1) comprenant une unité de contrôle (3) et une pluralité d’unités de traitement (5), les unités de traitement (5) interagissant selon une architecture de fonctionnement imposée dynamiquement par l’unité de contrôle parmi au moins deux des architectures suivantes et des combinaisons d’architectures suivantes :- une architecture à unique flux d’instructions et multiples flux de données (SIMD),- une architecture à multiples flux d’instructions et unique flux de données (MISD),- une architecture à multiples flux d’instructions et multiples flux de données (MIMD), l’architecture de fonctionnement étant imposée dynamiquement par l’unité de contrôle selon :- des fonctions de configuration incluses dans un code machine, et/ou- des données à traiter et d’instructions de traitement courantes reçues en entrée du processeur.
- 2. Procédé de compilation d’un code source, mis en œuvre par des moyens informatiques, comprenant les étapes suivantes :- recevoir un code source en entrée,- rechercher dans le code source :- des données de configuration imposant une architecture de fonctionnement d’un processeur,- des premières parties du code source correspondant à des instructions de traitement de données incluant des séquences d’opérations élémentaires en cascade, et- des secondes parties du code source correspondant à des instructions de traitement de données incluant des opérations élémentaires indépendantes les unes des autres, le procédé comprenant en outre l’étape suivante :- compiler le code source en un code machine, dans le cas où au moins une donnée de configuration imposant une architecture de fonctionnement d’un processeur a été identifiée et/ou dans le cas où au moins une première partie du code source et au moins une seconde partie du code source ont été identifiées, la compilation comprend l’inclusion dans le code machine de fonctions de configuration, lesdites fonctions de configuration étant agencées pour imposer dynamiquement à un processeur exécutant le code machine une architecture parmi au moins deux des architectures suivantes et des combinaisons d’architectures suivantes :- une architecture à unique flux d’instructions et multiples flux de données (SIMD),- une architecture à multiples flux d’instructions et unique flux de données (MISD),- une architecture à multiples flux d’instructions et multiples flux de données (MIMD).
- 3. Procédé selon la revendication 2, comprenant en outre la vérification du respect d’un ensemble de règles préétablies dans les instructions de traitement en entrée, les fonctions de configuration incluses dans le code machine au cours de la compilation étant en outre sélectionnées en fonction du respect ou du non-respect desdites règles.
- 4. Support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un programme de compilation comprenant des instructions pour la mise en œuvre du procédé selon l’une des revendications 2 et 3.
- 5. Programme informatique de compilation comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 2 et 3, lorsque ce programme est exécuté par un processeur.
- 6. Procédé de gestion d’architecture d’un processeur (1), mis en œuvre par des moyens informatiques, comprenant les étapes suivantes :- recevoir des données à traiter et des instructions de traitement en entrée du processeur, et- imposer dynamiquement à au moins une unité de traitement (5) du processeur une architecture de fonctionnement en fonction desdites données à traiter et des instructions de traitement reçues, les architectures de fonctionnement étant sélectionnées parmi au moins deux des architectures suivantes et combinaison des architectures suivantes :- une architecture à unique flux d’instructions et multiples flux de données (SIMD),- une architecture à multiples flux d’instructions et unique flux de données (MISD),- une architecture à multiples flux d’instructions et multiples flux de données (MIMD).
- 7. Support d’enregistrement non transitoire lisible par une unité de contrôle (3) d’un processeur (1) sur lequel est enregistré un jeu d’instructions machine pour la mise en œuvre du procédé selon la revendication 6.
- 8. Jeu d’instructions machine pour la mise en œuvre du procédé selon la revendication 6, lorsque ce jeu d’instructions machine est exécuté par l’unité de contrôle d’un processeur.
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1762068A FR3074931B1 (fr) | 2017-12-13 | 2017-12-13 | Architectures de processeur |
| US16/771,376 US20210173809A1 (en) | 2017-12-13 | 2018-11-27 | Processor architectures |
| PCT/FR2018/052995 WO2019115902A1 (fr) | 2017-12-13 | 2018-11-27 | Architectures de processeur |
| CN201880080771.2A CN111512296A (zh) | 2017-12-13 | 2018-11-27 | 处理器架构 |
| EP18833085.6A EP3724779A1 (fr) | 2017-12-13 | 2018-11-27 | Architectures de processeur |
| KR1020207020211A KR20200121788A (ko) | 2017-12-13 | 2018-11-27 | 프로세서 아키텍처들 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1762068A FR3074931B1 (fr) | 2017-12-13 | 2017-12-13 | Architectures de processeur |
| FR1762068 | 2017-12-13 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3074931A1 true FR3074931A1 (fr) | 2019-06-14 |
| FR3074931B1 FR3074931B1 (fr) | 2020-01-03 |
Family
ID=61802089
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1762068A Active FR3074931B1 (fr) | 2017-12-13 | 2017-12-13 | Architectures de processeur |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20210173809A1 (fr) |
| EP (1) | EP3724779A1 (fr) |
| KR (1) | KR20200121788A (fr) |
| CN (1) | CN111512296A (fr) |
| FR (1) | FR3074931B1 (fr) |
| WO (1) | WO2019115902A1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5475856A (en) * | 1991-11-27 | 1995-12-12 | International Business Machines Corporation | Dynamic multi-mode parallel processing array |
| US5903771A (en) * | 1996-01-16 | 1999-05-11 | Alacron, Inc. | Scalable multi-processor architecture for SIMD and MIMD operations |
| US20090282223A1 (en) * | 2008-05-07 | 2009-11-12 | Lyuh Chun-Gi | Data processing circuit |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5765011A (en) * | 1990-11-13 | 1998-06-09 | International Business Machines Corporation | Parallel processing system having a synchronous SIMD processing with processing elements emulating SIMD operation using individual instruction streams |
| US5933642A (en) * | 1995-04-17 | 1999-08-03 | Ricoh Corporation | Compiling system and method for reconfigurable computing |
| US8099777B1 (en) * | 2004-08-26 | 2012-01-17 | Rockwell Collins, Inc. | High security, multi-level processor and method of operating a computing system |
| GB2423604B (en) * | 2005-02-25 | 2007-11-21 | Clearspeed Technology Plc | Microprocessor architectures |
| US8156474B2 (en) * | 2007-12-28 | 2012-04-10 | Cadence Design Systems, Inc. | Automation of software verification |
| WO2014142704A1 (fr) * | 2013-03-15 | 2014-09-18 | Intel Corporation | Procédés et appareil pour compiler des instructions pour une architecture de processeur à vecteurs de pointeurs d'instruction |
| US10055228B2 (en) * | 2013-08-19 | 2018-08-21 | Shanghai Xinhao Microelectronics Co. Ltd. | High performance processor system and method based on general purpose units |
| KR20160061701A (ko) * | 2014-11-24 | 2016-06-01 | 삼성전자주식회사 | 서로 다른 정확도를 갖는 연산기들을 이용하여 데이터를 처리하는 방법 및 장치 |
| JP6427055B2 (ja) * | 2015-03-31 | 2018-11-21 | 株式会社デンソー | 並列化コンパイル方法、及び並列化コンパイラ |
-
2017
- 2017-12-13 FR FR1762068A patent/FR3074931B1/fr active Active
-
2018
- 2018-11-27 EP EP18833085.6A patent/EP3724779A1/fr active Pending
- 2018-11-27 US US16/771,376 patent/US20210173809A1/en active Pending
- 2018-11-27 CN CN201880080771.2A patent/CN111512296A/zh active Pending
- 2018-11-27 WO PCT/FR2018/052995 patent/WO2019115902A1/fr unknown
- 2018-11-27 KR KR1020207020211A patent/KR20200121788A/ko unknown
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5475856A (en) * | 1991-11-27 | 1995-12-12 | International Business Machines Corporation | Dynamic multi-mode parallel processing array |
| US5903771A (en) * | 1996-01-16 | 1999-05-11 | Alacron, Inc. | Scalable multi-processor architecture for SIMD and MIMD operations |
| US20090282223A1 (en) * | 2008-05-07 | 2009-11-12 | Lyuh Chun-Gi | Data processing circuit |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3074931B1 (fr) | 2020-01-03 |
| KR20200121788A (ko) | 2020-10-26 |
| US20210173809A1 (en) | 2021-06-10 |
| EP3724779A1 (fr) | 2020-10-21 |
| CN111512296A (zh) | 2020-08-07 |
| WO2019115902A1 (fr) | 2019-06-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11106437B2 (en) | Lookup table optimization for programming languages that target synchronous digital circuits | |
| EP3912025B1 (fr) | Langage et compilateur pour la génération d'un circuit numerique synchrone qui maintient l'ordre d'exécution des fils | |
| FR3035243A1 (fr) | Placement d'une tache de calcul sur un processeur fonctionnellement asymetrique | |
| FR2819073A1 (fr) | Microarchitecture d'unite arithmetique | |
| WO2020150002A1 (fr) | Mise en correspondance de constructions logicielles avec des circuits numériques synchrones qui ne se bloquent pas | |
| EP1290554A1 (fr) | Systeme informatique modulaire et procede associe | |
| EP2860656B1 (fr) | Procédé d'exécution par un microprocesseur d'un code binaire polymorphique d'une fonction prédéterminée | |
| FR3074931A1 (fr) | Architectures de processeur | |
| WO2013110801A1 (fr) | Procédé de compilation, programme d'ordinateur et système informatique | |
| Sengupta | Julia High Performance | |
| FR3071642B1 (fr) | Procede d'execution d'un programme par un appareil electronique | |
| WO2020002782A1 (fr) | Accès mémoire de processeurs | |
| EP3314421B1 (fr) | Procédé d'exécution d'un programme d'ordinateur comportant une fonction paramétrée | |
| Najjar et al. | ROCCC 2.0 | |
| WO2014195141A1 (fr) | Accelerateur materiel pour la manipulation d'arbres rouges et noirs | |
| EP1082656A1 (fr) | Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles | |
| Ejjaaouani | Design of the InKS programming model for the separation of algorithm and optimizations in simulation codes: application to the 6D Vlasov-Poisson system solving | |
| WO2020002783A1 (fr) | Architecture de processeur asynchrone | |
| FR3121242A1 (fr) | Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé | |
| FR3103590A1 (fr) | Procédé de construction d’une signature caractéristique des accès, par un microprocesseur, à une mémoire | |
| FR2996654A1 (fr) | Procede de generation d'un graphe a partir d'un code source ecrit en un langage de description de processus flot de donnees | |
| FR2914452A1 (fr) | Procede et un dispositif d'evaluation d'au moins un predicat d'une expression sur des elements d'un document structure. | |
| FR2919081A1 (fr) | Implementation de calculs pour processeurs |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLSC | Publication of the preliminary search report |
Effective date: 20190614 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |