EP3724779A1 - Architectures de processeur - Google Patents

Architectures de processeur

Info

Publication number
EP3724779A1
EP3724779A1 EP18833085.6A EP18833085A EP3724779A1 EP 3724779 A1 EP3724779 A1 EP 3724779A1 EP 18833085 A EP18833085 A EP 18833085A EP 3724779 A1 EP3724779 A1 EP 3724779A1
Authority
EP
European Patent Office
Prior art keywords
architecture
processor
instructions
data
architectures
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.)
Pending
Application number
EP18833085.6A
Other languages
German (de)
English (en)
Inventor
Khaled Maalej
Trung Dung NGUYEN
Julien Schmitt
Pierre-Emmanuel BERNARD
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vsora
Original Assignee
Vsora
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Vsora filed Critical Vsora
Publication of EP3724779A1 publication Critical patent/EP3724779A1/fr
Pending legal-status Critical Current

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/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
    • 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
    • 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

Definitions

  • the invention relates to the field of processors, in particular their intrinsic operation.
  • processors have a defined architecture when they are designed.
  • the architecture is at least partly defined by the implementation of a set of machine instructions that the processor can execute (or ISA for "Instruction Set Architecture"). It is generally accepted that each known structure can be classified into one of the following types (or classes), defined according to the Flynn taxonomy:
  • MISD Multiple Instructions Single Data
  • MIMD Multiple Instructions Multiple Data
  • the invention improves the situation.
  • a processor comprising a control unit and a plurality of processing units. Processing units interacting according to an operating architecture dynamically imposed by the control unit among at least two of the following architectures and combinations of architectures:
  • MIMD multi-flow instruction architecture and unique data flow
  • the operating architecture is dynamically imposed by the control unit according to:
  • Such a processor allows dynamic and contextual adaptation of its internal functioning.
  • the calculations to be carried out are independent of each other, they can be processed in parallel, therefore at the same time, by calculation units that are distinct from one another. The processing of all calculations is accelerated.
  • a parallel processing is not suitable.
  • Recursive calculations are an example of calculations that are not very suitable for parallel processing: to perform a calculation, the result of a previous calculation is necessary. Line or multiple calculation units must perform calculations sequentially one cycle after the other.
  • Lin such processor is versatile. Lin such processor has a variant architecture during the execution of the calculations according to the calculations themselves.
  • the method further comprises the following step:
  • the compilation includes the inclusion in the machine code of configuration functions.
  • the configuration functions are arranged to dynamically impose on a processor executing the machine code an architecture among at least two of the following architectures and combinations of architectures: - architecture with a single flow of instructions and multiple data flows (SIMD),
  • MISD multi-flow instruction architecture and unique data flow
  • MIMD multiple flow instruction architecture and multiple data flows
  • the method of compiling a source code further comprises verifying compliance with a set of pre-established rules in the input processing instructions, the configuration functions included in the machine code during the compilation being furthermore selected according to the respect or the non-respect of these rules.
  • processor management method of a processor implemented by computer means, comprising the following steps:
  • an operating architecture as a function of said data to be processed and received processing instructions, the operating architectures being selected from at least two of the following architectures and combination of the following architectures:
  • MISD multi-flow instruction architecture and unique data flow
  • MIMD multiple flow instruction architecture and multiple data flows
  • a non-transitory recording medium readable by a computer on which is recorded a compilation program comprising instructions for the implementation of the method above.
  • a compilation computer program comprising instructions for implementing the compilation method, when this program is executed by a processor.
  • a non-transitory recording medium readable by a control unit of a processor on which is recorded a set of machine instructions for the implementation of an architectural management method. as defined herein.
  • a set of machine instructions for implementing the architecture management method when the set of machine instructions is executed by the control unit of a processor.
  • FIG. 1 partially shows an architecture of a processor according to the invention
  • FIG. 2 shows a mode of operation of a processor according to the invention
  • FIG. 3 shows a mode of operation of a processor according to the invention
  • FIG. 4 shows a detail of operation of a processor according to the invention.
  • FIG. 1 shows a processor 1, sometimes called the central processing unit or 041 for "Central Processing Unit".
  • the processor 1 comprises:
  • the processor 1 receives via the input-output unit 7 data to be processed ("data") and processing instructions ("instructions").
  • data data to be processed
  • processing instructions instructions
  • the data and instructions are stored in the memory unit 9.
  • the memory unit 9 can be divided into several parts.
  • the memory unit 9 comprises a data part (or “data pool”) and an instruction part (or “instruction pool”).
  • Each processing unit 5 performs the calculations on data and according to instructions derived from those stored in the memory unit 9.
  • the control unit 3 imposes on each processing unit 5 the manner of carrying out the elementary calculations, in particular their order, and attribute to each calculating unit of the processing unit the operations to be performed.
  • each processing unit 5, or PLF for "Processing Unit” comprises several computing units: the arithmetic and logical units, or ALUs for "Arithmetic-Logic Unit”.
  • Each processing unit 5 comprises at least one ALU and at least one set of associated registers REG.
  • each processing unit 5 is numbered from PU 0 to PU N.
  • Each ALU is numbered AB, where "A" identifies the processing unit PU A to which the ALU belongs and "B”. is an identifier of the ALU among the other ALUs of the PU A processing unit.
  • the processor 1 comprises at least two ALUs distributed in two processing units 5.
  • each processing unit 5 comprises a single ALU or a plurality of ALUs.
  • each processing unit 5 comprises four ALUs numbered 0 to 3.
  • the processing unit 5 is called multi-core.
  • Each ALU can perform:
  • the processing units 5 and the memory unit 9 interact according to one and / or the other of the following three architectures:
  • MISD multi-flow instruction architecture and unique data flow
  • MIMD multiple flow instruction architecture and multiple data flows
  • FIG. 2 An example of a SIMD architecture is shown in FIG. 2.
  • the processing units 5 interact according to the SIMD architecture.
  • the data to be processed are copied (loaded) from the memory unit 9 to each of the reg register sets REG 0, REG 1, ..., REG N of the corresponding processing unit 5.
  • ALUs perform the calculations.
  • the results are written in the register set REG 0, REG 1, ..., REG N.
  • the results are copied from the register sets REG 0, REG 1, ..., REG N in the unit of memory 9.
  • the processing units 5 do not exchange data directly with each other.
  • the ALUs of each processing unit process the data and perform calculations independently of one processing unit 5 to another.
  • the operation of the processor 1 is parallelized at the level of the processing units 5.
  • FIG. 3 An example of the MISD architecture is shown in FIG. 3.
  • the processing units 5 interact according to the MISD architecture.
  • the data is copied (loaded) from the memory unit 9 to the set of registers of a single processing unit 5, here the register set REG 0 of the processing unit PU 0.
  • the ALUs 0.0, 0.1, 0.2 and 0.3 perform calculations.
  • the results are written in the register set REG 0.
  • the results are copied from the register set REG 0 onto a set of registers of another processing unit 5, here on the register set REG 1 of the PU processing unit 1.
  • ALUs 1.0, 1.1, 1.2 and 1.3 perform calculations and the results are written in the REG 1 register set. These operations are reproduced one by one by each of the units 5 until the results are written in the register set of the last processing unit 5, here the register set REG N of the processing unit PU N. Then, the results are copied from the The last set of registers REG N in the memory unit 9.
  • the processing units 5 exchange data directly with each other.
  • the ALUs of each processing unit 5 perform calculations on data which are themselves the results of the calculations implemented by the other processing units 5.
  • the operation of the processor 1 is not parallelized at the level of the processing units 5.
  • the processing units 5 have series or cascade operation. This type of operation is for example adapted to so-called recursive calculations.
  • the operations implemented by the processing units 5 may be the same but are applied to data which are each time different. Alternatively, the instructions could also be different from each other and the data also be different from each other. In the example of Figure 3, as in that of Figure 2, the interactions between the ALU are not represented.
  • the operations of two PUs are represented.
  • the PU X processing unit comprises four ALUs.
  • the ALUs of the PU X processing unit interact with each other.
  • the data is loaded from the register set REG X onto each of the ALUs X.0, X1, X.2, X.3 of the processing unit PU X.
  • the ALUs perform the calculations.
  • the results are then written to the REG X register set.
  • ALUs do not exchange data directly with each other.
  • the architectures at the level of the processing units 5 are not represented.
  • the processing units 5 can interact according to one and / or the other of the SIMD, MISD and MIMD architectures, as described above with respect to FIGS. 2 and 3.
  • the example of the PU X is compatible with the example of Figure 2 and with the example of Figure 3.
  • the operating architectures can be imposed dynamically by the control unit 3 according to the data to be processed and the current instructions received at the input of the processor 1.
  • Such dynamic adaptation of the architectures can be implemented as soon as the compilation stage, adapting the machine instructions generated by the compiler according to the type of data to be processed and instructions when the type of data to be processed and the instructions can be deduced from the source code.
  • Such an adaptation can also be implemented only at the processor level when it executes a conventional machine code when this processor is programmed to implement a set of configuration instructions depending on the data to be processed and the current instructions received.
  • This code extract corresponds for example to instructions of a source code to be implemented by the processor 1.
  • the processor comprises four processing units PU, each processing unit PU comprises four arithmetic and logical units ALU.
  • the matrix multiplication is processed first while the matrix addition is processed Secondly.
  • the compiler is able to process matrix operations by breaking them down into elementary operations. For each matrix operation, the elementary operations that compose it are independent of each other. In other words, the result of an elementary operation is useless for implementing another elementary operation. The elementary operations can therefore be implemented in parallel with each other.
  • the addition of two matrices of dimensions 4 by 4 requires 16 elementary operations (addition). This matrix addition, ie the 16 elementary operations, can be executed in a single cycle.
  • the multiplication of the two matrices of dimensions 4 by 4 requires 64 elementary operations (multiplication + accumulation). This matrix multiplication, ie the 64 elementary operations, are thus executed at least in four cycles.
  • processor 1 adopts a SIMD architecture.
  • processor 1 adopts a MISD architecture.
  • Each cycle is implemented by a PU processing unit.
  • the assignment of the N stages of a cycle to the ALUs of the processing unit PU is, for example, as follows:
  • ALU 1, ALU 2 and ALU 3 are unused.
  • the operating architectures can be imposed dynamically by the control unit 3 according to the data and current instructions received at the input of the processor 1. This covers two cases.
  • the architecture and resource allocation are fixed during compilation.
  • a developer of a third-party program (other than those governing the intrinsic operation of the processor) may include specific configuration instructions in the source code.
  • the specific instructions are transcribed in target language (during compilation) in specific instructions (machine code) recognized by the control unit 3.
  • the control unit 3 On reception, on the processor 1, the control unit 3 imposes architectures on the control units. treatment 5 in a predefined manner by the instructions.
  • the responsibility for optimizing the operation of the processor may be left to the creator of the third-party program.
  • the programmer is free to impose or not a particular operation of the processor, that is to say here an architecture selected from SISD, MISD, MIMD or a combination thereof.
  • the architecture and the allocation of resources are fixed in a pre-established manner according to a set of machine instructions implemented in the processor.
  • a set of instructions is generally implemented before marketing and use of the processor.
  • the machine instruction set is not intended to be modified by the CPU users.
  • the control unit 3 upon receiving the instructions on the processor 1, the control unit 3 implements an architecture management method, or configuration of the architectures, prior to the implementation of the instructions received at the input. For example, the control unit 3 transmits beforehand to each processing unit PU configuration data specific to each processing unit PU. Each of the configuration data sets is stored in a configuration register accessible to the corresponding processing unit. Then, PU processing units receive generic processing instructions (common to all PUs) of an instruction bus.
  • Each PU implements the processing instructions in a manner that varies according to the configuration data previously received and stored in the configuration register.
  • each PU interprets the generic processing instructions using the configuration data to adapt the processing to be implemented.
  • the second case allows to introduce a flexibility in the control.
  • Generic instructions can be transmitted to all PUs, regardless of the architecture to be adopted (SIMD, MISD, MIMD). The prior transmission of the configuration data makes it possible to select the architecture actually adopted by the PUs on receipt of generic instructions.
  • the architectures can be dynamic, that is to say, evolve over the execution steps of the instructions received, in particular according to the nature of the calculations to be performed.
  • a SIMD architecture may be imposed by default and an MISD architecture may be required for recursive calculations.
  • the processor 1 can be arranged to implement an architecture management method according to specific configuration instructions received (contained in the compiled computer code) and to implement a method of management of the architectures according to a set of machine instructions in the absence or in addition to specific configuration instructions among the instructions received at the input.
  • the control unit 3 transforms the processing instructions received in the usual way into entry in adapted instructions or "macro-instructions" (or "custom instructions”).
  • the adapted instructions contain both processing instructions and configuration instructions.
  • the processor operates in SIMD mode.
  • Processing units 5 perform all the same operations on different data to be processed.
  • the processor operates in MISD or MIMD mode.
  • Processing units 5 perform operations distinct from each other on identical (MISD) or different (MIMD) data to be processed.
  • ⁇ In the example is defined an array of matrices, each matrix being of dimension 4 by 4, the array being of size 2 (including two matrices).
  • the function noted “inv” on a matrix array consists in inverting each element of the array, that is to say inverting each of the two matrices of dimension 4 by 4.
  • the processor comprises four ALUs.
  • cycle 1 steps 1 to 4 for matrix A [0];
  • cycle 2 steps 1 to 4 for matrix A [l];
  • cycle 3 steps 5 to 8 for the matrix A [0];
  • cycle 4 steps 5 to 8 for matrix A [l];
  • cycle 5 step 9 for matrix A [0];
  • cycle 6 step 9 for matrix A [l].
  • the ALU 0 can be assigned to the calculations relating to the matrix A [0] whereas the ALU 1 is assigned to the calculations relating to the matrix A [1].
  • the assignment of each ALU to operations may be scheduled at compile time if at least a portion of the data is known at this stage, including the size of the arrays and the size of the array.
  • the assignment can be done dynamically.
  • the allocation may be imposed by the control unit 3 according to a set of machine instructions implemented on the processor 1.
  • the set of machine instructions is recorded on a support of non-transient recording (for example a part of the memory unit 9) readable by the control unit 3 to implement a management method of the architecture of the processor 1.
  • control unit 3 is arranged to impose on a processing unit 5 the implementation of a first set of operations by the set of ALUs, then the first set of operations is reiterated on each of the two sets of operations. elements of the array (each of the matrices in the previous example). Next, the number of operations that can be carried out in parallel (no interdependent) is estimated. For example, the number of resources (the number of ALUs) is divided by the number of operations to be implemented. Finally, the assignment of operations to each ALU is performed so that at least some of the operations are performed in parallel with each other by separate ALUs of distinct processing units.
  • the architecture of the processing units 5 may vary over time.
  • the architecture of the processing units 5 can alternate between SIMD, MISD and MIMD.
  • the invention is not limited to the examples of processors described above, only by way of example, but it encompasses all the variants that may be considered by those skilled in the art within the framework of the protection sought.
  • the invention also relates to a set of machine instructions implementable in a processor for obtaining such a processor, the implementation of such a set of machine instructions on a processor, the processor architecture management method implemented by the processor, the computer program comprising the corresponding set of machine instructions, and the recording medium on which such a set of machine instructions is recorded.

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'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 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

ARCHITECTURES DE PROCESSEUR
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.
Lin 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. Line ou plusieurs unités de calcul doivent exécuter des calculs de manière séquentielle, un cycle après l’autre. Lin tel processeur est polyvalent. Lin 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.
Le 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. Les 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 041 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 PLF pour « Processing Unit », comprend plusieurs organes de calcul : les unités arithmétiques et logiques, ou ALU pour « Arithmetic-Logic Unit ». Chaque unité de traitement 5 comprend au moins une ALU 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 ALU est numérotée A.B, où « A » identifie l’unité de traitement PU A à laquelle l’ALU appartient et « B » est un identifiant de l’ALU parmi les autres ALU 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’ALU. Dans les exemples des figures 1 à 3, chaque unité de traitement 5 comprend quatre ALU numérotées 0 à 3. Lorsqu’une unité de traitement 5 comprend une pluralité d’ALU, l’unité de traitement 5 est dite multi-cœur.
Chaque ALU 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.).
Les 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. Les données à traiter sont copiées (chargées) depuis l’unité de mémoire 9 sur chacun des jeux de registres REG 0, REG 1, ..., REG N de l’unité de traitement 5 correspondante. Les ALU effectuent les calculs. Les 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. Le 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 ALU ne sont pas représentées. Ainsi, alors que les unités de traitement 5 interagissent entre elles selon une architecture SIMD, les ALU 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. À 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 REG X sur chacune des ALU X.0, X.l, X.2, X.3 de l’unité de traitement PU X. 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 processing( )
{
matrix A(4, 4);
matrix B(4, 4);
matrix C(4,4j;
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. Lin 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 AU I 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. L’affectation des N étapes d’un cycle aux ALU de l’unité de traitement PU se fait, par exemple, de la manière suivante :
Cycle 1 :
ALU 0 étape_l
ALU 1 étape_2
ALU 2 étape_3
ALU 3 étape_4
Cycle 2 :
ALU 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. À 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. Le 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). La 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. Les 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 »). Les instructions adaptées contiennent à la fois des instructions de traitement et des instructions de configuration. Lorsque les instructions adaptées transmises à chacune des unités de traitement 5 sont toutes identiques, le processeur fonctionne en mode SIMD. Les unités de traitement 5 effectuent toutes les mêmes opérations sur des données à traiter différentes. Lorsque 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. Les 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 processing( )
{
matrix A(4,4j [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[l] ;
cycle 3 : étapes 5 à 8 pour la matrice A[0] ;
cycle 4 : étapes 5 à 8 pour la matrice A[l] ;
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[l] .
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 ALU 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.
L’invention ne se limite pas aux exemples de processeurs décrits ci-avant, seulement à titre d’exemple, mais elle englobe toutes les variantes que pourra envisager l’homme de l’art dans le cadre de la protection recherchée. L’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 machines correspondant, ainsi que le support d’enregistrement sur lequel est enregistré informatiquement un tel jeu d’instructions machines.

Claims

Revendications
1. 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.
EP18833085.6A 2017-12-13 2018-11-27 Architectures de processeur Pending EP3724779A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1762068A FR3074931B1 (fr) 2017-12-13 2017-12-13 Architectures de processeur
PCT/FR2018/052995 WO2019115902A1 (fr) 2017-12-13 2018-11-27 Architectures de processeur

Publications (1)

Publication Number Publication Date
EP3724779A1 true EP3724779A1 (fr) 2020-10-21

Family

ID=61802089

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18833085.6A Pending EP3724779A1 (fr) 2017-12-13 2018-11-27 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)

Family Cites Families (12)

* Cited by examiner, † Cited by third party
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
CA2073516A1 (fr) * 1991-11-27 1993-05-28 Peter Michael Kogge Ordinateur a reseau de processeurs paralleles multimode dynamiques
US5933642A (en) * 1995-04-17 1999-08-03 Ricoh Corporation Compiling system and method for reconfigurable computing
US5903771A (en) * 1996-01-16 1999-05-11 Alacron, Inc. Scalable multi-processor architecture for SIMD and MIMD operations
US8099777B1 (en) * 2004-08-26 2012-01-17 Rockwell Collins, Inc. High security, multi-level processor and method of operating a computing system
GB2437837A (en) * 2005-02-25 2007-11-07 Clearspeed Technology Plc Microprocessor architecture
US8156474B2 (en) * 2007-12-28 2012-04-10 Cadence Design Systems, Inc. Automation of software verification
KR100960148B1 (ko) * 2008-05-07 2010-05-27 한국전자통신연구원 데이터 프로세싱 회로
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 株式会社デンソー 並列化コンパイル方法、及び並列化コンパイラ

Also Published As

Publication number Publication date
FR3074931B1 (fr) 2020-01-03
US20210173809A1 (en) 2021-06-10
WO2019115902A1 (fr) 2019-06-20
FR3074931A1 (fr) 2019-06-14
CN111512296A (zh) 2020-08-07
KR20200121788A (ko) 2020-10-26

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
US10810343B2 (en) Mapping software constructs to synchronous digital circuits that do not deadlock
US20100250564A1 (en) Translating a comprehension into code for execution on a single instruction, multiple data (simd) execution
EP2860656B1 (fr) Procédé d'exécution par un microprocesseur d'un code binaire polymorphique d'une fonction prédéterminée
EP1290554A1 (fr) Systeme informatique modulaire et procede associe
EP3724779A1 (fr) Architectures de processeur
US20230315409A1 (en) Compilation and execution of source code as services
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
CN112602058B (zh) 处理器存储器存取
Najjar et al. ROCCC 2.0
WO2000060460A1 (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

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200611

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230714