Formation musicale

<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.11/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.11/ http://www.mediawiki.org/xml/export-0.11.xsd" version="0.11" xml:lang="fr">
  <siteinfo>
    <sitename>Wikilivres</sitename>
    <dbname>frwikibooks</dbname>
    <base>https://fr.wikibooks.org/wiki/Accueil</base>
    <generator>MediaWiki 1.45.0-wmf.7</generator>
    <case>first-letter</case>
    <namespaces>
      <namespace key="-2" case="first-letter">Média</namespace>
      <namespace key="-1" case="first-letter">Spécial</namespace>
      <namespace key="0" case="first-letter" />
      <namespace key="1" case="first-letter">Discussion</namespace>
      <namespace key="2" case="first-letter">Utilisateur</namespace>
      <namespace key="3" case="first-letter">Discussion utilisateur</namespace>
      <namespace key="4" case="first-letter">Wikilivres</namespace>
      <namespace key="5" case="first-letter">Discussion Wikilivres</namespace>
      <namespace key="6" case="first-letter">Fichier</namespace>
      <namespace key="7" case="first-letter">Discussion fichier</namespace>
      <namespace key="8" case="first-letter">MediaWiki</namespace>
      <namespace key="9" case="first-letter">Discussion MediaWiki</namespace>
      <namespace key="10" case="first-letter">Modèle</namespace>
      <namespace key="11" case="first-letter">Discussion modèle</namespace>
      <namespace key="12" case="first-letter">Aide</namespace>
      <namespace key="13" case="first-letter">Discussion aide</namespace>
      <namespace key="14" case="first-letter">Catégorie</namespace>
      <namespace key="15" case="first-letter">Discussion catégorie</namespace>
      <namespace key="100" case="first-letter">Transwiki</namespace>
      <namespace key="101" case="first-letter">Discussion Transwiki</namespace>
      <namespace key="102" case="first-letter">Wikijunior</namespace>
      <namespace key="103" case="first-letter">Discussion Wikijunior</namespace>
      <namespace key="710" case="first-letter">TimedText</namespace>
      <namespace key="711" case="first-letter">TimedText talk</namespace>
      <namespace key="828" case="first-letter">Module</namespace>
      <namespace key="829" case="first-letter">Discussion module</namespace>
    </namespaces>
  </siteinfo>
  <page>
    <title>Formation musicale</title>
    <ns>0</ns>
    <id>3408</id>
    <revision>
      <id>745454</id>
      <parentid>710573</parentid>
      <timestamp>2025-06-27T09:11:25Z</timestamp>
      <contributor>
        <username>Cdang</username>
        <id>1202</id>
      </contributor>
      <comment>+</comment>
      <origin>745454</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3960" sha1="2q4pe1wntp3bcy96fkadzqvsvgtph5o" xml:space="preserve">{{Page de garde|image=Colormusik Print Detail.jpg|description=

La formation musicale est l'étude des éléments permettant d'interpréter un morceau de musique, et inclut solfège, oreille, sens du rythme, travail collectif, mais aussi culture générale.

L'étude inclut la musique écrite. Elle n'est pas indispensable à la pratique de la musique ; elle permet toutefois de faciliter à la fois la lecture de partitions de musique et ainsi interpréter un morceau inconnu. C'est aussi un moyen de transmission de la musique aux interprètes, une forme de « communication technique ».
|avancement=Avancé
|cdu=
* {{CDU item|7|78}}
}}

Le '''[[w:Solfège|solfège]]''' est l'étude des éléments permettant d'interpréter un morceau de musique.

Le solfège n'est pas ''indispensable'' à la pratique de la musique : de nombreux musiciens, amateurs comme professionnel, jouent « à l'oreille » et apprennent la musique par mimétisme. La musique est d'abord une tradition orale. Toutefois, le solfège fournit un cadre qui facilite :
* l'interprétation de musique écrite, en déchiffrant : un musicien peut ainsi interpréter un morceau qu'il ne connaît pas à partir de la seule partition ; la musique écrite est donc un moyen simple, économique et robuste de transmettre et de conserver la musique ;
* la préparation d'un concert : un orchestre de plusieurs dizaines de musiciens peut monter un concert d'une heure avec seulement quatre répétitions en s'appuyant sur les partitions ;
* la composition : si un auteur de livre peut se contenter d'enregistrer sa voix (principe du dictaphone), le passage par l'écriture permet de reprendre des passages et de mettre en cohérence les différentes parties du livre ; il en est de même pour la musique.
En France, le terme de « solfège » a été remplacé par celui de '''formation musicale (FM)'''. En effet, il s'agit également de former de manière globale le musicien — oreille, sens du rythme, travail collectif, mais aussi culture générale.

Nous nous intéressons essentiellement à la musique « occidentale » : musiques savantes et populaires du nord-ouest de l'Europe et des États-Unis d'Amérique, dont les musiques dites « classique », « jazz », « pop », « rock ». L'accent est mis sur la musique dite « classique » car c'est pour elle que le formalisme présenté a été développé.

== Table des matières ==
# [[/Qu'est-ce que la musique ?|Qu'est-ce que la musique ?]]
# [[/Transmettre la musique|Transmettre la musique]]
# [[/Caractéristiques et notation des sons musicaux|Caractéristiques et notation des sons musicaux]]
# [[/Gammes et intervalles|Gammes et intervalles]]
# [[/Mélodie|Mélodie]]
# [[/Harmonie|Harmonie]]
# [[/Représentation musicale|Représentation musicale]]
# [[/Analyse d'une œuvre|Analyse d'une œuvre]]
# [[/Culture générale musicale|Culture générale musicale]]
# Annexes
## [[/Bibliographie et liens|Bibliographie et liens]]
## [[/Index|Index]]

== Voir aussi ==
; Sur la wikiversité
* ''[[wikiversity:fr:Accord|Accord]]''
* ''[[wikiversity:fr:Gamme|Gamme]]''
* ''[[wikiversity:fr:Intervalle, accord|Intervalle, accord]]''
* ''[[wikiversity:fr:Introduction au solfège|Introduction au solfège]]''
* ''[[wikiversity:fr:Lecture de partitions|Lecture de partitions]]''
* ''[[wikiversity:fr:Solfège pour débutants|Solfège pour débutants]]''
; Sur Wikisource
* Adolphe Danhauser, ''[[wikisource:fr:Théorie_de_la_musique_(Danhauser,_1889)|Théorie de la musique]]'' (1889)
* Augustin d'Hippone dit « saint Augustin », ''[[wikisource:fr:Traité_de_la_musique|Traité de la musique]]'' (env. 389, 1864 pour la traduction)
* Marie Bobillier (sous le pseudonyme Michel Brenet), ''[[wikisource:fr:Dictionnaire_pratique_et_historique_de_la_musique|Dictionnaire pratique et historique de la musique ]]'' (1926)

[[Catégorie:Musique]]
[[Catégorie:Livres en cours de rédaction]]
[[Catégorie:Formation musicale (livre)|*]]</text>
      <sha1>2q4pe1wntp3bcy96fkadzqvsvgtph5o</sha1>
    </revision>
    <revision>
      <id>745455</id>
      <parentid>745454</parentid>
      <timestamp>2025-06-27T09:11:59Z</timestamp>
      <contributor>
        <username>Cdang</username>
        <id>1202</id>
      </contributor>
      <minor />
      <comment>rectif</comment>
      <origin>745455</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3979" sha1="d9ovo4jc95kiedxuw2gu32z6cg2li4h" xml:space="preserve">{{Page de garde|image=Colormusik Print Detail.jpg|description=

La formation musicale est l'étude des éléments permettant d'interpréter un morceau de musique, et inclut solfège, oreille, sens du rythme, travail collectif, mais aussi culture générale.

L'étude inclut la musique écrite. Elle n'est pas indispensable à la pratique de la musique ; elle permet toutefois de faciliter à la fois la lecture de partitions de musique et ainsi interpréter un morceau inconnu. C'est aussi un moyen de transmission de la musique aux interprètes, une forme de « communication technique ».
|avancement=Avancé
|cdu=
* {{CDU item|7|78}}
}}

Le '''[[w:Solfège|solfège]]''' est l'étude des éléments permettant d'interpréter un morceau de musique.

Le solfège n'est pas ''indispensable'' à la pratique de la musique : de nombreux musiciens, amateurs comme professionnel, jouent « à l'oreille » et apprennent la musique par mimétisme. La musique est d'abord une tradition orale. Toutefois, le solfège fournit un cadre qui facilite :
* l'interprétation d'un morceau que l'on ne connaît pas, en déchiffrant : un musicien peut ainsi interpréter un morceau qu'il ne connaît pas à partir de la seule partition ; la musique écrite est donc un moyen simple, économique et robuste de transmettre et de conserver la musique ;
* la préparation d'un concert : un orchestre de plusieurs dizaines de musiciens peut monter un concert d'une heure avec seulement quatre répétitions en s'appuyant sur les partitions ;
* la composition : si un auteur de livre peut se contenter d'enregistrer sa voix (principe du dictaphone), le passage par l'écriture permet de reprendre des passages et de mettre en cohérence les différentes parties du livre ; il en est de même pour la musique.
En France, le terme de « solfège » a été remplacé par celui de '''formation musicale (FM)'''. En effet, il s'agit également de former de manière globale le musicien — oreille, sens du rythme, travail collectif, mais aussi culture générale.

Nous nous intéressons essentiellement à la musique « occidentale » : musiques savantes et populaires du nord-ouest de l'Europe et des États-Unis d'Amérique, dont les musiques dites « classique », « jazz », « pop », « rock ». L'accent est mis sur la musique dite « classique » car c'est pour elle que le formalisme présenté a été développé.

== Table des matières ==
# [[/Qu'est-ce que la musique ?|Qu'est-ce que la musique ?]]
# [[/Transmettre la musique|Transmettre la musique]]
# [[/Caractéristiques et notation des sons musicaux|Caractéristiques et notation des sons musicaux]]
# [[/Gammes et intervalles|Gammes et intervalles]]
# [[/Mélodie|Mélodie]]
# [[/Harmonie|Harmonie]]
# [[/Représentation musicale|Représentation musicale]]
# [[/Analyse d'une œuvre|Analyse d'une œuvre]]
# [[/Culture générale musicale|Culture générale musicale]]
# Annexes
## [[/Bibliographie et liens|Bibliographie et liens]]
## [[/Index|Index]]

== Voir aussi ==
; Sur la wikiversité
* ''[[wikiversity:fr:Accord|Accord]]''
* ''[[wikiversity:fr:Gamme|Gamme]]''
* ''[[wikiversity:fr:Intervalle, accord|Intervalle, accord]]''
* ''[[wikiversity:fr:Introduction au solfège|Introduction au solfège]]''
* ''[[wikiversity:fr:Lecture de partitions|Lecture de partitions]]''
* ''[[wikiversity:fr:Solfège pour débutants|Solfège pour débutants]]''
; Sur Wikisource
* Adolphe Danhauser, ''[[wikisource:fr:Théorie_de_la_musique_(Danhauser,_1889)|Théorie de la musique]]'' (1889)
* Augustin d'Hippone dit « saint Augustin », ''[[wikisource:fr:Traité_de_la_musique|Traité de la musique]]'' (env. 389, 1864 pour la traduction)
* Marie Bobillier (sous le pseudonyme Michel Brenet), ''[[wikisource:fr:Dictionnaire_pratique_et_historique_de_la_musique|Dictionnaire pratique et historique de la musique ]]'' (1926)

[[Catégorie:Musique]]
[[Catégorie:Livres en cours de rédaction]]
[[Catégorie:Formation musicale (livre)|*]]</text>
      <sha1>d9ovo4jc95kiedxuw2gu32z6cg2li4h</sha1>
    </revision>
  </page>
  <page>
    <title>Japonais/Vocabulaire/Animaux</title>
    <ns>0</ns>
    <id>4983</id>
    <revision>
      <id>745461</id>
      <parentid>732429</parentid>
      <timestamp>2025-06-27T11:56:37Z</timestamp>
      <contributor>
        <ip>2A01:CB05:8BC9:BF00:A9DC:319E:88D2:6C97</ip>
      </contributor>
      <comment>/* Insectes */</comment>
      <origin>745461</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="23987" sha1="pjhp2zkztj4ijhd5lqvw3sf9s4qbszq" xml:space="preserve">== Classifications ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Chaîne alimentaire
|[[wikt:fr:食物連鎖|食物連鎖]]
|しょくもつれんさ
|shokumotsu rensa
|/
|-
|Pâture
|[[wikt:fr:餌食|餌食]]
|えじき
|ejiki
|/
|-
|Prédateur
|[[wikt:fr:捕食者|捕食者]]
|ほしょくしゃ
|hoshokusha
|/
|-
|Prédation
|[[wikt:fr:捕食|捕食]]
|ほしょく
|hoshoku
|/
|-
|Proie
|[[wikt:fr:獲物|獲物]]
|えもの
|emono
|/
|}


== Ordres ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Carnivore
|[[wikt:fr:肉食動物|肉食動物]]
|にくしょくどうぶつ
|nikushoku dōbutsu
|Carnivore/Animal
|-
|Herbivore
|[[wikt:fr:草食動物|草食動物]]
|そうしょくどうぶつ
|sōshoku dōbutsu
|Herbivore/Animal
|-
|Frugivore
|[[wikt:fr:|fr:]]
|
|
|Frugivore/Animal
|-
|Granivore
|[[wikt:fr:|fr:]]
|
|
|Granivore/Animal
|-
|Insectivore
|[[wikt:fr:食虫動物|食虫動物]]
|しょくちゅうどうぶつ
|shokuchū dōbutsu
|Insectivore/Animal
|-
|Omnivore
|[[wikt:fr:雑食動物|雑食動物]]
|ざっしょくどうぶつ
|zasshoku dōbutsu
|Omnivore/Animal
|}

== Arachnides ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Acarien/Pou
|[[wikt:fr:壁蝨|壁蝨]]
|だに
|dani
|
|-
|Araignée
|[[wikt:fr:蜘蛛|蜘蛛]]
|くも
|kumo
|
|-
|Scorpion
|[[wikt:fr:蠍|蠍]]
|さそり
|sasori
|
|}

== Insectes ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Abeille
|[[wikt:fr:蜂|蜂]]
|はち
|hachi
|
|-
|Blatte, cafard
|[[wikt:fr:蜚蠊|蜚蠊]]
|ごきぶり
|gokiburi
|
|-
|Cigale
|[[wikt:fr:蝉|蝉]]
|せみ
|semi
|/Insecte
|-
|Coccinelle
|[[wikt:fr:天道虫|天道虫]]
|てんとうむし
|tentōmushi
|Sentier céleste/Insecte
|-
|Criquet
|[[wikt:飛蝗|飛蝗]]
|ばった
|batta
|/Insecte
|-
|Grillon
|[[wikt:fr:蟋蟀|蟋蟀]]
|こおろぎ
|kōrogi
|/Insecte
|-
|Fourmi
|[[wikt:fr:蟻|蟻]]
|あり
|ari
|/Insecte
|-
|Guêpe, frelon
|[[wikt:fr:雀蜂|雀蜂]]
|すずめばち
|suzumebachi
|Moineau/Abeille
|-
|　
|[[wikt:fr:|頬長雀蜂]]
|ほおながスズメバチ
|hōnagasuzumebachi
|Joue/Long/Guêpe
|-
|Insecte
|[[wikt:fr:虫|虫]]
|むし 
|mushi
|
|-
|Libellule
|[[wikt:fr:蜻蛉|蜻蛉]]
|とんぼ
|tonbo
|/Insecte
|-
|Luciole
|[[wikt:fr:蛍|蛍]]
|ほたる
|hotaru
|Petit couvercle/Insecte
|-
|Mante religieuse
|[[wikt:fr:蟷螂|蟷螂]]
|かまきり
|kamakiri
|/
|-
|Mouche
|[[wikt:fr:蝿|蝿]]
|はえ
|hae
|
|-
|Moustique
|[[wikt:fr:蚊|蚊]]
|か
|ka
|
|-
|Papillon
|[[wikt:fr:蝶々|蝶々]]
|ちょうちょう
|chōchō
|
|-
|Puce
|[[wikt:fr:蚤|蚤]]
|のみ
|nomi
|
|-
|Sauterelle
|[[wikt:蝗|蝗]]
|いなご
|inago
|/Insecte
|-
|Scarabée
|[[wikt:fr:兜虫|兜虫]]
|かぶとむし 
|kabutomushi
|Casque/Insecte
|}

==Oiseaux==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Hirgana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Aigle
|[[wikt:fr:鷲|鷲]]
|わし
|washi
|Lieu grandiose/Oiseau
|-
|Aigle royal
|[[wikt:fr:犬鷲|犬鷲]]
|いぬわし
|inuwashi
|Chien/Aigle
|-
|Aigrette
|[[wikt:fr:白鷺|白鷺]]
|しらさぎ
|shirasagi
|Blanc/Héron
|-
|Aigrette sacrée
|[[wikt:fr:黒鷺|黒鷺]]
|くろさぎ
|kurosagi
|Noir/Héron
|-
|Alouette
|[[wikt:fr:雲雀|雲雀]]
|ひばり
|hibari
|Nuage/Moineau
|-
|Autruche
|[[wikt:fr:鴕鳥|鴕鳥]]
|だちょう
|dachō
|Autruche/Oiseau
|-
|Bécasse
|[[wikt:fr:山鴫|山鴫]]
|やましぎ
|yamashigi
|Montagne/Chevalier
|-
|Bihoreau goisagi
|[[wikt:fr:溝五位|溝五位]]
|みぞごい
|mizogoi
|Fossé/Cinq/Couronne
|-
|Bihoreau violacé
|[[wikt:fr:蓑五位|蓑五位]]
|みのごい
|minogoi
|Manteau de paille/Cinq/Couronne
|-
|Caille
|[[wikt:fr:鶉|鶉]]
|うずら
|uzura
|/Oiseau
|-
|Calao
|[[wikt:fr:犀鳥|犀鳥]]
|さいちょう
|saichō
|Rhinocéros/Oiseau
|-
|Calopsitte 
|[[wikt:阿亀鸚哥|阿亀鸚哥]]
|おかめいんこ
|okame inko
|Femme inélégante/Perruche
|-
|Canard 
|[[wikt:fr:鴨|鴨]] (sauvage)&lt;br /&gt;[[wikt:fr:家鴨|家鴨]] (domestique)
|かも&lt;br /&gt;あひる
|kamo&lt;br /&gt;ahiru
|Enveloppe dure/Oiseau&lt;br /&gt;Maison/Canard sauvage
|-
|Canard colvert
|[[wikt:fr:真鴨|真鴨]]
|まがも
|magamo
|Vrai/Canard sauvage
|-
|Canard mandarin
|[[wikt:fr:鴛鴦|鴛鴦]]
|おしどり
|oshidori
|/
|-
|Canaroie semipalmée
|[[wikt:fr:鵲雁|鵲雁]]
|かささぎがん
|kasasagigan
|Pie/Oie sauvage
|-
|Casoar
|[[wikt:fr:火食鳥|火食鳥]]
|ひくいどり
|hikuidori
|Feu/Mangeant/Oiseau
|-
|Cassican flûteur 
|[[wikt:fr:鵲笛鴉|鵲笛鴉]]
|かささぎふえがらす
|kasasagi fuegarasu
|Pie/Flûte/Corbeau
|-
|Chouette
|[[wikt:fr:梟|梟]]
|ふくろう
|fukurō
|Oiseau/Arbre
|-
|Cigogne
|[[wikt:fr:鸛|鸛]]
|こうのとり
|kōnotori
|Enfant/Oiseau
|-
|Cigogne blanche
|[[wikt:fr:朱嘴鸛|朱嘴鸛]]
|しゅばしこう
|shubashikō
|Vermillon/Bec/Cigogne
|-
|Cigogne d'Abdim
|[[wikt:fr:青端鸛|青端鸛]]
|あおはしこう
|aohashikō
|Bleu/Extrémité/Cigogne
|-
|Cigogne épiscopale
|[[wikt:fr:白襟鸛|白襟鸛]]
|しろえりこう
|shiroerikō
|Blanc/Cou/Cigogne
|-
|Cigogne maguari
|[[wikt:fr:燕尾鸛|燕尾鸛]]
|えんびこう
|enbikō
|Hirondelle/Queue/Cigogne
|-
|Cigogne noire
|[[wikt:fr:鍋鸛|鍋鸛]]
|なべこう
|nabekō
|Chaudron/Cigogne
|-
|Colombe/Pigeon
|[[wikt:fr:鳩|鳩]]
|はと
|hato
|/Oiseau
|-
|Condor
|[[wikt:fr:公佗児|公佗児]]
|こうわじ
|kōwaji
|Public/Fier ; solitaire/ (On trouve également le terme 「コンドル」issu de l'anglais &quot;condor&quot;.)
|-
|Coq de bruyère
|[[wikt:fr:雷鳥|雷鳥]]
|らいちょう
|raichō
|Tonnerre/Oiseau
|-
|Coq
|[[wikt:fr:雄鳥|雄鳥]]
|おんどり
|ondori
|Mâle/Oiseau
|-
|Corbeau
|[[wikt:fr:烏|烏]]
|からす
|karasu
|Terme général désignant les animaux du genre ''corvus''
|-
|Corneille mantelée
|[[wikt:fr:頭巾烏|頭巾烏]]
|ずきんがらす
|zukingarasu
|Capuche/Corbeau
|-
|Dinde
|[[wikt:fr:七面鳥|七面鳥]]
|しちめんちょう
|shichimenchō
|Sept visages/Oiseau
|-
|Faisan
|[[wikt:fr:雉|雉]]
|きじ 
|kiji
|
|-
|Faucon
|[[wikt:fr:鷹|鷹]]
|たか
|taka
|
|-
|Faucon crécerelle
|[[wikt:fr:長元坊|長元坊]]
|ちょうげんぼう
|chōgenbō
|Chef/Fondation/Chambre
|-	
|Faucon pèlerin
|[[wikt:fr:隼|隼]]
|はやぶさ
|hayabusa
|
|-
|Geai
|[[wikt:fr:懸巣|懸巣]]
|かけす
|kakesu
|/
|-
|Grand-duc de Blakiston
|[[wikt:fr:島梟|島梟]]
|しまふくろう
|shimafukurō
|Île/Chouette
|-
|Grèbe castagneux
|[[wikt:fr:鸊鷉|鸊鷉]]
|かいつぶり
|kaitsuburi
|/
|-
|Grive
|[[wikt:fr:鶇|鶇]]
|つぐみ
|tsugumi
|Tenir sa langue/Oiseau
|-
|Grue demoiselle
|[[wikt:fr:姉羽鶴|姉羽鶴]]
|あねはづる
|anehazuru
|Grande sœur/Aile/Grue
|-
|Grue
|[[wikt:fr:鶴|鶴]]
|つる
|tsuru
|S'élever/Oiseau
|-
|Grue royale
|[[wikt:fr:頬白冠鶴|頬白冠鶴]]
|ほおじろかんむりづる
|hōjiro kanmurizuru
|Bruant à longue queue/Grue couronnée
|-
|Harpie féroce
|[[wikt:fr:扇鷲|扇鷲]]
|おうぎわし
|ōgiwashi
|Éventail/Aigle
|-
|Héron cendré
|[[wikt:fr:蒼鷺|蒼鷺]]
|あおさぎ
|aosagi
|Bleu/Héron
|-
|Hibou
|[[wikt:fr:木菟|木菟]]
|みみずく
|mimizuku
|Arbre/Lapin
|-
|Hirondelle
|[[wikt:fr:燕|燕]]
|つばめ
|tsubame
|
|-
|Hirondelle bicolore
|[[wikt:fr:緑燕|緑燕]]
|みどりつばめ
|midori tsubame
|Vert/Hirondelle
|-
|Huppe fasciée
|[[wikt:fr:戴勝|戴勝]]
|やつがしら
|yatsugashira
|Serviteur/Tête
|-
|Lagopède alpin
|[[wikt:fr:雷鳥|雷鳥]]
|らいちょう 
|raichō
|Foudre/Oiseau
|-
|Macareux moine
|[[wikt:fr:西角目鳥|西角目鳥]]
|にしつのめどり
|nishitsunomedori
|Ouest/Macareux cornu
|-
|Martinet
|[[wikt:fr:雨燕|雨燕]]
|あまつばめ
|amatsubame
|Pluie/Hirondelle
|-
|Moineau
|[[wikt:fr:雀|雀]]
|すずめ
|suzume
|
|-
|Mouette
|[[wikt:fr:鴎|鴎]]
|かもめ
|kamome
|Arrondissement citadin/Oiseau
|-
|Oie
|[[wikt:fr:鵞鳥|鵞鳥]]
|がちょう
|gachō
|Oie/Oiseau
|-
|Oiseau de proie
|[[wikt:fr:猛禽|猛禽]]
|もうきん
|mōkin
|Fureur/Oiseau
|-
|Oiseau
|[[wikt:fr:鳥|鳥]]
|とり
|tori
|
|-
|Palombe/Ramier
|[[wikt:fr:森鳩|森鳩]]
|もりばと
|moribato
|Forêt/Pigeon
|-
|Paon
|[[wikt:fr:孔雀|孔雀]]
|くじゃく
|kujaku
|Cavité/Moineau
|-
|Paradisier
|[[wikt:fr:風鳥|風鳥]]
|ふうちょう
|fūchō
|Vent/Oiseau
|-
|Perroquet
|[[wikt:fr:鸚鵡|鸚鵡]]
|おうむ 
|ōmu
|
|-
|Perruche
|[[wikt:fr:鸚哥|鸚哥]]
|いんこ
|inko
|
|-
|Pie
|[[wikt:fr:鵲|鵲]]
|かささぎ
|kasasagi
|Autrefois/Oiseau
|-
|Plongeon imbrin
|[[wikt:fr:嘴黒阿比|嘴黒阿比]]
|はしぐろあび
|hashiguroabi
|Bec noir/Plongeon
|-
|Poule
|[[wikt:fr:雌鶏|雌鶏]] 
|めんどり
|mendori
|Femelle/Poulet
|-
|Poulet 
|[[wikt:fr:鶏|鶏]] (domestique)
|にわとり
|niwatori
|Jardin/Oiseau
|-
|Passerin indigo 
|[[wikt:fr:瑠璃野路子|瑠璃野路子]]
|るりのじこ
|rurinojiko
|/Enfant
|-
|Roitelet
|[[wikt:fr:鷦鷯|鷦鷯]]
|みそさざい
|misosazai
|/
|-
|Roselin pourpré
|[[wikt:fr:紫猿子|紫猿子]]
|むらさきましこ
|murasaki mashiko
|Violet/Singe/Enfant
|-
|Rossignol
|[[wikt:fr:小夜啼鳥|小夜啼鳥]]
|さよなきどり
|sayonakidori
|Petite nuit/Oiseau chanteur
|-
|Rouge-gorge
|[[wikt:fr:駒鳥|駒鳥]]
|こまどり
|komadori
|Chevalet/Oiseau
|-
|Sarcelle
|[[wikt:fr:小鴨|小鴨]]
|こがも
|kogamo
|Petit/Canard sauvage
|-
|Sterne arctique
|[[wikt:fr:極鰺刺|極鰺刺]]
|きょくあじさし
|kyokuajisashi
|Extrême/Sterne
|-
|Sterne
|[[wikt:fr:鰺刺|鰺刺]]
|あじさし
|ajisashi
|Chinchard/
|-
|Toucan
|[[wikt:fr:大嘴|大嘴]]
|おおはし
|ōhashi
|Grand/Bec
|-
|Tourterelle 
|[[wikt:fr:山鳩|山鳩]]
|やまばと
|yamabato
|Montagne/Colombe, pigeon
|-
|Tourterelle des bois
|[[wikt:fr:小雉鳩|小雉鳩]]
|こきじばと
|kokijibato
|Petit/Tourterelle occidentale
|-
|Vautour
|[[wikt:fr:禿鷹|禿鷹]]
|はげたか
|hagetaka
|Calvitie/Faucon
|}

== Mammifères ==

[[Image:Books-aj.svg aj ashton 01.svg|right|70px]]
{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Agneau
|[[wikt:fr:子羊|子羊]]
|こひつじ
|kohitsuji
|Enfant/Mouton
|-
|Alpaga
|
|アルパカ
|arupaka
|
|-
|Âne
|[[wikt:fr:驢馬|驢馬]]
|ろば
|roba
|Ce terme s'écrit en katakana comme suit :「ロバ」
|-
|Babouin
|[[wikt:狒々|狒々]]
|ひひ
|hihi
|Issu de la créature légendaire du folklore japonais : ''[[w:Hi-hi|Hi-hi]]''
|-
|Baleine
|[[wikt:fr:鯨|鯨]] 
|くじら
|kujira
|Ce terme s'écrit en katakana comme suit :「クジラ」
|-
|Bassaris rusé
|
|カコミスル
|kakomisuru
|Issu de l'anglais « cacomistle ».
|-
|Belette d’Europe
|[[wikt:fr:飯綱|飯綱]]
|いいづな
|īzuna
|Riz/corde. Désignait originellement une créature légendaire du nom de [[w:Kuda-kitsune|kuda-gitsune]].
|-
|Belette du Japon / Itatsi
|㹨
|いたち
|Itachi
|Désigne également les mustélidés en général. Ce terme s’écrit en katakana comme suit : 「イタチ」
|-
|Bélier
|[[wikt:雄羊|雄羊]]
|おひつじ
|ohitsuji
|Mâle/Mouton
|-
|Bison
|[[wikt:野牛|野牛]]
|やぎゅう
|yagyū
|Champ/Bœuf. Est surtout désigné sous le terme baizon 「バイゾン」
|-
|Blaireau
|[[wikt:fr:穴熊|穴熊]]
|あなぐま
|anaguma
|Trou (穴) Ours (熊). Ce terme s'écrit en katakana comme suit :「アナグマ」
|-
|Blaireau japonais
|[[wikt:fr:日本穴熊|日本穴熊]]
|にほんあなぐま
|Nihon anaguma
|Japon (日本) Blaireau (穴熊)
|-
|Bouc
|[[wikt:雄山羊|雄山羊]]
|おやぎ
|oyagi
|Mâle/Chèvre
|-
|Brebis
|[[wikt:雌羊|雌羊]]
|めひつじ
|mehitsuji
|Femelle/Mouton
|-
|Buffle
|水牛
|すいぎゅ
|suigyu
|Eau/Bœuf : Vient du buffle d’Eau d’Asie.
|-
|Castor
|
|ビーバー
|bībā
|Beaver (en)
|-
|Chameau
|[[wikt:fr:駱駝|駱駝]]
|らくだ
|rakuda
|
|-
|Chat
|[[wikt:fr:猫|猫]]
|ねこ
|neko
|
|-
|Chaton
|[[wikt:fr:子猫|子猫]]
|こねこ
|koneko
|Enfant/Chat
|-
|Chauve-souris
|[[wikt:fr:蝙蝠|蝙蝠]]
|こうもり
|kōmori 
|
|-
|Chevreau
|[[wikt:子山羊|子山羊]]
|こやぎ
|koyagi
|Enfant/Chèvre
|-
|Chevreuil
|[[wikt:麕鹿|麕鹿]]
|のろじか
|norojika
|Chevreuil/Cerf
|-
|Cerf
|[[wikt:fr:鹿|鹿]]
|しか
|shika
|
|-
|Cerf du père David
|四不像
|ししふうぞう
|shifuzō
|Quatre/Négatif/Image(en tête). Du chinois « aucun des quatre »
|-
|Cerf sika
|日本鹿
|にほんじか
|Nihon jika
|Japon/Cerf
|-
|Chacal
|
|ジャッカル
|jakkaru
|jackal (en)
|-
|Cheval
|[[wikt:fr:馬|馬]]
|うま
|uma
|
|-
|Chèvre 
|[[wikt:fr:山羊|山羊]]
|やぎ
|yagi
|Montagne (山) Mouton (羊)
|-
|Chien
|[[wikt:fr:犬|犬]]
|いぬ
|inu
|
|-
|Chien viverrin / Tanuki
|[[wikt:fr:狸|狸]]
|たぬき
|tanuki
|
|-
|Chinchilla
|
|チンチラ
|chinchira
|
|-
|Chiot
|[[wikt:fr:子犬|子犬]]
|こいぬ
|koinu
|Enfant (子) Chien (犬)
|-
|Civette
|[[wikt:fr:麝香猫|麝香猫]] 
|じゃこうねこ 
|jakōneko
|Musc (麝香) Chat (猫)  
|-
|Coati
|鼻熊
|はなぐま
|hanaguma
|Nez (鼻) Ours (熊)
|-
|Cochon
|[[wikt:fr:豚|豚]]
|ぶた
|buta
|
|-
|Cochon d'Inde
|
|モルモット
|morumotto
|On trouve également le terme 「ギニアピッグ」
|-
|Coyote
|
|コヨーテ
|koyōte
|
|-
|Daim
|
|ダマジカ
|damajika
|Dama(Daim)/Cerf
|-
|Dasyure
|[[wikt:fr:袋猫|袋猫]]
|ふくろねこ
|fukuroneko
|Sac (袋) Chat (猫)
|-
|Dauphin
|[[wikt:fr:海豚|海豚]]
|いるか
|iruka
|Mer/Cochon
|-
|Dègue
|
|デグー
|degū
|
|-
|Dhole
|犲
|やまいぬ
|Yamainu
|Montagne/Chien. Confondu avec les chiens errants et les loups, est aujourd’hui plutôt désigné sous le nom de ''dōru'' 「ドール」
|-
|Dromadaire
|[[wikt:fr:一瘤駱駝|一瘤駱駝]]
|ひとこぶらくだ
|hitokobu rakuda
|Bosse unique/Chameau
|-
|Dugong / Vache marine
|儒艮
|じゅごん
|jugon
|
|-
|Échidné
|[[wikt:fr:針土竜|針土竜]]
|はりねずみ
|harimogura
|Aiguille/Taupe
|-
|Écureuil
|[[wikt:fr:栗鼠|栗鼠]]
|りす
|risu
|Noix (栗) Rat (鼠)
|-
|Écureuil volant
|[[wikt:fr:鼯鼠|鼯鼠]]
|ももんが
|momonga
|Écureuil volant (鼯) Rat (鼠)
|-
|Élan
|[[wikt:fr:箆鹿|箆鹿]]
|へらじか
|herajika
|Spatule (箆) Cerf (鹿)
|-
|Éléphant
|[[wikt:fr:象|象]]
|ぞう
|zō
|-
|Faon
|[[wikt:子鹿|子鹿]]
|こじか
|kojika
|Enfant/Cerf
|-
|Fouine
|[[wikt:fr:胸白貂|胸白貂]]
|むねしろてん
|muneshiroten
|Poitrail blanc/Martre
|-
|Furet
|[[wikt:fr:白鼬|白鼬]]
|しろいたち
|shiroitachi
|Blanc/Belette (On trouve également le terme「フェレット」issu de l'anglais &quot;ferret&quot;.)
|-
|Gerbille de Mongolie
|[[wikt:fr:砂鼠|砂鼠]]
|すなねずみ
|sunanezumi
|Sable (砂) Souris (鼠)
|-
|Gibbon
|[[wikt:fr:手長猿|手長猿]]
|てながざる
|tenagazaru
|Main/Long/Singe
|-
|Gibbon à mains blanches
|[[wikt:fr:白手手長猿|白手手長猿]]
|しろててながざる
|shirote tenagazaru
|Blanc/Main/Long/Singe
|-
|Girafe
|[[wikt:fr:麒麟|麒麟]]
|きりん
|kirin
|Issue de la créature légendaire du folklore assiatique : [[w:Qilin|Qilin]]
|-
|Glouton
|[[wikt:fr:屈狸|屈狸]]
|くずり
|kuzuri
|Ce terme s'écrit en katakana comme suit:「クズリ」
|-
|Gorille
|
|ゴリラ
|gorira
|Gorilla (en)
|-
|Grizzly
|[[wikt:fr:灰色熊|灰色熊]]
|はいいろぐま
|haīroguma
|Gris/Ours
|-
|Guépard
|[[wikt:fr:狩猟豹|狩猟豹]]
|しゅりょうひょう
|shuryōhyō
|Chasse/Panthère (On trouve également le terme 「チーター」issu de l'anglais &quot;cheetah&quot;.)
|-
|Hamster
|
|ハムスター
|hamusutā
|Hamster (fr)
|-
|Hermine
|[[wikt:fr:白鼬|白鼬]]
|おこじょ
|okojo
|Blanc/Belette
|-
|Hérisson
|[[wikt:fr:針鼠|針鼠]]
|はりねずみ
|harinezumi
|Aiguille (針) Rat (鼠)
|-
|Hippopotame
|[[wikt:fr:河馬|河馬]]
|かば
|kaba
|Fleuve (河) Cheval (馬)
|-
|Kinkajou
|
|キンカジュー
|kinkajū
|Variante de quincajou.
|-
|Lama
|
|ラマ
|rama
|Lama (fr)
|-
|Lamantin
|
|マナティー
|manatī
|Issu de l'anglais &quot;manatee&quot;.
|-
|Lapin
|[[wikt:fr:兎|兎]]
|うさぎ
|usagi
|Terme général désignant les lagomorphes
|-
|Léopard/Panthère
|[[wikt:豹#ja|豹]]
|ひょう
|hyō
|
|-
|Lièvre
|[[wikt:fr:野兎|野兎]]
|のうさぎ
|nousagi
|Champ (野) Lapin (兎)
|-
|Lion
|[[wikt:fr:獅子|獅子]]
|しし
|shishi
|Le terme 「ライオン」 issu de l'anglais &quot;lion&quot; est aujourd'hui plus largement utilisé.
|-
|Loup
|[[wikt:fr:狼|狼]]
|おおかみ
|ōkami
|
|-
|Loutre
|[[wikt:fr:川獺|川獺]]
|かわうそ
|kawauso
|Rivère (川) Loutre (獺)
|-
|Loutre de mer
|海獺
|らっこ
|rakko
|Mer/Loutre
|-
|Loutre japonaise
|[[wikt:fr:日本川獺|日本川獺]]
|にほんあなぐま
|Nihon kawauso
|Japon (日本) Loutre (獺) (Cette espèce est aujourd’hui éteinte.)
|-
|Lycaon
|
|リカオン 
|rikaon
|
|-
|Lynx 
|[[wikt:fr:大山猫|大山猫]]
|おおやまねこ
|ōyamaneko
|Grand (大) Montagne (山) Chat (猫)
|-
|Marmotte
|
|ウッドチャック
|uddochakku
|Issu de l'anglais &quot;woodchuck&quot;.
|-
|Martre
|貂
|てん
|ten
|
|-
|Mouffette
|
|スカンク
|sukanku
|Skunk (en)
|-
|Mouton
|[[wikt:fr:羊|羊]]
|ひつじ
|hitsuji
|
|-
|Mule
|[[wikt:fr:騾馬|騾馬]]
|らば
|raba
|Cheval (馬)
|-
|Mulet
|[[wikt:fr:駃騠|駃騠]]
|けってい
|kettei
|
|-
|Narval
|[[wikt:一角|一角]]
|いっかく
|ikkaku
|Une (一), Corne (角)
|-
|Numbat
|[[wikt:袋蟻食|袋蟻食]]
|ふくろありくい 
|fukuroarikui
|Poche/Fourmilier 
|-
|Opossum
|
|[[wikt:オポッサム|オポッサム]]
|opossamu
|Opossum (en)
|-
|Ornithorynque 
|[[wikt:fr:鴨嘴|鴨嘴]]
|かものはし
|kamonohashi
|Canard/Bec
|-
|Ours
|[[wikt:fr:熊|熊]]
|くま
|kuma
|
|-
|Ours brun
|羆
|ひぐま
|higuma
|
|-
|Ours noir d’Asie
|月輪熊
|ツキノワグマ
|tsukinowaguma
|Lune/Anneau/Ours. Est parfois raccourci par ''tsukiguma'' (月熊)
|-
|Ours polaire
|[[wikt:fr:白熊|白熊]]
|しろくま
|shirokuma
|Blanc (白) Ours (熊)
|-
|Panda
|
|パンダ
|panda
|Panda (fr)
|-
|Paresseux
|[[wikt:樹懶|樹懶]]
|なまけもの
|namakemono
|
|-
|Petit panda
|
|レッサーパンダ
|ressā panda
|Issu de l'anglais &quot;lesser panda&quot;.
|-
|Porc-épic
|[[wikt:fr:山荒|山荒]]
|やまあらし
|yamaarashi
|Montagne (山) Stérile (荒)
|-
|Protèle
|[[wikt:fr:土狼|土狼]]
|つちおおかみ
|tsuchiōkami 
|Terre/Loup (On trouve également le terme 「アードウルフ」issu de l'anglais &quot;aardwolf&quot;.)
|-
|Puma
|
|ピューマ
|pyūma
|Puma (en)
|-
|Putois
|[[wikt:fr:毛長鼬|毛長鼬]]
|けながいたち
|kenagaitachi
|Poil long/Belette
|-
|Rat
|[[wikt:fr:熊鼠|熊鼠]]
|くまねずみ
|kumanezumi
|Ours/Souris
|-
|Raton laveur
|[[wikt:fr:洗熊|洗熊]]
|あらいぐま
|araiguma
|Laver/Ours
|-
|Renard
|[[wikt:fr:狐|狐]]
|きつね
|kitsune
|
|-
|Renard argenté
|[[wikt:fr:銀狐|銀狐]]
|ぎんぎつね
|gingitsune
|Argent (銀) Renard (狐)
|-
|Renard gris
|[[wikt:fr:灰色狐|灰色狐]]
|はいいろぎんぎつね
|haīro gitsune
|Cendre (灰) Couleur (色) Renard (狐)
|-
|Rhinoceros
|[[wikt:fr:犀|犀]]
|さい
|sai
|
|-
|Sanglier
|[[wikt:fr:猪|猪]]
|いのしし
|inoshishi
|
|-
|Saro
|鴨鹿
|カモシカ
|kamoshika
|Canard sauvage/Cerf. Les kanjis ne sont jamais utilisés, le nom est écrit exclusivement en katakana
|-
|Siamang
|[[wikt:fr:袋手長猿|袋手長猿]]
|ふくろてながざる
|fukurotenagazaru
|Sac/Main/Long/Singe
|-
|Singe
|[[wikt:fr:猿|猿]]
|さる
|saru
|
|-
|Souris
|[[wikt:fr:鼠|鼠]]
|ねずみ
|nezumi
|
|-
|Suricate
|
|ミーアキャット
|mīakyatto
|Meerkat (en)
|-
|Tamia
|[[wikt:fr:縞栗鼠|縞栗鼠]]
|しまりす
|shimarisu
|Rayure/Écureuil
|-
|Tapir
|[[wikt:fr:獏|獏]]
|ばく
|baku
|Issu de la créature légendaire : [[w:Baku|baku]], elle même issue des textes chinois sur le tapir. 
|-
|Taupe
|[[wikt:fr:土竜|土竜]]
|もぐら
|mogura
|Terre/Dragon
|-
|Taureau
|[[wikt:fr:雄牛|雄牛]]
|おうし
|oushi
|Mâle (雄) Vache (牛)
|-
|Tigre
|[[wikt:fr:虎|虎]]
|とら
|tora
|
|-
|Vache
|[[wikt:fr:牛|牛]]
|うし
|ushi
|
|-
|Veau
|[[wikt:fr:子牛|子牛]]
|こうし
|koushi
|Enfant (子) Vache (牛)
|-
|Vison
|
|ミンク
|minku
|mink (en)
|-
|Zèbre
|[[wikt:fr:縞馬|縞馬]]
|しまうま
|shimauma
|Rayure (縞) Cheval (馬)
|-
|Zèbre de montagne
|[[wikt:fr:山縞馬|山縞馬]]
|やましまうま
|yamashimauma
|Montagne (山) Zèbre (縞馬)
|-
|Zibeline 
|[[wikt:fr:黒貂|黒貂]]
|くろてん
|kuroten
|Noir (黒) Martre (貂)
|}

== Reptiles, poissons et autres vies marines ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Anguille
|[[wikt:fr:鰻|鰻]]
|うなぎ
|unagi
|
|-
|Barracuda
|[[wikt:fr:梭子魚|梭子魚]]
|かます
|kamasu
|Navette/Enfant/Poisson
|-
|Calamar
|[[wikt:fr:墨魚|墨魚]]
|いか
|ika
|Encre/Poisson
|-
|Carpe
|[[wikt:fr:鯉|鯉]]
|こい
|koi
|
|-
|Concombre de mer
|[[wikt:海鼠|海鼠]]
|なまこ
|namako
|Mer/Rat
|-
|Congre
|[[wikt:fr:穴子|穴子]]
|あなご
|anago
|Trou/Enfant
|-
|Crabe
|[[wikt:fr:蟹|蟹]]
|かに
|kani
|
|-
|Crabe de cocotier
|[[wikt:fr:椰子蟹|椰子蟹]]
|やしがに
|yashigani
|Palmier/Crabe
|-
|Crapaud 
|[[wikt:蟇蛙|蟇蛙]]
|ひきがえる
|hikigaeru
|Crapaud/Grenouille
|-
|Crevette
|[[wikt:fr:蝦|蝦]]
|えび
|ebi
|
|-
|Crocodile
|[[wikt:fr:鰐|鰐]]
|わに
|wani
|
|-
|Dragon
|[[wikt:fr:竜|竜]]
|りゅう
|ryū
|Pour parler d'un dragon occidental, on emploiera「ドラゴン」.
|-
|Dragon de Komodo
|
|コモドドラゴン
|Komodo-doragon
|Komodo Dragon (en)
|-
|Escargot
|[[wikt:fr:蝸牛|蝸牛]]
|かたつむり
|katatsumuri
|Escargot/Vache
|-
|Gecko
|[[wikt:守宮|守宮]]
|やもり
|yamori
|Protection/Palais
|-
|Gecko léopard
|[[wikt:豹紋蜥蜴擬き|豹紋蜥蜴擬き]]
|ひょうもんとかげもどき
|hyōmon'tokagemodoki
|/Lézard/
|-
|Grenouille
|[[wikt:fr:蛙|蛙]]
|かえる
|kaeru
|
|-
|Iguane
|
|イグアナ
|iguana
|Iguana(en)
|-
|Léopard de mer
|[[wikt:fr:豹海豹|豹海豹]]
|ひょうあざらし
|hyōazarashi
|Panthère/Phoque
|-
|Méduse
|[[wikt:fr:水母|水母]]／[[wikt:fr:海月|海月]]
|くらげ
|kurage
|Eau/Mère ; Mer/Lune
|-
|Morse
|[[wikt:fr:海象|海象]]
|せいうち
|seiuchi
|Mer/Éléphant
|-
|Murène
|[[wikt:鱓|鱓]]
|うつぼ
|utsubo
|/
|-
|Orque
|[[wikt:fr:鯱|鯱]]
|しゃち
|shachi
|/
|-
|Otarie
|[[wikt:fr:海驢|海驢]]
|あしか
|ashika
|Mer/Âne
|-
|Phoque
|[[wikt:fr:海豹|海豹]]
|あざらし
|azarashi
|Mer/Panthère
|-
|Pieuvre
|[[wikt:fr:蛸|蛸]] 
|たこ
|tako
|
|-
|Poisson
|[[wikt:fr:魚|魚]]
|さかな
|sakana
|
|-
|Poisson rouge
|[[wikt:fr:金魚|金魚]]
|きんぎょ
|kingyo
|Or/Poisson
|-
|Raie
|[[wikt:fr:鱝|鱝]]
|えい
|ei
|Poisson/Orné
|-
|Requin
|[[wikt:fr:鮫|鮫]]
|さめ
|same
|Poisson/Croisement
|-
|Requin-baleine 
|甚兵衛鮫
|じんべいざめ
|jinbeizame
|Jinbei/Requin
|-
|Requin-renard
|[[wikt:fr:尾長鮫|尾長鮫]]
|おながざめ
|onagazame
|Longue queue/Requin
|-
|Requin-tigre
|[[wikt:fr:鼬鮫|鼬鮫]]
|いたちざめ
|itachizame
|Belette/Requin
|-
|Salamandre
|[[wikt:fr:蠑螈|蠑螈]]
|いもり
|imori
|/
|-
|Sardine
|[[wikt:鰯|鰯]]
|いわし
|iwashi
|Poisson/Faible
|-
|Serpent
|[[wikt:fr:蛇|蛇]]
|へび
|hebi
|
|-
|Thon
|[[wikt:fr:鮪|鮪]]
|まぐろ
|maguro
|Poisson/Bleu
|-
|Tortue
|[[wikt:fr:亀|亀]]
|かめ
|kame
|
|-
|Tortue de mer
|[[wikt:fr:海亀|海亀]]
|うみがめ
|umigame
|Mer/Tortue
|}

== Voir aussi ==
*Une série d'[[Japonais/Exercices de vocabulaire#Animaux|exercices]] sur les animaux est également disponible.
*[[wikt:fr:Catégorie:Noms_communs_japonais|Les noms dans le wiktionnaire]]

{{Glossaires_de_Japonais}}
[[Catégorie:Glossaires de Japonais]]

[[en:Japanese/Vocabulary/Animals]]
[[es:Japonés/Vocabulario/Animales]]</text>
      <sha1>pjhp2zkztj4ijhd5lqvw3sf9s4qbszq</sha1>
    </revision>
    <revision>
      <id>745462</id>
      <parentid>745461</parentid>
      <timestamp>2025-06-27T11:58:07Z</timestamp>
      <contributor>
        <ip>2A01:CB05:8BC9:BF00:A9DC:319E:88D2:6C97</ip>
      </contributor>
      <comment>/* Insectes */</comment>
      <origin>745462</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="23968" sha1="9u771fciyhkddc52vnge66p1m9ijhjy" xml:space="preserve">== Classifications ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Chaîne alimentaire
|[[wikt:fr:食物連鎖|食物連鎖]]
|しょくもつれんさ
|shokumotsu rensa
|/
|-
|Pâture
|[[wikt:fr:餌食|餌食]]
|えじき
|ejiki
|/
|-
|Prédateur
|[[wikt:fr:捕食者|捕食者]]
|ほしょくしゃ
|hoshokusha
|/
|-
|Prédation
|[[wikt:fr:捕食|捕食]]
|ほしょく
|hoshoku
|/
|-
|Proie
|[[wikt:fr:獲物|獲物]]
|えもの
|emono
|/
|}


== Ordres ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Carnivore
|[[wikt:fr:肉食動物|肉食動物]]
|にくしょくどうぶつ
|nikushoku dōbutsu
|Carnivore/Animal
|-
|Herbivore
|[[wikt:fr:草食動物|草食動物]]
|そうしょくどうぶつ
|sōshoku dōbutsu
|Herbivore/Animal
|-
|Frugivore
|[[wikt:fr:|fr:]]
|
|
|Frugivore/Animal
|-
|Granivore
|[[wikt:fr:|fr:]]
|
|
|Granivore/Animal
|-
|Insectivore
|[[wikt:fr:食虫動物|食虫動物]]
|しょくちゅうどうぶつ
|shokuchū dōbutsu
|Insectivore/Animal
|-
|Omnivore
|[[wikt:fr:雑食動物|雑食動物]]
|ざっしょくどうぶつ
|zasshoku dōbutsu
|Omnivore/Animal
|}

== Arachnides ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Acarien/Pou
|[[wikt:fr:壁蝨|壁蝨]]
|だに
|dani
|
|-
|Araignée
|[[wikt:fr:蜘蛛|蜘蛛]]
|くも
|kumo
|
|-
|Scorpion
|[[wikt:fr:蠍|蠍]]
|さそり
|sasori
|
|}

== Insectes ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Abeille
|[[wikt:fr:蜂|蜂]]
|はち
|hachi
|
|-
|Blatte, cafard
|[[wikt:fr:蜚蠊|蜚蠊]]
|ごきぶり
|gokiburi
|
|-
|Cigale
|[[wikt:fr:蝉|蝉]]
|せみ
|semi
|/Insecte
|-
|Coccinelle
|[[wikt:fr:天道虫|天道虫]]
|てんとうむし
|tentōmushi
|Sentier céleste/Insecte
|-
|Criquet
|[[wikt:飛蝗|飛蝗]]
|ばった
|batta
|/Insecte
|-
|Grillon
|[[wikt:fr:蟋蟀|蟋蟀]]
|こおろぎ
|kōrogi
|/Insecte
|-
|Fourmi
|[[wikt:fr:蟻|蟻]]
|あり
|ari
|/Insecte
|-
|Guêpe, frelon
|[[wikt:fr:雀蜂|雀蜂]]
|すずめばち
|suzumebachi
|Moineau/Abeille
|-
|　
|[[wikt:fr:|頬長雀蜂]]
|ほおながスズメバチ
|hōnagasuzumebachi
|Joue/Long/Guêpe
|-
|Insecte
|[[wikt:fr:虫|虫]]
|むし 
|mushi
|
|-
|Libellule
|[[wikt:fr:蜻蛉|蜻蛉]]
|とんぼ
|tonbo
|/Insecte
|-
|Luciole
|[[wikt:fr:蛍|蛍]]
|ほたる
|hotaru
|Petit couvercle/Insecte
|-
|Mante religieuse
|[[wikt:fr:蟷螂|蟷螂]]
|かまきり
|kamakiri
|/
|-
|Mouche
|[[wikt:fr:蝿|蝿]]
|はえ
|hae
|
|-
|Moustique
|[[wikt:fr:蚊|蚊]]
|か
|ka
|
|-
|Papillon
|[[wikt:fr:蝶|蝶]]
|ちょう
|chō
|
|-
|Puce
|[[wikt:fr:蚤|蚤]]
|のみ
|nomi
|
|-
|Sauterelle
|[[wikt:蝗|蝗]]
|いなご
|inago
|/Insecte
|-
|Scarabée
|[[wikt:fr:兜虫|兜虫]]
|かぶとむし 
|kabutomushi
|Casque/Insecte
|}

==Oiseaux==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Hirgana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Aigle
|[[wikt:fr:鷲|鷲]]
|わし
|washi
|Lieu grandiose/Oiseau
|-
|Aigle royal
|[[wikt:fr:犬鷲|犬鷲]]
|いぬわし
|inuwashi
|Chien/Aigle
|-
|Aigrette
|[[wikt:fr:白鷺|白鷺]]
|しらさぎ
|shirasagi
|Blanc/Héron
|-
|Aigrette sacrée
|[[wikt:fr:黒鷺|黒鷺]]
|くろさぎ
|kurosagi
|Noir/Héron
|-
|Alouette
|[[wikt:fr:雲雀|雲雀]]
|ひばり
|hibari
|Nuage/Moineau
|-
|Autruche
|[[wikt:fr:鴕鳥|鴕鳥]]
|だちょう
|dachō
|Autruche/Oiseau
|-
|Bécasse
|[[wikt:fr:山鴫|山鴫]]
|やましぎ
|yamashigi
|Montagne/Chevalier
|-
|Bihoreau goisagi
|[[wikt:fr:溝五位|溝五位]]
|みぞごい
|mizogoi
|Fossé/Cinq/Couronne
|-
|Bihoreau violacé
|[[wikt:fr:蓑五位|蓑五位]]
|みのごい
|minogoi
|Manteau de paille/Cinq/Couronne
|-
|Caille
|[[wikt:fr:鶉|鶉]]
|うずら
|uzura
|/Oiseau
|-
|Calao
|[[wikt:fr:犀鳥|犀鳥]]
|さいちょう
|saichō
|Rhinocéros/Oiseau
|-
|Calopsitte 
|[[wikt:阿亀鸚哥|阿亀鸚哥]]
|おかめいんこ
|okame inko
|Femme inélégante/Perruche
|-
|Canard 
|[[wikt:fr:鴨|鴨]] (sauvage)&lt;br /&gt;[[wikt:fr:家鴨|家鴨]] (domestique)
|かも&lt;br /&gt;あひる
|kamo&lt;br /&gt;ahiru
|Enveloppe dure/Oiseau&lt;br /&gt;Maison/Canard sauvage
|-
|Canard colvert
|[[wikt:fr:真鴨|真鴨]]
|まがも
|magamo
|Vrai/Canard sauvage
|-
|Canard mandarin
|[[wikt:fr:鴛鴦|鴛鴦]]
|おしどり
|oshidori
|/
|-
|Canaroie semipalmée
|[[wikt:fr:鵲雁|鵲雁]]
|かささぎがん
|kasasagigan
|Pie/Oie sauvage
|-
|Casoar
|[[wikt:fr:火食鳥|火食鳥]]
|ひくいどり
|hikuidori
|Feu/Mangeant/Oiseau
|-
|Cassican flûteur 
|[[wikt:fr:鵲笛鴉|鵲笛鴉]]
|かささぎふえがらす
|kasasagi fuegarasu
|Pie/Flûte/Corbeau
|-
|Chouette
|[[wikt:fr:梟|梟]]
|ふくろう
|fukurō
|Oiseau/Arbre
|-
|Cigogne
|[[wikt:fr:鸛|鸛]]
|こうのとり
|kōnotori
|Enfant/Oiseau
|-
|Cigogne blanche
|[[wikt:fr:朱嘴鸛|朱嘴鸛]]
|しゅばしこう
|shubashikō
|Vermillon/Bec/Cigogne
|-
|Cigogne d'Abdim
|[[wikt:fr:青端鸛|青端鸛]]
|あおはしこう
|aohashikō
|Bleu/Extrémité/Cigogne
|-
|Cigogne épiscopale
|[[wikt:fr:白襟鸛|白襟鸛]]
|しろえりこう
|shiroerikō
|Blanc/Cou/Cigogne
|-
|Cigogne maguari
|[[wikt:fr:燕尾鸛|燕尾鸛]]
|えんびこう
|enbikō
|Hirondelle/Queue/Cigogne
|-
|Cigogne noire
|[[wikt:fr:鍋鸛|鍋鸛]]
|なべこう
|nabekō
|Chaudron/Cigogne
|-
|Colombe/Pigeon
|[[wikt:fr:鳩|鳩]]
|はと
|hato
|/Oiseau
|-
|Condor
|[[wikt:fr:公佗児|公佗児]]
|こうわじ
|kōwaji
|Public/Fier ; solitaire/ (On trouve également le terme 「コンドル」issu de l'anglais &quot;condor&quot;.)
|-
|Coq de bruyère
|[[wikt:fr:雷鳥|雷鳥]]
|らいちょう
|raichō
|Tonnerre/Oiseau
|-
|Coq
|[[wikt:fr:雄鳥|雄鳥]]
|おんどり
|ondori
|Mâle/Oiseau
|-
|Corbeau
|[[wikt:fr:烏|烏]]
|からす
|karasu
|Terme général désignant les animaux du genre ''corvus''
|-
|Corneille mantelée
|[[wikt:fr:頭巾烏|頭巾烏]]
|ずきんがらす
|zukingarasu
|Capuche/Corbeau
|-
|Dinde
|[[wikt:fr:七面鳥|七面鳥]]
|しちめんちょう
|shichimenchō
|Sept visages/Oiseau
|-
|Faisan
|[[wikt:fr:雉|雉]]
|きじ 
|kiji
|
|-
|Faucon
|[[wikt:fr:鷹|鷹]]
|たか
|taka
|
|-
|Faucon crécerelle
|[[wikt:fr:長元坊|長元坊]]
|ちょうげんぼう
|chōgenbō
|Chef/Fondation/Chambre
|-	
|Faucon pèlerin
|[[wikt:fr:隼|隼]]
|はやぶさ
|hayabusa
|
|-
|Geai
|[[wikt:fr:懸巣|懸巣]]
|かけす
|kakesu
|/
|-
|Grand-duc de Blakiston
|[[wikt:fr:島梟|島梟]]
|しまふくろう
|shimafukurō
|Île/Chouette
|-
|Grèbe castagneux
|[[wikt:fr:鸊鷉|鸊鷉]]
|かいつぶり
|kaitsuburi
|/
|-
|Grive
|[[wikt:fr:鶇|鶇]]
|つぐみ
|tsugumi
|Tenir sa langue/Oiseau
|-
|Grue demoiselle
|[[wikt:fr:姉羽鶴|姉羽鶴]]
|あねはづる
|anehazuru
|Grande sœur/Aile/Grue
|-
|Grue
|[[wikt:fr:鶴|鶴]]
|つる
|tsuru
|S'élever/Oiseau
|-
|Grue royale
|[[wikt:fr:頬白冠鶴|頬白冠鶴]]
|ほおじろかんむりづる
|hōjiro kanmurizuru
|Bruant à longue queue/Grue couronnée
|-
|Harpie féroce
|[[wikt:fr:扇鷲|扇鷲]]
|おうぎわし
|ōgiwashi
|Éventail/Aigle
|-
|Héron cendré
|[[wikt:fr:蒼鷺|蒼鷺]]
|あおさぎ
|aosagi
|Bleu/Héron
|-
|Hibou
|[[wikt:fr:木菟|木菟]]
|みみずく
|mimizuku
|Arbre/Lapin
|-
|Hirondelle
|[[wikt:fr:燕|燕]]
|つばめ
|tsubame
|
|-
|Hirondelle bicolore
|[[wikt:fr:緑燕|緑燕]]
|みどりつばめ
|midori tsubame
|Vert/Hirondelle
|-
|Huppe fasciée
|[[wikt:fr:戴勝|戴勝]]
|やつがしら
|yatsugashira
|Serviteur/Tête
|-
|Lagopède alpin
|[[wikt:fr:雷鳥|雷鳥]]
|らいちょう 
|raichō
|Foudre/Oiseau
|-
|Macareux moine
|[[wikt:fr:西角目鳥|西角目鳥]]
|にしつのめどり
|nishitsunomedori
|Ouest/Macareux cornu
|-
|Martinet
|[[wikt:fr:雨燕|雨燕]]
|あまつばめ
|amatsubame
|Pluie/Hirondelle
|-
|Moineau
|[[wikt:fr:雀|雀]]
|すずめ
|suzume
|
|-
|Mouette
|[[wikt:fr:鴎|鴎]]
|かもめ
|kamome
|Arrondissement citadin/Oiseau
|-
|Oie
|[[wikt:fr:鵞鳥|鵞鳥]]
|がちょう
|gachō
|Oie/Oiseau
|-
|Oiseau de proie
|[[wikt:fr:猛禽|猛禽]]
|もうきん
|mōkin
|Fureur/Oiseau
|-
|Oiseau
|[[wikt:fr:鳥|鳥]]
|とり
|tori
|
|-
|Palombe/Ramier
|[[wikt:fr:森鳩|森鳩]]
|もりばと
|moribato
|Forêt/Pigeon
|-
|Paon
|[[wikt:fr:孔雀|孔雀]]
|くじゃく
|kujaku
|Cavité/Moineau
|-
|Paradisier
|[[wikt:fr:風鳥|風鳥]]
|ふうちょう
|fūchō
|Vent/Oiseau
|-
|Perroquet
|[[wikt:fr:鸚鵡|鸚鵡]]
|おうむ 
|ōmu
|
|-
|Perruche
|[[wikt:fr:鸚哥|鸚哥]]
|いんこ
|inko
|
|-
|Pie
|[[wikt:fr:鵲|鵲]]
|かささぎ
|kasasagi
|Autrefois/Oiseau
|-
|Plongeon imbrin
|[[wikt:fr:嘴黒阿比|嘴黒阿比]]
|はしぐろあび
|hashiguroabi
|Bec noir/Plongeon
|-
|Poule
|[[wikt:fr:雌鶏|雌鶏]] 
|めんどり
|mendori
|Femelle/Poulet
|-
|Poulet 
|[[wikt:fr:鶏|鶏]] (domestique)
|にわとり
|niwatori
|Jardin/Oiseau
|-
|Passerin indigo 
|[[wikt:fr:瑠璃野路子|瑠璃野路子]]
|るりのじこ
|rurinojiko
|/Enfant
|-
|Roitelet
|[[wikt:fr:鷦鷯|鷦鷯]]
|みそさざい
|misosazai
|/
|-
|Roselin pourpré
|[[wikt:fr:紫猿子|紫猿子]]
|むらさきましこ
|murasaki mashiko
|Violet/Singe/Enfant
|-
|Rossignol
|[[wikt:fr:小夜啼鳥|小夜啼鳥]]
|さよなきどり
|sayonakidori
|Petite nuit/Oiseau chanteur
|-
|Rouge-gorge
|[[wikt:fr:駒鳥|駒鳥]]
|こまどり
|komadori
|Chevalet/Oiseau
|-
|Sarcelle
|[[wikt:fr:小鴨|小鴨]]
|こがも
|kogamo
|Petit/Canard sauvage
|-
|Sterne arctique
|[[wikt:fr:極鰺刺|極鰺刺]]
|きょくあじさし
|kyokuajisashi
|Extrême/Sterne
|-
|Sterne
|[[wikt:fr:鰺刺|鰺刺]]
|あじさし
|ajisashi
|Chinchard/
|-
|Toucan
|[[wikt:fr:大嘴|大嘴]]
|おおはし
|ōhashi
|Grand/Bec
|-
|Tourterelle 
|[[wikt:fr:山鳩|山鳩]]
|やまばと
|yamabato
|Montagne/Colombe, pigeon
|-
|Tourterelle des bois
|[[wikt:fr:小雉鳩|小雉鳩]]
|こきじばと
|kokijibato
|Petit/Tourterelle occidentale
|-
|Vautour
|[[wikt:fr:禿鷹|禿鷹]]
|はげたか
|hagetaka
|Calvitie/Faucon
|}

== Mammifères ==

[[Image:Books-aj.svg aj ashton 01.svg|right|70px]]
{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Agneau
|[[wikt:fr:子羊|子羊]]
|こひつじ
|kohitsuji
|Enfant/Mouton
|-
|Alpaga
|
|アルパカ
|arupaka
|
|-
|Âne
|[[wikt:fr:驢馬|驢馬]]
|ろば
|roba
|Ce terme s'écrit en katakana comme suit :「ロバ」
|-
|Babouin
|[[wikt:狒々|狒々]]
|ひひ
|hihi
|Issu de la créature légendaire du folklore japonais : ''[[w:Hi-hi|Hi-hi]]''
|-
|Baleine
|[[wikt:fr:鯨|鯨]] 
|くじら
|kujira
|Ce terme s'écrit en katakana comme suit :「クジラ」
|-
|Bassaris rusé
|
|カコミスル
|kakomisuru
|Issu de l'anglais « cacomistle ».
|-
|Belette d’Europe
|[[wikt:fr:飯綱|飯綱]]
|いいづな
|īzuna
|Riz/corde. Désignait originellement une créature légendaire du nom de [[w:Kuda-kitsune|kuda-gitsune]].
|-
|Belette du Japon / Itatsi
|㹨
|いたち
|Itachi
|Désigne également les mustélidés en général. Ce terme s’écrit en katakana comme suit : 「イタチ」
|-
|Bélier
|[[wikt:雄羊|雄羊]]
|おひつじ
|ohitsuji
|Mâle/Mouton
|-
|Bison
|[[wikt:野牛|野牛]]
|やぎゅう
|yagyū
|Champ/Bœuf. Est surtout désigné sous le terme baizon 「バイゾン」
|-
|Blaireau
|[[wikt:fr:穴熊|穴熊]]
|あなぐま
|anaguma
|Trou (穴) Ours (熊). Ce terme s'écrit en katakana comme suit :「アナグマ」
|-
|Blaireau japonais
|[[wikt:fr:日本穴熊|日本穴熊]]
|にほんあなぐま
|Nihon anaguma
|Japon (日本) Blaireau (穴熊)
|-
|Bouc
|[[wikt:雄山羊|雄山羊]]
|おやぎ
|oyagi
|Mâle/Chèvre
|-
|Brebis
|[[wikt:雌羊|雌羊]]
|めひつじ
|mehitsuji
|Femelle/Mouton
|-
|Buffle
|水牛
|すいぎゅ
|suigyu
|Eau/Bœuf : Vient du buffle d’Eau d’Asie.
|-
|Castor
|
|ビーバー
|bībā
|Beaver (en)
|-
|Chameau
|[[wikt:fr:駱駝|駱駝]]
|らくだ
|rakuda
|
|-
|Chat
|[[wikt:fr:猫|猫]]
|ねこ
|neko
|
|-
|Chaton
|[[wikt:fr:子猫|子猫]]
|こねこ
|koneko
|Enfant/Chat
|-
|Chauve-souris
|[[wikt:fr:蝙蝠|蝙蝠]]
|こうもり
|kōmori 
|
|-
|Chevreau
|[[wikt:子山羊|子山羊]]
|こやぎ
|koyagi
|Enfant/Chèvre
|-
|Chevreuil
|[[wikt:麕鹿|麕鹿]]
|のろじか
|norojika
|Chevreuil/Cerf
|-
|Cerf
|[[wikt:fr:鹿|鹿]]
|しか
|shika
|
|-
|Cerf du père David
|四不像
|ししふうぞう
|shifuzō
|Quatre/Négatif/Image(en tête). Du chinois « aucun des quatre »
|-
|Cerf sika
|日本鹿
|にほんじか
|Nihon jika
|Japon/Cerf
|-
|Chacal
|
|ジャッカル
|jakkaru
|jackal (en)
|-
|Cheval
|[[wikt:fr:馬|馬]]
|うま
|uma
|
|-
|Chèvre 
|[[wikt:fr:山羊|山羊]]
|やぎ
|yagi
|Montagne (山) Mouton (羊)
|-
|Chien
|[[wikt:fr:犬|犬]]
|いぬ
|inu
|
|-
|Chien viverrin / Tanuki
|[[wikt:fr:狸|狸]]
|たぬき
|tanuki
|
|-
|Chinchilla
|
|チンチラ
|chinchira
|
|-
|Chiot
|[[wikt:fr:子犬|子犬]]
|こいぬ
|koinu
|Enfant (子) Chien (犬)
|-
|Civette
|[[wikt:fr:麝香猫|麝香猫]] 
|じゃこうねこ 
|jakōneko
|Musc (麝香) Chat (猫)  
|-
|Coati
|鼻熊
|はなぐま
|hanaguma
|Nez (鼻) Ours (熊)
|-
|Cochon
|[[wikt:fr:豚|豚]]
|ぶた
|buta
|
|-
|Cochon d'Inde
|
|モルモット
|morumotto
|On trouve également le terme 「ギニアピッグ」
|-
|Coyote
|
|コヨーテ
|koyōte
|
|-
|Daim
|
|ダマジカ
|damajika
|Dama(Daim)/Cerf
|-
|Dasyure
|[[wikt:fr:袋猫|袋猫]]
|ふくろねこ
|fukuroneko
|Sac (袋) Chat (猫)
|-
|Dauphin
|[[wikt:fr:海豚|海豚]]
|いるか
|iruka
|Mer/Cochon
|-
|Dègue
|
|デグー
|degū
|
|-
|Dhole
|犲
|やまいぬ
|Yamainu
|Montagne/Chien. Confondu avec les chiens errants et les loups, est aujourd’hui plutôt désigné sous le nom de ''dōru'' 「ドール」
|-
|Dromadaire
|[[wikt:fr:一瘤駱駝|一瘤駱駝]]
|ひとこぶらくだ
|hitokobu rakuda
|Bosse unique/Chameau
|-
|Dugong / Vache marine
|儒艮
|じゅごん
|jugon
|
|-
|Échidné
|[[wikt:fr:針土竜|針土竜]]
|はりねずみ
|harimogura
|Aiguille/Taupe
|-
|Écureuil
|[[wikt:fr:栗鼠|栗鼠]]
|りす
|risu
|Noix (栗) Rat (鼠)
|-
|Écureuil volant
|[[wikt:fr:鼯鼠|鼯鼠]]
|ももんが
|momonga
|Écureuil volant (鼯) Rat (鼠)
|-
|Élan
|[[wikt:fr:箆鹿|箆鹿]]
|へらじか
|herajika
|Spatule (箆) Cerf (鹿)
|-
|Éléphant
|[[wikt:fr:象|象]]
|ぞう
|zō
|-
|Faon
|[[wikt:子鹿|子鹿]]
|こじか
|kojika
|Enfant/Cerf
|-
|Fouine
|[[wikt:fr:胸白貂|胸白貂]]
|むねしろてん
|muneshiroten
|Poitrail blanc/Martre
|-
|Furet
|[[wikt:fr:白鼬|白鼬]]
|しろいたち
|shiroitachi
|Blanc/Belette (On trouve également le terme「フェレット」issu de l'anglais &quot;ferret&quot;.)
|-
|Gerbille de Mongolie
|[[wikt:fr:砂鼠|砂鼠]]
|すなねずみ
|sunanezumi
|Sable (砂) Souris (鼠)
|-
|Gibbon
|[[wikt:fr:手長猿|手長猿]]
|てながざる
|tenagazaru
|Main/Long/Singe
|-
|Gibbon à mains blanches
|[[wikt:fr:白手手長猿|白手手長猿]]
|しろててながざる
|shirote tenagazaru
|Blanc/Main/Long/Singe
|-
|Girafe
|[[wikt:fr:麒麟|麒麟]]
|きりん
|kirin
|Issue de la créature légendaire du folklore assiatique : [[w:Qilin|Qilin]]
|-
|Glouton
|[[wikt:fr:屈狸|屈狸]]
|くずり
|kuzuri
|Ce terme s'écrit en katakana comme suit:「クズリ」
|-
|Gorille
|
|ゴリラ
|gorira
|Gorilla (en)
|-
|Grizzly
|[[wikt:fr:灰色熊|灰色熊]]
|はいいろぐま
|haīroguma
|Gris/Ours
|-
|Guépard
|[[wikt:fr:狩猟豹|狩猟豹]]
|しゅりょうひょう
|shuryōhyō
|Chasse/Panthère (On trouve également le terme 「チーター」issu de l'anglais &quot;cheetah&quot;.)
|-
|Hamster
|
|ハムスター
|hamusutā
|Hamster (fr)
|-
|Hermine
|[[wikt:fr:白鼬|白鼬]]
|おこじょ
|okojo
|Blanc/Belette
|-
|Hérisson
|[[wikt:fr:針鼠|針鼠]]
|はりねずみ
|harinezumi
|Aiguille (針) Rat (鼠)
|-
|Hippopotame
|[[wikt:fr:河馬|河馬]]
|かば
|kaba
|Fleuve (河) Cheval (馬)
|-
|Kinkajou
|
|キンカジュー
|kinkajū
|Variante de quincajou.
|-
|Lama
|
|ラマ
|rama
|Lama (fr)
|-
|Lamantin
|
|マナティー
|manatī
|Issu de l'anglais &quot;manatee&quot;.
|-
|Lapin
|[[wikt:fr:兎|兎]]
|うさぎ
|usagi
|Terme général désignant les lagomorphes
|-
|Léopard/Panthère
|[[wikt:豹#ja|豹]]
|ひょう
|hyō
|
|-
|Lièvre
|[[wikt:fr:野兎|野兎]]
|のうさぎ
|nousagi
|Champ (野) Lapin (兎)
|-
|Lion
|[[wikt:fr:獅子|獅子]]
|しし
|shishi
|Le terme 「ライオン」 issu de l'anglais &quot;lion&quot; est aujourd'hui plus largement utilisé.
|-
|Loup
|[[wikt:fr:狼|狼]]
|おおかみ
|ōkami
|
|-
|Loutre
|[[wikt:fr:川獺|川獺]]
|かわうそ
|kawauso
|Rivère (川) Loutre (獺)
|-
|Loutre de mer
|海獺
|らっこ
|rakko
|Mer/Loutre
|-
|Loutre japonaise
|[[wikt:fr:日本川獺|日本川獺]]
|にほんあなぐま
|Nihon kawauso
|Japon (日本) Loutre (獺) (Cette espèce est aujourd’hui éteinte.)
|-
|Lycaon
|
|リカオン 
|rikaon
|
|-
|Lynx 
|[[wikt:fr:大山猫|大山猫]]
|おおやまねこ
|ōyamaneko
|Grand (大) Montagne (山) Chat (猫)
|-
|Marmotte
|
|ウッドチャック
|uddochakku
|Issu de l'anglais &quot;woodchuck&quot;.
|-
|Martre
|貂
|てん
|ten
|
|-
|Mouffette
|
|スカンク
|sukanku
|Skunk (en)
|-
|Mouton
|[[wikt:fr:羊|羊]]
|ひつじ
|hitsuji
|
|-
|Mule
|[[wikt:fr:騾馬|騾馬]]
|らば
|raba
|Cheval (馬)
|-
|Mulet
|[[wikt:fr:駃騠|駃騠]]
|けってい
|kettei
|
|-
|Narval
|[[wikt:一角|一角]]
|いっかく
|ikkaku
|Une (一), Corne (角)
|-
|Numbat
|[[wikt:袋蟻食|袋蟻食]]
|ふくろありくい 
|fukuroarikui
|Poche/Fourmilier 
|-
|Opossum
|
|[[wikt:オポッサム|オポッサム]]
|opossamu
|Opossum (en)
|-
|Ornithorynque 
|[[wikt:fr:鴨嘴|鴨嘴]]
|かものはし
|kamonohashi
|Canard/Bec
|-
|Ours
|[[wikt:fr:熊|熊]]
|くま
|kuma
|
|-
|Ours brun
|羆
|ひぐま
|higuma
|
|-
|Ours noir d’Asie
|月輪熊
|ツキノワグマ
|tsukinowaguma
|Lune/Anneau/Ours. Est parfois raccourci par ''tsukiguma'' (月熊)
|-
|Ours polaire
|[[wikt:fr:白熊|白熊]]
|しろくま
|shirokuma
|Blanc (白) Ours (熊)
|-
|Panda
|
|パンダ
|panda
|Panda (fr)
|-
|Paresseux
|[[wikt:樹懶|樹懶]]
|なまけもの
|namakemono
|
|-
|Petit panda
|
|レッサーパンダ
|ressā panda
|Issu de l'anglais &quot;lesser panda&quot;.
|-
|Porc-épic
|[[wikt:fr:山荒|山荒]]
|やまあらし
|yamaarashi
|Montagne (山) Stérile (荒)
|-
|Protèle
|[[wikt:fr:土狼|土狼]]
|つちおおかみ
|tsuchiōkami 
|Terre/Loup (On trouve également le terme 「アードウルフ」issu de l'anglais &quot;aardwolf&quot;.)
|-
|Puma
|
|ピューマ
|pyūma
|Puma (en)
|-
|Putois
|[[wikt:fr:毛長鼬|毛長鼬]]
|けながいたち
|kenagaitachi
|Poil long/Belette
|-
|Rat
|[[wikt:fr:熊鼠|熊鼠]]
|くまねずみ
|kumanezumi
|Ours/Souris
|-
|Raton laveur
|[[wikt:fr:洗熊|洗熊]]
|あらいぐま
|araiguma
|Laver/Ours
|-
|Renard
|[[wikt:fr:狐|狐]]
|きつね
|kitsune
|
|-
|Renard argenté
|[[wikt:fr:銀狐|銀狐]]
|ぎんぎつね
|gingitsune
|Argent (銀) Renard (狐)
|-
|Renard gris
|[[wikt:fr:灰色狐|灰色狐]]
|はいいろぎんぎつね
|haīro gitsune
|Cendre (灰) Couleur (色) Renard (狐)
|-
|Rhinoceros
|[[wikt:fr:犀|犀]]
|さい
|sai
|
|-
|Sanglier
|[[wikt:fr:猪|猪]]
|いのしし
|inoshishi
|
|-
|Saro
|鴨鹿
|カモシカ
|kamoshika
|Canard sauvage/Cerf. Les kanjis ne sont jamais utilisés, le nom est écrit exclusivement en katakana
|-
|Siamang
|[[wikt:fr:袋手長猿|袋手長猿]]
|ふくろてながざる
|fukurotenagazaru
|Sac/Main/Long/Singe
|-
|Singe
|[[wikt:fr:猿|猿]]
|さる
|saru
|
|-
|Souris
|[[wikt:fr:鼠|鼠]]
|ねずみ
|nezumi
|
|-
|Suricate
|
|ミーアキャット
|mīakyatto
|Meerkat (en)
|-
|Tamia
|[[wikt:fr:縞栗鼠|縞栗鼠]]
|しまりす
|shimarisu
|Rayure/Écureuil
|-
|Tapir
|[[wikt:fr:獏|獏]]
|ばく
|baku
|Issu de la créature légendaire : [[w:Baku|baku]], elle même issue des textes chinois sur le tapir. 
|-
|Taupe
|[[wikt:fr:土竜|土竜]]
|もぐら
|mogura
|Terre/Dragon
|-
|Taureau
|[[wikt:fr:雄牛|雄牛]]
|おうし
|oushi
|Mâle (雄) Vache (牛)
|-
|Tigre
|[[wikt:fr:虎|虎]]
|とら
|tora
|
|-
|Vache
|[[wikt:fr:牛|牛]]
|うし
|ushi
|
|-
|Veau
|[[wikt:fr:子牛|子牛]]
|こうし
|koushi
|Enfant (子) Vache (牛)
|-
|Vison
|
|ミンク
|minku
|mink (en)
|-
|Zèbre
|[[wikt:fr:縞馬|縞馬]]
|しまうま
|shimauma
|Rayure (縞) Cheval (馬)
|-
|Zèbre de montagne
|[[wikt:fr:山縞馬|山縞馬]]
|やましまうま
|yamashimauma
|Montagne (山) Zèbre (縞馬)
|-
|Zibeline 
|[[wikt:fr:黒貂|黒貂]]
|くろてん
|kuroten
|Noir (黒) Martre (貂)
|}

== Reptiles, poissons et autres vies marines ==

{| {{tableau_japonais}}
! Français !! [[Japonais/Kanji|Kanji]] !! [[Japonais/Kana|Kana]] !! [[Japonais/Romaji|Rōmaji]] !! Sens littéral
|-
|Anguille
|[[wikt:fr:鰻|鰻]]
|うなぎ
|unagi
|
|-
|Barracuda
|[[wikt:fr:梭子魚|梭子魚]]
|かます
|kamasu
|Navette/Enfant/Poisson
|-
|Calamar
|[[wikt:fr:墨魚|墨魚]]
|いか
|ika
|Encre/Poisson
|-
|Carpe
|[[wikt:fr:鯉|鯉]]
|こい
|koi
|
|-
|Concombre de mer
|[[wikt:海鼠|海鼠]]
|なまこ
|namako
|Mer/Rat
|-
|Congre
|[[wikt:fr:穴子|穴子]]
|あなご
|anago
|Trou/Enfant
|-
|Crabe
|[[wikt:fr:蟹|蟹]]
|かに
|kani
|
|-
|Crabe de cocotier
|[[wikt:fr:椰子蟹|椰子蟹]]
|やしがに
|yashigani
|Palmier/Crabe
|-
|Crapaud 
|[[wikt:蟇蛙|蟇蛙]]
|ひきがえる
|hikigaeru
|Crapaud/Grenouille
|-
|Crevette
|[[wikt:fr:蝦|蝦]]
|えび
|ebi
|
|-
|Crocodile
|[[wikt:fr:鰐|鰐]]
|わに
|wani
|
|-
|Dragon
|[[wikt:fr:竜|竜]]
|りゅう
|ryū
|Pour parler d'un dragon occidental, on emploiera「ドラゴン」.
|-
|Dragon de Komodo
|
|コモドドラゴン
|Komodo-doragon
|Komodo Dragon (en)
|-
|Escargot
|[[wikt:fr:蝸牛|蝸牛]]
|かたつむり
|katatsumuri
|Escargot/Vache
|-
|Gecko
|[[wikt:守宮|守宮]]
|やもり
|yamori
|Protection/Palais
|-
|Gecko léopard
|[[wikt:豹紋蜥蜴擬き|豹紋蜥蜴擬き]]
|ひょうもんとかげもどき
|hyōmon'tokagemodoki
|/Lézard/
|-
|Grenouille
|[[wikt:fr:蛙|蛙]]
|かえる
|kaeru
|
|-
|Iguane
|
|イグアナ
|iguana
|Iguana(en)
|-
|Léopard de mer
|[[wikt:fr:豹海豹|豹海豹]]
|ひょうあざらし
|hyōazarashi
|Panthère/Phoque
|-
|Méduse
|[[wikt:fr:水母|水母]]／[[wikt:fr:海月|海月]]
|くらげ
|kurage
|Eau/Mère ; Mer/Lune
|-
|Morse
|[[wikt:fr:海象|海象]]
|せいうち
|seiuchi
|Mer/Éléphant
|-
|Murène
|[[wikt:鱓|鱓]]
|うつぼ
|utsubo
|/
|-
|Orque
|[[wikt:fr:鯱|鯱]]
|しゃち
|shachi
|/
|-
|Otarie
|[[wikt:fr:海驢|海驢]]
|あしか
|ashika
|Mer/Âne
|-
|Phoque
|[[wikt:fr:海豹|海豹]]
|あざらし
|azarashi
|Mer/Panthère
|-
|Pieuvre
|[[wikt:fr:蛸|蛸]] 
|たこ
|tako
|
|-
|Poisson
|[[wikt:fr:魚|魚]]
|さかな
|sakana
|
|-
|Poisson rouge
|[[wikt:fr:金魚|金魚]]
|きんぎょ
|kingyo
|Or/Poisson
|-
|Raie
|[[wikt:fr:鱝|鱝]]
|えい
|ei
|Poisson/Orné
|-
|Requin
|[[wikt:fr:鮫|鮫]]
|さめ
|same
|Poisson/Croisement
|-
|Requin-baleine 
|甚兵衛鮫
|じんべいざめ
|jinbeizame
|Jinbei/Requin
|-
|Requin-renard
|[[wikt:fr:尾長鮫|尾長鮫]]
|おながざめ
|onagazame
|Longue queue/Requin
|-
|Requin-tigre
|[[wikt:fr:鼬鮫|鼬鮫]]
|いたちざめ
|itachizame
|Belette/Requin
|-
|Salamandre
|[[wikt:fr:蠑螈|蠑螈]]
|いもり
|imori
|/
|-
|Sardine
|[[wikt:鰯|鰯]]
|いわし
|iwashi
|Poisson/Faible
|-
|Serpent
|[[wikt:fr:蛇|蛇]]
|へび
|hebi
|
|-
|Thon
|[[wikt:fr:鮪|鮪]]
|まぐろ
|maguro
|Poisson/Bleu
|-
|Tortue
|[[wikt:fr:亀|亀]]
|かめ
|kame
|
|-
|Tortue de mer
|[[wikt:fr:海亀|海亀]]
|うみがめ
|umigame
|Mer/Tortue
|}

== Voir aussi ==
*Une série d'[[Japonais/Exercices de vocabulaire#Animaux|exercices]] sur les animaux est également disponible.
*[[wikt:fr:Catégorie:Noms_communs_japonais|Les noms dans le wiktionnaire]]

{{Glossaires_de_Japonais}}
[[Catégorie:Glossaires de Japonais]]

[[en:Japanese/Vocabulary/Animals]]
[[es:Japonés/Vocabulario/Animales]]</text>
      <sha1>9u771fciyhkddc52vnge66p1m9ijhjy</sha1>
    </revision>
  </page>
  <page>
    <title>Fonctionnement d'un ordinateur/Les processeurs superscalaires</title>
    <ns>0</ns>
    <id>65956</id>
    <revision>
      <id>745426</id>
      <parentid>743109</parentid>
      <timestamp>2025-06-26T23:13:45Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745426</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67035" sha1="k1uwdv47vg59245q9zygx76jioe73i3" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui était capable de décoder 4 instructions différentes par cycle et l'unité d'émission avait 5 ports d'émission. Elle disposait de deux ALU entières, d'une FPU, d'une unité LOAD/STORE pour les accès mémoire et d'une unité de branchement. Il utilisait des stations de réservations dédiées chacune à une unité de calcul.

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a abandonné les stations de réservation pour passer à une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable d'émettre en même 6 micro-opérations, dont deux entières, une flottante, une SIMD, et deux micro-opérations mémoire. Ils disposaient de deux ALU toutes capables de faire des opérations basiques (add/sub/cmp/shifts/...), l'une étant sur le même port que le multiplieur. Cela permet d'exécuter en même temps soit deux additions/soustractions, soit une addition/soustraction en parallèle d'une multiplication. Il s'agit d'un compromis assez intéressant, qui réduit le nombre de ports de l'unité d'émission, sans vraiment réduire les performances.

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon était intermédiaire entre les deux précédentes. Elle avait deux files de micro-opérations : une pour les flottants, une autre pour le reste (entiers et adresses). Il y avait trois unités de calcul entières, asymétriques, avec trois ports d'émission associés. Les FPU étaient reliées à deux ports d'émission, leur nombre exact est inconnu. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Mais sur ce processeur, le nombre d'unités d'accès mémoire était déséquilibré. Les 3 ALU entières n'étaient pas associées à 3 unités d'accès mémoire, mais seulement 2 vu que le cache était double port. 

[[File:Athlon.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivant, nommée K8, a été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. Les changements entre les deux sont assez mineures, mais citons le retour à une fenêtre centralisée. Les deux architectures ont beaucoup d'additionneurs : trois ALU entières simples, trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. En somme, une microarchitecture conçue pour exécuter beaucoup d'opérations entières simples en parallèle, avec une ALU entière en plus comparé aux précédentes.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

Viennent ensuite les microarchitectures Bulldozer, avec quatre révisions. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chaun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>k1uwdv47vg59245q9zygx76jioe73i3</sha1>
    </revision>
    <revision>
      <id>745431</id>
      <parentid>745426</parentid>
      <timestamp>2025-06-26T23:21:16Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745431</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67612" sha1="d4x3fmtte522ofte2tv3hj2o9k7jr4m" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui était capable de décoder 4 instructions différentes par cycle et l'unité d'émission avait 5 ports d'émission. Elle disposait de deux ALU entières, d'une FPU, d'une unité LOAD/STORE pour les accès mémoire et d'une unité de branchement. Il utilisait des stations de réservations dédiées chacune à une unité de calcul.

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a abandonné les stations de réservation pour passer à une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable d'émettre en même 6 micro-opérations, dont deux entières, une flottante, une SIMD, et deux micro-opérations mémoire. Ils disposaient de deux ALU toutes capables de faire des opérations basiques (add/sub/cmp/shifts/...), l'une étant sur le même port que le multiplieur. Cela permet d'exécuter en même temps soit deux additions/soustractions, soit une addition/soustraction en parallèle d'une multiplication. Il s'agit d'un compromis assez intéressant, qui réduit le nombre de ports de l'unité d'émission, sans vraiment réduire les performances.

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon était intermédiaire entre les deux précédentes. Elle avait deux files de micro-opérations : une pour les flottants, une autre pour le reste (entiers et adresses). Il y avait trois unités de calcul entières, asymétriques, avec trois ports d'émission associés. Les FPU étaient reliées à deux ports d'émission, leur nombre exact est inconnu. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Mais sur ce processeur, le nombre d'unités d'accès mémoire était déséquilibré. Les 3 ALU entières n'étaient pas associées à 3 unités d'accès mémoire, mais seulement 2 vu que le cache était double port. 

[[File:Athlon.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000. Les changements entre l'architecture K10 et la K8 sont assez mineures, la principale est que le K10 a une fenêtre d'instruction centralisée.

Les deux architectures ont beaucoup d'additionneurs : trois ALU entières simples, trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. En somme, une microarchitecture conçue pour exécuter beaucoup d'opérations entières simples en parallèle, avec une ALU entière en plus comparé aux précédentes.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec quatre révisions. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chaun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>d4x3fmtte522ofte2tv3hj2o9k7jr4m</sha1>
    </revision>
    <revision>
      <id>745433</id>
      <parentid>745431</parentid>
      <timestamp>2025-06-26T23:23:46Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745433</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67872" sha1="q428fea0ropzckzv24ovwfsz8w76cv5" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui était capable de décoder 4 instructions différentes par cycle et l'unité d'émission avait 5 ports d'émission. Elle disposait de deux ALU entières, d'une FPU, d'une unité LOAD/STORE pour les accès mémoire et d'une unité de branchement. Il utilisait des stations de réservations dédiées chacune à une unité de calcul.

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a abandonné les stations de réservation pour passer à une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable d'émettre en même 6 micro-opérations, dont deux entières, une flottante, une SIMD, et deux micro-opérations mémoire. Ils disposaient de deux ALU toutes capables de faire des opérations basiques (add/sub/cmp/shifts/...), l'une étant sur le même port que le multiplieur. Cela permet d'exécuter en même temps soit deux additions/soustractions, soit une addition/soustraction en parallèle d'une multiplication. Il s'agit d'un compromis assez intéressant, qui réduit le nombre de ports de l'unité d'émission, sans vraiment réduire les performances.

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon était intermédiaire entre les deux précédentes. Elle avait deux files de micro-opérations : une pour les flottants, une autre pour le reste (entiers et adresses). Il y avait trois unités de calcul entières, asymétriques, avec trois ports d'émission associés. Les FPU étaient reliées à deux ports d'émission, leur nombre exact est inconnu. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Mais sur ce processeur, le nombre d'unités d'accès mémoire était déséquilibré. Les 3 ALU entières n'étaient pas associées à 3 unités d'accès mémoire, mais seulement 2 vu que le cache était double port. 

[[File:Athlon.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000. Les changements entre l'architecture K10 et la K8 sont assez mineures, la principale est que le K10 a une fenêtre d'instruction centralisée.

Les deux architectures ont beaucoup d'additionneurs : trois ALU entières simples, trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. En somme, une microarchitecture conçue pour exécuter beaucoup d'opérations entières simples en parallèle, avec une ALU entière en plus comparé aux précédentes.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>q428fea0ropzckzv24ovwfsz8w76cv5</sha1>
    </revision>
    <revision>
      <id>745434</id>
      <parentid>745433</parentid>
      <timestamp>2025-06-26T23:26:56Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745434</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="68048" sha1="4be66tkxw9hl2v143os7balwptlgyr7" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui était capable de décoder 4 instructions différentes par cycle et l'unité d'émission avait 5 ports d'émission. Elle disposait de deux ALU entières, d'une FPU, d'une unité LOAD/STORE pour les accès mémoire et d'une unité de branchement. Il utilisait des stations de réservations dédiées chacune à une unité de calcul.

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a abandonné les stations de réservation pour passer à une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable d'émettre en même 6 micro-opérations, dont deux entières, une flottante, une SIMD, et deux micro-opérations mémoire. Ils disposaient de deux ALU toutes capables de faire des opérations basiques (add/sub/cmp/shifts/...), l'une étant sur le même port que le multiplieur. Cela permet d'exécuter en même temps soit deux additions/soustractions, soit une addition/soustraction en parallèle d'une multiplication. Il s'agit d'un compromis assez intéressant, qui réduit le nombre de ports de l'unité d'émission, sans vraiment réduire les performances.

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon était intermédiaire entre les deux précédentes. Elle avait deux files de micro-opérations : une pour les flottants, une autre pour le reste (entiers et adresses). Il y avait trois unités de calcul entières, asymétriques, avec trois ports d'émission associés. Les FPU étaient reliées à deux ports d'émission, leur nombre exact est inconnu. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Mais sur ce processeur, le nombre d'unités d'accès mémoire était déséquilibré. Les 3 ALU entières n'étaient pas associées à 3 unités d'accès mémoire, mais seulement 2 vu que le cache était double port. 

[[File:Athlon.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a une fenêtre d'instruction décentralisée, avec plusieurs stations de réservation. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent. Elle dispose de trois ALU entières simples et trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. Les unités flottantes sont reliées à une station de réservation flottante unique. Les ALU entières ont chacune leur propre station de réservation, partagée avec une unité de calcul d'adresse par ALU. Le circuit multiplieur est regroupé avec une des trois ALU.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts, contre trois dans les microarchitectures précédentes. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>4be66tkxw9hl2v143os7balwptlgyr7</sha1>
    </revision>
    <revision>
      <id>745436</id>
      <parentid>745434</parentid>
      <timestamp>2025-06-26T23:29:08Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745436</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67974" sha1="lmnm0ar9vgzr53p94s3b0ebveyxqayw" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui disposait de deux ALU entières, d'une FPU, d'une unité LOAD/STORE pour les accès mémoire et d'une unité de branchement. Elle était capable de décoder 4 instructions différentes par cycle et utilisait une station de réservation par unité de calcul.

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a abandonné les stations de réservation pour passer à une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable d'émettre en même 6 micro-opérations, dont deux entières, une flottante, une SIMD, et deux micro-opérations mémoire. Ils disposaient de deux ALU toutes capables de faire des opérations basiques (add/sub/cmp/shifts/...), l'une étant sur le même port que le multiplieur. Cela permet d'exécuter en même temps soit deux additions/soustractions, soit une addition/soustraction en parallèle d'une multiplication. Il s'agit d'un compromis assez intéressant, qui réduit le nombre de ports de l'unité d'émission, sans vraiment réduire les performances.

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon était intermédiaire entre les deux précédentes. Elle avait deux files de micro-opérations : une pour les flottants, une autre pour le reste (entiers et adresses). Il y avait trois unités de calcul entières, asymétriques, avec trois ports d'émission associés. Les FPU étaient reliées à deux ports d'émission, leur nombre exact est inconnu. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Mais sur ce processeur, le nombre d'unités d'accès mémoire était déséquilibré. Les 3 ALU entières n'étaient pas associées à 3 unités d'accès mémoire, mais seulement 2 vu que le cache était double port. 

[[File:Athlon.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a une fenêtre d'instruction décentralisée, avec plusieurs stations de réservation. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent. Elle dispose de trois ALU entières simples et trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. Les unités flottantes sont reliées à une station de réservation flottante unique. Les ALU entières ont chacune leur propre station de réservation, partagée avec une unité de calcul d'adresse par ALU. Le circuit multiplieur est regroupé avec une des trois ALU.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts, contre trois dans les microarchitectures précédentes. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>lmnm0ar9vgzr53p94s3b0ebveyxqayw</sha1>
    </revision>
    <revision>
      <id>745437</id>
      <parentid>745436</parentid>
      <timestamp>2025-06-26T23:32:28Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745437</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67805" sha1="1nl9n37p3yiec9vglh2i9fh1devsd89" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui disposait de deux ALU entières, d'une FPU, de deux unités LOAD/STORE pour les accès mémoire et d'une unité de branchement. Elle était capable de décoder 4 instructions différentes par cycle et utilisait une station de réservation par unité de calcul (sauf pour les unités mémoire, qui partagent une seule station de réservation).

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a ajouté une unité SIMD aux unité précédentes, sans compter que les deux unités LOAD/STORE sont séparées en une unité LOAD pour les lectures et une unité STORE pour les écritures. Elle a ussi abandonné les stations de réservation pour une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable de décoder 4 instructions, mais aussi d'émettre en même 6 micro-opérations (une par unité de calcul/mémoire).

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon était intermédiaire entre les deux précédentes. Elle avait deux files de micro-opérations : une pour les flottants, une autre pour le reste (entiers et adresses). Il y avait trois unités de calcul entières, asymétriques, avec trois ports d'émission associés. Les FPU étaient reliées à deux ports d'émission, leur nombre exact est inconnu. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Mais sur ce processeur, le nombre d'unités d'accès mémoire était déséquilibré. Les 3 ALU entières n'étaient pas associées à 3 unités d'accès mémoire, mais seulement 2 vu que le cache était double port. 

[[File:Athlon.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a une fenêtre d'instruction décentralisée, avec plusieurs stations de réservation. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent. Elle dispose de trois ALU entières simples et trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. Les unités flottantes sont reliées à une station de réservation flottante unique. Les ALU entières ont chacune leur propre station de réservation, partagée avec une unité de calcul d'adresse par ALU. Le circuit multiplieur est regroupé avec une des trois ALU.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts, contre trois dans les microarchitectures précédentes. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>1nl9n37p3yiec9vglh2i9fh1devsd89</sha1>
    </revision>
    <revision>
      <id>745439</id>
      <parentid>745437</parentid>
      <timestamp>2025-06-26T23:34:57Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745439</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67476" sha1="238hua990sf1li45b5dxvjylljzwrc3" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui disposait de deux ALU entières, d'une FPU, de deux unités LOAD/STORE pour les accès mémoire et d'une unité de branchement. Elle était capable de décoder 4 instructions différentes par cycle et utilisait une station de réservation par unité de calcul (sauf pour les unités mémoire, qui partagent une seule station de réservation).

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a ajouté une unité SIMD aux unité précédentes, sans compter que les deux unités LOAD/STORE sont séparées en une unité LOAD pour les lectures et une unité STORE pour les écritures. Elle a ussi abandonné les stations de réservation pour une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable de décoder 4 instructions, mais aussi d'émettre en même 6 micro-opérations (une par unité de calcul/mémoire).

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon avait deux stations de réservation : une pour les opérations flottantes, une autre pour les instructions entières et les accès mémoire. Il y avait trois unités de calcul entières, asymétriques, avec trois ports d'émission associés. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse.

[[File:Athlon.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a une fenêtre d'instruction décentralisée, avec plusieurs stations de réservation. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent. Elle dispose de trois ALU entières simples et trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. Les unités flottantes sont reliées à une station de réservation flottante unique. Les ALU entières ont chacune leur propre station de réservation, partagée avec une unité de calcul d'adresse par ALU. Le circuit multiplieur est regroupé avec une des trois ALU.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts, contre trois dans les microarchitectures précédentes. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>238hua990sf1li45b5dxvjylljzwrc3</sha1>
    </revision>
    <revision>
      <id>745441</id>
      <parentid>745439</parentid>
      <timestamp>2025-06-26T23:44:36Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745441</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67783" sha1="exy4bkxlcdj2zkfad2v1nkjsyklbc8y" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui disposait de deux ALU entières, d'une FPU, de deux unités LOAD/STORE pour les accès mémoire et d'une unité de branchement. Elle était capable de décoder 4 instructions différentes par cycle et utilisait une station de réservation par unité de calcul (sauf pour les unités mémoire, qui partagent une seule station de réservation).

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a ajouté une unité SIMD aux unité précédentes, sans compter que les deux unités LOAD/STORE sont séparées en une unité LOAD pour les lectures et une unité STORE pour les écritures. Elle a ussi abandonné les stations de réservation pour une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable de décoder 4 instructions, mais aussi d'émettre en même 6 micro-opérations (une par unité de calcul/mémoire).

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon ne pouvait que décoder que trois instructions par cycle, soit une de moins que les architectures précédente. Mais elle se rattrapait sur l'exécution dans le désordre. Elle avait un tampon de ré-ordonnancement de 72 instructions, nommé ''instruction control unit'' dans le schéma qui suit. Elle avait deux stations de réservation : une pour les opérations flottantes, une autre pour les instructions entières et les accès mémoire. Il y avait trois unités de calcul entières, asymétriques, avec trois ports d'émission associés. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse.

[[File:Athlon arch.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a une fenêtre d'instruction décentralisée, avec plusieurs stations de réservation. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent. Elle dispose de trois ALU entières simples et trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. Les unités flottantes sont reliées à une station de réservation flottante unique. Les ALU entières ont chacune leur propre station de réservation, partagée avec une unité de calcul d'adresse par ALU. Le circuit multiplieur est regroupé avec une des trois ALU.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts, contre trois dans les microarchitectures précédentes. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>exy4bkxlcdj2zkfad2v1nkjsyklbc8y</sha1>
    </revision>
    <revision>
      <id>745443</id>
      <parentid>745441</parentid>
      <timestamp>2025-06-26T23:46:53Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745443</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67924" sha1="quzdeb981zk33io0q4omqi4uv8fpfom" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui disposait de deux ALU entières, d'une FPU, de deux unités LOAD/STORE pour les accès mémoire et d'une unité de branchement. Elle était capable de décoder 4 instructions différentes par cycle et utilisait une station de réservation par unité de calcul (sauf pour les unités mémoire, qui partagent une seule station de réservation).

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a ajouté une unité SIMD aux unité précédentes, sans compter que les deux unités LOAD/STORE sont séparées en une unité LOAD pour les lectures et une unité STORE pour les écritures. Elle a ussi abandonné les stations de réservation pour une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable de décoder 4 instructions, mais aussi d'émettre en même 6 micro-opérations (une par unité de calcul/mémoire).

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon ne pouvait que décoder que trois instructions par cycle, soit une de moins que les architectures précédentes. Mais elle se rattrapait sur l'exécution dans le désordre. Elle avait un tampon de ré-ordonnancement de 72 instructions, nommé ''instruction control unit'' dans le schéma qui suit. Elle avait deux stations de réservation : une pour les opérations flottantes, une autre pour les instructions entières et les accès mémoire. Le processeur utilisait le renommage de registre, mais seulement pour les registres flottants, pas pour les registres entiers. Il y avait trois unités de calcul entières, chacun avec son propre port d'émission, et un circuit multiplieur. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse.

[[File:Athlon arch.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a une fenêtre d'instruction décentralisée, avec plusieurs stations de réservation. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent. Elle dispose de trois ALU entières simples et trois unités de calcul d'adresse dont il n'est pas certain si elles sont distinctes des unités entières, plusieurs unités flottantes spécialisées, et un circuit multiplieur qui partage le port d'une ALU entière. Les unités flottantes sont reliées à une station de réservation flottante unique. Les ALU entières ont chacune leur propre station de réservation, partagée avec une unité de calcul d'adresse par ALU. Le circuit multiplieur est regroupé avec une des trois ALU.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts, contre trois dans les microarchitectures précédentes. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>quzdeb981zk33io0q4omqi4uv8fpfom</sha1>
    </revision>
    <revision>
      <id>745445</id>
      <parentid>745443</parentid>
      <timestamp>2025-06-26T23:52:58Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745445</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="68065" sha1="b3dfuuvi526xtss6r3nvbvchxgzehar" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui disposait de deux ALU entières, d'une FPU, de deux unités LOAD/STORE pour les accès mémoire et d'une unité de branchement. Elle était capable de décoder 4 instructions différentes par cycle et utilisait une station de réservation par unité de calcul (sauf pour les unités mémoire, qui partagent une seule station de réservation).

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a ajouté une unité SIMD aux unité précédentes, sans compter que les deux unités LOAD/STORE sont séparées en une unité LOAD pour les lectures et une unité STORE pour les écritures. Elle a aussi abandonné les stations de réservation pour une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable de décoder 4 instructions, mais aussi d'émettre en même 6 micro-opérations (une par unité de calcul/mémoire).

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon ne pouvait que décoder que trois instructions par cycle, soit une de moins que les architectures précédentes. Mais elle se rattrapait sur l'exécution dans le désordre. Elle avait un tampon de ré-ordonnancement de 72 instructions, nommé ''instruction control unit'' dans le schéma qui suit. Elle avait deux stations de réservation : une pour les opérations flottantes, une autre pour les instructions entières et les accès mémoire. Le processeur utilisait le renommage de registre, mais seulement pour les registres flottants, pas pour les registres entiers.

Il y avait trois unités de calcul entières, chacun avec son propre port d'émission, et un circuit multiplieur relié sur le premier port d'émission entier. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Niveau unités flottantes, le processeur avait une unité d'addition flottante, une unité de multiplication flottante, et une autre unité pour le reste.

[[File:Athlon arch.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a les mêmes ALU, mais a une organisation différente pour ses stations de réservation. Premièrement, le processeur utilise le renommage de registres pour tous les registres, entiers comme flottants. Ensuite, la station de réservation pour les opérations entière est scindée en trois : une station de réservation par ALU entière. Chaque station de réservation entière alimente une unité de calcul entière et une unité de calcul d'adresse. Le multiplieur est relié à la première station de réservation, sur le même port d'émission que l'ALU. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts, contre trois dans les microarchitectures précédentes. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>b3dfuuvi526xtss6r3nvbvchxgzehar</sha1>
    </revision>
    <revision>
      <id>745446</id>
      <parentid>745445</parentid>
      <timestamp>2025-06-26T23:55:40Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745446</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="68129" sha1="mct3eir0kyfpexk3gactt2x6f5t59x4" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui disposait de deux ALU entières, d'une FPU, de deux unités LOAD/STORE pour les accès mémoire et d'une unité de branchement. Elle était capable de décoder 4 instructions différentes par cycle et utilisait une station de réservation par unité de calcul (sauf pour les unités mémoire, qui partagent une seule station de réservation).

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a ajouté une unité SIMD aux unité précédentes, sans compter que les deux unités LOAD/STORE sont séparées en une unité LOAD pour les lectures et une unité STORE pour les écritures. Elle a aussi abandonné les stations de réservation pour une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable de décoder 4 instructions, mais aussi d'émettre en même 6 micro-opérations (une par unité de calcul/mémoire).

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon ne pouvait que décoder que trois instructions par cycle, soit une de moins que les architectures précédentes. Mais elle se rattrapait sur l'exécution dans le désordre. Elle avait un tampon de ré-ordonnancement de 72 instructions, nommé ''instruction control unit'' dans le schéma qui suit. Elle avait deux stations de réservation : une pour les opérations flottantes, une autre pour les instructions entières et les accès mémoire. Le processeur utilisait le renommage de registre, mais seulement pour les registres flottants, pas pour les registres entiers.

Il y avait trois unités de calcul entières, chacun avec son propre port d'émission, et un circuit multiplieur relié sur le premier port d'émission entier. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Niveau unités flottantes, le processeur avait une unité d'addition flottante, une unité de multiplication flottante, et une autre unité pour le reste.

[[File:Athlon arch.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a les mêmes ALU, mais a une organisation différente pour ses stations de réservation. Premièrement, le processeur utilise le renommage de registres pour tous les registres, entiers comme flottants. Niveau micro-opérations entières, la station de réservation unique de 15 micro-opérations est remplacée par trois stations de réservations, une par ALU entière, de 8 micro-opérations chacune. Chaque station de réservation entière alimente une unité de calcul entière et une unité de calcul d'adresse. Le multiplieur est relié à la première station de réservation, sur le même port d'émission que l'ALU. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Elle pouvait décoder quatre instructions par cycle dans quatre décodeurs distincts, contre trois dans les microarchitectures précédentes. Là encore, on trouve des fenêtres décentralisées. On trouve un paquet d'unités de calcul flottantes, regroupées dans un ''cluster''. Les entiers sont dans deux ''clusters'' séparés, avec chacun deux ALU entières, deux unités de calcul d'adresse, et une unité d'accès mémoire. Les registres entiers sont dupliqués, du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé. Pour simplifier, l'ensemble est équivalent à deux cœurs de processeur avec une unité flottante partagée entre les coeurs.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]] 

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>mct3eir0kyfpexk3gactt2x6f5t59x4</sha1>
    </revision>
    <revision>
      <id>745447</id>
      <parentid>745446</parentid>
      <timestamp>2025-06-26T23:56:28Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les microarchitectures x86 d'AMD */</comment>
      <origin>745447</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="67463" sha1="2bbv3j5ou5kxcl0ko2rq2at94x0shjc" xml:space="preserve">Les processeurs vus auparavant ne peuvent émettre au maximum qu'une instruction par cycle d'horloge : ce sont des processeurs à émission unique. Et quand on court après la performance, ce n'est pas assez ! Les concepteurs de processeurs ont inventés des processeurs qui émettent plusieurs instructions par cycle : les '''processeurs à émissions multiples'''.

Les processeurs à émission multiple sont de deux types : les processeurs VLIW et les '''processeurs superscalaires'''. Nous mettons les processeurs VLIW de côté en attendant le prochain chapitre. La raison est que ces derniers ont un jeu d'instruction spécialisé qui expose le parallélisme d'instruction directement au niveau des instructions, là où les processeurs superscalaires restent des processeurs au jeu d'instruction normal.

Un processeur superscalaire exécute plusieurs instructions en parallèle. Il charge plusieurs instructions en même temps, les décode en parallèle, puis les exécute sur des unités de calculs séparées. De plus, il faut gérer les dépendances entre instructions, répartir les instructions sur différentes unités de calcul, et cela n'est pas une mince affaire. Certains processeurs superscalaires n'utilisent pas l'exécution dans le désordre, tandis que d'autres le font. La différence principale entre les deux est qu'un processeur superscalaire répartit les instructions sur les unités de calcul à l’exécution, là où un processeur VLIW délègue cette tâche au compilateur. 

[[File:Fivestagespipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur non-superscalaire.]]
[[File:Superscalarpipeline.svg|centre|vignette|upright=1.5|Pipeline RISC classique à cinq étages sur un processeur superscalaire. On voit bien que plusieurs instructions sont chargées en même temps.]]

==Les processeurs superscalaires : vision globale de leur implémentation ==

Sur un processeur à émission multiple, plusieurs micro-opérations sont émises en même temps, le nombre varie d'un processeur à l'autre. Les processeurs superscalaires les plus simples ne permettent que d'émettre deux micro-opérations à la fois, d'où leur nom de processeur ''dual issue'', ce qui se traduit en '''processeur à double émission'''. Les processeurs modernes peuvent émettre 3, 4, 6, voire 8 micro-opérations simultanément. Aller au-delà ne sert pas à grand-chose.

Il faut noter que la plupart des processeurs superscalaires ont des contraintes sur la manière dont sont émises les instructions.  Si on prend un processeur ''dual-issue'', il y a donc des paires d'instructions autorisées et des paires interdites. Par exemple, ils autorisent l'émission simultanée de deux instructions entières, voire flottantes. Mais pour ce qui est des accès mémoire, c'est autre chose. Les CPU superscalaires simples ne gèrent qu'un accès mémoire à la fois, ce qui fait qu'ils ne peuvent pas émettre deux accès mémoire simultanés. Les accès mémoire sont alors sérialisés, exécutés l'un après l'autre. Par contre, émettre un accès mémoire en même temps qu'un calcul est généralement faisable.

Un problème similaire a lieu pour les branchements. Il faut notamment éviter le cas où une instruction exécutée en parallèle du branchement l'est par erreur, en cas de mauvaise prédiction de branchement. Typiquement, les branchements sont souvent sérialisés, dans le sens où le processeur ne peut pas émettre un branchement avec une autre instruction. Les branchements sont émis seuls, le processeur ne profite pas de l'émission multiple au moment d'émettre un branchement, comme pour les accès mémoire. Des processeurs incorporent des optimisations pour éviter cela, mais cela rend le processeur plus complexe, même si le gain en performance est toujours bon à prendre.

===L'implémentation, dans les grandes lignes===

Un processeur superscalaire doit être capable de : lire plusieurs instructions depuis la mémoire, les décoder, renommer leurs registres, et les envoyer à l'unité d'émission. Intuitivement, on se fit qu'on doit dupliquer tous les circuits : les décodeurs, l'unité de renommage, les unités de calcul, le ROB, etc. Dans les faits, l'implémentation d'un processeur superscalaire demande de dupliquer plusieurs circuits et d'en adapter d'autres. Les décodeurs sont dupliqués, les ALU sont déjà présentes en plusieurs exemplaires mais ajouter des ALU est une bonne chose. Les autres circuits sont adaptés pour gérer plusieurs instructions à la fois. Ils ne sont pas dupliqués, car il peut y avoir des dépendances entre instruction chargées simultanément. Voici ce que cela donne dans les grandes lignes.

{|class=&quot;wikitable&quot;
|-
! rowspan=&quot;2&quot; | Processeur sans émission multiple
| rowspan=&quot;2&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;2&quot; | Renommage
| rowspan=&quot;2&quot; | Émission
| Exécution / ALU
| rowspan=&quot;2&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
! rowspan=&quot;4&quot; | Processeur superscalaire
| rowspan=&quot;4&quot; | Chargement
| rowspan=&quot;2&quot; | Décodage
| rowspan=&quot;4&quot; | Renommage
| rowspan=&quot;4&quot; | Émission
| Exécution / ALU
| rowspan=&quot;4&quot; | ''Commit''/ROB
|-
| Exécution / ALU
|-
| rowspan=&quot;2&quot; | Décodage
| Exécution / ALU
|-
| Exécution / ALU
|}

Un processeur superscalaire doit pouvoir charger plusieurs instructions en même temps. Deux solutions pour cela. La première est de doubler la taille du bus connecté au cache d'instruction. Si les instructions sont de longueur fixe, cela charge deux instructions à la fois. Pour un processeur à triple émission, il faut tripler la taille du bus, quadrupler pour un processeur quadruple émission, etc. Mais tout n'est pas si simple, quelques subtilités font qu'on doit ajouter des circuits en plus pour corriger les défauts peu intuitifs de cette implémentation naïve. Une autre solution est d'utiliser un cache d'instruction multiport. Mais dans ce cas, le ''program counter'' doit générer deux adresses, au mieux consécutives, au pire prédites par l'unité de prédiction de branchement. L'implémentation est alors encore plus complexe, comme on le verra plus bas.

Il doit ensuite décoder plusieurs instructions en même temps. Il se trouve que les dépendances entre instruction ne posent pas de problème pour le décodeur. Rien ne s'oppose à ce qu'on utilise plusieurs décodeurs séparés.

Ensuite, l'unité d'émission doit être modifiée de manière à émettre plusieurs instructions à la fois. Si c'est un ''scoreboard'', il doit être modifié pour détecter les dépendances entre les instructions à émettre et les instructions déjà dans le pipeline. De plus, il faut aussi qu'il détecte les dépendances entre instruction à émettre, entre elles. Si c'est une fenêtre d'instruction ou une station de réservation, les choses sont plus simples, il faut basiquement rajouter des ports de lecture et écriture pour insérer et émettre plusieurs instructions à la fois, et modifier la logique de sélection en conséquence. Le ROB et les autres structures doivent aussi être modifiées pour pouvoir émettre et terminer plusieurs instructions en même temps.

Pour émettre plusieurs instructions en même temps, encore faut-il avoir de quoi les exécuter. En clair : un processeur superscalaire doit avoir plusieurs unités de calcul séparées. Par unités de calcul, on veut parler des unités de calcul proprement dit, mais aussi les unités d'accès mémoire et de branchement. Un autre terme plus correct serait le terme d'avals, que nous avions introduit dans le chapitre sur les pipelines dynamiques, mais n'avons pas eu l'occasion d'utiliser par la suite.

==L'étape de chargement superscalaire==

Lire des instructions sur un processeur superscalaire peut paraitre simple. La méthode la plus simple consiste à doubler, tripler ou quadrupler la taille du bus mémoire. Précisément, c'est le port de lecture du cache d’instruction qui est élargit, pour lire 2/3/4/... fois plus d'instruction en même temps. Sur un processeur avec des instructions de longueur fixe, la méthode marche très bien. Mais sur les CPU CISC, comme les CPU x86 des PC modernes, c'est une autre paire de manches, car on doit gérer des instruction de taille variable. 

Gérer des instructions de taille variable en chargeant plusieurs instructions à la fois est un vrai défi. Il faut découper le bloc chargé en plusieurs instructions, délimiter les frontières de chaque instruction dans le bloc. Le circuit de détection des tailles d'instruction vu dans le chapitre sur l'unité de chargement est donc fortement modifié. Sur le principe, il est dupliqué : on détecte la première instruction, décale le résultat pour récupérer le reste du bloc, puis on recommence tant que le bloc ne contient plus d'instructions. Le résultat est que cela prend parfois un étage de pipeline entier, c'est le cas sur les processeurs Intel de microarchitecture P6.

Mais laissons de côté cette difficulté, et passons au vrai problème du chargement des instructions sur un CPU superscalaire. Charger un gros bloc de mémoire permet de charger plus d'instructions à la fois, mais il y a potentiellement des branchements dans le bloc. Et on doit gérer le cas où ils sont pris, le cas où les instructions suivantes dans le bloc doivent être annulées. En clair, il faut détecter les branchements dans le bloc chargé et gérer le cas où ils sont pris. Dans ce qui va suivre, un morceau de code sans branchement est appelé un bloc de base (''basic block'').

===Le circuit de fusion de blocs===

Les processeurs superscalaires simples ne se préoccupent pas des branchements lors du chargement. Les instructions chargées en même temps sont toutes décodées et exécutées en même temps, même s'il y a un branchement dans le tas. Les branchements sont donc prédits comme étant non-pris systématiquement. Mais d'autres sont plus malins et partent du principe que le branchement est pris : ils exécutent toutes les instructions d'un bloc, sauf celles qui suivent un branchement pris. L'unité de chargement coupe le bloc chargé au niveau du premier branchement non-pris, remplit les vides avec des NOP, avant d'envoyer le tout à l'unité de décodage. Le processeur détermine quels branchements sont pris ou non avec la prédiction de branchements.

[[File:Fetch sur un processeur superscalaire avec prediction de branchements.png|centre|vignette|upright=2|Fetch sur un processeur superscalaire avec prédiction de branchements.]]

D'autres chargent les instructions de destination du branchement et les placent à sa suite. Ils chargent deux blocs à la fois et les fusionnent en un seul qui ne contient que les instructions présumées utiles (exécutées). Le principe peut se généraliser avec un nombre de blocs supérieur à deux.

[[File:Cache d'instructions autoaligné.png|centre|vignette|upright=2|Cache d'instructions autoaligné.]]

Ces processeurs utilisent des unités de prédiction de branchement capables de prédire plusieurs branchements par cycle, au minimum l'adresse du bloc à charger et la ou les adresses de destination des branchements dans le bloc. De plus, on doit charger deux blocs de mémoire en une fois, via des caches d'instruction multiports. Il faut aussi ajouter un circuit pour assembler plusieurs morceaux de blocs en un seul : le fusionneur (''merger''). Le résultat en sortie du fusionneur est ce qu'on appelle une '''trace'''.

[[File:Implémentation d'un cache d'instructions autoaligné.png|centre|vignette|upright=2|Implémentation d'un cache d'instructions autoaligné.]]

===Le cache de traces===

Si jamais un bloc est rechargé et que ses branchements sont pris à l'identique, le résultat du fusionneur sera le même. Il est intéressant de conserver cette trace dans un '''cache de traces''' pour la réutiliser ultérieurement. Mais il reste à déterminer si une trace peut être réutilisée.

Une trace est réutilisable quand le premier bloc de base est identique et que les prédictions de branchement restent identiques. Pour vérifier cela, le tag du cache de traces contient l'adresse du premier bloc de base, la position des branchements dans la trace et le résultat des prédictions utilisées pour construire la trace. Le résultat des prédictions de branchement utilisées pour construire la trace est stocké sous la forme d'une suite de bits : si la trace contient n branchements, le n-ième bit vaut 1 si ce branchement a été pris, et 0 sinon. Même chose pour la position des branchements dans la trace : le bit numéro n indique si la n-ième instruction de la trace est un branchement : si c'est le cas, il vaut 1, et 0 sinon.

Pour savoir si une trace est réutilisable, l'unité de chargement envoie l'adresse de chargement au cache de traces, le reste des informations étant fournie par l'unité de prédiction de branchement. Si le tag est identique, alors on a un succès de cache de traces, et la trace est envoyée directement au décodeur. Sinon, la trace est chargée depuis le cache d'instructions et assemblée.

[[File:TraceCache.png|centre|vignette|upright=2|Cache de traces.]]

Certains caches de traces peuvent stocker plusieurs traces différentes pour une même adresse de départ, avec une trace par ensemble de prédiction. Mais d'autres caches de traces n'autorisent qu'une seule trace par adresse de départ, ce qui est sous-optimal. Mais on peut limiter la casse on utilisant des correspondances partielles. Si jamais les prédictions de branchement et la position des branchements n'est pas strictement identique, il arrive quand même que les premières prédictions et les premiers branchements soient les mêmes. Dans ce cas, on peut alors réutiliser les blocs de base concernés et le processeur charge les portions de la trace qui sont valides depuis le cache de traces. Une autre solution consiste à reconstituer les traces à la volée. Il suffit de mémoriser les blocs de base dans des caches dédiés et les assembler par un fusionneur. Par exemple, au lieu d'utiliser un cache de traces dont chaque ligne peut contenir quatre blocs de base, on va utiliser quatre caches de blocs de base. Cela permet de supprimer la redondance que l'on trouve dans les traces, quand elles se partagent des blocs de base identiques, ce qui est avantageux à mémoire égale.

La présence d'un cache de traces se marie très bien avec une unité de prédiction de branchement capable de prédire un grand nombre de branchements par cycle. Malheureusement, ces unités de prédiction de branchement sont très complexes et gourmandes en circuits. Les concepteurs de processeurs préfèrent utiliser une unité de prédiction de branchement normale, qui ne peut prédire l'adresse que d'un seul bloc de base. Pour pouvoir utiliser un cache de traces avec une unité de prédiction aussi simple, les concepteurs de processeurs vont ajouter une seconde unité de prédiction, spécialisée dans le cache de traces.

==Le séquenceur d'un processeur superscalaire==

Le séquenceur d'un processeur superscalaire est modifié, afin de pouvoir décoder plusieurs instructions à la fois. Ce n'est pas le cas général, mais la présence de plusieurs décodeurs est très fréquent sur les processeur superscalaires. De plus, les unités de renommage et d'émission doivent être modifiées.

===Les décodeurs d'instructions superscalaires===

Un processeur superscalaire contient généralement plusieurs décodeurs, chacun pouvant décoder une instruction en parallèle des autres. Prenons par exemple un processeur RISC dont toutes les instructions font 32 bits. Un processeur superscalaire de ce type peut charger des blocs de 128 bits, ce qui permet de charger 4 instructions d'un seul coup. Et pour les décoder, le décodage se fera dans quatre décodeurs séparés, qui fonctionneront en parallèle. Ou alors, il se fera dans un seul décodeur qui pourra décoder plusieurs instructions par cycles.

La seconde méthode facilite l'implémentation de la technique de '''macro-fusion''', qui permet au décodeur de fusionner une suite de deux-trois instructions en une seule micro-opération. Par exemple, il est possible de fusionner une multiplication suivie d'une addition en une seule instruction MAD (''multiply and add''), si les conditions adéquates sont réunies pour les opérandes. Comme autre exemple, il est possible de fusionner un calcul d'adresse suivi d'une lecture à l'adresse calculée en une seule micro-opération d'accès mémoire. Ou encore, fusionner une instruction de test et une instruction de saut en une seule micro-opération de branchement. Cette technique n'est pas exclusive aux processeurs superscalaires et fonctionne si tout processeur avec un pipeline, mais elle fonctionne au mieux sur ces processeurs, du fait de leur capacité à charger plusieurs instructions à la fois.

Pour donner un exemple assez particulier, prenons le cas des processeurs RISC-V. Sur ce jeu d'instruction, il existe des instructions longues de 32 bits et des instructions courtes de 16 bits. Le chargement des instructions se fait par blocs de 32 bits, ce qui permet de charger une instruction de 32 bits, ou deux instructions de 16 bits. Pour simplifier, supposons que les instructions sont alignées sur des blocs de 32 bits, ce qui signifie qu'un bloc chargé contient soit une instruction de 32 bits, soit deux instructions de 16 bits. On ne tient pas compte des cas où une instruction de 16 bit est immédiatement suivie par une instruction de 32 bits à cheval sur deux blocs. Il est possible de créer un processeur RISC-V partiellement superscalaire en utilisant deux voies : une avec un décodeur pour les instructions 32 bits et une autre voie contenant deux décodeurs pour les instructions de 16 bits. Ainsi, lors du chargement d'un bloc de deux instructions courtes, les deux instructions sont chacune décodées par un décodeur séparé.

Il est même possible de décoder les instructions dans les deux voies en parallèle, avant de choisir quel est celui qui a raison. Sans cette méthode, on doit identifier si le bloc contient une instruction longue ou deux instructions courtes, avant d'envoyer les instructions au décodeur adéquat. Mais avec cette méthode, l'identification du nombre d'instruction se fait en parallèle du décodage proprement dit. Évidemment, une des deux voies donnera des résultats aberrants et totalement faux, mais l'autre donnera le bon résultat. Il suffit de choisir le bon résultat en sortie avec un multiplexeur.

[[File:Décodage des instructions à longueur variable, exemple.png|centre|vignette|upright=2|Décodage des instructions à longueur variable dans l'exemple du RISC-V, où les instructions font 32 ou 16 bits et sont alignées.]]

===L'unité de renommage superscalaire===

Sur un processeur à émission multiple, l'unité de renommage de registres doit renommer plusieurs instructions à la fois, mais aussi gérer les dépendances entre instructions. Pour cela, elle renomme les registres sans tenir compte des dépendances, pour ensuite corriger le résultat.

[[File:Unité de renommage superscalaire.png|centre|vignette|upright=2|Unité de renommage superscalaire.]]

Seules les dépendances lecture-après-écriture doivent être détectées, les autres étant supprimées par le renommage de registres. Repérer ce genre de dépendances se fait assez simplement : il suffit de regarder si un registre de destination d'une instruction est un opérande d'une instruction suivante.

[[File:Détection des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Détection des dépendances sur un processeur superscalaire.]]

Ensuite, il faut corriger le résultat du renommage en fonction des dépendances. Si une instruction n'a pas de dépendance avec une autre, on la laisse telle quelle. Dans le cas contraire, un registre opérande sera identique avec le registre de destination d'une instruction précédente. Dans ce cas, le registre opérande n'est pas le bon après renommage : on doit le remplacer par le registre de destination de l'instruction avec laquelle il y a dépendance. Cela se fait simplement en utilisant un multiplexeur dont les entrées sont reliées à l'unité de détection des dépendances. On doit faire ce replacement pour chaque registre opérande.

[[File:Correction des dépendances sur un processeur superscalaire.png|centre|vignette|upright=2|Correction des dépendances sur un processeur superscalaire.]]

===L'unité d'émission superscalaire===

Pour émettre plusieurs instructions en même temps, l'unité d'émission doit être capable d'émettre plusieurs instructions par cycle. Et Pour cela, elle doit détecter les dépendances entre instructions. Il faut noter que la plupart des processeurs superscalaires utilisent le renommage de registre pour éliminer un maximum de dépendances inter-instructions. Les seules dépendances à détecter sont alors les dépendances RAW, qu'on peut détecter en comparant les registres de deux instructions consécutives.

Sur les processeurs superscalaires à exécution dans l’ordre, il faut aussi gérer l'alignement des instructions dans la fenêtre d'instruction. Dans le cas le plus simple, les instructions sont chargées par blocs et on doit attendre que toutes les instructions du bloc soient émises pour charger un nouveau bloc. Avec la seconde méthode, La fenêtre d'instruction fonctionne comme une fenêtre glissante, qui se déplace de plusieurs crans à chaque cycle d'horloge.

Mais au-delà de ça, le design de l'unité d'émission change. Avant, elle recevait une micro-opération sur son entrée, et fournissait une micro-opération émise sur une sortie. Et cela vaut aussi bien pour une unité d'émission simple, un ''scoreboard'', une fenêtre d'instruction ou des stations de réservation. Mais avec l'émission multiple, les sorties et entrées sont dupliquées. Pour la double émission, il y a deux entrées vu qu'elle doit recevoir deux micro-opération décodées/renommées, et deux sorties pour émettre deux micro-opérations. Formellement, il est possible de faire une analogie avec une mémoire : l'unité d'émission dispose de ports d'écriture et de lecture. On envoie des micro-opérations décodées/renommées sur des ports d'écriture, et elle renvoie des micro-opérations émises sur le port de lecture. Dans ce qui suit, nous parlerons de '''ports de décodage''' et de '''ports d'émission'''.

Si l'unité d'émission est un vulgaire ''scoreboard'', il doit détecter les dépendances entre instructions émises simultanément. De plus, il doit détecter les paires d'instructions interdites et les sérialiser. Autant dire que ce n'est pas très pratique. La détection des dépendances entre instructions consécutives est simplifiée avec une fenêtre d'instruction, il n'y a pour ainsi dire pas grand chose à faire, vu que les dépendances sont éliminées par le renommage de registre et que les signaux de réveil s'occupent de gérer les dépendances RAW. C'est la raison pour laquelle les processeurs superscalaires utilisent tous une fenêtre d'instruction centralisée ou décentralisée, et non des ''scoreboard''.

Les processeurs superscalaires privilégient souvent des stations de réservations aux fenêtres d'instruction. Rappelons la terminologie utilisée dans ce cours. Les fenêtres d'instruction se contentent de mémoriser la micro-opération à émettre et quelques bits pour la disponibilité des opérandes. Par contre, les stations de réservations mémorisent aussi les opérandes des instructions. Les registres sont lus après émission avec une fenêtre d'instruction, avant avec des stations de réservation. Et cette différence a une influence sur le pipeline du processeur, le banc de registres et tout ce qui s'en suit. La différence principale est liée au banc de registre, et précisément au nombre de ports de lecture.

Supposons que toutes les instructions sont dyadiques, ou du moins qu'il n'existe pas de micro-opération à trois opérandes. Avec une fenêtre d'instruction, le nombre d'opérandes à lire simultanément est proportionnel à la quantité d'instructions qu'on peut émettre en même temps. Sur un processeur ''dual issue'', qui peut émettre deux micro-opérations, cela fait deux micro-opérations à deux opérandes chacune, soit 4 opérandes. Le nombre de ports de lecture est donc de quatre. Avec une station de réservation, la lecture des opérandes a lieu avant l'émission, juste après le décodage/renommage. Le nombre d'opérande est le double du nombre de micro-opérations décodées/renommées, pas émises. Si le décodeur peut décoder/renommer 4 instructions par cycle, cela veut dire 4 micro-opérations émises par cycle.

Et il se trouve que les deux situations ne sont pas évidentes. Avec une fenêtre d'instruction centralisée, cela ne change rien. Le nombre d'instructions décodées et émises en même temps sont identiques. Mais dès qu'on utilise des fenêtres d'instruction décentralisées, les choses changent. Si le décodeur peut décoder/renommer 4 instructions par cycle, alors l'idéal est d'avoir 4 micro-opérations émises par cycle, ''par fenêtre d'instruction''. Imaginez que le décodeur décode 4 instructions entières : la fenêtre d'instruction entière doit pouvoir émettre 4 micro-opérations entières en même temps. Idem pour des instructions flottantes avec la fenêtre d'instruction flottantes. Vu qu'il y a deux fenêtres d'instruction, cela fait 4 micro-opérations entières + 4 micro-opérations flottantes = 8 ports de lecture. Non pas qu'ils soient tous simultanément utiles, mais il faut les câbler.

Les fenêtres d'instruction impliquent plus de lectures d'opérandes, ce qui implique plus de ports de lecture. Les stations de réservation sont plus économes, elles vont bien avec un nombre modéré de ports de lecture.

===Les conséquences sur le banc de registre===

Émettre plusieurs instructions en même temps signifie lire ou écrire plusieurs opérandes à la fois : le nombre de ports du banc de registres doit être augmenté. De plus, le banc de registre doit être relié à toutes les unités de calcul en même temps, ce qui fait 2 ports de lecture par unité de calcul. Et avec plusieurs dizaines d'unités de calcul différentes, le câblage est tout simplement ignoble. Et plus un banc de registres a de ports, plus il utilise de circuits, est compliqué à concevoir, consomme de courant et chauffe. Mais diverses optimisations permettent de réduire le nombre de ports assez simplement.

Un autre solution utilise un banc de registre unique, mais n'utilise pas autant de ports que le pire des cas le demanderait. Pour cela, le processeur doit détecter quand il n'y a pas assez de ports pour servir toutes les instructions : l'unité d'émission devra alors mettre en attente certaines instructions, le temps que les ports se libèrent. Cette détection est réalisée par un circuit d'arbitrage spécialisé, intégré à l'unité d'émission, l’arbitre du banc de registres (''register file arbiter'').

==Les unités de calcul des processeurs superscalaires==

Disposer de plusieurs unités de calcul est tout sauf compliqué, les processeurs avec un pipeline dynamique sont dans ce cas. Typiquement ils incorporent plusieurs unités pour les instructions entières, une unité pour les instructions flottantes, une unité pour les accès mémoire (calcul d'adresse inclus) et éventuellement une unité pour les tests/branchements.

Les processeurs superscalaires les plus simples ne font qu'exploiter au mieux ces unités de calcul existantes. Les processeurs avec un pipeline dynamique sont parfaitement capables d'exécuter des calculs indépendants dans des unités de calcul séparées. Mais il faut faire la nuance entre émettre une instruction par cycle et exécuter une instruction par cycle. En moyenne, les deux sont identiques. Mais on peut avoir plusieurs instructions en exécution dans les ALU alors qu'on n'en émet qu'une seule à la fois. Dès que des instructions multicycle se manifestent, c'est le cas. Une instruction multicycle s'exécute, mais le processeur continue à émettre des instructions pendant son exécution.

Des optimisations comme l'exécution dans le désordre permettent de profiter de cette possibilité, mais pas totalement. Les processeurs superscalaires sont une optimisation de plus dans cet objectif. Vu qu'on n'ajoute pas d'unités de calcul en plus, les seules modifications sont au niveau de l'amont, dans les unités de chargement, décodage, de renommage et d'émission. Le tampon de réordonnancement/ROB est aussi modifié de manière à ce qu'on puisse émettre et ''commit'' plusieurs instructions à la fois.

===Exploiter les ALU existantes entraine une sous-utilisation des ports d'émission===

Une idée assez simple, et passablement inefficace, est d'allouer un port d'émission à chaque ALU déjà présente dans un processeur à pipeline dynamique. Mais voyons ce que cela donne avec un processeur assez réaliste. Le processeur en question contient une ALU spécialisée dans les opérations à un cycle (add/sub/cmp/shift/XOR/NOT/OR/AND/...), un circuit multiplieur/diviseur séparé de l'ALU entière proprement dite, un ''barrel shifter'' séparé des autres ALU, une FPU et l'unité mémoire. Les 5 unités permettent d'émettre 5 micro-opérations en même temps, ce qui demande d'ajouter 5 ports d'émission.

Maintenant, posons-nous la question : est-ce que faire ainsi en vaut la peine ? En pratique, il est rare qu'un programme profite de toutes les avals en même temps. Il émet/exécute des micro-opérations sur 1/2 unités de calcul, mais pas sur toutes. Les unités de calcul sont donc sous-utilisées du point de vue de l'émission. Un cas similaire s'était présenté sur les processeurs Intel d'architecture P6. Le processeur était capable d'émettre 5 micro-opérations (deux entières, une flottante, deux mémoire), mais les concepteurs de la puce savaient que le processeur n'en émettait en moyenne que 3. Aussi, il est intéressant de limiter le nombre de ports d'émission, pour ne pas gaspiller de matériel pour des cas très peu fréquents. L'unité d'émission a moins de ports de lecture que l'ALU, certaines ALU doivent partager le même port de lecture.

Mais pourquoi une telle sous-utilisation ? Les raisons à cela sont multiples. La première est liée aux instructions multicycles. Prenons la FPU, par exemple. Imaginons qu'on ait une FPU capable de faire des additions/soustractions/multiplication en 10 cycles. Concrètement, cela signifie qu'on peut émettre une micro-opération flottante tous les 10 cycles. Si la FPU a son propre port d'émission, il sera utilisé une fois tous les 10 cycles et sera donc sous-utilisé.

Une autre raison est que les programmes exécutent un mix d'instruction qui est différent de ce que les unités de calcul permettent. Par exemple, certains programmes n'exécutent que des opérations entières, sans calculs flottants. Avec eux, le port d'émission de la FPU est inutilisé ou presque. Mais reprenons l'exemple du processeur précédent avec un multiplieur, un décaleur et une unité entière simple. Rares sont les programmes qui ont un nombre égal de décalages, multiplications et additions/soustractions. La plupart des programmes sont majoritairement remplis d'additions, avec des multiplications assez rares et des décalages qui le sont encore plus. Dans ces conditions, le port d'émission de l'ALU entière est sur-utilisé, alors que ceux du multiplieur et du ''barrel shifter'' sont sous-utilisés.

En soi, on peut faire avec. Mais le résultat est un gain limité en performance, pour un cout en transistor élevé. Ajouter des ports d'émission n'est pas gratuit. La solution consiste à partager les ports entre plusieurs unités de calcul. Le processeur inclu moins de ports que d'unités de calcul, avec certains ports qui sont reliés à plusieurs unités de calcul. Typiquement, il n'est pas rare qu'une ALU entière et une FPU partagent le même port. De même, les FPU sont souvent éclatées en un additionneur flottant, un multiplieur flottant, et d'autres circuits séparés, mais qui sont reliés au même port. Les circuits multiplieurs ont souvent un port partagé avec ''barrel shifter'' ou avec une ALU entière simple, etc. Le résultat de ce partage est que la répartition entre ALU et ports d'émission est assez étranger sur les architectures modernes avec des dizaines d'ALUs.

En faisant cela, on économise beaucoup de circuits pour un cout en performance mineur. Car cout en performance il y a. Par exemple, imaginez que le multiplieur entier partage son port d'émission avec la FPU. Imaginez qu'on se trouve dans une situation où on veut émettre une multiplication et une opération flottante en même temps : impossible ! Au lieu d'émettre les deux instructions en même temps, pendant le même cycle, on devra les émettre l'une à la suite de l'autre, en deux cycles. On perd donc un cycle d'horloge pour une des deux opérations. Mais la situation ne se présente que pour certaines combinaisons de micro-opérations bien précises, qui sont idéalement assez rares si on choisit bien quelles ALU mettre sur telle port.

===Les processeurs à double emission FPU/INT/MEM===

Prenons un cas de processeur simple, avec une ALU entière et une ALU flottante, éventuellement une unité d'accès mémoire. La plupart des premiers processeurs superscalaires étaient de ce type. Ils sont assez anciens, ce qui fait qu'ils devaient se débrouiller avec peu de circuits dont ils disposaient, typiquement une ALU entière et une FPU. La double émission était alors naturelle.

Le processeur a donc deux pipelines séparés : un pour les micro-opérations entières, un autre pour les micro-opérations flottantes. Le processeur dispose pour cela d'une FPU séparée de l'ALU entière, mais aussi de banc de registres séparés pour les entiers et les flottants. Le séquenceur devait aussi être conçu pour, naturellement. L'avantage se situe au niveau de la gestion des calculs d'adresse. Les unités de calcul entière peuvent être utilisées pour les calculs d'adresse et transmettre les adresses calculées aux unités mémoire. La technique a été utilisée sur les processeurs POWER 1 et ses dérivés comme le ''RISC Single Chip''.

===Les processeurs superscalaires ont souvent plusieurs ALU entières===

Pour plus de performances, les processeurs superscalaire modernes ajoutent des unités de calcul, qui n'auraient servies à rien sur un processeur sans émission multiple. Sur presque tous les processeurs superscalaires existants, l'unité de calcul entière est dupliquée en plusieurs exemplaires identiques. La raison est qu'un processeur exécute en grosse majorité des additions, soustraction et comparaisons, qui sont prises en charge par l'ALU entière. Avec plusieurs ALU entières, on peut émettre plusieurs opérations de ce type en même temps, ce qui donne un gain en performance assez important. Bien plus important qu'avec les techniques précédentes.

Sur les processeurs disposant d'une ALU simples et d'un multiplieur séparé, les ALU sont souvent dupliqués, mais pas forcément le multiplieur. La raison est que les multiplications sont moins fréquentes que les additions/soustractions et opérations logiques. Si le processeur exécute plusieurs opérations en même temps, il sera rare d'avoir plusieurs multiplications à exécuter en parallèle. Disposer de plusieurs circuits multiplieurs serait donc un cout en circuits qui ne servirait que rarement et n'en vaut pas la chandelle. Par contre, il sera fréquent d'avoir plein d'additions/soustractions/décalages avec éventuellement une multiplication de temps en temps. Typiquement, il n'est pas rare d'avoir une multiplication pour 4/5 additions. Dans ce cas, la solution la plus rentable consiste à dupliquer les ALU simples, mais pas les multiplieurs.

De nombreux processeurs décident de regrouper le circuit multiplieur avec une ALU simple sur le même port d'émission. Une autre solution est de fusionner le multiplieur avec l'ALU qui partage le même port. Les deux donnent le même résultat, ou presque. Un exemple de processeur de ce type est le Power PC 440. Il s'agit d'un processeur double émission qui n'a pas de FPU et se contente de deux unités de calcul entières, d'un circuit multiplieur, et d'une unité mémoire. L'unité mémoire et une ALU entière simple sont regroupées sur le même port d'exécution, sans doute afin d'utiliser l'ALU entière pour les calculs d'adresse. Le second port est relié à une ALU entière capable de faire soit une multiplication, soit une addition, soit les deux, et éventuellement quelques opérations en plus. L'organisation en question permet soit d'émettre un accès mémoire en même temps qu'une opération entière, soit d'émettre deux opérations entières simples, soit d’émettre une multiplication et une addition/soustraction/comparaison. Une organisation simple, mais très efficace !

[[File:PowerPC 440.png|centre|vignette|upright=2|Microarchitecture du PowerPC 440.]]

Les unités de calcul entières sont généralement alimentées par une fenêtre d'instruction dédiée aux micro-opérations entières. Si toutes les ALU liées à une fenêtre d'instruction sont identiques, l'implémentation du répartiteur est très simple. Un simple algorithme ''round-robin'' fait l'affaire. En clair, on envoie la première instruction entière dans la première ALU, la suivante dans l'ALU suivante, et ainsi de suite, avant de revenir à la première ALU et de refaire un tour, etc.

Mais sur beaucoup de processeurs, le ''scheduler'' n'est pas relié à des ALU hétérogènes. Par hétérogènes, on veut dire qu'elles ne sont pas forcément identiques, certaines peuvent faire des opérations que les autres ne peuvent pas faire. Les ALU reliées à une même fenêtre d'instruction sont rarement très hétérogènes, très différentes. Elles sont souvent très similaires, avec cependant quelques unités un peu à part. Par exemple, il est fréquent d'avoir plusieurs ALU entières limitées à des opérations simples aux côtés d'ALU plus complexes. Il est par exemple courant de relier plusieurs ALU simples et un multiplieur à une fenêtre d'instruction. Un exemple est celui des processeur AMD Athlon 64, sorti dans les années 2000 : toutes les ALU entières sont identiques et peuvent gérer les mêmes opérations, à l'exception de la multiplication qui n'est gérée que par la première ALU.

Il faut donc répartir les instructions sur les bonnes unités de calcul : on n'envoie pas une multiplication sur une ALU qui ne gère que l'addition. L'unité de ''scheduling'' doit répartir les instructions sur les unités de calcul hétérogènes, en évitant d'envoyer une instruction que l'ALU ne prend pas en charge. Soit le problème que l'usage de fenêtre décentralisée tendait à résoudre. Cependant, un tri a déjà été fait lors du ''dispatch'', ce qui fait que la répartition sur les ALUs est en fait réalisée en plusieurs étapes chacune très simples.

===L'unité mémoire des CPU superscalaires===

Pour rappel, l'unité mémoire s'interpose entre le cache et le reste du pipeline. Elle est composée d'une ''Load-store queue'' et d'une unité de calcul d'adresse. La ''Load-store queue'' met en attente les accès mémoire tant qu'ils ne sont pas prêts à s'exécuter, soit parce que leur adresse n'est pas disponible, soit parce qu'ils ont une dépendance avec un autre accès mémoire, soit pour respecter l'ordre du programme, soit parce que le cache n'est pas libre, etc.

Les processeurs superscalaires n'ont toujours qu'une seule ''Load-store queue'', ça ne change pas. Elle est éventuellement modifiée pour gérer plusieurs accès mémoire simultanés, ce qui va de pair avec des caches multiports et/ou non-bloquants. De plus, les unités de calcul sont dupliquées pour gérer plusieurs calculs d'adresse simultanés. Pour gérer des accès simultanés, les ports d'entrée et de sortie sont dupliqués, avec plusieurs ports connectés au cache, et plusieurs ports d'entrée pour recevoir les accès mémoire.

Un exemple est celui du processeur Athlon 64, un processeur AMD sorti dans les années 2000. Il disposait d'une LSQ unique, reliée à un cache L1 de donnée double port. La LSQ était reliée à trois unités de calcul séparées de la LSQ. La LSQ avait des connexions avec les registres, pour gérer les lectures/écritures. 

[[File:Athlon.png|centre|vignette|upright=2.5|Athlon]]

Comme autre exemple, les processeurs skylake ont une LSQ avec deux ports de lecture et d'un port d'écriture, ce qui permet d'émettre trois micro-opérations mémoire à la fois.

Un autre exemple est celle des processeurs AMD K6, qui avaient une unité mémoire assez différente du reste. Le cache était un cache double port, avec un port de lecture et un port d'écriture. Le port de lecture était alimenté par une unité de calcul d'adresse dédiée, dont la sortie était directement reliée au cache. Le port d'écriture du cache était précédé par une ''Store Queue'', une version simplifiée de la LSQ, elle-même précédée par un circuit de calcul d'adresse. Le processeur exécutait les lectures dès qu'elles avaient leurs opérandes de disponibles, seules les écritures étaient mises en attente. 

[[File:Amdk6 arch.svg|centre|vignette|upright=2.5|AMD K6.]]

==Le contournement sur les processeurs superscalaires==

Pour rappel, la technique du contournement (''register bypass'') permet au résultat d'une instruction d'être immédiatement utilisable en sortie de l'ALU, avant même d'être enregistré dans les registres. Implémenter la technique du contournement demande d'utiliser des multiplexeurs pour relier la sortie de l'unité de calcul sur son entrée si besoin. il faut aussi des comparateurs pour détecter des dépendances de données. 

[[File:Pipeline Bypass.png|centre|vignette|upright=1|Pipeline Bypass]]

===Les problèmes du contournement sur les CPU avec beaucoup d'ALUs===

Avec plusieurs unités de calcul, la sortie de chaque ALU doit être reliée aux entrées de toutes les autres, avec les comparateurs qui vont avec ! Sur les processeurs ayant plusieurs d'unités de calculs, cela demande beaucoup de circuits. Pour N unités de calcul, cela demande 2 * N² interconnexions, implémentées avec 2N multiplexeurs de N entrées chacun. Si c'est faisable pour 2 ou 3 ALUs, la solution est impraticable sur les processeurs modernes, qui ont facilement une dizaine d'unité de calcul.

De plus, la complexité du réseau de contournement (l'ensemble des interconnexions entre ALU) a un cout en terme de rapidité du processeur. Plus il est complexe, plus les données contournées traversent de longs fils, plus leur temps de trajet est long, plus la fréquence du processeur en prend un coup. Diverses techniques permettent de limiter la casse, comme l'usage d'un bus de contournement, mais elle est assez impraticable avec beaucoup d'unités de calcul.

Notez que cela vaut pour les processeurs superscalaires, mais aussi pour tout processeur avec beaucoup d'unités de calcul. Un simple CPU à exécution dans le désordre, non-superscalaire, a souvent pas mal d'unités de calcul et fait face au même problème. En théorie, un processeur sans exécution dans le désordre ou superscalarité pourrait avoir le problème. Mais en pratique, avoir une dizaine d'ALU implique processeur superscalaire à exécution dans le désordre. D'où le fait qu'on parle du problème maintenant.

La seule solution praticable est de ne pas relier toutes les unités de calcul ensemble. À la place, on préfère regrouper les unités de calcul dans différents '''agglomérats''' ('''cluster'''). Le contournement est alors possible entre les unités d'un même agglomérat, mais pas entre agglomérats différents. Généralement, cela arrive pour les unités de calcul entières, mais pas pour les unités flottantes. La raison est que les CPU ont souvent beaucoup d'unités de calcul entières, car les instructions entières sont légion, alors que les instructions flottantes sont plus rares et demandent au mieux une FPU simple.

Évidemment, l'usage d'agglomérats fait que certaines possibilités de contournement sont perdues, avec la perte de performance qui va avec. Mais la perte en possibilités de contournement vaut bien le gain en fréquence et le cout en circuit/fils réduit. C'est un bon compromis, ce qui explique que presque tous les processeurs modernes l'utilisent. Les rares exceptions sont les processeurs POWER 4 et POWER 5, qui ont préféré se passer de contournement pour garder un processeur très simple et une fréquence élevée.

===Les bancs de registre sont aussi adaptés pour le contournement===

L'usage d'agglomérats peut aussi prendre en compte les interconnections entre unités de calcul et registres. C'est-à-dire que les registres peuvent être agglomérés. Et cela peut se faire de plusieurs façons différentes.

Une première solution, déjà vue dans les chapitres sur la micro-architecture d'un processeur, consiste à découper le banc de registres en plusieurs bancs de registres plus petits. Il faut juste prévoir un réseau d'interconnexions pour échanger des données entre bancs de registres. Dans la plupart des cas, cette séparation est invisible du point de vue de l'assembleur et du langage machine. Le processeur se charge de transférer les données entre bancs de registres suivant les besoins. Sur d'autres processeurs, les transferts de données se font via une instruction spéciale, souvent appelée ''COPY''.

[[File:Banc de registres distribué.png|centre|vignette|upright=2|Banc de registres distribué.]]

Sur de certains processeurs, un branchement est exécuté par une unité de calcul spécialisée. Or les registres à lire pour déterminer l'adresse de destination du branchement ne sont pas forcément dans le même agglomérat que cette unité de calcul. Pour éviter cela, certains processeurs disposent d'une unité de calcul des branchements dans chaque agglomérat. Dans les cas où plusieurs unités veulent modifier le ''program counter'' en même temps, un système de contrôle général décide quelle unité a la priorité sur les autres. Mais d'autres processeurs fonctionnent autrement : seul un agglomérat possède une unité de branchement, qui peut recevoir des résultats de tests de toutes les autres unités de calcul, quel que soit l’agglomérat.

Une autre solution duplique le banc de registres en plusieurs exemplaires qui contiennent exactement les mêmes données, mais avec moins de ports de lecture/écriture. Un exemple est celui des processeurs POWER, Alpha 21264 et Alpha 21464. Sur ces processeurs, le banc de registre est dupliqué en plusieurs exemplaires, qui contiennent exactement les mêmes données. Les lectures en RAM et les résultats des opérations sont envoyées à tous les bancs de registres, afin de garantir que leur contenu est identique. Le banc de registre est dupliqué en autant d'exemplaires qu'il y a d'agglomérats. Chaque exemplaire a exactement deux ports de lecture, une par opérande, au lieu de plusieurs dizaines. La conception du processeur est simplifiée, que ce soit au niveau du câblage, que de la conception des bancs de registres.

==Les optimisations de la pile d'appel : le ''stack engine''==

Les processeurs modernes intègrent une optimisation liée au pointeur de pile. Pour rappel, sur les architectures modernes, le pointeur de pile est un registre utilisé pour gérer la pile d'appel, précisément pour savoir où se trouve le sommet de la pile. Il est manipulé par les instructions CALL, RET, PUSH et POP, mais aussi par les instructions d'addition/soustraction pour gérer des cadres de pile de taille variable. De plus, il peut servir d'opérande pour des instructions LOAD/STORE, afin de lire/écrire des variables locales, les arguments d'une fonction, et autres. C'est donc un registre général adressable, intégré au banc de registre, altéré par l'unité de calcul entière.

L'incrémentation/décrémentation du pointeur de pile passe donc par l'unité de calcul, lors des instructions CALL, RET, PUSH et POP. Mais, l'optimisation que nous allons voir permet d'incrémenter/décrémenter le pointeur de pile sans passer par l'ALU, ou presque. L'idée est de s'inspirer des architectures avec une pile d'adresse de retour, qui intègrent le pointeur de pile dans le séquenceur et l'incrémentent avec un incrémenteur dédié.

===Le ''stack engine''===

L'optimisation que nous allons voir utilise un '''''stack engine''''' intégré à l'unité de contrôle, au séquenceur. Le processeur contient toujours un pointeur de pile dans le banc de registre, cela ne change pas. Par contre, il n'est pas incrémenté/décrémenté à chaque instruction CALL, RET, PUSH, POP. Un compteur intégré au séquenceur est incrémenté à la place, nous l’appellerons le '''compteur delta'''. La vraie valeur du pointeur de pile s'obtient en additionnant le compteur delta avec le registre dans le banc de registre. Précisons que si le compteur delta vaut zéro, la vraie valeur est dans le banc de registre et peut s'utiliser telle quelle.

Lorsqu'une instruction ADD/SUB/LOAD/STORE utilise le pointeur de pile comme opérande, elle a besoin de la vraie valeur. Si elle n'est pas dans le banc de registre, le séquenceur déclenche l'addition compteur-registre pour calculer la vraie valeur. Finalement, le banc de registre contient alors la bonne valeur et l'instruction peut s'exécuter sans encombre.

L'idée est que le pointeur de pile est généralement altéré par une série d'instruction PUSH/POP consécutives, puis des instructions LOAD/STORE/ADD/SUB utilisent le pointeur de pile final comme opérande. En clair, une bonne partie des incrémentations/décrémentation est accumulée dans le compteur delta, puis la vraie valeur est calculée une fois pour toutes et est utilisée comme opérande. On accumule un delta dans le compteur delta, et ce compteur delta est additionné quand nécessaire.

Précisons que le compteur delta est placé juste après le décodeur d'instruction, avant même le cache de micro-opération, l'unité de renommage et l'unité d'émission. Ainsi, les incrémentations/décrémentations du pointeur de pile disparaissent dès l'unité de décodage. Elles ne prennent pas de place dans le cache de micro-opération, ni dans la fenêtre d'instruction, ni dans la suite du pipeline. De nombreuses ressources sont économisées dans le ''front-end''.

Mais utiliser un ''stack engine'' a aussi de nombreux avantages au niveau du chemin de données/''back-end''. Déjà, sur les processeurs à exécution dans le désordre, cela libère une unité de calcul qui peut être utilisée pour faire d'autres calculs. Ensuite, le compteur delta mémorise un delta assez court, de 8 bits sur le processeur Pentium M, un peu plus pour les suivants. L'incrémentation se fait donc via un incrémenteur 8 bits, pas une grosse ALU 32/64 bits. Il y a un gain en termes de consommation d'énergie, un incrémenteur 8 bits étant moins gourmand qu'une grosse ALU 32/64 bits.

===Les points de synchronisation du delta===

La technique ne fonctionne que si la vraie valeur du pointeur de pile est calculée au bon moment, avant chaque utilisation pertinente. Il y a donc des '''points de synchronisation''' qui forcent le calcul de la vraie valeur. Plus haut, nous avions dit que c'était à chaque fois qu'une instruction adresse le pointeur de pile explicitement, qui l'utilise comme opérande. Les instructions CALL, RET, PUSH et POP ne sont pas concernées par elles utilisent le pointeur de pile de manière implicite et ne font que l'incrémenter/décrémenter. Mais dans les faits, c'est plus compliqué.

D'autres situations peuvent forcer une synchronisation, notamment un débordement du compteur delta. Le compteur delta est généralement un compteur de 8 bits, ce qui fait qu'il peut déborder. En cas de débordement du compteur, le séquenceur déclenche le calcul de la vraie valeur, puis réinitialise le compteur delta. La vraie valeur est donc calculée en avance dans ce cas précis. Précisons qu'un compteur delta de 8 bits permet de gérer environ 30 instructions PUSH/POP consécutives, ce qui rend les débordements de compteur delta assez peu fréquent. A noter que si le compteur delta vaut zéro, il n'y a pas besoin de calculer la vraie valeur, le séquenceur prend cette situation en compte.

Un autre point de synchronisation est celui des interruptions et exceptions matérielles. Il faut que le compteur delta soit sauvegardé lors d'une interruption et restauré quand elle se termine. Idem lors d'une commutation de contexte, quand on passe d'un programme à un autre. Pour cela, le processeur peut déclencher le calcul de la vraie valeur lors d'une interruption, avant de sauvegarder les registres. Pour cela, le processeur intègre un mécanisme de sauvegarde automatique, qui mémorise la valeur de ce compteur dans le tampon de réordonnancement, pour forcer le calcul de la vraie valeur en cas de problème.

La technique du ''stack engine'' est apparue sur les processeurs Pentium M d'Intel et les processeurs K10 d'AMD, et a été conservée sur tous les modèles ultérieurs. L'implémentation est cependant différente selon les processeurs, bien qu'on n'en connaisse pas les détails et que l'on doive se contenter des résultats de micro-benchmarks et des détails fournit par Intel et AMD. Selon certaines sources, dont les manuels d'optimisation d'Agner Fog, les processeurs AMD auraient moins de points de synchronisation que les processeurs Intel. De plus, leur ''stack engine'' serait placé plus loin que prévu dans le pipeline, après la file de micro-opération.

==Un étude des microarchitectures superscalaires d'Intel==

Après avoir vu beaucoup de théorie, voyons maintenant comment les microarchitectures Intel et AMD ont implémenté l'exécution superscalaire. Nous allons nous concentrer sur les processeurs Intel pour une raison simple : il y a plus de schémas disponibles sur wikicommons, ce qui me facilite le travail.

===Exemple : le Pentium 1/MMX et les pipelines U/V===

Un exemple de processeur superscalaire est celui du premier Pentium. Le pipeline faisait 5 étages : un étage de chargement/prédiction de branchement, deux étages de décodage, un étage d'exécution et un dernier étage pour l'écriture dans les registres. Une organisation très simple, compliquée uniquement par les instructions x86 CISC. 

Le pentium 1 était un processeur à double émission, qui disposait de deux pipelines nommés U et V. On pouvait en tirer parti lorsque deux instructions consécutives pouvaient être exécutées en parallèles, si elles n'avaient pas de dépendances. Chose peu courante, les deux pipelines étaient des pipelines entiers, mais qui n'étaient pas identiques. Les pipelines U et V n'exécutaient pas les mêmes instructions, certaines étaient partagées, d'autres spécifiques au pipeline U, d'autres au pipeline V. Le pipeline U pouvait exécuter toutes les instructions, mais le pipeline V était beaucoup plus limité. 

Avant toute chose, précisons que le pipeline U peut faire des calculs flottants, alors que le pipeline V ne fait que des calculs entiers et des branchements. L'unité flottante était sur le port d'émission du pipeline U, idem pour l'unité de calcul vectoriel MMX sur le Pentium MMX. Les branchements sont exécutables dans les deux pipelines, mais on ne peut exécuter une autre opération en parallèle qu'à la condition que le branchement soit exécuté dans le pipeline V. Passons maintenant aux opérations entières.

Les deux pipelines disposaient d'une unité de calcul entière, ainsi que d'une unité de calcul d'adresse, mais elles n'étaient pas identiques. Les deux unités de calcul entière géraient les opérations bit à bit, les additions et soustractions (et les comparaisons, qui sont des soustractions déguisées). Le pipeline U incorporait aussi des circuits pour les multiplications et les divisions, ainsi qu'un ''barrel shifter'' pour les décalages/rotations. L'unité de calcul d'adresse du pipeline V ne pouvait effectuer que l'instruction LEA, pas les autres calculs d'adresse. 

Les instructions suivantes étaient exécutables dans les deux pipelines, ce qui fait qu'on pouvait en faire deux en même temps :
* l'instruction MOV, dépend du mode d'adressage ;
* les instructions de gestion de la pile PUSH et POP, dépend du mode d'adressage ;
* Les instructions arithmétiques INC, DEC, ADD, SUB ;
* l'instruction de comparaison CMP ;
* les instructions bit à bit AND, OR, XOR ;
* l'instruction de calcul d'adresse LEA ;
* l'instruction NOP, qui ne fait rien.

Les instructions suivantes sont exécutables seulement dans le pipeline U :
* les décalages et rotations, mais seulement pour certains opérandes ou pour certains modes d'adressage. 
* les autres instructions arithmétiques entières, comme la multiplication et la division, mais elles ne permettent pas d'exécuter une opération dans le pipeline V en parallèle.

[[File:Intel Pentium arch.svg|centre|vignette|upright=2.5|Microarchitecture de l'Intel Pentium MMX. On voit que certaines unités de calcul sont dupliquées.]]

===La microarchitecture P6 du Pentium 2/3===

La microachitecture suivante, nommée P6, était une microarchitecture plus élaborée. Le pipeline faisait 12 étages, dont seuls les trois derniers correspondent au chemin de données. Il s'agissait du premier processeur à exécution dans le désordre de la marque, avec une implémentation basée sur des stations de réservation. Il gérait aussi le renommage de registre, avec un renommage de registre dans le ROB, commandé par une table d'alias.

[[File:Intel Pentium Pro Microarchitecture Block Diagram.svg|centre|vignette|upright=2|Intel Pentium Pro Microarchitecture Block Diagram]]

Le décodage des instructions x86 était géré par plusieurs décodeurs. Il y avait trois décodeurs : deux décodeurs simples, et un décodeur complexe. Les décodeurs simples décodaient les instructions les plus fréquentes, mais aussi les plus simples. Les instructions CISC complexes étaient gérées uniquement par le décodeur complexe, basé sur un microcode. Le processeur était à doubvle émission, du fait que les deux décodeurs simples faisaient le gros du travail, et passaient la main au décodeur microcodé quand aucune instruction ne leur était attribué.

Les stations de réservations étaient regroupées dans une structure centralisée, en sortie de l'unité de renommage. Elles avaient 5 ports d'émission, qui étaient sous-utilisés en pratique. Niveau ALU, on trouve deux ALUs entières, une flottante, une unité pour les instructions SSE et autres, et trois unités pour les accès mémoire (regroupées en une seule unité dans le schéma ci-dessous). Les unités mémoire regroupent une unité de calcul d'adresse pour les lectures, une autre pour les écritures, et une unité pour la gestion des données à écrire. Les unités de calcul d'adresse sont des additionneurs à 4 opérandes, complétement différents des ALU entières. Les ALU entières sont deux unités asymétriques : une ALU simple, et une ALU complexe incorporant un multiplieur. Les deux peuvent exécuter des opérations d'addition, soustraction, comparaison, etc.

[[File:P6 func diag.png|centre|vignette|upright=2|P6 func diag]]

===La microarchitecture Netburst du Pentium 4===

La microarchitecture Netburst, utilisée sur le Pentium 4, utilisait un pipeline à 20 étage, augmenté à 32 sur une révision ultérieure. Il a existé quatre révisions de l'architecture : Willamette (180 nm), Northwood (130 nm), Prescott (90 nm) et Cedar Mill (65 nm). Les deux premières avaient un pipeline de 20 étages, les deux suivants avaient 32 étages ! Le grand nombre d'étages permettait d'avoir une fréquence très élevée, mais posait de nombreux problèmes. Vider le pipeline était très long et il fallait une prédiction de branchement au top pour réduire l'impact des mauvaises prédictions. L'unité de prédiction de branchement était une des plus élvoluées pour l'époque. Pour l'époque.

Il dispose d'un cache de trace et a été le seul processeur commercial à en utiliser un. Niveau décodeurs, on retrouve le décodeur lent à base de microcode présent sur les anciennes versions, couplé à un décodeur simple. L'unité de renomage utilise une table d'alias. Le renommage de registres se fait avec un banc de registres physiques. Vous pouvez remarquer dans le schéma suivant la présence de deux files de micro-opérations : une pour les accès mémoire, l'autre pour les autres opérations. Il s'agit bel et bien de deux files d'instructions, pas de fenêtres d'instruction ni de stations de réservation.

Niveau ports d'émission, il y a quatre ports. Un pour les lectures mémoire, un pour les écriture mémoire, et deux autres qui mélangent FPU et ALUs. Le premier port est relié à une ALU complexe et une FPU spécialisée dans les MOV flottants. Le second port est relié à tout le reste : ALU basique ''barrel shifter'', FPU. Fait amusant, les ALU entières étaient cadencées à une fréquence double de celle du processeur, ce qui fait que les files d'émissionsont aussi censées l'être, de même que les ''scoreboard''. Sauf qu'en réalité, les circuits étaient dupliqués : l'un allait à une fréquence double, l'autre allait à la fréquence normale.

[[File:Architettura Pentium 4.png|centre|vignette|upright=3|Microarchitecture du Pentium 4.]]

===Les microarchitectures x86 d'AMD===

Les architectures AMD ont beaucoup évoluées avec le temps. La toute première était l'architecture K5, qui disposait de deux ALU entières, d'une FPU, de deux unités LOAD/STORE pour les accès mémoire et d'une unité de branchement. Elle était capable de décoder 4 instructions différentes par cycle et utilisait une station de réservation par unité de calcul (sauf pour les unités mémoire, qui partagent une seule station de réservation).

[[File:AMDK5Diagram.png|centre|vignette|upright=3|AMDK5 Diagramme.]]

L'architecture K6 a ajouté une unité SIMD aux unité précédentes, sans compter que les deux unités LOAD/STORE sont séparées en une unité LOAD pour les lectures et une unité STORE pour les écritures. Elle a aussi abandonné les stations de réservation pour une structure centralisée, dont je ne sais pas s'il s'agit d'une fenêtre d’instruction ou d'une station de réservation. Le processeur était capable de décoder 4 instructions, mais aussi d'émettre en même 6 micro-opérations (une par unité de calcul/mémoire).

[[File:Amdk6 arch.svg|centre|vignette|upright=3|Microarchitecture K6 d'AMD.]]

La microarchitecture K7 des processeurs Athlon ne pouvait que décoder que trois instructions par cycle, soit une de moins que les architectures précédentes. Mais elle se rattrapait sur l'exécution dans le désordre. Elle avait un tampon de ré-ordonnancement de 72 instructions, nommé ''instruction control unit'' dans le schéma qui suit. Elle avait deux stations de réservation : une pour les opérations flottantes, une autre pour les instructions entières et les accès mémoire. Le processeur utilisait le renommage de registre, mais seulement pour les registres flottants, pas pour les registres entiers.

Il y avait trois unités de calcul entières, chacun avec son propre port d'émission, et un circuit multiplieur relié sur le premier port d'émission entier. Les unités de calcul entières peuvent aussi être utilisées comme unités de calcul d'adresse. Niveau unités flottantes, le processeur avait une unité d'addition flottante, une unité de multiplication flottante, et une autre unité pour le reste.

[[File:Athlon arch.png|centre|vignette|upright=3|Microarchitecture K7 d'AMD.]]

La microarchitecture suivante, nommée K8, a elle-même été suivie par l'architecture K10, assez similaire. Il n'y a pas de K9, qui a été abandonné en cours de développement. La microarchitecture K10 a été déclinée en plusieurs versions, nommées Grayhound, Grayhound+ et Husky, Husky étant une architecture gravée en 32 nm dédiée aux processeurs A-3000.

L'architecture K10 a les mêmes ALU, mais a une organisation différente pour ses stations de réservation. Premièrement, le processeur utilise le renommage de registres pour tous les registres, entiers comme flottants. Niveau micro-opérations entières, la station de réservation unique de 15 micro-opérations est remplacée par trois stations de réservations, une par ALU entière, de 8 micro-opérations chacune. Chaque station de réservation entière alimente une unité de calcul entière et une unité de calcul d'adresse. Le multiplieur est relié à la première station de réservation, sur le même port d'émission que l'ALU. Les stations de réservation sont nommées des ''schedulers'' dans les schémas qui suivent.

[[File:AMD Grayhound microarchitecture.png|centre|vignette|upright=3|Microarchitecture K8 et K10 d'AMD.]]

L'architecture Grayhound a plus de cache et un ROB plus grand, la Husky est quand à elle un peu plus différente. Elle n'a pas de cache L3, contrairement aux autres architectures K10, ce qui simplifie fortement son sous-système mémoire. Par contre, les fenêtres d'instructions/stations de réservation et le ROB sont plus grands, pareil pour les files dans l'unité mémoire. Une ALU pour les divisions entières a aussi été ajoutée.

[[File:AMD Husky microarchitecture.png|centre|vignette|upright=3|AMD Husky microarchitecture]]

Viennent ensuite les microarchitectures Bulldozer, avec trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Mais du fait de l'utilisation de techniques de multithreading matériel que nous n'avons pas encore abordé, nous ne pouvons pas en parler ici.

Les microarchitectures suivantes sont les architecture ZEN 1/2/3/4/5. Elles se ressemblent beaucoup, chacune accumulant les améliorations des précédentes. Mais le cœur de l'architecture reste plus ou moins le même. En passant à la suivante, le nombre de registre virtuel augmente, le ''branch target buffer'' augmente en taille, le ROB et les files d'attente grossissent, les caches de micro-opération aussi, les caches grossissent, etc. La microarchitecture Zen 1 est illustrée ci-dessous. Le passage à Zen 2 a ajouté une unité de calcul d'adresse (4 ALU / 3 AGU), le Zen 5 a ajouté deux autres ALU entières et une unité de calcul d'adresse (6 ALU / 4 AGU)

[[File:Zen microarchitecture.svg|centre|vignette|upright=3|Microarchitecture Zen 1 d'AMD.]] 

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Le parallélisme mémoire au niveau du cache
           | prevText=Le parallélisme mémoire au niveau du cache
           | next=Les processeurs VLIW et EPIC
           | nextText=Les processeurs VLIW et EPIC
}}
&lt;/noinclude&gt;</text>
      <sha1>2bbv3j5ou5kxcl0ko2rq2at94x0shjc</sha1>
    </revision>
  </page>
  <page>
    <title>Fonctionnement d'un ordinateur/Architectures multiprocesseurs et multicœurs</title>
    <ns>0</ns>
    <id>65962</id>
    <revision>
      <id>745448</id>
      <parentid>745223</parentid>
      <timestamp>2025-06-26T23:57:48Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les architectures à cœurs conjoints */</comment>
      <origin>745448</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="32321" sha1="mftd6t3thh49tnaiiodneev8zvhjvdq" xml:space="preserve">Pour réellement tirer parti du parallélisme de taches, rien ne vaut l'utilisation de plusieurs processeurs et/ou de plusieurs ordinateurs, qui exécutent chacun un ou plusieurs programmes dans leur coin. Si utiliser plusieurs ordinateurs connectés par un réseau local est une solution simple et facile à implémenter, elle est cependant assez onéreuse et demande des logiciels adaptés qui permettent de profiter d'une telle architecture matérielle. D'autres solutions multiprocesseurs ont alors vu le jour pour rendre l'usage de plusieurs processeurs plus adéquat.

==Les systèmes multiprocesseur==

Les '''systèmes multiprocesseur''' placent plusieurs processeurs sur la même carte mère. Cette méthode marchait bien mais n'était pas des plus pratique, surtout que l'utilisation de plusieurs processeurs en même temps n'était de plus pas vraiment démocratisé à cette époque. Les logiciels et les systèmes d'exploitation grand public n'étaient pas adaptés pour, la demande pour des ordinateurs multiprocesseurs était limitée à quelques professionnels et ne justifiait pas un investissement majeure dans ces technologies.

Au niveau matériel, il fallait une carte mère adaptée, qui n'était pas facilement disponible et coûtait généralement plus cher que les cartes mères à un seul processeur. Sans compter qu'il valait mieux avoir une mémoire RAM rapide et des processeurs dotés de beaucoup de mémoire cache, ce qui coûtait encore plus cher. Au final, le gain était assez faible en terme de performance, peu de logiciels grand public profitaient de l'usage de plusieurs processeurs, la technologie est restée confidentielle.

===Le réseau d'interconnexion inter-processeur===

Un système multi-processeurs doit connecter entre eux plusieurs processeurs. Pour cela, les cartes mères multi-processeurs incorporent un réseau d'interconnexion pour connecter les processeurs entre eux, et les connecter avec la mémoire et les autres entrées-sorties. Il s'agit d'un '''réseau d'interconnexion inter-processeur''', placé sur la carte mère. Les processeurs sont tous connectés en utilisant deux solutions : soit avec un bus partagé, soit avec un réseau d'interconnexion très complexe.

Une solution simple relie les processeurs/cœurs entre eux grâce à un '''bus partagé'''. Nous parlerons en détail du bus partagé dans le chapitre sur la cohérence des caches, mais nous pouvons aborder le sujet maintenant, en précisant quel est ce bus partagé. Et suivant que l'on parle de systèmes multi-processeurs ou multicœurs, le bus qui est partagé n'est pas le même. Le cas le plus simple est celui d'une architecture multi-processeurs. Les processeurs sont alors tous reliés à la mémoire RAM à travers le bus mémoire. Le bus mémoire sert de point de ralliement, de point de convergence, il est le bus partagé. Les transferts entre caches se font alors en utilisant le bus mémoire.

[[File:Architecture multicoeurs à bus partagé.png|centre|vignette|upright=2|Architecture multiprocesseurs à bus partagé]]

De nos jours, les cartes mères pour serveur n'utilisent plus de bus partagé, mais utilisent un réseau d'interconnexion plus élaboré. Le réseau en question est un vrai réseau, qui peut être un réseau en anneau, un réseau crossbar, un réseau routé, etc. Le réseau d'interconnexion relie entre eux les cœurs, l'interface avec la mémoire RAM, le cache partagé L3/L4, mais aussi le bus PCI-Express, le GPU et quelques autres circuits séparés.

[[File:Architecture multicoeurs et réseau sur puce.png|centre|vignette|upright=1.5|Architecture multicoeurs et réseau sur puce]]

Les systèmes multi-processeurs modernes utilisent des réseaux d'interconnexion standardisés, les standards les plus communs étant l'HyperTransport, l'Intel QuickPath Interconnect, l'IBM Elastic Interface, le Intel Ultra Path Interconnect, l'Infinity Fabric, etc. Ils remplacent le fameux ''front-side bus'' des tout premiers processeurs multicœurs.

Un exemple de réseau d'interconnexion est celui des architectures AMD EPYC, de microarchitecture Zen 1. Elles utilisaient des chiplets, à savoir que le processeur était composé de plusieurs puces interconnectées entre elles. Chaque puce contenait un processeur multicoeurs intégrant un cache L3, avec un réseau d'interconnexion interne au processeur sans doute basé sur un ensemble de bus. De plus, les puces étaient reliées à une puce d'interconnexion qui servait à la fois d'interface entre les processeurs, mais aussi d'interface avec la R1AM, le bus PCI-Express, etc. La puce d'interconnexion était gravée en 14 nm contre 7nm pour les chiplets des cœurs. 

{|
|[[File:AMD Epyc 7702 delidded.jpg|centre|vignette|upright=2|AMD Epyc 7702.]]
|[[File:AMD Epyc Rome Aufbau.png|centre|vignette|upright=2|Schéma fonctionnel de l'AMD Epyc.]]
|}

===Les interruptions inter-processeurs===

Les différents processeurs sont gérés par le système d'exploitation de l'ordinateur, avec l'aide d''''interruptions inter-processeurs''', des interruptions déclenchées sur un processeur et exécutées sur un autre, éventuellement par tous les autres pour certaines interruptions spécifiques. Pour générer des interruptions inter-processeur, le contrôleur d'interruption doit pouvoir rediriger des interruptions déclenchées par un processeur vers un autre.

Un exemple d'implémentation très simple est celui de la console Néo-géo, qui contenait deux processeurs. Le premier est un Motorola 68000 qui sert de processeur principal, l'autre est un Z80 qui sert de processeur dédié à l'audio. Le Z80 commande un synthétiseur sonore, et est relié à sa propre mémoire, distincte de la mémoire principale. Le MC68000 est le processeur principal et a une relation maitre-esclave avec le Z80 : le MC68000 envoie des interruptions au Z80, mais la communication ne va pas dans l'autre sens.

Les deux processeurs communiquent via l'intermédiaire d'un '''''IO arbiter chip''''', un circuit sur la carte mère connecté ua bus, qui gère les interruptions inter-processeur. Il contient un registre de 8 bits, dans lequel le MC68000 peut écrire dedans à sa guise, le registre étant adressable par le processeur. Les valeurs écrites dans ce registre sont des numéros d'interruption, qui indiquent quelle routine d'interruption exécuter. Lorsque le MC68000 écrit une valeur dedans, cela déclenche l’exécution automatique d'une interruption sur le Z80. Le code de 8 bits est envoyé au processeur Z80, en parallèle de l'interruption.

: Il est possible de voir ce ''IO arbiter chip'' comme un contrôleur d'interruptions spécialisé dans les interruptions inter-processeur.

Les anciens PC incorporaient sur leur carte mère un contrôleur d'interruption créé par Intel, le 8259A, qui ne gérait pas les interruptions inter-processeurs. Les cartes mères multiprocesseurs devaient incorporer un contrôleur spécial en complément. De nos jours, chaque cœur x86 possède son propre contrôleur d’interruption, le local APIC, qui gère les interruptions en provenance ou arrivant vers ce processeur. On trouve aussi un IO-APIC, qui gère les interruptions en provenance des périphériques et de les redistribuer vers les APIC locaux. L'IO-APIC gère aussi les interruptions inter-processeurs en faisant passer les interruptions d'un local APIC vers un autre. Tous les APIC locaux et l'IO-APIC sont reliés ensembles par un bus APIC spécialisé, par lequel ils vont pouvoir communiquer et s'échanger des demandes d'interruptions.

[[File:Contrôleurs d'interrptions sur systèmes x86 multicoeurs.png|centre|vignette|upright=1.5|Contrôleurs d’interruptions sur systèmes x86 multicœurs.]]

On peut préciser le processeur de destination en configurant certains registres du IO-APIC, afin que celui-ci redirige la demande d'interruption d'un local APIC vers celui sélectionné. Cela se fait avec l'aide d'un registre de 64 bits nommé l'''Interrupt Command Register''. Pour simplifier le mécanisme complet, chaque processeur se voit attribuer un Id au démarrage qui permet de l'identifier (en fait, cet Id est attribué au local APIC de chaque processeur). Certains bits de ce registre permettent de préciser quel est le type de transfert : doit-on envoyer l'interruption au processeur émetteur, à tous les autres processeurs, à un processeur particulier. Dans le dernier cas, certains bits du registre permettent de préciser l'Id du processeur qui va devoir recevoir l'interruption. À charge de l'APIC de faire ce qu'il faut en fonction du contenu de ce registre.

==Les processeurs multicœurs==

Puis, avec les progrès en matière de miniaturisation des processeurs, les fabricants ont eu l'idée d'utiliser les transistors qu'ils avaient pour fabriquer des '''processeurs multicœurs''', un terme que vous avez peut-être déjà entendu sans vraiment comprendre ce qu'il signifiait réellement. Les processeurs multicœurs peuvent être vus comme un regroupement de plusieurs processeurs sur la même puce de silicium.

Pour être plus précis, ils contiennent plusieurs ''cœurs'', chaque cœur pouvant exécuter un programme tout seul. Chaque cœur dispose de toute la machinerie électronique pour exécuter un programme, que ce soit un séquenceur d'instruction, des registres, une unité de calcul. Par contre, certains circuits d'un processeur ne sont présents qu'en un seul exemplaire dans un processeur multicœurs, comme les circuits de communication avec la mémoire ou les circuits d’interfaçage avec la carte mère. Suivant le nombre de cœurs présents dans notre processeur, celui-ci sera appelé un processeur double-cœur (deux cœurs), quadruple-cœur (4 cœurs), octuple-cœur (8 cœurs), etc. Ces processeurs sont devenus la norme dans les ordinateurs grand public et les logiciels et systèmes d'exploitation se sont adaptés.

Dans ce qui suit, nous utiliserons le terme cœurs pour désigner soit les cœurs d'un processeur multicœurs, soit les différents processeurs d'un ordinateur multiprocesseur. Tout le contenu de ce chapitre vaut aussi bien pour les systèmes multicœurs que multiprocesseur. Les différences entre les deux sont mineures, les deux font face aux mêmes problèmes, les mêmes solutions peuvent s'appliquer sur les deux types de systèmes.

===Le multicœurs symétrique ou asymétrique===

Dans la grosse majorité des cas, les cœurs d'un processeur multicœurs sont tous identiques. Mais ce n'est certainement pas une obligation et on peut très bien mettre plusieurs cœurs assez différents sur la même puce. On peut par exemple utiliser un cœur principal avec des cœurs plus spécialisés autour. Il faut ainsi distinguer le '''multicœurs symétrique''', dans lequel on place des processeurs identiques sur la même puce de silicium, du '''multicœurs asymétrique''' où les cœurs ne sont pas identiques.

Un exemple est celui du processeur CELL de la console de jeu PS3. Il intègre un cœur principal POWER PC v5 et 8 coeurs qui servent de processeurs auxiliaires. Le processeur principal est appelé le PPE et les processeurs auxiliaires sont les SPE. Les SPE sont reliés à une mémoire locale (''local store'') de 256 kibioctets qui communique avec le processeur principal via un bus spécial. Les SPE communiquent avec la RAM principale via des contrôleurs DMA. Les SPE possèdent des instructions permettant de commander leur contrôleur DMA et c'est le seul moyen qu'ils ont pour récupérer des informations depuis la mémoire. Et c'est au programmeur de gérer tout ça ! C'est le processeur principal qui va envoyer aux SPE les programmes qu'ils doivent exécuter. Il délègue des calculs aux SPE en écrivant dans le local store du SPE et en lui ordonnant l’exécution du programme qu'il vient d'écrire.

[[File:Schema Cell.png|centre|vignette|upright=2|Architecture du processeur CELL de la PS3. Le PPE est le processeur principal, les SPE sont des processeurs auxiliaires qui comprennent : un ''local store'' noté LS, un processeur noté SXU, et un contrôleur DMA pour échanger des informations avec la mémoire principale.]]

===Les architectures à cœurs conjoints===

Sur certains processeurs multicœurs, certains circuits sont partagés entre plusieurs cœurs. Cette technique consistant à ne pas dupliquer certains circuits et à en partager certains s'appelle le '''cluster multithreading''', ou encore les '''architectures à cœurs conjoints''' (''Conjoined Core Architectures''). Typiquement, les mémoires caches et l'unité de calcul flottantes peuvent être partagées sans trop de problèmes, les unités SIMD qu'on verra dans quelques chapitres sont aussi dans ce cas.

Elle est notamment utilisée sur les processeurs AMD de microarchitecture Bulldozer, incluant ses trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Un exemple est celui des processeurs AMD FX-8150 et FX-8120. Sur ces processeurs, tous les cœurs se partagent l'unité de calcul sur les nombres flottants. Le partage de circuits permet d'éviter de dupliquer trop de circuits et donc d'économiser des transistors. Le problème est que ce partage est source de dépendances structurelles, ce qui peut entraîner des pertes de performances.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]]

===Les architectures ''many core''===

Les architectures ''many core'' ont un très grand nombre de cœurs, plus d'une cinquantaine, voire plusieurs centaines ou milliers. La différence est surtout une question de degré, mais aussi de but recherché.

Les architectures multicœurs sont surtout conçues pour les ordinateurs personnels, éventuellement les serveurs. Elles recherchent un bon compromis entre un grand nombre de cœurs, et une bonne performance pour les programmes non-parallèles. En clair, elles évitent de sacrifier les performances pour les applications non-parallèles, ce qui fait que leurs cœurs sont généralement très puissants, avec beaucoup d'optimisations micro-architecturales.

Les architectures ''many core'' font le compromis inverse : elles ont beaucoup de cœurs, mais ceux-ci ne sont pas très puissants, surtout pour les applications non-parallèles. Les cœurs des architectures ''many core'' sont généralement des cœurs sans exécution dans le désordre, sans prédiction de branchements, sans renommage de registres, voire sans pipeline ni parallélisme d'instruction.

==Le partage des caches==

Quand on conçoit un processeur multicœur, il ne faut pas oublier ce qui arrive à la pièce maîtresse de tout processeur actuel : le cache ! Pour le moment nous allons oublier le fait que les processeurs ont une hiérarchie de caches, avec des caches L1, L2, L3 et autres. Nous allons partir du principe qu'un processeur simple cœur a un seul cache, et voir comment adapter le cache à la présence de plusieurs cœurs. Nous allons rapidement lever cette hypothèse, pour étudier le cas où un processeur multicœur a une hiérarchie de caches, mais seulement après avoir vu le cas le plus simple à un seul cache.

===Le partage des caches sans hiérarchie de caches : caches dédiés et partagés===

Avec un seul niveau de cache, sans hiérarchie, deux solutions sont possibles. La première consiste à garder un seul cache, et de le partager entre les cœurs. L'autre solution est de dupliquer le cache et d'utiliser un cache par cœur. Les deux solutions sont appelées différemment. On parle de '''caches dédiés''' si chaque cœur possède son propre cache, et de '''cache partagé''' avec un cache partagé entre tous les cœurs. Ces deux méthodes ont des inconvénients et des avantages.

{|
|[[File:Caches dédiés.png|vignette|Caches dédiés]]
|[[File:Caches partagés.png|vignette|Cache partagé]]
|}

Le premier point sur lequel comparer caches dédiés et partagés est celui de la capacité du cache. La quantité de mémoire cache que l'on peut placer dans un processeur est limitée, car le cache prend beaucoup de place, près de la moitié des circuits du processeur. Aussi, un processeur incorpore une certaine quantité de mémoire cache, qu'il faut répartir entre un ou plusieurs caches. Les caches dédiés et partagés ne donnent pas le même résultat. D'un côté, le cache partagé fait que toute la mémoire cache est dédiée au cache partagé, qui est très gros. De l'autre, on doit répartir la capacité du cache entre plusieurs caches séparés, individuellement plus petits. En conséquence, on a le choix entre un petit cache pour chaque processeur ou un gros cache partagé.

Le choix entre les deux n'est pas simple, mais doit tenir compte du fait que les programmes exécutés sur les cœurs n'ont pas les mêmes besoins. Certains programmes sont plus gourmands et demandent beaucoup de cache, alors que d'autres utilisent peu la mémoire cache. Avec un cache dédié, tous les programmes ont accès à la même quantité de cache, car les caches des différents cœurs sont de la même taille. Les caches dédiés étant assez petits, les programmes plus gourmands devront se débrouiller avec un petit cache, alors que les autres programmes auront du cache en trop. A l'opposé, un cache partagé répartit le cache de manière optimale : un programme gourmand peut utiliser autant de cache qu'il veut, laissant juste ce qu'il faut aux programmes moins gourmands. le cache peut être répartit plus facilement selon les besoins des différents programmes.

[[File:Cache partagé contre cache dédié.png|centre|vignette|upright=2.5|Cache partagé contre cache dédié]]

Un autre avantage des caches partagés est quand plusieurs cœurs accèdent aux même données. C'est un cas très courant, souvent lié à l'usage de mémoire partagé ou de ''threads''. Avec des caches dédiés, chaque cœur a une copie des données partagées. Mais avec un cache partagé, il n'y a qu'une seule copie de chaque donnée, ce qui utilise moins de mémoire cache. Imaginons que l'on sait 8 caches dédiés de 8 Kibioctets, soit 64 kibioctets au total, comparé à un cache partagé de même capacité totale. Les doublons dans les caches dédiés réduiront la capacité mémoire utile, effective, comparé à un cache partagé. S'il y a 1 Kibioctet de mémoire partagé, 8 kibioctets seront utilisés pour stocker ces données en doublons, seulement 1 kibioctet sur un cache partagé. Ajoutons aussi que la cohérence des caches est grandement simplifiée avec l'usage d'un cache partagé, vu que les données ne sont pas dupliquées dans plusieurs caches.

Mais le partage du cache peut se transformer en inconvénient si les programmes entrent en compétition pour le cache, que ce soit pour y placer des données ou pour les accès mémoire. Deux programmes peuvent vouloir accéder au cache en même temps, voire carrément se marcher sur les pieds. La résolution des conflits d'accès au cache est résolu soit en prenant un cache multiport, avec un port dédié par cœur, soit par des mécanismes d'arbitrages avec des circuits dédiés. Le revers de la médaille tient au temps de latence. Plus un cache est gros, plus il est lent. En conséquence, des caches dédiés seront plus rapides qu'un  gros cache partagé plus lent.

===Le partage des caches adapté à une hiérarchie de caches===

Dans la réalité, un processeur multicœur ne contient pas qu'un seul cache, mais une hiérarchie de caches avec des caches L1, L2 et L3, parfois L4. Dans cette hiérarchie, certains caches sont partagés entre plusieurs cœurs, les autres sont dédiés. Le cache L1 n'est jamais partagé, car il doit avoir un temps d'accès très faible. Pour les autres caches, tout dépend du processeur.

[[File:Dual Core Generic.svg|vignette|Cache L2 partagé.]]

Les premiers processeurs multicœurs commerciaux utilisaient deux niveaux de cache : des caches L1 dédiés et un cache L2 partagé. Le cache L2 partagé était relié aux caches L1, grâce à un système assez complexe d'interconnexions. Le cache de niveau L2 était souvent simple port, car les caches L1 se chargent de filtrer les accès aux caches de niveau inférieurs.

Les processeurs multicœurs modernes ont des caches L3 et même L4, de grande capacité, ce qui a modifié le partage des caches. Le cache le plus proche de la mémoire, le cache de dernier niveau L3 ou L4, est systématiquement partagé, car son rôle est d'être un cache lent mais gros. Le cas du cache L2 dépend des architectures : il est partagé sur certains processeurs, dédié sur d'autres.

Dans le cas le plus courant, il y a plusieurs caches L2 qui sont chacun partagés entre plusieurs cœurs mais pas à tous. En effet, on peut limiter le partage du cache à quelques cœurs particuliers pour des raisons de performances.

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2.0|Partage des caches sur un processeur multicœur.]]

D'autres processeurs ont des caches L2 dédiés. Il s'agit surtout des processeurs multicœurs anciens, parmi les premières générations de processeurs multicœurs. Un exemple est celui de la microarchitecture Nehalem d'Intel. Il avait des caches L1 et L2 dédiés, mais un cache L3 partagé.

[[File:Nehalem EP.png|centre|vignette|upright=2.0|Partage des caches sur un processeur Intel d'architecture Nehalem.]]

===Les caches partagés centralisés et distribués===

Un point important est que quand on parle de cache partagé ou de cache dédié, on ne parle que de la manière dont les cœurs peuvent accéder au cache, pas de la manière dont le caches est réellement localisé sur la puce. En théorie, qui dit plusieurs caches dédiés signifie que l'on a vraiment plusieurs caches séparés sur la puce. Et chaque cache dédié est proche du cœur qui lui est attribué. Et pour les caches partagés unique, une portion de la puce de silicium contient le cache, que cette portion est un énorme bloc de transistors. Il est généralement placé au milieu de la puce ou sur un côté, histoire de facilement le connecter à tous les cœurs.

Mais pour les caches séparés, ce n'est pas toujours le cas. Avoir un cache énorme poserait des problèmes sur les architectures avec beaucoup de cœurs. En réalité, le cache est souvent découpé en plusieurs banques, reliées à un contrôleur du cache par un système d'interconnexion assez complexe. Les banques sont physiquement séparées, et il arrive qu'elles soient placées proche d'un cœur chacune. L'organisation des banques ressemble beaucoup à l'organisation des caches dédiés, avec une banque étant l'équivalent d'un cache dédié. La différence est que les cœurs peuvent lire et écrire dans toutes les banques, grâce au système d'interconnexion et au contrôleur de cache.

Tel était le cas sur les processeurs AMD Jaguar. Ils avaient un cache L2 de 2 mébioctets, partagés entre tous les cœurs, qui était composé de 4 banques de 512 Kibioctets. Les quatre banques du cache étaient reliées aux 4 cœurs par un réseaux d'interconnexion assez complexe.

[[File:AMDJaguarModule.png|centre|vignette|upright=2|AMD Jaguar Module]]

La différence entre les deux solutions pour les caches partagés porte le nom de cache centralisés versus distribués. Un gros cache unique sur la puce est un '''cache centralisé''', et c'est généralement un cache partagé. Mais un cache composé de plusieurs banques dispersées sur la puce est un '''cache distribué''', qui peut être aussi bien dédié que partagé.

===Les caches virtualisés===

Il faut noter que quelques processeurs utilisent cette technique pour fusionnent le cache L2 et le cache L3. Par exemple, les processeurs IBM Telum utilisent des caches L3 virtualisés, dans leurs versions récentes. Le processeur Telum 2 contient 10 caches L2 de 36 mébioctets chacun, soit 360 mébioctets de cache. L'idée est que ces 360 mébioctets sont partagés à la demande entre cache L2 dédié et cache L3. On parle alors de '''cache virtualisé'''.

Un cache de 36 mébioctet est associé à un cœur, auquel il est directement relié. Les cœurs n'utilisent pas tous leur cache dédié à 100% Il arrive que des cœurs aient des caches partiellement vides, alors que d'autres on un cache qui déborde. L'idée est que si un cœur a un cache plein, les données évincées du cache L2 privé sont déplacées dans le cache L2 d'un autre cœur, qui lui est partiellement vide. Le cache L2 en question est alors partitionné en deux : une portion pour les données associée à son cœur, une portion pour les données des L2 des autres cœurs. 

Pour que la technique fonctionne, le processeur mesure le remplissage de chaque cache L2. De plus, il faut gérer la politique de remplacement des lignes de cache. Une ligne de cache évincée du cache doit être déplacé dans un autre L2, pas dans les niveaux de cache inférieur, ni dans la mémoire. Du moins, tant qu'il reste de la place dans le cache L3. De plus, une lecture/écriture dans le cache L3 demande de localiser le cache L2 contenant la donnée. Pour cela, les caches L2 sont tous consultés lors d'un accès au L3, c'est la solution la plus simple, elle marche très bien si le taux de défaut du cache L2 est faible.

Une telle optimisation ressemble beaucoup à un cache L2/L3 distribué, mais il y a quelques différences qui sont décrites dans le paragraphe précédent. Avec un L2 distribué, tout accès au L2 déclencherait une consultation de toutes les banques du L2. Avec un cache L3 virtualisé, ce n'est pas le cas. Le cache L2 associé au cœur est consulté, et c'est seulement en cas de défaut de cache que les autres caches L2 sont consultés. De plus, avec un cache L2 distribué, il n'y a pas de déplacement d'une ligne de cache entre deux banques, entre deux caches L2 physiques. Alors qu'avec un cache L3 virtualisé, c'est le cas en cas de remplacement d'une ligne de cache dans le cache L2.

Sur le processeur Telum 1, le partage du cache L2 est assez simple. Un cache L2 fait 32 mébioctets et est découpé en deux banques de 16 mébioctets. En temps normal, les premiers 16 mébioctets sont toujours associé au cache L2, au cœur associé. Les 16 mébioctets restants peuvent soit être attribués au cache L3, soit fusionnés avec les 16 premiers mébioctets. Dans le cas où le cœur associé est en veille, n'est absolument pas utilisé, les 32 mébioctets sont attribués au cache L3. Un partage assez simple, donc. Le partage du cache L2/L3 sur les processeurs Telum 2 n'est pas connu, il est supposé être plus flexible.

==Le réseau d'interconnexion entre cœurs==

Les CPU multicœurs connectent plusieurs cœurs entre eux, tout comme les systèmes multi-processeurs connectent plusieurs processeurs entre eux. Mais les transferts de données entre cœurs se font par l'intermédiaire des caches, ce qui fait que l'implémentation est différente de celle utilisée sur les systèmes multi-processeurs. Les standards pour les interconnexions entre coeurs sont assez proches de ceux utilisés pour interconnecter des processeurs, mais les standards utilisés ne sont pas les mêmes en pratique. Là encore, les cœurs sont connectés entre eux soit par un bus, soit par un réseau d'interconnexion.

===Le bus partagé entre plusieurs cœurs===

Une solution simple relie les cœurs entre eux grâce à un '''bus partagé'''. Le cas le plus simple est celui où chaque cœur dispose de caches dédiés, qui sont alors tous reliés au bus mémoire, qui sert d'intermédiaire. Mais l'idée doit être adaptée sur les processeurs multicœurs avec des caches partagés. Voyons d'abord le cas d'un CPU avec deux niveaux de cache, dont un cache L2 est partagé entre tous les cœurs. Les caches L1 sont reliés au cache L2 partagé par un bus, qui n'a souvent pas de nom. Nous désignerons le bus entre le cache L1 et le cache L2 : '''bus partagé''', sous-entendu partagé entre tous les caches. C'est lui qui sert à connecter les cœurs entre eux.

[[File:Architecture multicoeurs à bus partagé entre caches L1 et L2.png|centre|vignette|upright=2|Architecture multicoeurs à bus partagé entre caches L1 et L2]]

Un processeur multicœur typique a une architecture avec trois niveaux de cache (L1, L2 et L3), avec un niveau L1 dédié par cœur, un niveau L2 partiellement partagé et un L3 totalement partagé. Le bus partagé est alors difficile à décrire, mais il correspond à l'ensemble des bus qui connectent les caches L1 aux caches L2, et les caches L2 au cache L3. Il s'agit alors d'un ensemble de bus, plus que d'un bus partagé unique.

===Le réseau d'interconnexion entre plusieurs cœurs===

Relier plusieurs cœurs avec des bus pose de nombreux problèmes techniques qui sont d'autant plus problématiques que le nombre de cœurs augmente. Le câblage est notamment très complexe, les contraintes électriques pour la transmission des signaux sont beaucoup plus fortes, les problèmes d'arbitrages se font plus fréquents, etc. Pour régler ces problèmes, les processeurs multicoeurs n'utilisent pas de bus partagé, mais un réseau d'interconnexion plus complexe.

Le réseau d'interconnexion peut être très complexe, avec des connexions réseau, des commutateurs, et des protocoles d'échanges entre processeurs assez complexes basés sur du passage de messages. De telles puces utilisent un '''réseau sur puce''' (''network on chip''). Mais d'autres simplifient le réseau d'interconnexion, qui se résume à un réseau ''crossbar'', voire à des mémoires FIFO pour faire l'interface entre les cœurs.

Le problème principal des réseaux sur puce est que les mémoires FIFOs sont difficiles à implémenter sur une puce de silicium. Elles prennent beaucoup de place, utilisent beaucoup de portes logiques, consomment beaucoup d'énergie, sont difficiles à concevoir pour diverses raisons (les accès concurrents/simultanés sont fréquents et font mauvais ménage avec les ''timings'' serrés de quelques cycles d'horloges requis). Il est donc impossible de placer beaucoup de mémoires FIFO dans un processeur, ce qui fait que les commutateur sont réduits à leur strict minimum : un réseau d'interconnexion, un système d'arbitrage simple parfois sans aucune FIFO, guère plus.

===Les architectures en ''tile''===

Un cas particulier de réseau sur puce est celui des '''architectures en ''tile''''', des architectures avec un grand nombre de cœurs, connectés les unes aux autres par un réseau d'interconnexion &quot;rectangulaire&quot;. Chaque cœur est associé à un commutateur (''switch'') qui le connecte au réseau d'interconnexion, l'ensemble formant une ''tile''.

[[File:Tile64-Tile.svg|centre|vignette|upright=1.5|''Tile'' de base du Tile64.]]

Le réseau est souvent organisé en tableau, chaque ''tile'' étant connectée à plusieurs voisines. Dans le cas le plus fréquent, chaque ''tile'' est connectée à quatre voisines : celle du dessus, celle du dessous, celle de gauche et celle de droite. Précisons que cette architecture n'est pas une architecture distribuée dont tous les processeurs seraient placés sur la même puce de silicium. En effet, la comparaison ne marche pas pour ce qui est de la mémoire : tous les cœurs accèdent à une mémoire partagée située en dehors de la puce de silicium. Le réseau ne connecte pas plusieurs ordinateurs séparés avec chacun leur propre mémoire, mais plusieurs cœurs qui accèdent à une mémoire partagée.

Un bon exemple d'architecture en ''tile'' serait les déclinaisons de l'architecture Tilera. Les schémas du-dessous montrent l'architecture du processeur Tile 64. Outre les ''tiles'', qui sont les éléments de calcul de l'architecture, on trouve plusieurs contrôleurs mémoire DDR, divers interfaces réseau, des interfaces série et parallèles, et d'autres entrées-sorties.

[[File:Tile64.svg|centre|vignette|upright=2|Architecture Tile64 du Tilera.]]

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Les architectures parallèles
           | prevText=Les architectures parallèles
           | next=Architectures multithreadées et Hyperthreading
           | nextText=Architectures multithreadées et Hyperthreading
}}
&lt;/noinclude&gt;</text>
      <sha1>mftd6t3thh49tnaiiodneev8zvhjvdq</sha1>
    </revision>
    <revision>
      <id>745449</id>
      <parentid>745448</parentid>
      <timestamp>2025-06-27T00:04:14Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les architectures à cœurs conjoints */</comment>
      <origin>745449</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="32806" sha1="ej7aoj00vj4fmpbdkoxjjiacqymy6v9" xml:space="preserve">Pour réellement tirer parti du parallélisme de taches, rien ne vaut l'utilisation de plusieurs processeurs et/ou de plusieurs ordinateurs, qui exécutent chacun un ou plusieurs programmes dans leur coin. Si utiliser plusieurs ordinateurs connectés par un réseau local est une solution simple et facile à implémenter, elle est cependant assez onéreuse et demande des logiciels adaptés qui permettent de profiter d'une telle architecture matérielle. D'autres solutions multiprocesseurs ont alors vu le jour pour rendre l'usage de plusieurs processeurs plus adéquat.

==Les systèmes multiprocesseur==

Les '''systèmes multiprocesseur''' placent plusieurs processeurs sur la même carte mère. Cette méthode marchait bien mais n'était pas des plus pratique, surtout que l'utilisation de plusieurs processeurs en même temps n'était de plus pas vraiment démocratisé à cette époque. Les logiciels et les systèmes d'exploitation grand public n'étaient pas adaptés pour, la demande pour des ordinateurs multiprocesseurs était limitée à quelques professionnels et ne justifiait pas un investissement majeure dans ces technologies.

Au niveau matériel, il fallait une carte mère adaptée, qui n'était pas facilement disponible et coûtait généralement plus cher que les cartes mères à un seul processeur. Sans compter qu'il valait mieux avoir une mémoire RAM rapide et des processeurs dotés de beaucoup de mémoire cache, ce qui coûtait encore plus cher. Au final, le gain était assez faible en terme de performance, peu de logiciels grand public profitaient de l'usage de plusieurs processeurs, la technologie est restée confidentielle.

===Le réseau d'interconnexion inter-processeur===

Un système multi-processeurs doit connecter entre eux plusieurs processeurs. Pour cela, les cartes mères multi-processeurs incorporent un réseau d'interconnexion pour connecter les processeurs entre eux, et les connecter avec la mémoire et les autres entrées-sorties. Il s'agit d'un '''réseau d'interconnexion inter-processeur''', placé sur la carte mère. Les processeurs sont tous connectés en utilisant deux solutions : soit avec un bus partagé, soit avec un réseau d'interconnexion très complexe.

Une solution simple relie les processeurs/cœurs entre eux grâce à un '''bus partagé'''. Nous parlerons en détail du bus partagé dans le chapitre sur la cohérence des caches, mais nous pouvons aborder le sujet maintenant, en précisant quel est ce bus partagé. Et suivant que l'on parle de systèmes multi-processeurs ou multicœurs, le bus qui est partagé n'est pas le même. Le cas le plus simple est celui d'une architecture multi-processeurs. Les processeurs sont alors tous reliés à la mémoire RAM à travers le bus mémoire. Le bus mémoire sert de point de ralliement, de point de convergence, il est le bus partagé. Les transferts entre caches se font alors en utilisant le bus mémoire.

[[File:Architecture multicoeurs à bus partagé.png|centre|vignette|upright=2|Architecture multiprocesseurs à bus partagé]]

De nos jours, les cartes mères pour serveur n'utilisent plus de bus partagé, mais utilisent un réseau d'interconnexion plus élaboré. Le réseau en question est un vrai réseau, qui peut être un réseau en anneau, un réseau crossbar, un réseau routé, etc. Le réseau d'interconnexion relie entre eux les cœurs, l'interface avec la mémoire RAM, le cache partagé L3/L4, mais aussi le bus PCI-Express, le GPU et quelques autres circuits séparés.

[[File:Architecture multicoeurs et réseau sur puce.png|centre|vignette|upright=1.5|Architecture multicoeurs et réseau sur puce]]

Les systèmes multi-processeurs modernes utilisent des réseaux d'interconnexion standardisés, les standards les plus communs étant l'HyperTransport, l'Intel QuickPath Interconnect, l'IBM Elastic Interface, le Intel Ultra Path Interconnect, l'Infinity Fabric, etc. Ils remplacent le fameux ''front-side bus'' des tout premiers processeurs multicœurs.

Un exemple de réseau d'interconnexion est celui des architectures AMD EPYC, de microarchitecture Zen 1. Elles utilisaient des chiplets, à savoir que le processeur était composé de plusieurs puces interconnectées entre elles. Chaque puce contenait un processeur multicoeurs intégrant un cache L3, avec un réseau d'interconnexion interne au processeur sans doute basé sur un ensemble de bus. De plus, les puces étaient reliées à une puce d'interconnexion qui servait à la fois d'interface entre les processeurs, mais aussi d'interface avec la R1AM, le bus PCI-Express, etc. La puce d'interconnexion était gravée en 14 nm contre 7nm pour les chiplets des cœurs. 

{|
|[[File:AMD Epyc 7702 delidded.jpg|centre|vignette|upright=2|AMD Epyc 7702.]]
|[[File:AMD Epyc Rome Aufbau.png|centre|vignette|upright=2|Schéma fonctionnel de l'AMD Epyc.]]
|}

===Les interruptions inter-processeurs===

Les différents processeurs sont gérés par le système d'exploitation de l'ordinateur, avec l'aide d''''interruptions inter-processeurs''', des interruptions déclenchées sur un processeur et exécutées sur un autre, éventuellement par tous les autres pour certaines interruptions spécifiques. Pour générer des interruptions inter-processeur, le contrôleur d'interruption doit pouvoir rediriger des interruptions déclenchées par un processeur vers un autre.

Un exemple d'implémentation très simple est celui de la console Néo-géo, qui contenait deux processeurs. Le premier est un Motorola 68000 qui sert de processeur principal, l'autre est un Z80 qui sert de processeur dédié à l'audio. Le Z80 commande un synthétiseur sonore, et est relié à sa propre mémoire, distincte de la mémoire principale. Le MC68000 est le processeur principal et a une relation maitre-esclave avec le Z80 : le MC68000 envoie des interruptions au Z80, mais la communication ne va pas dans l'autre sens.

Les deux processeurs communiquent via l'intermédiaire d'un '''''IO arbiter chip''''', un circuit sur la carte mère connecté ua bus, qui gère les interruptions inter-processeur. Il contient un registre de 8 bits, dans lequel le MC68000 peut écrire dedans à sa guise, le registre étant adressable par le processeur. Les valeurs écrites dans ce registre sont des numéros d'interruption, qui indiquent quelle routine d'interruption exécuter. Lorsque le MC68000 écrit une valeur dedans, cela déclenche l’exécution automatique d'une interruption sur le Z80. Le code de 8 bits est envoyé au processeur Z80, en parallèle de l'interruption.

: Il est possible de voir ce ''IO arbiter chip'' comme un contrôleur d'interruptions spécialisé dans les interruptions inter-processeur.

Les anciens PC incorporaient sur leur carte mère un contrôleur d'interruption créé par Intel, le 8259A, qui ne gérait pas les interruptions inter-processeurs. Les cartes mères multiprocesseurs devaient incorporer un contrôleur spécial en complément. De nos jours, chaque cœur x86 possède son propre contrôleur d’interruption, le local APIC, qui gère les interruptions en provenance ou arrivant vers ce processeur. On trouve aussi un IO-APIC, qui gère les interruptions en provenance des périphériques et de les redistribuer vers les APIC locaux. L'IO-APIC gère aussi les interruptions inter-processeurs en faisant passer les interruptions d'un local APIC vers un autre. Tous les APIC locaux et l'IO-APIC sont reliés ensembles par un bus APIC spécialisé, par lequel ils vont pouvoir communiquer et s'échanger des demandes d'interruptions.

[[File:Contrôleurs d'interrptions sur systèmes x86 multicoeurs.png|centre|vignette|upright=1.5|Contrôleurs d’interruptions sur systèmes x86 multicœurs.]]

On peut préciser le processeur de destination en configurant certains registres du IO-APIC, afin que celui-ci redirige la demande d'interruption d'un local APIC vers celui sélectionné. Cela se fait avec l'aide d'un registre de 64 bits nommé l'''Interrupt Command Register''. Pour simplifier le mécanisme complet, chaque processeur se voit attribuer un Id au démarrage qui permet de l'identifier (en fait, cet Id est attribué au local APIC de chaque processeur). Certains bits de ce registre permettent de préciser quel est le type de transfert : doit-on envoyer l'interruption au processeur émetteur, à tous les autres processeurs, à un processeur particulier. Dans le dernier cas, certains bits du registre permettent de préciser l'Id du processeur qui va devoir recevoir l'interruption. À charge de l'APIC de faire ce qu'il faut en fonction du contenu de ce registre.

==Les processeurs multicœurs==

Puis, avec les progrès en matière de miniaturisation des processeurs, les fabricants ont eu l'idée d'utiliser les transistors qu'ils avaient pour fabriquer des '''processeurs multicœurs''', un terme que vous avez peut-être déjà entendu sans vraiment comprendre ce qu'il signifiait réellement. Les processeurs multicœurs peuvent être vus comme un regroupement de plusieurs processeurs sur la même puce de silicium.

Pour être plus précis, ils contiennent plusieurs ''cœurs'', chaque cœur pouvant exécuter un programme tout seul. Chaque cœur dispose de toute la machinerie électronique pour exécuter un programme, que ce soit un séquenceur d'instruction, des registres, une unité de calcul. Par contre, certains circuits d'un processeur ne sont présents qu'en un seul exemplaire dans un processeur multicœurs, comme les circuits de communication avec la mémoire ou les circuits d’interfaçage avec la carte mère. Suivant le nombre de cœurs présents dans notre processeur, celui-ci sera appelé un processeur double-cœur (deux cœurs), quadruple-cœur (4 cœurs), octuple-cœur (8 cœurs), etc. Ces processeurs sont devenus la norme dans les ordinateurs grand public et les logiciels et systèmes d'exploitation se sont adaptés.

Dans ce qui suit, nous utiliserons le terme cœurs pour désigner soit les cœurs d'un processeur multicœurs, soit les différents processeurs d'un ordinateur multiprocesseur. Tout le contenu de ce chapitre vaut aussi bien pour les systèmes multicœurs que multiprocesseur. Les différences entre les deux sont mineures, les deux font face aux mêmes problèmes, les mêmes solutions peuvent s'appliquer sur les deux types de systèmes.

===Le multicœurs symétrique ou asymétrique===

Dans la grosse majorité des cas, les cœurs d'un processeur multicœurs sont tous identiques. Mais ce n'est certainement pas une obligation et on peut très bien mettre plusieurs cœurs assez différents sur la même puce. On peut par exemple utiliser un cœur principal avec des cœurs plus spécialisés autour. Il faut ainsi distinguer le '''multicœurs symétrique''', dans lequel on place des processeurs identiques sur la même puce de silicium, du '''multicœurs asymétrique''' où les cœurs ne sont pas identiques.

Un exemple est celui du processeur CELL de la console de jeu PS3. Il intègre un cœur principal POWER PC v5 et 8 coeurs qui servent de processeurs auxiliaires. Le processeur principal est appelé le PPE et les processeurs auxiliaires sont les SPE. Les SPE sont reliés à une mémoire locale (''local store'') de 256 kibioctets qui communique avec le processeur principal via un bus spécial. Les SPE communiquent avec la RAM principale via des contrôleurs DMA. Les SPE possèdent des instructions permettant de commander leur contrôleur DMA et c'est le seul moyen qu'ils ont pour récupérer des informations depuis la mémoire. Et c'est au programmeur de gérer tout ça ! C'est le processeur principal qui va envoyer aux SPE les programmes qu'ils doivent exécuter. Il délègue des calculs aux SPE en écrivant dans le local store du SPE et en lui ordonnant l’exécution du programme qu'il vient d'écrire.

[[File:Schema Cell.png|centre|vignette|upright=2|Architecture du processeur CELL de la PS3. Le PPE est le processeur principal, les SPE sont des processeurs auxiliaires qui comprennent : un ''local store'' noté LS, un processeur noté SXU, et un contrôleur DMA pour échanger des informations avec la mémoire principale.]]

===Les architectures à cœurs conjoints===

Sur certains processeurs multicœurs, certains circuits sont partagés entre plusieurs cœurs. Typiquement, l'unité de calcul flottante est partagée entre deux coeurs/''threads'', les unités SIMD qu'on verra dans quelques chapitres sont aussi dans ce cas. Le partage de circuits permet d'éviter de dupliquer trop de circuits et donc d'économiser des transistors. Le problème est que ce partage est source de dépendances structurelles, ce qui peut entraîner des pertes de performances.

Cette technique consistant de partage d'unités de calcul entre coeurs s'appelle le '''cluster multithreading''', ou encore les '''architectures à cœurs conjoints''' (''Conjoined Core Architectures''). Elle est notamment utilisée sur les processeurs AMD de microarchitecture Bulldozer, incluant ses trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Un exemple est celui des processeurs AMD FX-8150 et FX-8120.

Sur ces processeurs, les instructions sont chargées dans deux files d'instructions séparées, une par ''thread'' matériel. Les instructions sont ensuite décodées par un décodeur unique et renommées dans une unité de renommage unique. Par la suite, il y a deux voies entières séparées et une voie flottante partagée. Chaque voie entière a sa propre fenêtre d'instruction entière, ses unités de calcul dédiées, ses registres, sa ''load-store queue'', son cache L1. Par contre, la voie flottante partage les unités de calcul flottantes et n'a qu'une seule fenêtre d'instruction partagée par les deux ''threads''.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]]

===Les architectures ''many core''===

Les architectures ''many core'' ont un très grand nombre de cœurs, plus d'une cinquantaine, voire plusieurs centaines ou milliers. La différence est surtout une question de degré, mais aussi de but recherché.

Les architectures multicœurs sont surtout conçues pour les ordinateurs personnels, éventuellement les serveurs. Elles recherchent un bon compromis entre un grand nombre de cœurs, et une bonne performance pour les programmes non-parallèles. En clair, elles évitent de sacrifier les performances pour les applications non-parallèles, ce qui fait que leurs cœurs sont généralement très puissants, avec beaucoup d'optimisations micro-architecturales.

Les architectures ''many core'' font le compromis inverse : elles ont beaucoup de cœurs, mais ceux-ci ne sont pas très puissants, surtout pour les applications non-parallèles. Les cœurs des architectures ''many core'' sont généralement des cœurs sans exécution dans le désordre, sans prédiction de branchements, sans renommage de registres, voire sans pipeline ni parallélisme d'instruction.

==Le partage des caches==

Quand on conçoit un processeur multicœur, il ne faut pas oublier ce qui arrive à la pièce maîtresse de tout processeur actuel : le cache ! Pour le moment nous allons oublier le fait que les processeurs ont une hiérarchie de caches, avec des caches L1, L2, L3 et autres. Nous allons partir du principe qu'un processeur simple cœur a un seul cache, et voir comment adapter le cache à la présence de plusieurs cœurs. Nous allons rapidement lever cette hypothèse, pour étudier le cas où un processeur multicœur a une hiérarchie de caches, mais seulement après avoir vu le cas le plus simple à un seul cache.

===Le partage des caches sans hiérarchie de caches : caches dédiés et partagés===

Avec un seul niveau de cache, sans hiérarchie, deux solutions sont possibles. La première consiste à garder un seul cache, et de le partager entre les cœurs. L'autre solution est de dupliquer le cache et d'utiliser un cache par cœur. Les deux solutions sont appelées différemment. On parle de '''caches dédiés''' si chaque cœur possède son propre cache, et de '''cache partagé''' avec un cache partagé entre tous les cœurs. Ces deux méthodes ont des inconvénients et des avantages.

{|
|[[File:Caches dédiés.png|vignette|Caches dédiés]]
|[[File:Caches partagés.png|vignette|Cache partagé]]
|}

Le premier point sur lequel comparer caches dédiés et partagés est celui de la capacité du cache. La quantité de mémoire cache que l'on peut placer dans un processeur est limitée, car le cache prend beaucoup de place, près de la moitié des circuits du processeur. Aussi, un processeur incorpore une certaine quantité de mémoire cache, qu'il faut répartir entre un ou plusieurs caches. Les caches dédiés et partagés ne donnent pas le même résultat. D'un côté, le cache partagé fait que toute la mémoire cache est dédiée au cache partagé, qui est très gros. De l'autre, on doit répartir la capacité du cache entre plusieurs caches séparés, individuellement plus petits. En conséquence, on a le choix entre un petit cache pour chaque processeur ou un gros cache partagé.

Le choix entre les deux n'est pas simple, mais doit tenir compte du fait que les programmes exécutés sur les cœurs n'ont pas les mêmes besoins. Certains programmes sont plus gourmands et demandent beaucoup de cache, alors que d'autres utilisent peu la mémoire cache. Avec un cache dédié, tous les programmes ont accès à la même quantité de cache, car les caches des différents cœurs sont de la même taille. Les caches dédiés étant assez petits, les programmes plus gourmands devront se débrouiller avec un petit cache, alors que les autres programmes auront du cache en trop. A l'opposé, un cache partagé répartit le cache de manière optimale : un programme gourmand peut utiliser autant de cache qu'il veut, laissant juste ce qu'il faut aux programmes moins gourmands. le cache peut être répartit plus facilement selon les besoins des différents programmes.

[[File:Cache partagé contre cache dédié.png|centre|vignette|upright=2.5|Cache partagé contre cache dédié]]

Un autre avantage des caches partagés est quand plusieurs cœurs accèdent aux même données. C'est un cas très courant, souvent lié à l'usage de mémoire partagé ou de ''threads''. Avec des caches dédiés, chaque cœur a une copie des données partagées. Mais avec un cache partagé, il n'y a qu'une seule copie de chaque donnée, ce qui utilise moins de mémoire cache. Imaginons que l'on sait 8 caches dédiés de 8 Kibioctets, soit 64 kibioctets au total, comparé à un cache partagé de même capacité totale. Les doublons dans les caches dédiés réduiront la capacité mémoire utile, effective, comparé à un cache partagé. S'il y a 1 Kibioctet de mémoire partagé, 8 kibioctets seront utilisés pour stocker ces données en doublons, seulement 1 kibioctet sur un cache partagé. Ajoutons aussi que la cohérence des caches est grandement simplifiée avec l'usage d'un cache partagé, vu que les données ne sont pas dupliquées dans plusieurs caches.

Mais le partage du cache peut se transformer en inconvénient si les programmes entrent en compétition pour le cache, que ce soit pour y placer des données ou pour les accès mémoire. Deux programmes peuvent vouloir accéder au cache en même temps, voire carrément se marcher sur les pieds. La résolution des conflits d'accès au cache est résolu soit en prenant un cache multiport, avec un port dédié par cœur, soit par des mécanismes d'arbitrages avec des circuits dédiés. Le revers de la médaille tient au temps de latence. Plus un cache est gros, plus il est lent. En conséquence, des caches dédiés seront plus rapides qu'un  gros cache partagé plus lent.

===Le partage des caches adapté à une hiérarchie de caches===

Dans la réalité, un processeur multicœur ne contient pas qu'un seul cache, mais une hiérarchie de caches avec des caches L1, L2 et L3, parfois L4. Dans cette hiérarchie, certains caches sont partagés entre plusieurs cœurs, les autres sont dédiés. Le cache L1 n'est jamais partagé, car il doit avoir un temps d'accès très faible. Pour les autres caches, tout dépend du processeur.

[[File:Dual Core Generic.svg|vignette|Cache L2 partagé.]]

Les premiers processeurs multicœurs commerciaux utilisaient deux niveaux de cache : des caches L1 dédiés et un cache L2 partagé. Le cache L2 partagé était relié aux caches L1, grâce à un système assez complexe d'interconnexions. Le cache de niveau L2 était souvent simple port, car les caches L1 se chargent de filtrer les accès aux caches de niveau inférieurs.

Les processeurs multicœurs modernes ont des caches L3 et même L4, de grande capacité, ce qui a modifié le partage des caches. Le cache le plus proche de la mémoire, le cache de dernier niveau L3 ou L4, est systématiquement partagé, car son rôle est d'être un cache lent mais gros. Le cas du cache L2 dépend des architectures : il est partagé sur certains processeurs, dédié sur d'autres.

Dans le cas le plus courant, il y a plusieurs caches L2 qui sont chacun partagés entre plusieurs cœurs mais pas à tous. En effet, on peut limiter le partage du cache à quelques cœurs particuliers pour des raisons de performances.

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2.0|Partage des caches sur un processeur multicœur.]]

D'autres processeurs ont des caches L2 dédiés. Il s'agit surtout des processeurs multicœurs anciens, parmi les premières générations de processeurs multicœurs. Un exemple est celui de la microarchitecture Nehalem d'Intel. Il avait des caches L1 et L2 dédiés, mais un cache L3 partagé.

[[File:Nehalem EP.png|centre|vignette|upright=2.0|Partage des caches sur un processeur Intel d'architecture Nehalem.]]

===Les caches partagés centralisés et distribués===

Un point important est que quand on parle de cache partagé ou de cache dédié, on ne parle que de la manière dont les cœurs peuvent accéder au cache, pas de la manière dont le caches est réellement localisé sur la puce. En théorie, qui dit plusieurs caches dédiés signifie que l'on a vraiment plusieurs caches séparés sur la puce. Et chaque cache dédié est proche du cœur qui lui est attribué. Et pour les caches partagés unique, une portion de la puce de silicium contient le cache, que cette portion est un énorme bloc de transistors. Il est généralement placé au milieu de la puce ou sur un côté, histoire de facilement le connecter à tous les cœurs.

Mais pour les caches séparés, ce n'est pas toujours le cas. Avoir un cache énorme poserait des problèmes sur les architectures avec beaucoup de cœurs. En réalité, le cache est souvent découpé en plusieurs banques, reliées à un contrôleur du cache par un système d'interconnexion assez complexe. Les banques sont physiquement séparées, et il arrive qu'elles soient placées proche d'un cœur chacune. L'organisation des banques ressemble beaucoup à l'organisation des caches dédiés, avec une banque étant l'équivalent d'un cache dédié. La différence est que les cœurs peuvent lire et écrire dans toutes les banques, grâce au système d'interconnexion et au contrôleur de cache.

Tel était le cas sur les processeurs AMD Jaguar. Ils avaient un cache L2 de 2 mébioctets, partagés entre tous les cœurs, qui était composé de 4 banques de 512 Kibioctets. Les quatre banques du cache étaient reliées aux 4 cœurs par un réseaux d'interconnexion assez complexe.

[[File:AMDJaguarModule.png|centre|vignette|upright=2|AMD Jaguar Module]]

La différence entre les deux solutions pour les caches partagés porte le nom de cache centralisés versus distribués. Un gros cache unique sur la puce est un '''cache centralisé''', et c'est généralement un cache partagé. Mais un cache composé de plusieurs banques dispersées sur la puce est un '''cache distribué''', qui peut être aussi bien dédié que partagé.

===Les caches virtualisés===

Il faut noter que quelques processeurs utilisent cette technique pour fusionnent le cache L2 et le cache L3. Par exemple, les processeurs IBM Telum utilisent des caches L3 virtualisés, dans leurs versions récentes. Le processeur Telum 2 contient 10 caches L2 de 36 mébioctets chacun, soit 360 mébioctets de cache. L'idée est que ces 360 mébioctets sont partagés à la demande entre cache L2 dédié et cache L3. On parle alors de '''cache virtualisé'''.

Un cache de 36 mébioctet est associé à un cœur, auquel il est directement relié. Les cœurs n'utilisent pas tous leur cache dédié à 100% Il arrive que des cœurs aient des caches partiellement vides, alors que d'autres on un cache qui déborde. L'idée est que si un cœur a un cache plein, les données évincées du cache L2 privé sont déplacées dans le cache L2 d'un autre cœur, qui lui est partiellement vide. Le cache L2 en question est alors partitionné en deux : une portion pour les données associée à son cœur, une portion pour les données des L2 des autres cœurs. 

Pour que la technique fonctionne, le processeur mesure le remplissage de chaque cache L2. De plus, il faut gérer la politique de remplacement des lignes de cache. Une ligne de cache évincée du cache doit être déplacé dans un autre L2, pas dans les niveaux de cache inférieur, ni dans la mémoire. Du moins, tant qu'il reste de la place dans le cache L3. De plus, une lecture/écriture dans le cache L3 demande de localiser le cache L2 contenant la donnée. Pour cela, les caches L2 sont tous consultés lors d'un accès au L3, c'est la solution la plus simple, elle marche très bien si le taux de défaut du cache L2 est faible.

Une telle optimisation ressemble beaucoup à un cache L2/L3 distribué, mais il y a quelques différences qui sont décrites dans le paragraphe précédent. Avec un L2 distribué, tout accès au L2 déclencherait une consultation de toutes les banques du L2. Avec un cache L3 virtualisé, ce n'est pas le cas. Le cache L2 associé au cœur est consulté, et c'est seulement en cas de défaut de cache que les autres caches L2 sont consultés. De plus, avec un cache L2 distribué, il n'y a pas de déplacement d'une ligne de cache entre deux banques, entre deux caches L2 physiques. Alors qu'avec un cache L3 virtualisé, c'est le cas en cas de remplacement d'une ligne de cache dans le cache L2.

Sur le processeur Telum 1, le partage du cache L2 est assez simple. Un cache L2 fait 32 mébioctets et est découpé en deux banques de 16 mébioctets. En temps normal, les premiers 16 mébioctets sont toujours associé au cache L2, au cœur associé. Les 16 mébioctets restants peuvent soit être attribués au cache L3, soit fusionnés avec les 16 premiers mébioctets. Dans le cas où le cœur associé est en veille, n'est absolument pas utilisé, les 32 mébioctets sont attribués au cache L3. Un partage assez simple, donc. Le partage du cache L2/L3 sur les processeurs Telum 2 n'est pas connu, il est supposé être plus flexible.

==Le réseau d'interconnexion entre cœurs==

Les CPU multicœurs connectent plusieurs cœurs entre eux, tout comme les systèmes multi-processeurs connectent plusieurs processeurs entre eux. Mais les transferts de données entre cœurs se font par l'intermédiaire des caches, ce qui fait que l'implémentation est différente de celle utilisée sur les systèmes multi-processeurs. Les standards pour les interconnexions entre coeurs sont assez proches de ceux utilisés pour interconnecter des processeurs, mais les standards utilisés ne sont pas les mêmes en pratique. Là encore, les cœurs sont connectés entre eux soit par un bus, soit par un réseau d'interconnexion.

===Le bus partagé entre plusieurs cœurs===

Une solution simple relie les cœurs entre eux grâce à un '''bus partagé'''. Le cas le plus simple est celui où chaque cœur dispose de caches dédiés, qui sont alors tous reliés au bus mémoire, qui sert d'intermédiaire. Mais l'idée doit être adaptée sur les processeurs multicœurs avec des caches partagés. Voyons d'abord le cas d'un CPU avec deux niveaux de cache, dont un cache L2 est partagé entre tous les cœurs. Les caches L1 sont reliés au cache L2 partagé par un bus, qui n'a souvent pas de nom. Nous désignerons le bus entre le cache L1 et le cache L2 : '''bus partagé''', sous-entendu partagé entre tous les caches. C'est lui qui sert à connecter les cœurs entre eux.

[[File:Architecture multicoeurs à bus partagé entre caches L1 et L2.png|centre|vignette|upright=2|Architecture multicoeurs à bus partagé entre caches L1 et L2]]

Un processeur multicœur typique a une architecture avec trois niveaux de cache (L1, L2 et L3), avec un niveau L1 dédié par cœur, un niveau L2 partiellement partagé et un L3 totalement partagé. Le bus partagé est alors difficile à décrire, mais il correspond à l'ensemble des bus qui connectent les caches L1 aux caches L2, et les caches L2 au cache L3. Il s'agit alors d'un ensemble de bus, plus que d'un bus partagé unique.

===Le réseau d'interconnexion entre plusieurs cœurs===

Relier plusieurs cœurs avec des bus pose de nombreux problèmes techniques qui sont d'autant plus problématiques que le nombre de cœurs augmente. Le câblage est notamment très complexe, les contraintes électriques pour la transmission des signaux sont beaucoup plus fortes, les problèmes d'arbitrages se font plus fréquents, etc. Pour régler ces problèmes, les processeurs multicoeurs n'utilisent pas de bus partagé, mais un réseau d'interconnexion plus complexe.

Le réseau d'interconnexion peut être très complexe, avec des connexions réseau, des commutateurs, et des protocoles d'échanges entre processeurs assez complexes basés sur du passage de messages. De telles puces utilisent un '''réseau sur puce''' (''network on chip''). Mais d'autres simplifient le réseau d'interconnexion, qui se résume à un réseau ''crossbar'', voire à des mémoires FIFO pour faire l'interface entre les cœurs.

Le problème principal des réseaux sur puce est que les mémoires FIFOs sont difficiles à implémenter sur une puce de silicium. Elles prennent beaucoup de place, utilisent beaucoup de portes logiques, consomment beaucoup d'énergie, sont difficiles à concevoir pour diverses raisons (les accès concurrents/simultanés sont fréquents et font mauvais ménage avec les ''timings'' serrés de quelques cycles d'horloges requis). Il est donc impossible de placer beaucoup de mémoires FIFO dans un processeur, ce qui fait que les commutateur sont réduits à leur strict minimum : un réseau d'interconnexion, un système d'arbitrage simple parfois sans aucune FIFO, guère plus.

===Les architectures en ''tile''===

Un cas particulier de réseau sur puce est celui des '''architectures en ''tile''''', des architectures avec un grand nombre de cœurs, connectés les unes aux autres par un réseau d'interconnexion &quot;rectangulaire&quot;. Chaque cœur est associé à un commutateur (''switch'') qui le connecte au réseau d'interconnexion, l'ensemble formant une ''tile''.

[[File:Tile64-Tile.svg|centre|vignette|upright=1.5|''Tile'' de base du Tile64.]]

Le réseau est souvent organisé en tableau, chaque ''tile'' étant connectée à plusieurs voisines. Dans le cas le plus fréquent, chaque ''tile'' est connectée à quatre voisines : celle du dessus, celle du dessous, celle de gauche et celle de droite. Précisons que cette architecture n'est pas une architecture distribuée dont tous les processeurs seraient placés sur la même puce de silicium. En effet, la comparaison ne marche pas pour ce qui est de la mémoire : tous les cœurs accèdent à une mémoire partagée située en dehors de la puce de silicium. Le réseau ne connecte pas plusieurs ordinateurs séparés avec chacun leur propre mémoire, mais plusieurs cœurs qui accèdent à une mémoire partagée.

Un bon exemple d'architecture en ''tile'' serait les déclinaisons de l'architecture Tilera. Les schémas du-dessous montrent l'architecture du processeur Tile 64. Outre les ''tiles'', qui sont les éléments de calcul de l'architecture, on trouve plusieurs contrôleurs mémoire DDR, divers interfaces réseau, des interfaces série et parallèles, et d'autres entrées-sorties.

[[File:Tile64.svg|centre|vignette|upright=2|Architecture Tile64 du Tilera.]]

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Les architectures parallèles
           | prevText=Les architectures parallèles
           | next=Architectures multithreadées et Hyperthreading
           | nextText=Architectures multithreadées et Hyperthreading
}}
&lt;/noinclude&gt;</text>
      <sha1>ej7aoj00vj4fmpbdkoxjjiacqymy6v9</sha1>
    </revision>
    <revision>
      <id>745450</id>
      <parentid>745449</parentid>
      <timestamp>2025-06-27T00:05:20Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les architectures à cœurs conjoints */</comment>
      <origin>745450</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="32840" sha1="h39snnrinvr38djxokbijnkyu4eprse" xml:space="preserve">Pour réellement tirer parti du parallélisme de taches, rien ne vaut l'utilisation de plusieurs processeurs et/ou de plusieurs ordinateurs, qui exécutent chacun un ou plusieurs programmes dans leur coin. Si utiliser plusieurs ordinateurs connectés par un réseau local est une solution simple et facile à implémenter, elle est cependant assez onéreuse et demande des logiciels adaptés qui permettent de profiter d'une telle architecture matérielle. D'autres solutions multiprocesseurs ont alors vu le jour pour rendre l'usage de plusieurs processeurs plus adéquat.

==Les systèmes multiprocesseur==

Les '''systèmes multiprocesseur''' placent plusieurs processeurs sur la même carte mère. Cette méthode marchait bien mais n'était pas des plus pratique, surtout que l'utilisation de plusieurs processeurs en même temps n'était de plus pas vraiment démocratisé à cette époque. Les logiciels et les systèmes d'exploitation grand public n'étaient pas adaptés pour, la demande pour des ordinateurs multiprocesseurs était limitée à quelques professionnels et ne justifiait pas un investissement majeure dans ces technologies.

Au niveau matériel, il fallait une carte mère adaptée, qui n'était pas facilement disponible et coûtait généralement plus cher que les cartes mères à un seul processeur. Sans compter qu'il valait mieux avoir une mémoire RAM rapide et des processeurs dotés de beaucoup de mémoire cache, ce qui coûtait encore plus cher. Au final, le gain était assez faible en terme de performance, peu de logiciels grand public profitaient de l'usage de plusieurs processeurs, la technologie est restée confidentielle.

===Le réseau d'interconnexion inter-processeur===

Un système multi-processeurs doit connecter entre eux plusieurs processeurs. Pour cela, les cartes mères multi-processeurs incorporent un réseau d'interconnexion pour connecter les processeurs entre eux, et les connecter avec la mémoire et les autres entrées-sorties. Il s'agit d'un '''réseau d'interconnexion inter-processeur''', placé sur la carte mère. Les processeurs sont tous connectés en utilisant deux solutions : soit avec un bus partagé, soit avec un réseau d'interconnexion très complexe.

Une solution simple relie les processeurs/cœurs entre eux grâce à un '''bus partagé'''. Nous parlerons en détail du bus partagé dans le chapitre sur la cohérence des caches, mais nous pouvons aborder le sujet maintenant, en précisant quel est ce bus partagé. Et suivant que l'on parle de systèmes multi-processeurs ou multicœurs, le bus qui est partagé n'est pas le même. Le cas le plus simple est celui d'une architecture multi-processeurs. Les processeurs sont alors tous reliés à la mémoire RAM à travers le bus mémoire. Le bus mémoire sert de point de ralliement, de point de convergence, il est le bus partagé. Les transferts entre caches se font alors en utilisant le bus mémoire.

[[File:Architecture multicoeurs à bus partagé.png|centre|vignette|upright=2|Architecture multiprocesseurs à bus partagé]]

De nos jours, les cartes mères pour serveur n'utilisent plus de bus partagé, mais utilisent un réseau d'interconnexion plus élaboré. Le réseau en question est un vrai réseau, qui peut être un réseau en anneau, un réseau crossbar, un réseau routé, etc. Le réseau d'interconnexion relie entre eux les cœurs, l'interface avec la mémoire RAM, le cache partagé L3/L4, mais aussi le bus PCI-Express, le GPU et quelques autres circuits séparés.

[[File:Architecture multicoeurs et réseau sur puce.png|centre|vignette|upright=1.5|Architecture multicoeurs et réseau sur puce]]

Les systèmes multi-processeurs modernes utilisent des réseaux d'interconnexion standardisés, les standards les plus communs étant l'HyperTransport, l'Intel QuickPath Interconnect, l'IBM Elastic Interface, le Intel Ultra Path Interconnect, l'Infinity Fabric, etc. Ils remplacent le fameux ''front-side bus'' des tout premiers processeurs multicœurs.

Un exemple de réseau d'interconnexion est celui des architectures AMD EPYC, de microarchitecture Zen 1. Elles utilisaient des chiplets, à savoir que le processeur était composé de plusieurs puces interconnectées entre elles. Chaque puce contenait un processeur multicoeurs intégrant un cache L3, avec un réseau d'interconnexion interne au processeur sans doute basé sur un ensemble de bus. De plus, les puces étaient reliées à une puce d'interconnexion qui servait à la fois d'interface entre les processeurs, mais aussi d'interface avec la R1AM, le bus PCI-Express, etc. La puce d'interconnexion était gravée en 14 nm contre 7nm pour les chiplets des cœurs. 

{|
|[[File:AMD Epyc 7702 delidded.jpg|centre|vignette|upright=2|AMD Epyc 7702.]]
|[[File:AMD Epyc Rome Aufbau.png|centre|vignette|upright=2|Schéma fonctionnel de l'AMD Epyc.]]
|}

===Les interruptions inter-processeurs===

Les différents processeurs sont gérés par le système d'exploitation de l'ordinateur, avec l'aide d''''interruptions inter-processeurs''', des interruptions déclenchées sur un processeur et exécutées sur un autre, éventuellement par tous les autres pour certaines interruptions spécifiques. Pour générer des interruptions inter-processeur, le contrôleur d'interruption doit pouvoir rediriger des interruptions déclenchées par un processeur vers un autre.

Un exemple d'implémentation très simple est celui de la console Néo-géo, qui contenait deux processeurs. Le premier est un Motorola 68000 qui sert de processeur principal, l'autre est un Z80 qui sert de processeur dédié à l'audio. Le Z80 commande un synthétiseur sonore, et est relié à sa propre mémoire, distincte de la mémoire principale. Le MC68000 est le processeur principal et a une relation maitre-esclave avec le Z80 : le MC68000 envoie des interruptions au Z80, mais la communication ne va pas dans l'autre sens.

Les deux processeurs communiquent via l'intermédiaire d'un '''''IO arbiter chip''''', un circuit sur la carte mère connecté ua bus, qui gère les interruptions inter-processeur. Il contient un registre de 8 bits, dans lequel le MC68000 peut écrire dedans à sa guise, le registre étant adressable par le processeur. Les valeurs écrites dans ce registre sont des numéros d'interruption, qui indiquent quelle routine d'interruption exécuter. Lorsque le MC68000 écrit une valeur dedans, cela déclenche l’exécution automatique d'une interruption sur le Z80. Le code de 8 bits est envoyé au processeur Z80, en parallèle de l'interruption.

: Il est possible de voir ce ''IO arbiter chip'' comme un contrôleur d'interruptions spécialisé dans les interruptions inter-processeur.

Les anciens PC incorporaient sur leur carte mère un contrôleur d'interruption créé par Intel, le 8259A, qui ne gérait pas les interruptions inter-processeurs. Les cartes mères multiprocesseurs devaient incorporer un contrôleur spécial en complément. De nos jours, chaque cœur x86 possède son propre contrôleur d’interruption, le local APIC, qui gère les interruptions en provenance ou arrivant vers ce processeur. On trouve aussi un IO-APIC, qui gère les interruptions en provenance des périphériques et de les redistribuer vers les APIC locaux. L'IO-APIC gère aussi les interruptions inter-processeurs en faisant passer les interruptions d'un local APIC vers un autre. Tous les APIC locaux et l'IO-APIC sont reliés ensembles par un bus APIC spécialisé, par lequel ils vont pouvoir communiquer et s'échanger des demandes d'interruptions.

[[File:Contrôleurs d'interrptions sur systèmes x86 multicoeurs.png|centre|vignette|upright=1.5|Contrôleurs d’interruptions sur systèmes x86 multicœurs.]]

On peut préciser le processeur de destination en configurant certains registres du IO-APIC, afin que celui-ci redirige la demande d'interruption d'un local APIC vers celui sélectionné. Cela se fait avec l'aide d'un registre de 64 bits nommé l'''Interrupt Command Register''. Pour simplifier le mécanisme complet, chaque processeur se voit attribuer un Id au démarrage qui permet de l'identifier (en fait, cet Id est attribué au local APIC de chaque processeur). Certains bits de ce registre permettent de préciser quel est le type de transfert : doit-on envoyer l'interruption au processeur émetteur, à tous les autres processeurs, à un processeur particulier. Dans le dernier cas, certains bits du registre permettent de préciser l'Id du processeur qui va devoir recevoir l'interruption. À charge de l'APIC de faire ce qu'il faut en fonction du contenu de ce registre.

==Les processeurs multicœurs==

Puis, avec les progrès en matière de miniaturisation des processeurs, les fabricants ont eu l'idée d'utiliser les transistors qu'ils avaient pour fabriquer des '''processeurs multicœurs''', un terme que vous avez peut-être déjà entendu sans vraiment comprendre ce qu'il signifiait réellement. Les processeurs multicœurs peuvent être vus comme un regroupement de plusieurs processeurs sur la même puce de silicium.

Pour être plus précis, ils contiennent plusieurs ''cœurs'', chaque cœur pouvant exécuter un programme tout seul. Chaque cœur dispose de toute la machinerie électronique pour exécuter un programme, que ce soit un séquenceur d'instruction, des registres, une unité de calcul. Par contre, certains circuits d'un processeur ne sont présents qu'en un seul exemplaire dans un processeur multicœurs, comme les circuits de communication avec la mémoire ou les circuits d’interfaçage avec la carte mère. Suivant le nombre de cœurs présents dans notre processeur, celui-ci sera appelé un processeur double-cœur (deux cœurs), quadruple-cœur (4 cœurs), octuple-cœur (8 cœurs), etc. Ces processeurs sont devenus la norme dans les ordinateurs grand public et les logiciels et systèmes d'exploitation se sont adaptés.

Dans ce qui suit, nous utiliserons le terme cœurs pour désigner soit les cœurs d'un processeur multicœurs, soit les différents processeurs d'un ordinateur multiprocesseur. Tout le contenu de ce chapitre vaut aussi bien pour les systèmes multicœurs que multiprocesseur. Les différences entre les deux sont mineures, les deux font face aux mêmes problèmes, les mêmes solutions peuvent s'appliquer sur les deux types de systèmes.

===Le multicœurs symétrique ou asymétrique===

Dans la grosse majorité des cas, les cœurs d'un processeur multicœurs sont tous identiques. Mais ce n'est certainement pas une obligation et on peut très bien mettre plusieurs cœurs assez différents sur la même puce. On peut par exemple utiliser un cœur principal avec des cœurs plus spécialisés autour. Il faut ainsi distinguer le '''multicœurs symétrique''', dans lequel on place des processeurs identiques sur la même puce de silicium, du '''multicœurs asymétrique''' où les cœurs ne sont pas identiques.

Un exemple est celui du processeur CELL de la console de jeu PS3. Il intègre un cœur principal POWER PC v5 et 8 coeurs qui servent de processeurs auxiliaires. Le processeur principal est appelé le PPE et les processeurs auxiliaires sont les SPE. Les SPE sont reliés à une mémoire locale (''local store'') de 256 kibioctets qui communique avec le processeur principal via un bus spécial. Les SPE communiquent avec la RAM principale via des contrôleurs DMA. Les SPE possèdent des instructions permettant de commander leur contrôleur DMA et c'est le seul moyen qu'ils ont pour récupérer des informations depuis la mémoire. Et c'est au programmeur de gérer tout ça ! C'est le processeur principal qui va envoyer aux SPE les programmes qu'ils doivent exécuter. Il délègue des calculs aux SPE en écrivant dans le local store du SPE et en lui ordonnant l’exécution du programme qu'il vient d'écrire.

[[File:Schema Cell.png|centre|vignette|upright=2|Architecture du processeur CELL de la PS3. Le PPE est le processeur principal, les SPE sont des processeurs auxiliaires qui comprennent : un ''local store'' noté LS, un processeur noté SXU, et un contrôleur DMA pour échanger des informations avec la mémoire principale.]]

===Les architectures à cœurs conjoints===

Sur certains processeurs multicœurs, certains circuits sont partagés entre plusieurs cœurs. Typiquement, l'unité de calcul flottante est partagée entre deux coeurs/''threads'', les unités SIMD qu'on verra dans quelques chapitres sont aussi dans ce cas. Le partage de circuits permet d'éviter de dupliquer trop de circuits et donc d'économiser des transistors. Le problème est que ce partage est source de dépendances structurelles, ce qui peut entraîner des pertes de performances.

Cette technique consistant de partage d'unités de calcul entre coeurs s'appelle le '''cluster multithreading''', ou encore les '''architectures à cœurs conjoints''' (''Conjoined Core Architectures''). Elle est notamment utilisée sur les processeurs AMD de microarchitecture Bulldozer, incluant ses trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Un exemple est celui des processeurs AMD FX-8150 et FX-8120.

Sur ces processeurs, les instructions sont chargées dans deux files d'instructions séparées, une par ''thread'' matériel. Les instructions sont ensuite décodées par un décodeur unique et renommées dans une unité de renommage unique. Par la suite, il y a deux voies entières séparées et une voie flottante partagée. Chaque voie entière a sa propre fenêtre d'instruction entière, son tampon de ré-ordonnancement, ses unités de calcul dédiées, ses registres, sa ''load-store queue'', son cache L1. Par contre, la voie flottante partage les unités de calcul flottantes et n'a qu'une seule fenêtre d'instruction partagée par les deux ''threads''.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer  d'AMD.]]

===Les architectures ''many core''===

Les architectures ''many core'' ont un très grand nombre de cœurs, plus d'une cinquantaine, voire plusieurs centaines ou milliers. La différence est surtout une question de degré, mais aussi de but recherché.

Les architectures multicœurs sont surtout conçues pour les ordinateurs personnels, éventuellement les serveurs. Elles recherchent un bon compromis entre un grand nombre de cœurs, et une bonne performance pour les programmes non-parallèles. En clair, elles évitent de sacrifier les performances pour les applications non-parallèles, ce qui fait que leurs cœurs sont généralement très puissants, avec beaucoup d'optimisations micro-architecturales.

Les architectures ''many core'' font le compromis inverse : elles ont beaucoup de cœurs, mais ceux-ci ne sont pas très puissants, surtout pour les applications non-parallèles. Les cœurs des architectures ''many core'' sont généralement des cœurs sans exécution dans le désordre, sans prédiction de branchements, sans renommage de registres, voire sans pipeline ni parallélisme d'instruction.

==Le partage des caches==

Quand on conçoit un processeur multicœur, il ne faut pas oublier ce qui arrive à la pièce maîtresse de tout processeur actuel : le cache ! Pour le moment nous allons oublier le fait que les processeurs ont une hiérarchie de caches, avec des caches L1, L2, L3 et autres. Nous allons partir du principe qu'un processeur simple cœur a un seul cache, et voir comment adapter le cache à la présence de plusieurs cœurs. Nous allons rapidement lever cette hypothèse, pour étudier le cas où un processeur multicœur a une hiérarchie de caches, mais seulement après avoir vu le cas le plus simple à un seul cache.

===Le partage des caches sans hiérarchie de caches : caches dédiés et partagés===

Avec un seul niveau de cache, sans hiérarchie, deux solutions sont possibles. La première consiste à garder un seul cache, et de le partager entre les cœurs. L'autre solution est de dupliquer le cache et d'utiliser un cache par cœur. Les deux solutions sont appelées différemment. On parle de '''caches dédiés''' si chaque cœur possède son propre cache, et de '''cache partagé''' avec un cache partagé entre tous les cœurs. Ces deux méthodes ont des inconvénients et des avantages.

{|
|[[File:Caches dédiés.png|vignette|Caches dédiés]]
|[[File:Caches partagés.png|vignette|Cache partagé]]
|}

Le premier point sur lequel comparer caches dédiés et partagés est celui de la capacité du cache. La quantité de mémoire cache que l'on peut placer dans un processeur est limitée, car le cache prend beaucoup de place, près de la moitié des circuits du processeur. Aussi, un processeur incorpore une certaine quantité de mémoire cache, qu'il faut répartir entre un ou plusieurs caches. Les caches dédiés et partagés ne donnent pas le même résultat. D'un côté, le cache partagé fait que toute la mémoire cache est dédiée au cache partagé, qui est très gros. De l'autre, on doit répartir la capacité du cache entre plusieurs caches séparés, individuellement plus petits. En conséquence, on a le choix entre un petit cache pour chaque processeur ou un gros cache partagé.

Le choix entre les deux n'est pas simple, mais doit tenir compte du fait que les programmes exécutés sur les cœurs n'ont pas les mêmes besoins. Certains programmes sont plus gourmands et demandent beaucoup de cache, alors que d'autres utilisent peu la mémoire cache. Avec un cache dédié, tous les programmes ont accès à la même quantité de cache, car les caches des différents cœurs sont de la même taille. Les caches dédiés étant assez petits, les programmes plus gourmands devront se débrouiller avec un petit cache, alors que les autres programmes auront du cache en trop. A l'opposé, un cache partagé répartit le cache de manière optimale : un programme gourmand peut utiliser autant de cache qu'il veut, laissant juste ce qu'il faut aux programmes moins gourmands. le cache peut être répartit plus facilement selon les besoins des différents programmes.

[[File:Cache partagé contre cache dédié.png|centre|vignette|upright=2.5|Cache partagé contre cache dédié]]

Un autre avantage des caches partagés est quand plusieurs cœurs accèdent aux même données. C'est un cas très courant, souvent lié à l'usage de mémoire partagé ou de ''threads''. Avec des caches dédiés, chaque cœur a une copie des données partagées. Mais avec un cache partagé, il n'y a qu'une seule copie de chaque donnée, ce qui utilise moins de mémoire cache. Imaginons que l'on sait 8 caches dédiés de 8 Kibioctets, soit 64 kibioctets au total, comparé à un cache partagé de même capacité totale. Les doublons dans les caches dédiés réduiront la capacité mémoire utile, effective, comparé à un cache partagé. S'il y a 1 Kibioctet de mémoire partagé, 8 kibioctets seront utilisés pour stocker ces données en doublons, seulement 1 kibioctet sur un cache partagé. Ajoutons aussi que la cohérence des caches est grandement simplifiée avec l'usage d'un cache partagé, vu que les données ne sont pas dupliquées dans plusieurs caches.

Mais le partage du cache peut se transformer en inconvénient si les programmes entrent en compétition pour le cache, que ce soit pour y placer des données ou pour les accès mémoire. Deux programmes peuvent vouloir accéder au cache en même temps, voire carrément se marcher sur les pieds. La résolution des conflits d'accès au cache est résolu soit en prenant un cache multiport, avec un port dédié par cœur, soit par des mécanismes d'arbitrages avec des circuits dédiés. Le revers de la médaille tient au temps de latence. Plus un cache est gros, plus il est lent. En conséquence, des caches dédiés seront plus rapides qu'un  gros cache partagé plus lent.

===Le partage des caches adapté à une hiérarchie de caches===

Dans la réalité, un processeur multicœur ne contient pas qu'un seul cache, mais une hiérarchie de caches avec des caches L1, L2 et L3, parfois L4. Dans cette hiérarchie, certains caches sont partagés entre plusieurs cœurs, les autres sont dédiés. Le cache L1 n'est jamais partagé, car il doit avoir un temps d'accès très faible. Pour les autres caches, tout dépend du processeur.

[[File:Dual Core Generic.svg|vignette|Cache L2 partagé.]]

Les premiers processeurs multicœurs commerciaux utilisaient deux niveaux de cache : des caches L1 dédiés et un cache L2 partagé. Le cache L2 partagé était relié aux caches L1, grâce à un système assez complexe d'interconnexions. Le cache de niveau L2 était souvent simple port, car les caches L1 se chargent de filtrer les accès aux caches de niveau inférieurs.

Les processeurs multicœurs modernes ont des caches L3 et même L4, de grande capacité, ce qui a modifié le partage des caches. Le cache le plus proche de la mémoire, le cache de dernier niveau L3 ou L4, est systématiquement partagé, car son rôle est d'être un cache lent mais gros. Le cas du cache L2 dépend des architectures : il est partagé sur certains processeurs, dédié sur d'autres.

Dans le cas le plus courant, il y a plusieurs caches L2 qui sont chacun partagés entre plusieurs cœurs mais pas à tous. En effet, on peut limiter le partage du cache à quelques cœurs particuliers pour des raisons de performances.

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2.0|Partage des caches sur un processeur multicœur.]]

D'autres processeurs ont des caches L2 dédiés. Il s'agit surtout des processeurs multicœurs anciens, parmi les premières générations de processeurs multicœurs. Un exemple est celui de la microarchitecture Nehalem d'Intel. Il avait des caches L1 et L2 dédiés, mais un cache L3 partagé.

[[File:Nehalem EP.png|centre|vignette|upright=2.0|Partage des caches sur un processeur Intel d'architecture Nehalem.]]

===Les caches partagés centralisés et distribués===

Un point important est que quand on parle de cache partagé ou de cache dédié, on ne parle que de la manière dont les cœurs peuvent accéder au cache, pas de la manière dont le caches est réellement localisé sur la puce. En théorie, qui dit plusieurs caches dédiés signifie que l'on a vraiment plusieurs caches séparés sur la puce. Et chaque cache dédié est proche du cœur qui lui est attribué. Et pour les caches partagés unique, une portion de la puce de silicium contient le cache, que cette portion est un énorme bloc de transistors. Il est généralement placé au milieu de la puce ou sur un côté, histoire de facilement le connecter à tous les cœurs.

Mais pour les caches séparés, ce n'est pas toujours le cas. Avoir un cache énorme poserait des problèmes sur les architectures avec beaucoup de cœurs. En réalité, le cache est souvent découpé en plusieurs banques, reliées à un contrôleur du cache par un système d'interconnexion assez complexe. Les banques sont physiquement séparées, et il arrive qu'elles soient placées proche d'un cœur chacune. L'organisation des banques ressemble beaucoup à l'organisation des caches dédiés, avec une banque étant l'équivalent d'un cache dédié. La différence est que les cœurs peuvent lire et écrire dans toutes les banques, grâce au système d'interconnexion et au contrôleur de cache.

Tel était le cas sur les processeurs AMD Jaguar. Ils avaient un cache L2 de 2 mébioctets, partagés entre tous les cœurs, qui était composé de 4 banques de 512 Kibioctets. Les quatre banques du cache étaient reliées aux 4 cœurs par un réseaux d'interconnexion assez complexe.

[[File:AMDJaguarModule.png|centre|vignette|upright=2|AMD Jaguar Module]]

La différence entre les deux solutions pour les caches partagés porte le nom de cache centralisés versus distribués. Un gros cache unique sur la puce est un '''cache centralisé''', et c'est généralement un cache partagé. Mais un cache composé de plusieurs banques dispersées sur la puce est un '''cache distribué''', qui peut être aussi bien dédié que partagé.

===Les caches virtualisés===

Il faut noter que quelques processeurs utilisent cette technique pour fusionnent le cache L2 et le cache L3. Par exemple, les processeurs IBM Telum utilisent des caches L3 virtualisés, dans leurs versions récentes. Le processeur Telum 2 contient 10 caches L2 de 36 mébioctets chacun, soit 360 mébioctets de cache. L'idée est que ces 360 mébioctets sont partagés à la demande entre cache L2 dédié et cache L3. On parle alors de '''cache virtualisé'''.

Un cache de 36 mébioctet est associé à un cœur, auquel il est directement relié. Les cœurs n'utilisent pas tous leur cache dédié à 100% Il arrive que des cœurs aient des caches partiellement vides, alors que d'autres on un cache qui déborde. L'idée est que si un cœur a un cache plein, les données évincées du cache L2 privé sont déplacées dans le cache L2 d'un autre cœur, qui lui est partiellement vide. Le cache L2 en question est alors partitionné en deux : une portion pour les données associée à son cœur, une portion pour les données des L2 des autres cœurs. 

Pour que la technique fonctionne, le processeur mesure le remplissage de chaque cache L2. De plus, il faut gérer la politique de remplacement des lignes de cache. Une ligne de cache évincée du cache doit être déplacé dans un autre L2, pas dans les niveaux de cache inférieur, ni dans la mémoire. Du moins, tant qu'il reste de la place dans le cache L3. De plus, une lecture/écriture dans le cache L3 demande de localiser le cache L2 contenant la donnée. Pour cela, les caches L2 sont tous consultés lors d'un accès au L3, c'est la solution la plus simple, elle marche très bien si le taux de défaut du cache L2 est faible.

Une telle optimisation ressemble beaucoup à un cache L2/L3 distribué, mais il y a quelques différences qui sont décrites dans le paragraphe précédent. Avec un L2 distribué, tout accès au L2 déclencherait une consultation de toutes les banques du L2. Avec un cache L3 virtualisé, ce n'est pas le cas. Le cache L2 associé au cœur est consulté, et c'est seulement en cas de défaut de cache que les autres caches L2 sont consultés. De plus, avec un cache L2 distribué, il n'y a pas de déplacement d'une ligne de cache entre deux banques, entre deux caches L2 physiques. Alors qu'avec un cache L3 virtualisé, c'est le cas en cas de remplacement d'une ligne de cache dans le cache L2.

Sur le processeur Telum 1, le partage du cache L2 est assez simple. Un cache L2 fait 32 mébioctets et est découpé en deux banques de 16 mébioctets. En temps normal, les premiers 16 mébioctets sont toujours associé au cache L2, au cœur associé. Les 16 mébioctets restants peuvent soit être attribués au cache L3, soit fusionnés avec les 16 premiers mébioctets. Dans le cas où le cœur associé est en veille, n'est absolument pas utilisé, les 32 mébioctets sont attribués au cache L3. Un partage assez simple, donc. Le partage du cache L2/L3 sur les processeurs Telum 2 n'est pas connu, il est supposé être plus flexible.

==Le réseau d'interconnexion entre cœurs==

Les CPU multicœurs connectent plusieurs cœurs entre eux, tout comme les systèmes multi-processeurs connectent plusieurs processeurs entre eux. Mais les transferts de données entre cœurs se font par l'intermédiaire des caches, ce qui fait que l'implémentation est différente de celle utilisée sur les systèmes multi-processeurs. Les standards pour les interconnexions entre coeurs sont assez proches de ceux utilisés pour interconnecter des processeurs, mais les standards utilisés ne sont pas les mêmes en pratique. Là encore, les cœurs sont connectés entre eux soit par un bus, soit par un réseau d'interconnexion.

===Le bus partagé entre plusieurs cœurs===

Une solution simple relie les cœurs entre eux grâce à un '''bus partagé'''. Le cas le plus simple est celui où chaque cœur dispose de caches dédiés, qui sont alors tous reliés au bus mémoire, qui sert d'intermédiaire. Mais l'idée doit être adaptée sur les processeurs multicœurs avec des caches partagés. Voyons d'abord le cas d'un CPU avec deux niveaux de cache, dont un cache L2 est partagé entre tous les cœurs. Les caches L1 sont reliés au cache L2 partagé par un bus, qui n'a souvent pas de nom. Nous désignerons le bus entre le cache L1 et le cache L2 : '''bus partagé''', sous-entendu partagé entre tous les caches. C'est lui qui sert à connecter les cœurs entre eux.

[[File:Architecture multicoeurs à bus partagé entre caches L1 et L2.png|centre|vignette|upright=2|Architecture multicoeurs à bus partagé entre caches L1 et L2]]

Un processeur multicœur typique a une architecture avec trois niveaux de cache (L1, L2 et L3), avec un niveau L1 dédié par cœur, un niveau L2 partiellement partagé et un L3 totalement partagé. Le bus partagé est alors difficile à décrire, mais il correspond à l'ensemble des bus qui connectent les caches L1 aux caches L2, et les caches L2 au cache L3. Il s'agit alors d'un ensemble de bus, plus que d'un bus partagé unique.

===Le réseau d'interconnexion entre plusieurs cœurs===

Relier plusieurs cœurs avec des bus pose de nombreux problèmes techniques qui sont d'autant plus problématiques que le nombre de cœurs augmente. Le câblage est notamment très complexe, les contraintes électriques pour la transmission des signaux sont beaucoup plus fortes, les problèmes d'arbitrages se font plus fréquents, etc. Pour régler ces problèmes, les processeurs multicoeurs n'utilisent pas de bus partagé, mais un réseau d'interconnexion plus complexe.

Le réseau d'interconnexion peut être très complexe, avec des connexions réseau, des commutateurs, et des protocoles d'échanges entre processeurs assez complexes basés sur du passage de messages. De telles puces utilisent un '''réseau sur puce''' (''network on chip''). Mais d'autres simplifient le réseau d'interconnexion, qui se résume à un réseau ''crossbar'', voire à des mémoires FIFO pour faire l'interface entre les cœurs.

Le problème principal des réseaux sur puce est que les mémoires FIFOs sont difficiles à implémenter sur une puce de silicium. Elles prennent beaucoup de place, utilisent beaucoup de portes logiques, consomment beaucoup d'énergie, sont difficiles à concevoir pour diverses raisons (les accès concurrents/simultanés sont fréquents et font mauvais ménage avec les ''timings'' serrés de quelques cycles d'horloges requis). Il est donc impossible de placer beaucoup de mémoires FIFO dans un processeur, ce qui fait que les commutateur sont réduits à leur strict minimum : un réseau d'interconnexion, un système d'arbitrage simple parfois sans aucune FIFO, guère plus.

===Les architectures en ''tile''===

Un cas particulier de réseau sur puce est celui des '''architectures en ''tile''''', des architectures avec un grand nombre de cœurs, connectés les unes aux autres par un réseau d'interconnexion &quot;rectangulaire&quot;. Chaque cœur est associé à un commutateur (''switch'') qui le connecte au réseau d'interconnexion, l'ensemble formant une ''tile''.

[[File:Tile64-Tile.svg|centre|vignette|upright=1.5|''Tile'' de base du Tile64.]]

Le réseau est souvent organisé en tableau, chaque ''tile'' étant connectée à plusieurs voisines. Dans le cas le plus fréquent, chaque ''tile'' est connectée à quatre voisines : celle du dessus, celle du dessous, celle de gauche et celle de droite. Précisons que cette architecture n'est pas une architecture distribuée dont tous les processeurs seraient placés sur la même puce de silicium. En effet, la comparaison ne marche pas pour ce qui est de la mémoire : tous les cœurs accèdent à une mémoire partagée située en dehors de la puce de silicium. Le réseau ne connecte pas plusieurs ordinateurs séparés avec chacun leur propre mémoire, mais plusieurs cœurs qui accèdent à une mémoire partagée.

Un bon exemple d'architecture en ''tile'' serait les déclinaisons de l'architecture Tilera. Les schémas du-dessous montrent l'architecture du processeur Tile 64. Outre les ''tiles'', qui sont les éléments de calcul de l'architecture, on trouve plusieurs contrôleurs mémoire DDR, divers interfaces réseau, des interfaces série et parallèles, et d'autres entrées-sorties.

[[File:Tile64.svg|centre|vignette|upright=2|Architecture Tile64 du Tilera.]]

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Les architectures parallèles
           | prevText=Les architectures parallèles
           | next=Architectures multithreadées et Hyperthreading
           | nextText=Architectures multithreadées et Hyperthreading
}}
&lt;/noinclude&gt;</text>
      <sha1>h39snnrinvr38djxokbijnkyu4eprse</sha1>
    </revision>
    <revision>
      <id>745451</id>
      <parentid>745450</parentid>
      <timestamp>2025-06-27T00:10:50Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les architectures à cœurs conjoints */</comment>
      <origin>745451</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="33231" sha1="62ug8clgn85a93u5hlopv0m1f4con75" xml:space="preserve">Pour réellement tirer parti du parallélisme de taches, rien ne vaut l'utilisation de plusieurs processeurs et/ou de plusieurs ordinateurs, qui exécutent chacun un ou plusieurs programmes dans leur coin. Si utiliser plusieurs ordinateurs connectés par un réseau local est une solution simple et facile à implémenter, elle est cependant assez onéreuse et demande des logiciels adaptés qui permettent de profiter d'une telle architecture matérielle. D'autres solutions multiprocesseurs ont alors vu le jour pour rendre l'usage de plusieurs processeurs plus adéquat.

==Les systèmes multiprocesseur==

Les '''systèmes multiprocesseur''' placent plusieurs processeurs sur la même carte mère. Cette méthode marchait bien mais n'était pas des plus pratique, surtout que l'utilisation de plusieurs processeurs en même temps n'était de plus pas vraiment démocratisé à cette époque. Les logiciels et les systèmes d'exploitation grand public n'étaient pas adaptés pour, la demande pour des ordinateurs multiprocesseurs était limitée à quelques professionnels et ne justifiait pas un investissement majeure dans ces technologies.

Au niveau matériel, il fallait une carte mère adaptée, qui n'était pas facilement disponible et coûtait généralement plus cher que les cartes mères à un seul processeur. Sans compter qu'il valait mieux avoir une mémoire RAM rapide et des processeurs dotés de beaucoup de mémoire cache, ce qui coûtait encore plus cher. Au final, le gain était assez faible en terme de performance, peu de logiciels grand public profitaient de l'usage de plusieurs processeurs, la technologie est restée confidentielle.

===Le réseau d'interconnexion inter-processeur===

Un système multi-processeurs doit connecter entre eux plusieurs processeurs. Pour cela, les cartes mères multi-processeurs incorporent un réseau d'interconnexion pour connecter les processeurs entre eux, et les connecter avec la mémoire et les autres entrées-sorties. Il s'agit d'un '''réseau d'interconnexion inter-processeur''', placé sur la carte mère. Les processeurs sont tous connectés en utilisant deux solutions : soit avec un bus partagé, soit avec un réseau d'interconnexion très complexe.

Une solution simple relie les processeurs/cœurs entre eux grâce à un '''bus partagé'''. Nous parlerons en détail du bus partagé dans le chapitre sur la cohérence des caches, mais nous pouvons aborder le sujet maintenant, en précisant quel est ce bus partagé. Et suivant que l'on parle de systèmes multi-processeurs ou multicœurs, le bus qui est partagé n'est pas le même. Le cas le plus simple est celui d'une architecture multi-processeurs. Les processeurs sont alors tous reliés à la mémoire RAM à travers le bus mémoire. Le bus mémoire sert de point de ralliement, de point de convergence, il est le bus partagé. Les transferts entre caches se font alors en utilisant le bus mémoire.

[[File:Architecture multicoeurs à bus partagé.png|centre|vignette|upright=2|Architecture multiprocesseurs à bus partagé]]

De nos jours, les cartes mères pour serveur n'utilisent plus de bus partagé, mais utilisent un réseau d'interconnexion plus élaboré. Le réseau en question est un vrai réseau, qui peut être un réseau en anneau, un réseau crossbar, un réseau routé, etc. Le réseau d'interconnexion relie entre eux les cœurs, l'interface avec la mémoire RAM, le cache partagé L3/L4, mais aussi le bus PCI-Express, le GPU et quelques autres circuits séparés.

[[File:Architecture multicoeurs et réseau sur puce.png|centre|vignette|upright=1.5|Architecture multicoeurs et réseau sur puce]]

Les systèmes multi-processeurs modernes utilisent des réseaux d'interconnexion standardisés, les standards les plus communs étant l'HyperTransport, l'Intel QuickPath Interconnect, l'IBM Elastic Interface, le Intel Ultra Path Interconnect, l'Infinity Fabric, etc. Ils remplacent le fameux ''front-side bus'' des tout premiers processeurs multicœurs.

Un exemple de réseau d'interconnexion est celui des architectures AMD EPYC, de microarchitecture Zen 1. Elles utilisaient des chiplets, à savoir que le processeur était composé de plusieurs puces interconnectées entre elles. Chaque puce contenait un processeur multicoeurs intégrant un cache L3, avec un réseau d'interconnexion interne au processeur sans doute basé sur un ensemble de bus. De plus, les puces étaient reliées à une puce d'interconnexion qui servait à la fois d'interface entre les processeurs, mais aussi d'interface avec la R1AM, le bus PCI-Express, etc. La puce d'interconnexion était gravée en 14 nm contre 7nm pour les chiplets des cœurs. 

{|
|[[File:AMD Epyc 7702 delidded.jpg|centre|vignette|upright=2|AMD Epyc 7702.]]
|[[File:AMD Epyc Rome Aufbau.png|centre|vignette|upright=2|Schéma fonctionnel de l'AMD Epyc.]]
|}

===Les interruptions inter-processeurs===

Les différents processeurs sont gérés par le système d'exploitation de l'ordinateur, avec l'aide d''''interruptions inter-processeurs''', des interruptions déclenchées sur un processeur et exécutées sur un autre, éventuellement par tous les autres pour certaines interruptions spécifiques. Pour générer des interruptions inter-processeur, le contrôleur d'interruption doit pouvoir rediriger des interruptions déclenchées par un processeur vers un autre.

Un exemple d'implémentation très simple est celui de la console Néo-géo, qui contenait deux processeurs. Le premier est un Motorola 68000 qui sert de processeur principal, l'autre est un Z80 qui sert de processeur dédié à l'audio. Le Z80 commande un synthétiseur sonore, et est relié à sa propre mémoire, distincte de la mémoire principale. Le MC68000 est le processeur principal et a une relation maitre-esclave avec le Z80 : le MC68000 envoie des interruptions au Z80, mais la communication ne va pas dans l'autre sens.

Les deux processeurs communiquent via l'intermédiaire d'un '''''IO arbiter chip''''', un circuit sur la carte mère connecté ua bus, qui gère les interruptions inter-processeur. Il contient un registre de 8 bits, dans lequel le MC68000 peut écrire dedans à sa guise, le registre étant adressable par le processeur. Les valeurs écrites dans ce registre sont des numéros d'interruption, qui indiquent quelle routine d'interruption exécuter. Lorsque le MC68000 écrit une valeur dedans, cela déclenche l’exécution automatique d'une interruption sur le Z80. Le code de 8 bits est envoyé au processeur Z80, en parallèle de l'interruption.

: Il est possible de voir ce ''IO arbiter chip'' comme un contrôleur d'interruptions spécialisé dans les interruptions inter-processeur.

Les anciens PC incorporaient sur leur carte mère un contrôleur d'interruption créé par Intel, le 8259A, qui ne gérait pas les interruptions inter-processeurs. Les cartes mères multiprocesseurs devaient incorporer un contrôleur spécial en complément. De nos jours, chaque cœur x86 possède son propre contrôleur d’interruption, le local APIC, qui gère les interruptions en provenance ou arrivant vers ce processeur. On trouve aussi un IO-APIC, qui gère les interruptions en provenance des périphériques et de les redistribuer vers les APIC locaux. L'IO-APIC gère aussi les interruptions inter-processeurs en faisant passer les interruptions d'un local APIC vers un autre. Tous les APIC locaux et l'IO-APIC sont reliés ensembles par un bus APIC spécialisé, par lequel ils vont pouvoir communiquer et s'échanger des demandes d'interruptions.

[[File:Contrôleurs d'interrptions sur systèmes x86 multicoeurs.png|centre|vignette|upright=1.5|Contrôleurs d’interruptions sur systèmes x86 multicœurs.]]

On peut préciser le processeur de destination en configurant certains registres du IO-APIC, afin que celui-ci redirige la demande d'interruption d'un local APIC vers celui sélectionné. Cela se fait avec l'aide d'un registre de 64 bits nommé l'''Interrupt Command Register''. Pour simplifier le mécanisme complet, chaque processeur se voit attribuer un Id au démarrage qui permet de l'identifier (en fait, cet Id est attribué au local APIC de chaque processeur). Certains bits de ce registre permettent de préciser quel est le type de transfert : doit-on envoyer l'interruption au processeur émetteur, à tous les autres processeurs, à un processeur particulier. Dans le dernier cas, certains bits du registre permettent de préciser l'Id du processeur qui va devoir recevoir l'interruption. À charge de l'APIC de faire ce qu'il faut en fonction du contenu de ce registre.

==Les processeurs multicœurs==

Puis, avec les progrès en matière de miniaturisation des processeurs, les fabricants ont eu l'idée d'utiliser les transistors qu'ils avaient pour fabriquer des '''processeurs multicœurs''', un terme que vous avez peut-être déjà entendu sans vraiment comprendre ce qu'il signifiait réellement. Les processeurs multicœurs peuvent être vus comme un regroupement de plusieurs processeurs sur la même puce de silicium.

Pour être plus précis, ils contiennent plusieurs ''cœurs'', chaque cœur pouvant exécuter un programme tout seul. Chaque cœur dispose de toute la machinerie électronique pour exécuter un programme, que ce soit un séquenceur d'instruction, des registres, une unité de calcul. Par contre, certains circuits d'un processeur ne sont présents qu'en un seul exemplaire dans un processeur multicœurs, comme les circuits de communication avec la mémoire ou les circuits d’interfaçage avec la carte mère. Suivant le nombre de cœurs présents dans notre processeur, celui-ci sera appelé un processeur double-cœur (deux cœurs), quadruple-cœur (4 cœurs), octuple-cœur (8 cœurs), etc. Ces processeurs sont devenus la norme dans les ordinateurs grand public et les logiciels et systèmes d'exploitation se sont adaptés.

Dans ce qui suit, nous utiliserons le terme cœurs pour désigner soit les cœurs d'un processeur multicœurs, soit les différents processeurs d'un ordinateur multiprocesseur. Tout le contenu de ce chapitre vaut aussi bien pour les systèmes multicœurs que multiprocesseur. Les différences entre les deux sont mineures, les deux font face aux mêmes problèmes, les mêmes solutions peuvent s'appliquer sur les deux types de systèmes.

===Le multicœurs symétrique ou asymétrique===

Dans la grosse majorité des cas, les cœurs d'un processeur multicœurs sont tous identiques. Mais ce n'est certainement pas une obligation et on peut très bien mettre plusieurs cœurs assez différents sur la même puce. On peut par exemple utiliser un cœur principal avec des cœurs plus spécialisés autour. Il faut ainsi distinguer le '''multicœurs symétrique''', dans lequel on place des processeurs identiques sur la même puce de silicium, du '''multicœurs asymétrique''' où les cœurs ne sont pas identiques.

Un exemple est celui du processeur CELL de la console de jeu PS3. Il intègre un cœur principal POWER PC v5 et 8 coeurs qui servent de processeurs auxiliaires. Le processeur principal est appelé le PPE et les processeurs auxiliaires sont les SPE. Les SPE sont reliés à une mémoire locale (''local store'') de 256 kibioctets qui communique avec le processeur principal via un bus spécial. Les SPE communiquent avec la RAM principale via des contrôleurs DMA. Les SPE possèdent des instructions permettant de commander leur contrôleur DMA et c'est le seul moyen qu'ils ont pour récupérer des informations depuis la mémoire. Et c'est au programmeur de gérer tout ça ! C'est le processeur principal qui va envoyer aux SPE les programmes qu'ils doivent exécuter. Il délègue des calculs aux SPE en écrivant dans le local store du SPE et en lui ordonnant l’exécution du programme qu'il vient d'écrire.

[[File:Schema Cell.png|centre|vignette|upright=2|Architecture du processeur CELL de la PS3. Le PPE est le processeur principal, les SPE sont des processeurs auxiliaires qui comprennent : un ''local store'' noté LS, un processeur noté SXU, et un contrôleur DMA pour échanger des informations avec la mémoire principale.]]

===Les architectures à cœurs conjoints===

Sur certains processeurs multicœurs, certains circuits sont partagés entre plusieurs cœurs. Typiquement, l'unité de calcul flottante est partagée entre deux coeurs/''threads'', les unités SIMD qu'on verra dans quelques chapitres sont aussi dans ce cas. Le partage de circuits permet d'éviter de dupliquer trop de circuits et donc d'économiser des transistors. Le problème est que ce partage est source de dépendances structurelles, ce qui peut entraîner des pertes de performances.

Cette technique consistant de partage d'unités de calcul entre coeurs s'appelle le '''cluster multithreading''', ou encore les '''architectures à cœurs conjoints''' (''Conjoined Core Architectures''). Elle est notamment utilisée sur les processeurs AMD de microarchitecture Bulldozer, incluant ses trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Un exemple est celui des processeurs AMD FX-8150 et FX-8120.

Sur ces processeurs, les instructions sont chargées dans deux files d'instructions séparées, une par ''thread'' matériel. Les instructions sont ensuite décodées par un décodeur unique et renommées dans une unité de renommage unique. Par la suite, il y a deux voies entières séparées et une voie flottante partagée. Chaque voie entière a sa propre fenêtre d'instruction entière, son tampon de ré-ordonnancement, ses unités de calcul dédiées, ses registres, sa ''load-store queue'', son cache L1. Par contre, la voie flottante partage les unités de calcul flottantes et n'a qu'une seule fenêtre d'instruction partagée par les deux ''threads''.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer d'AMD.]]

La révision Steamroller sépara le ''front-end'' en deux voies distinctes, une par ''thread''. Concrètement, elle ajouta un second décodeur d'instruction, une seconde file de micro-opération et une seconde unité de renommage de registres, afin d'améliorer les performances.

[[File:AMD Steamroller microarchitecture.png|centre|vignette|upright=3|Microarchitecture Steamroller d'AMD.]]

===Les architectures ''many core''===

Les architectures ''many core'' ont un très grand nombre de cœurs, plus d'une cinquantaine, voire plusieurs centaines ou milliers. La différence est surtout une question de degré, mais aussi de but recherché.

Les architectures multicœurs sont surtout conçues pour les ordinateurs personnels, éventuellement les serveurs. Elles recherchent un bon compromis entre un grand nombre de cœurs, et une bonne performance pour les programmes non-parallèles. En clair, elles évitent de sacrifier les performances pour les applications non-parallèles, ce qui fait que leurs cœurs sont généralement très puissants, avec beaucoup d'optimisations micro-architecturales.

Les architectures ''many core'' font le compromis inverse : elles ont beaucoup de cœurs, mais ceux-ci ne sont pas très puissants, surtout pour les applications non-parallèles. Les cœurs des architectures ''many core'' sont généralement des cœurs sans exécution dans le désordre, sans prédiction de branchements, sans renommage de registres, voire sans pipeline ni parallélisme d'instruction.

==Le partage des caches==

Quand on conçoit un processeur multicœur, il ne faut pas oublier ce qui arrive à la pièce maîtresse de tout processeur actuel : le cache ! Pour le moment nous allons oublier le fait que les processeurs ont une hiérarchie de caches, avec des caches L1, L2, L3 et autres. Nous allons partir du principe qu'un processeur simple cœur a un seul cache, et voir comment adapter le cache à la présence de plusieurs cœurs. Nous allons rapidement lever cette hypothèse, pour étudier le cas où un processeur multicœur a une hiérarchie de caches, mais seulement après avoir vu le cas le plus simple à un seul cache.

===Le partage des caches sans hiérarchie de caches : caches dédiés et partagés===

Avec un seul niveau de cache, sans hiérarchie, deux solutions sont possibles. La première consiste à garder un seul cache, et de le partager entre les cœurs. L'autre solution est de dupliquer le cache et d'utiliser un cache par cœur. Les deux solutions sont appelées différemment. On parle de '''caches dédiés''' si chaque cœur possède son propre cache, et de '''cache partagé''' avec un cache partagé entre tous les cœurs. Ces deux méthodes ont des inconvénients et des avantages.

{|
|[[File:Caches dédiés.png|vignette|Caches dédiés]]
|[[File:Caches partagés.png|vignette|Cache partagé]]
|}

Le premier point sur lequel comparer caches dédiés et partagés est celui de la capacité du cache. La quantité de mémoire cache que l'on peut placer dans un processeur est limitée, car le cache prend beaucoup de place, près de la moitié des circuits du processeur. Aussi, un processeur incorpore une certaine quantité de mémoire cache, qu'il faut répartir entre un ou plusieurs caches. Les caches dédiés et partagés ne donnent pas le même résultat. D'un côté, le cache partagé fait que toute la mémoire cache est dédiée au cache partagé, qui est très gros. De l'autre, on doit répartir la capacité du cache entre plusieurs caches séparés, individuellement plus petits. En conséquence, on a le choix entre un petit cache pour chaque processeur ou un gros cache partagé.

Le choix entre les deux n'est pas simple, mais doit tenir compte du fait que les programmes exécutés sur les cœurs n'ont pas les mêmes besoins. Certains programmes sont plus gourmands et demandent beaucoup de cache, alors que d'autres utilisent peu la mémoire cache. Avec un cache dédié, tous les programmes ont accès à la même quantité de cache, car les caches des différents cœurs sont de la même taille. Les caches dédiés étant assez petits, les programmes plus gourmands devront se débrouiller avec un petit cache, alors que les autres programmes auront du cache en trop. A l'opposé, un cache partagé répartit le cache de manière optimale : un programme gourmand peut utiliser autant de cache qu'il veut, laissant juste ce qu'il faut aux programmes moins gourmands. le cache peut être répartit plus facilement selon les besoins des différents programmes.

[[File:Cache partagé contre cache dédié.png|centre|vignette|upright=2.5|Cache partagé contre cache dédié]]

Un autre avantage des caches partagés est quand plusieurs cœurs accèdent aux même données. C'est un cas très courant, souvent lié à l'usage de mémoire partagé ou de ''threads''. Avec des caches dédiés, chaque cœur a une copie des données partagées. Mais avec un cache partagé, il n'y a qu'une seule copie de chaque donnée, ce qui utilise moins de mémoire cache. Imaginons que l'on sait 8 caches dédiés de 8 Kibioctets, soit 64 kibioctets au total, comparé à un cache partagé de même capacité totale. Les doublons dans les caches dédiés réduiront la capacité mémoire utile, effective, comparé à un cache partagé. S'il y a 1 Kibioctet de mémoire partagé, 8 kibioctets seront utilisés pour stocker ces données en doublons, seulement 1 kibioctet sur un cache partagé. Ajoutons aussi que la cohérence des caches est grandement simplifiée avec l'usage d'un cache partagé, vu que les données ne sont pas dupliquées dans plusieurs caches.

Mais le partage du cache peut se transformer en inconvénient si les programmes entrent en compétition pour le cache, que ce soit pour y placer des données ou pour les accès mémoire. Deux programmes peuvent vouloir accéder au cache en même temps, voire carrément se marcher sur les pieds. La résolution des conflits d'accès au cache est résolu soit en prenant un cache multiport, avec un port dédié par cœur, soit par des mécanismes d'arbitrages avec des circuits dédiés. Le revers de la médaille tient au temps de latence. Plus un cache est gros, plus il est lent. En conséquence, des caches dédiés seront plus rapides qu'un  gros cache partagé plus lent.

===Le partage des caches adapté à une hiérarchie de caches===

Dans la réalité, un processeur multicœur ne contient pas qu'un seul cache, mais une hiérarchie de caches avec des caches L1, L2 et L3, parfois L4. Dans cette hiérarchie, certains caches sont partagés entre plusieurs cœurs, les autres sont dédiés. Le cache L1 n'est jamais partagé, car il doit avoir un temps d'accès très faible. Pour les autres caches, tout dépend du processeur.

[[File:Dual Core Generic.svg|vignette|Cache L2 partagé.]]

Les premiers processeurs multicœurs commerciaux utilisaient deux niveaux de cache : des caches L1 dédiés et un cache L2 partagé. Le cache L2 partagé était relié aux caches L1, grâce à un système assez complexe d'interconnexions. Le cache de niveau L2 était souvent simple port, car les caches L1 se chargent de filtrer les accès aux caches de niveau inférieurs.

Les processeurs multicœurs modernes ont des caches L3 et même L4, de grande capacité, ce qui a modifié le partage des caches. Le cache le plus proche de la mémoire, le cache de dernier niveau L3 ou L4, est systématiquement partagé, car son rôle est d'être un cache lent mais gros. Le cas du cache L2 dépend des architectures : il est partagé sur certains processeurs, dédié sur d'autres.

Dans le cas le plus courant, il y a plusieurs caches L2 qui sont chacun partagés entre plusieurs cœurs mais pas à tous. En effet, on peut limiter le partage du cache à quelques cœurs particuliers pour des raisons de performances.

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2.0|Partage des caches sur un processeur multicœur.]]

D'autres processeurs ont des caches L2 dédiés. Il s'agit surtout des processeurs multicœurs anciens, parmi les premières générations de processeurs multicœurs. Un exemple est celui de la microarchitecture Nehalem d'Intel. Il avait des caches L1 et L2 dédiés, mais un cache L3 partagé.

[[File:Nehalem EP.png|centre|vignette|upright=2.0|Partage des caches sur un processeur Intel d'architecture Nehalem.]]

===Les caches partagés centralisés et distribués===

Un point important est que quand on parle de cache partagé ou de cache dédié, on ne parle que de la manière dont les cœurs peuvent accéder au cache, pas de la manière dont le caches est réellement localisé sur la puce. En théorie, qui dit plusieurs caches dédiés signifie que l'on a vraiment plusieurs caches séparés sur la puce. Et chaque cache dédié est proche du cœur qui lui est attribué. Et pour les caches partagés unique, une portion de la puce de silicium contient le cache, que cette portion est un énorme bloc de transistors. Il est généralement placé au milieu de la puce ou sur un côté, histoire de facilement le connecter à tous les cœurs.

Mais pour les caches séparés, ce n'est pas toujours le cas. Avoir un cache énorme poserait des problèmes sur les architectures avec beaucoup de cœurs. En réalité, le cache est souvent découpé en plusieurs banques, reliées à un contrôleur du cache par un système d'interconnexion assez complexe. Les banques sont physiquement séparées, et il arrive qu'elles soient placées proche d'un cœur chacune. L'organisation des banques ressemble beaucoup à l'organisation des caches dédiés, avec une banque étant l'équivalent d'un cache dédié. La différence est que les cœurs peuvent lire et écrire dans toutes les banques, grâce au système d'interconnexion et au contrôleur de cache.

Tel était le cas sur les processeurs AMD Jaguar. Ils avaient un cache L2 de 2 mébioctets, partagés entre tous les cœurs, qui était composé de 4 banques de 512 Kibioctets. Les quatre banques du cache étaient reliées aux 4 cœurs par un réseaux d'interconnexion assez complexe.

[[File:AMDJaguarModule.png|centre|vignette|upright=2|AMD Jaguar Module]]

La différence entre les deux solutions pour les caches partagés porte le nom de cache centralisés versus distribués. Un gros cache unique sur la puce est un '''cache centralisé''', et c'est généralement un cache partagé. Mais un cache composé de plusieurs banques dispersées sur la puce est un '''cache distribué''', qui peut être aussi bien dédié que partagé.

===Les caches virtualisés===

Il faut noter que quelques processeurs utilisent cette technique pour fusionnent le cache L2 et le cache L3. Par exemple, les processeurs IBM Telum utilisent des caches L3 virtualisés, dans leurs versions récentes. Le processeur Telum 2 contient 10 caches L2 de 36 mébioctets chacun, soit 360 mébioctets de cache. L'idée est que ces 360 mébioctets sont partagés à la demande entre cache L2 dédié et cache L3. On parle alors de '''cache virtualisé'''.

Un cache de 36 mébioctet est associé à un cœur, auquel il est directement relié. Les cœurs n'utilisent pas tous leur cache dédié à 100% Il arrive que des cœurs aient des caches partiellement vides, alors que d'autres on un cache qui déborde. L'idée est que si un cœur a un cache plein, les données évincées du cache L2 privé sont déplacées dans le cache L2 d'un autre cœur, qui lui est partiellement vide. Le cache L2 en question est alors partitionné en deux : une portion pour les données associée à son cœur, une portion pour les données des L2 des autres cœurs. 

Pour que la technique fonctionne, le processeur mesure le remplissage de chaque cache L2. De plus, il faut gérer la politique de remplacement des lignes de cache. Une ligne de cache évincée du cache doit être déplacé dans un autre L2, pas dans les niveaux de cache inférieur, ni dans la mémoire. Du moins, tant qu'il reste de la place dans le cache L3. De plus, une lecture/écriture dans le cache L3 demande de localiser le cache L2 contenant la donnée. Pour cela, les caches L2 sont tous consultés lors d'un accès au L3, c'est la solution la plus simple, elle marche très bien si le taux de défaut du cache L2 est faible.

Une telle optimisation ressemble beaucoup à un cache L2/L3 distribué, mais il y a quelques différences qui sont décrites dans le paragraphe précédent. Avec un L2 distribué, tout accès au L2 déclencherait une consultation de toutes les banques du L2. Avec un cache L3 virtualisé, ce n'est pas le cas. Le cache L2 associé au cœur est consulté, et c'est seulement en cas de défaut de cache que les autres caches L2 sont consultés. De plus, avec un cache L2 distribué, il n'y a pas de déplacement d'une ligne de cache entre deux banques, entre deux caches L2 physiques. Alors qu'avec un cache L3 virtualisé, c'est le cas en cas de remplacement d'une ligne de cache dans le cache L2.

Sur le processeur Telum 1, le partage du cache L2 est assez simple. Un cache L2 fait 32 mébioctets et est découpé en deux banques de 16 mébioctets. En temps normal, les premiers 16 mébioctets sont toujours associé au cache L2, au cœur associé. Les 16 mébioctets restants peuvent soit être attribués au cache L3, soit fusionnés avec les 16 premiers mébioctets. Dans le cas où le cœur associé est en veille, n'est absolument pas utilisé, les 32 mébioctets sont attribués au cache L3. Un partage assez simple, donc. Le partage du cache L2/L3 sur les processeurs Telum 2 n'est pas connu, il est supposé être plus flexible.

==Le réseau d'interconnexion entre cœurs==

Les CPU multicœurs connectent plusieurs cœurs entre eux, tout comme les systèmes multi-processeurs connectent plusieurs processeurs entre eux. Mais les transferts de données entre cœurs se font par l'intermédiaire des caches, ce qui fait que l'implémentation est différente de celle utilisée sur les systèmes multi-processeurs. Les standards pour les interconnexions entre coeurs sont assez proches de ceux utilisés pour interconnecter des processeurs, mais les standards utilisés ne sont pas les mêmes en pratique. Là encore, les cœurs sont connectés entre eux soit par un bus, soit par un réseau d'interconnexion.

===Le bus partagé entre plusieurs cœurs===

Une solution simple relie les cœurs entre eux grâce à un '''bus partagé'''. Le cas le plus simple est celui où chaque cœur dispose de caches dédiés, qui sont alors tous reliés au bus mémoire, qui sert d'intermédiaire. Mais l'idée doit être adaptée sur les processeurs multicœurs avec des caches partagés. Voyons d'abord le cas d'un CPU avec deux niveaux de cache, dont un cache L2 est partagé entre tous les cœurs. Les caches L1 sont reliés au cache L2 partagé par un bus, qui n'a souvent pas de nom. Nous désignerons le bus entre le cache L1 et le cache L2 : '''bus partagé''', sous-entendu partagé entre tous les caches. C'est lui qui sert à connecter les cœurs entre eux.

[[File:Architecture multicoeurs à bus partagé entre caches L1 et L2.png|centre|vignette|upright=2|Architecture multicoeurs à bus partagé entre caches L1 et L2]]

Un processeur multicœur typique a une architecture avec trois niveaux de cache (L1, L2 et L3), avec un niveau L1 dédié par cœur, un niveau L2 partiellement partagé et un L3 totalement partagé. Le bus partagé est alors difficile à décrire, mais il correspond à l'ensemble des bus qui connectent les caches L1 aux caches L2, et les caches L2 au cache L3. Il s'agit alors d'un ensemble de bus, plus que d'un bus partagé unique.

===Le réseau d'interconnexion entre plusieurs cœurs===

Relier plusieurs cœurs avec des bus pose de nombreux problèmes techniques qui sont d'autant plus problématiques que le nombre de cœurs augmente. Le câblage est notamment très complexe, les contraintes électriques pour la transmission des signaux sont beaucoup plus fortes, les problèmes d'arbitrages se font plus fréquents, etc. Pour régler ces problèmes, les processeurs multicoeurs n'utilisent pas de bus partagé, mais un réseau d'interconnexion plus complexe.

Le réseau d'interconnexion peut être très complexe, avec des connexions réseau, des commutateurs, et des protocoles d'échanges entre processeurs assez complexes basés sur du passage de messages. De telles puces utilisent un '''réseau sur puce''' (''network on chip''). Mais d'autres simplifient le réseau d'interconnexion, qui se résume à un réseau ''crossbar'', voire à des mémoires FIFO pour faire l'interface entre les cœurs.

Le problème principal des réseaux sur puce est que les mémoires FIFOs sont difficiles à implémenter sur une puce de silicium. Elles prennent beaucoup de place, utilisent beaucoup de portes logiques, consomment beaucoup d'énergie, sont difficiles à concevoir pour diverses raisons (les accès concurrents/simultanés sont fréquents et font mauvais ménage avec les ''timings'' serrés de quelques cycles d'horloges requis). Il est donc impossible de placer beaucoup de mémoires FIFO dans un processeur, ce qui fait que les commutateur sont réduits à leur strict minimum : un réseau d'interconnexion, un système d'arbitrage simple parfois sans aucune FIFO, guère plus.

===Les architectures en ''tile''===

Un cas particulier de réseau sur puce est celui des '''architectures en ''tile''''', des architectures avec un grand nombre de cœurs, connectés les unes aux autres par un réseau d'interconnexion &quot;rectangulaire&quot;. Chaque cœur est associé à un commutateur (''switch'') qui le connecte au réseau d'interconnexion, l'ensemble formant une ''tile''.

[[File:Tile64-Tile.svg|centre|vignette|upright=1.5|''Tile'' de base du Tile64.]]

Le réseau est souvent organisé en tableau, chaque ''tile'' étant connectée à plusieurs voisines. Dans le cas le plus fréquent, chaque ''tile'' est connectée à quatre voisines : celle du dessus, celle du dessous, celle de gauche et celle de droite. Précisons que cette architecture n'est pas une architecture distribuée dont tous les processeurs seraient placés sur la même puce de silicium. En effet, la comparaison ne marche pas pour ce qui est de la mémoire : tous les cœurs accèdent à une mémoire partagée située en dehors de la puce de silicium. Le réseau ne connecte pas plusieurs ordinateurs séparés avec chacun leur propre mémoire, mais plusieurs cœurs qui accèdent à une mémoire partagée.

Un bon exemple d'architecture en ''tile'' serait les déclinaisons de l'architecture Tilera. Les schémas du-dessous montrent l'architecture du processeur Tile 64. Outre les ''tiles'', qui sont les éléments de calcul de l'architecture, on trouve plusieurs contrôleurs mémoire DDR, divers interfaces réseau, des interfaces série et parallèles, et d'autres entrées-sorties.

[[File:Tile64.svg|centre|vignette|upright=2|Architecture Tile64 du Tilera.]]

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Les architectures parallèles
           | prevText=Les architectures parallèles
           | next=Architectures multithreadées et Hyperthreading
           | nextText=Architectures multithreadées et Hyperthreading
}}
&lt;/noinclude&gt;</text>
      <sha1>62ug8clgn85a93u5hlopv0m1f4con75</sha1>
    </revision>
    <revision>
      <id>745452</id>
      <parentid>745451</parentid>
      <timestamp>2025-06-27T00:12:41Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les architectures à cœurs conjoints */</comment>
      <origin>745452</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="33544" sha1="5dr4rhk4d8x935zzknypgluizg17gu5" xml:space="preserve">Pour réellement tirer parti du parallélisme de taches, rien ne vaut l'utilisation de plusieurs processeurs et/ou de plusieurs ordinateurs, qui exécutent chacun un ou plusieurs programmes dans leur coin. Si utiliser plusieurs ordinateurs connectés par un réseau local est une solution simple et facile à implémenter, elle est cependant assez onéreuse et demande des logiciels adaptés qui permettent de profiter d'une telle architecture matérielle. D'autres solutions multiprocesseurs ont alors vu le jour pour rendre l'usage de plusieurs processeurs plus adéquat.

==Les systèmes multiprocesseur==

Les '''systèmes multiprocesseur''' placent plusieurs processeurs sur la même carte mère. Cette méthode marchait bien mais n'était pas des plus pratique, surtout que l'utilisation de plusieurs processeurs en même temps n'était de plus pas vraiment démocratisé à cette époque. Les logiciels et les systèmes d'exploitation grand public n'étaient pas adaptés pour, la demande pour des ordinateurs multiprocesseurs était limitée à quelques professionnels et ne justifiait pas un investissement majeure dans ces technologies.

Au niveau matériel, il fallait une carte mère adaptée, qui n'était pas facilement disponible et coûtait généralement plus cher que les cartes mères à un seul processeur. Sans compter qu'il valait mieux avoir une mémoire RAM rapide et des processeurs dotés de beaucoup de mémoire cache, ce qui coûtait encore plus cher. Au final, le gain était assez faible en terme de performance, peu de logiciels grand public profitaient de l'usage de plusieurs processeurs, la technologie est restée confidentielle.

===Le réseau d'interconnexion inter-processeur===

Un système multi-processeurs doit connecter entre eux plusieurs processeurs. Pour cela, les cartes mères multi-processeurs incorporent un réseau d'interconnexion pour connecter les processeurs entre eux, et les connecter avec la mémoire et les autres entrées-sorties. Il s'agit d'un '''réseau d'interconnexion inter-processeur''', placé sur la carte mère. Les processeurs sont tous connectés en utilisant deux solutions : soit avec un bus partagé, soit avec un réseau d'interconnexion très complexe.

Une solution simple relie les processeurs/cœurs entre eux grâce à un '''bus partagé'''. Nous parlerons en détail du bus partagé dans le chapitre sur la cohérence des caches, mais nous pouvons aborder le sujet maintenant, en précisant quel est ce bus partagé. Et suivant que l'on parle de systèmes multi-processeurs ou multicœurs, le bus qui est partagé n'est pas le même. Le cas le plus simple est celui d'une architecture multi-processeurs. Les processeurs sont alors tous reliés à la mémoire RAM à travers le bus mémoire. Le bus mémoire sert de point de ralliement, de point de convergence, il est le bus partagé. Les transferts entre caches se font alors en utilisant le bus mémoire.

[[File:Architecture multicoeurs à bus partagé.png|centre|vignette|upright=2|Architecture multiprocesseurs à bus partagé]]

De nos jours, les cartes mères pour serveur n'utilisent plus de bus partagé, mais utilisent un réseau d'interconnexion plus élaboré. Le réseau en question est un vrai réseau, qui peut être un réseau en anneau, un réseau crossbar, un réseau routé, etc. Le réseau d'interconnexion relie entre eux les cœurs, l'interface avec la mémoire RAM, le cache partagé L3/L4, mais aussi le bus PCI-Express, le GPU et quelques autres circuits séparés.

[[File:Architecture multicoeurs et réseau sur puce.png|centre|vignette|upright=1.5|Architecture multicoeurs et réseau sur puce]]

Les systèmes multi-processeurs modernes utilisent des réseaux d'interconnexion standardisés, les standards les plus communs étant l'HyperTransport, l'Intel QuickPath Interconnect, l'IBM Elastic Interface, le Intel Ultra Path Interconnect, l'Infinity Fabric, etc. Ils remplacent le fameux ''front-side bus'' des tout premiers processeurs multicœurs.

Un exemple de réseau d'interconnexion est celui des architectures AMD EPYC, de microarchitecture Zen 1. Elles utilisaient des chiplets, à savoir que le processeur était composé de plusieurs puces interconnectées entre elles. Chaque puce contenait un processeur multicoeurs intégrant un cache L3, avec un réseau d'interconnexion interne au processeur sans doute basé sur un ensemble de bus. De plus, les puces étaient reliées à une puce d'interconnexion qui servait à la fois d'interface entre les processeurs, mais aussi d'interface avec la R1AM, le bus PCI-Express, etc. La puce d'interconnexion était gravée en 14 nm contre 7nm pour les chiplets des cœurs. 

{|
|[[File:AMD Epyc 7702 delidded.jpg|centre|vignette|upright=2|AMD Epyc 7702.]]
|[[File:AMD Epyc Rome Aufbau.png|centre|vignette|upright=2|Schéma fonctionnel de l'AMD Epyc.]]
|}

===Les interruptions inter-processeurs===

Les différents processeurs sont gérés par le système d'exploitation de l'ordinateur, avec l'aide d''''interruptions inter-processeurs''', des interruptions déclenchées sur un processeur et exécutées sur un autre, éventuellement par tous les autres pour certaines interruptions spécifiques. Pour générer des interruptions inter-processeur, le contrôleur d'interruption doit pouvoir rediriger des interruptions déclenchées par un processeur vers un autre.

Un exemple d'implémentation très simple est celui de la console Néo-géo, qui contenait deux processeurs. Le premier est un Motorola 68000 qui sert de processeur principal, l'autre est un Z80 qui sert de processeur dédié à l'audio. Le Z80 commande un synthétiseur sonore, et est relié à sa propre mémoire, distincte de la mémoire principale. Le MC68000 est le processeur principal et a une relation maitre-esclave avec le Z80 : le MC68000 envoie des interruptions au Z80, mais la communication ne va pas dans l'autre sens.

Les deux processeurs communiquent via l'intermédiaire d'un '''''IO arbiter chip''''', un circuit sur la carte mère connecté ua bus, qui gère les interruptions inter-processeur. Il contient un registre de 8 bits, dans lequel le MC68000 peut écrire dedans à sa guise, le registre étant adressable par le processeur. Les valeurs écrites dans ce registre sont des numéros d'interruption, qui indiquent quelle routine d'interruption exécuter. Lorsque le MC68000 écrit une valeur dedans, cela déclenche l’exécution automatique d'une interruption sur le Z80. Le code de 8 bits est envoyé au processeur Z80, en parallèle de l'interruption.

: Il est possible de voir ce ''IO arbiter chip'' comme un contrôleur d'interruptions spécialisé dans les interruptions inter-processeur.

Les anciens PC incorporaient sur leur carte mère un contrôleur d'interruption créé par Intel, le 8259A, qui ne gérait pas les interruptions inter-processeurs. Les cartes mères multiprocesseurs devaient incorporer un contrôleur spécial en complément. De nos jours, chaque cœur x86 possède son propre contrôleur d’interruption, le local APIC, qui gère les interruptions en provenance ou arrivant vers ce processeur. On trouve aussi un IO-APIC, qui gère les interruptions en provenance des périphériques et de les redistribuer vers les APIC locaux. L'IO-APIC gère aussi les interruptions inter-processeurs en faisant passer les interruptions d'un local APIC vers un autre. Tous les APIC locaux et l'IO-APIC sont reliés ensembles par un bus APIC spécialisé, par lequel ils vont pouvoir communiquer et s'échanger des demandes d'interruptions.

[[File:Contrôleurs d'interrptions sur systèmes x86 multicoeurs.png|centre|vignette|upright=1.5|Contrôleurs d’interruptions sur systèmes x86 multicœurs.]]

On peut préciser le processeur de destination en configurant certains registres du IO-APIC, afin que celui-ci redirige la demande d'interruption d'un local APIC vers celui sélectionné. Cela se fait avec l'aide d'un registre de 64 bits nommé l'''Interrupt Command Register''. Pour simplifier le mécanisme complet, chaque processeur se voit attribuer un Id au démarrage qui permet de l'identifier (en fait, cet Id est attribué au local APIC de chaque processeur). Certains bits de ce registre permettent de préciser quel est le type de transfert : doit-on envoyer l'interruption au processeur émetteur, à tous les autres processeurs, à un processeur particulier. Dans le dernier cas, certains bits du registre permettent de préciser l'Id du processeur qui va devoir recevoir l'interruption. À charge de l'APIC de faire ce qu'il faut en fonction du contenu de ce registre.

==Les processeurs multicœurs==

Puis, avec les progrès en matière de miniaturisation des processeurs, les fabricants ont eu l'idée d'utiliser les transistors qu'ils avaient pour fabriquer des '''processeurs multicœurs''', un terme que vous avez peut-être déjà entendu sans vraiment comprendre ce qu'il signifiait réellement. Les processeurs multicœurs peuvent être vus comme un regroupement de plusieurs processeurs sur la même puce de silicium.

Pour être plus précis, ils contiennent plusieurs ''cœurs'', chaque cœur pouvant exécuter un programme tout seul. Chaque cœur dispose de toute la machinerie électronique pour exécuter un programme, que ce soit un séquenceur d'instruction, des registres, une unité de calcul. Par contre, certains circuits d'un processeur ne sont présents qu'en un seul exemplaire dans un processeur multicœurs, comme les circuits de communication avec la mémoire ou les circuits d’interfaçage avec la carte mère. Suivant le nombre de cœurs présents dans notre processeur, celui-ci sera appelé un processeur double-cœur (deux cœurs), quadruple-cœur (4 cœurs), octuple-cœur (8 cœurs), etc. Ces processeurs sont devenus la norme dans les ordinateurs grand public et les logiciels et systèmes d'exploitation se sont adaptés.

Dans ce qui suit, nous utiliserons le terme cœurs pour désigner soit les cœurs d'un processeur multicœurs, soit les différents processeurs d'un ordinateur multiprocesseur. Tout le contenu de ce chapitre vaut aussi bien pour les systèmes multicœurs que multiprocesseur. Les différences entre les deux sont mineures, les deux font face aux mêmes problèmes, les mêmes solutions peuvent s'appliquer sur les deux types de systèmes.

===Le multicœurs symétrique ou asymétrique===

Dans la grosse majorité des cas, les cœurs d'un processeur multicœurs sont tous identiques. Mais ce n'est certainement pas une obligation et on peut très bien mettre plusieurs cœurs assez différents sur la même puce. On peut par exemple utiliser un cœur principal avec des cœurs plus spécialisés autour. Il faut ainsi distinguer le '''multicœurs symétrique''', dans lequel on place des processeurs identiques sur la même puce de silicium, du '''multicœurs asymétrique''' où les cœurs ne sont pas identiques.

Un exemple est celui du processeur CELL de la console de jeu PS3. Il intègre un cœur principal POWER PC v5 et 8 coeurs qui servent de processeurs auxiliaires. Le processeur principal est appelé le PPE et les processeurs auxiliaires sont les SPE. Les SPE sont reliés à une mémoire locale (''local store'') de 256 kibioctets qui communique avec le processeur principal via un bus spécial. Les SPE communiquent avec la RAM principale via des contrôleurs DMA. Les SPE possèdent des instructions permettant de commander leur contrôleur DMA et c'est le seul moyen qu'ils ont pour récupérer des informations depuis la mémoire. Et c'est au programmeur de gérer tout ça ! C'est le processeur principal qui va envoyer aux SPE les programmes qu'ils doivent exécuter. Il délègue des calculs aux SPE en écrivant dans le local store du SPE et en lui ordonnant l’exécution du programme qu'il vient d'écrire.

[[File:Schema Cell.png|centre|vignette|upright=2|Architecture du processeur CELL de la PS3. Le PPE est le processeur principal, les SPE sont des processeurs auxiliaires qui comprennent : un ''local store'' noté LS, un processeur noté SXU, et un contrôleur DMA pour échanger des informations avec la mémoire principale.]]

===Les architectures à cœurs conjoints===

Sur certains processeurs multicœurs, certains circuits sont partagés entre plusieurs cœurs. Typiquement, l'unité de calcul flottante est partagée entre deux coeurs/''threads'', les unités SIMD qu'on verra dans quelques chapitres sont aussi dans ce cas. Le partage de circuits permet d'éviter de dupliquer trop de circuits et donc d'économiser des transistors. Le problème est que ce partage est source de dépendances structurelles, ce qui peut entraîner des pertes de performances.

Cette technique consistant de partage d'unités de calcul entre coeurs s'appelle le '''cluster multithreading''', ou encore les '''architectures à cœurs conjoints''' (''Conjoined Core Architectures''). Elle est notamment utilisée sur les processeurs AMD de microarchitecture Bulldozer, incluant ses trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Un exemple est celui des processeurs AMD FX-8150 et FX-8120.

Sur ces processeurs, les instructions sont chargées dans deux files d'instructions séparées, une par ''thread'' matériel. Les instructions sont ensuite décodées par un décodeur unique et renommées dans une unité de renommage unique. Par la suite, il y a deux voies entières séparées et une voie flottante partagée. Chaque voie entière a sa propre fenêtre d'instruction entière, son tampon de ré-ordonnancement, ses unités de calcul dédiées, ses registres, sa ''load-store queue'', son cache L1. Par contre, la voie flottante partage les unités de calcul flottantes et n'a qu'une seule fenêtre d'instruction partagée par les deux ''threads''.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer d'AMD.]]

La révision Steamroller sépara le ''front-end'' en deux voies distinctes, une par ''thread''. Concrètement, elle ajouta un second décodeur d'instruction, une seconde file de micro-opération et une seconde unité de renommage de registres, afin d'améliorer les performances. Niveaux optimisations mineures, les stations de réservation ont été augmentées, elles peuvent mémoriser plus de micro-opérations, idem pour les bancs de registre et les files de lecture/écriture. Un cache de micro-opérations a été ajouté, de même que des optimisations quant au renommage de registre.

[[File:AMD Steamroller microarchitecture.png|centre|vignette|upright=3|Microarchitecture Steamroller d'AMD.]]

===Les architectures ''many core''===

Les architectures ''many core'' ont un très grand nombre de cœurs, plus d'une cinquantaine, voire plusieurs centaines ou milliers. La différence est surtout une question de degré, mais aussi de but recherché.

Les architectures multicœurs sont surtout conçues pour les ordinateurs personnels, éventuellement les serveurs. Elles recherchent un bon compromis entre un grand nombre de cœurs, et une bonne performance pour les programmes non-parallèles. En clair, elles évitent de sacrifier les performances pour les applications non-parallèles, ce qui fait que leurs cœurs sont généralement très puissants, avec beaucoup d'optimisations micro-architecturales.

Les architectures ''many core'' font le compromis inverse : elles ont beaucoup de cœurs, mais ceux-ci ne sont pas très puissants, surtout pour les applications non-parallèles. Les cœurs des architectures ''many core'' sont généralement des cœurs sans exécution dans le désordre, sans prédiction de branchements, sans renommage de registres, voire sans pipeline ni parallélisme d'instruction.

==Le partage des caches==

Quand on conçoit un processeur multicœur, il ne faut pas oublier ce qui arrive à la pièce maîtresse de tout processeur actuel : le cache ! Pour le moment nous allons oublier le fait que les processeurs ont une hiérarchie de caches, avec des caches L1, L2, L3 et autres. Nous allons partir du principe qu'un processeur simple cœur a un seul cache, et voir comment adapter le cache à la présence de plusieurs cœurs. Nous allons rapidement lever cette hypothèse, pour étudier le cas où un processeur multicœur a une hiérarchie de caches, mais seulement après avoir vu le cas le plus simple à un seul cache.

===Le partage des caches sans hiérarchie de caches : caches dédiés et partagés===

Avec un seul niveau de cache, sans hiérarchie, deux solutions sont possibles. La première consiste à garder un seul cache, et de le partager entre les cœurs. L'autre solution est de dupliquer le cache et d'utiliser un cache par cœur. Les deux solutions sont appelées différemment. On parle de '''caches dédiés''' si chaque cœur possède son propre cache, et de '''cache partagé''' avec un cache partagé entre tous les cœurs. Ces deux méthodes ont des inconvénients et des avantages.

{|
|[[File:Caches dédiés.png|vignette|Caches dédiés]]
|[[File:Caches partagés.png|vignette|Cache partagé]]
|}

Le premier point sur lequel comparer caches dédiés et partagés est celui de la capacité du cache. La quantité de mémoire cache que l'on peut placer dans un processeur est limitée, car le cache prend beaucoup de place, près de la moitié des circuits du processeur. Aussi, un processeur incorpore une certaine quantité de mémoire cache, qu'il faut répartir entre un ou plusieurs caches. Les caches dédiés et partagés ne donnent pas le même résultat. D'un côté, le cache partagé fait que toute la mémoire cache est dédiée au cache partagé, qui est très gros. De l'autre, on doit répartir la capacité du cache entre plusieurs caches séparés, individuellement plus petits. En conséquence, on a le choix entre un petit cache pour chaque processeur ou un gros cache partagé.

Le choix entre les deux n'est pas simple, mais doit tenir compte du fait que les programmes exécutés sur les cœurs n'ont pas les mêmes besoins. Certains programmes sont plus gourmands et demandent beaucoup de cache, alors que d'autres utilisent peu la mémoire cache. Avec un cache dédié, tous les programmes ont accès à la même quantité de cache, car les caches des différents cœurs sont de la même taille. Les caches dédiés étant assez petits, les programmes plus gourmands devront se débrouiller avec un petit cache, alors que les autres programmes auront du cache en trop. A l'opposé, un cache partagé répartit le cache de manière optimale : un programme gourmand peut utiliser autant de cache qu'il veut, laissant juste ce qu'il faut aux programmes moins gourmands. le cache peut être répartit plus facilement selon les besoins des différents programmes.

[[File:Cache partagé contre cache dédié.png|centre|vignette|upright=2.5|Cache partagé contre cache dédié]]

Un autre avantage des caches partagés est quand plusieurs cœurs accèdent aux même données. C'est un cas très courant, souvent lié à l'usage de mémoire partagé ou de ''threads''. Avec des caches dédiés, chaque cœur a une copie des données partagées. Mais avec un cache partagé, il n'y a qu'une seule copie de chaque donnée, ce qui utilise moins de mémoire cache. Imaginons que l'on sait 8 caches dédiés de 8 Kibioctets, soit 64 kibioctets au total, comparé à un cache partagé de même capacité totale. Les doublons dans les caches dédiés réduiront la capacité mémoire utile, effective, comparé à un cache partagé. S'il y a 1 Kibioctet de mémoire partagé, 8 kibioctets seront utilisés pour stocker ces données en doublons, seulement 1 kibioctet sur un cache partagé. Ajoutons aussi que la cohérence des caches est grandement simplifiée avec l'usage d'un cache partagé, vu que les données ne sont pas dupliquées dans plusieurs caches.

Mais le partage du cache peut se transformer en inconvénient si les programmes entrent en compétition pour le cache, que ce soit pour y placer des données ou pour les accès mémoire. Deux programmes peuvent vouloir accéder au cache en même temps, voire carrément se marcher sur les pieds. La résolution des conflits d'accès au cache est résolu soit en prenant un cache multiport, avec un port dédié par cœur, soit par des mécanismes d'arbitrages avec des circuits dédiés. Le revers de la médaille tient au temps de latence. Plus un cache est gros, plus il est lent. En conséquence, des caches dédiés seront plus rapides qu'un  gros cache partagé plus lent.

===Le partage des caches adapté à une hiérarchie de caches===

Dans la réalité, un processeur multicœur ne contient pas qu'un seul cache, mais une hiérarchie de caches avec des caches L1, L2 et L3, parfois L4. Dans cette hiérarchie, certains caches sont partagés entre plusieurs cœurs, les autres sont dédiés. Le cache L1 n'est jamais partagé, car il doit avoir un temps d'accès très faible. Pour les autres caches, tout dépend du processeur.

[[File:Dual Core Generic.svg|vignette|Cache L2 partagé.]]

Les premiers processeurs multicœurs commerciaux utilisaient deux niveaux de cache : des caches L1 dédiés et un cache L2 partagé. Le cache L2 partagé était relié aux caches L1, grâce à un système assez complexe d'interconnexions. Le cache de niveau L2 était souvent simple port, car les caches L1 se chargent de filtrer les accès aux caches de niveau inférieurs.

Les processeurs multicœurs modernes ont des caches L3 et même L4, de grande capacité, ce qui a modifié le partage des caches. Le cache le plus proche de la mémoire, le cache de dernier niveau L3 ou L4, est systématiquement partagé, car son rôle est d'être un cache lent mais gros. Le cas du cache L2 dépend des architectures : il est partagé sur certains processeurs, dédié sur d'autres.

Dans le cas le plus courant, il y a plusieurs caches L2 qui sont chacun partagés entre plusieurs cœurs mais pas à tous. En effet, on peut limiter le partage du cache à quelques cœurs particuliers pour des raisons de performances.

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2.0|Partage des caches sur un processeur multicœur.]]

D'autres processeurs ont des caches L2 dédiés. Il s'agit surtout des processeurs multicœurs anciens, parmi les premières générations de processeurs multicœurs. Un exemple est celui de la microarchitecture Nehalem d'Intel. Il avait des caches L1 et L2 dédiés, mais un cache L3 partagé.

[[File:Nehalem EP.png|centre|vignette|upright=2.0|Partage des caches sur un processeur Intel d'architecture Nehalem.]]

===Les caches partagés centralisés et distribués===

Un point important est que quand on parle de cache partagé ou de cache dédié, on ne parle que de la manière dont les cœurs peuvent accéder au cache, pas de la manière dont le caches est réellement localisé sur la puce. En théorie, qui dit plusieurs caches dédiés signifie que l'on a vraiment plusieurs caches séparés sur la puce. Et chaque cache dédié est proche du cœur qui lui est attribué. Et pour les caches partagés unique, une portion de la puce de silicium contient le cache, que cette portion est un énorme bloc de transistors. Il est généralement placé au milieu de la puce ou sur un côté, histoire de facilement le connecter à tous les cœurs.

Mais pour les caches séparés, ce n'est pas toujours le cas. Avoir un cache énorme poserait des problèmes sur les architectures avec beaucoup de cœurs. En réalité, le cache est souvent découpé en plusieurs banques, reliées à un contrôleur du cache par un système d'interconnexion assez complexe. Les banques sont physiquement séparées, et il arrive qu'elles soient placées proche d'un cœur chacune. L'organisation des banques ressemble beaucoup à l'organisation des caches dédiés, avec une banque étant l'équivalent d'un cache dédié. La différence est que les cœurs peuvent lire et écrire dans toutes les banques, grâce au système d'interconnexion et au contrôleur de cache.

Tel était le cas sur les processeurs AMD Jaguar. Ils avaient un cache L2 de 2 mébioctets, partagés entre tous les cœurs, qui était composé de 4 banques de 512 Kibioctets. Les quatre banques du cache étaient reliées aux 4 cœurs par un réseaux d'interconnexion assez complexe.

[[File:AMDJaguarModule.png|centre|vignette|upright=2|AMD Jaguar Module]]

La différence entre les deux solutions pour les caches partagés porte le nom de cache centralisés versus distribués. Un gros cache unique sur la puce est un '''cache centralisé''', et c'est généralement un cache partagé. Mais un cache composé de plusieurs banques dispersées sur la puce est un '''cache distribué''', qui peut être aussi bien dédié que partagé.

===Les caches virtualisés===

Il faut noter que quelques processeurs utilisent cette technique pour fusionnent le cache L2 et le cache L3. Par exemple, les processeurs IBM Telum utilisent des caches L3 virtualisés, dans leurs versions récentes. Le processeur Telum 2 contient 10 caches L2 de 36 mébioctets chacun, soit 360 mébioctets de cache. L'idée est que ces 360 mébioctets sont partagés à la demande entre cache L2 dédié et cache L3. On parle alors de '''cache virtualisé'''.

Un cache de 36 mébioctet est associé à un cœur, auquel il est directement relié. Les cœurs n'utilisent pas tous leur cache dédié à 100% Il arrive que des cœurs aient des caches partiellement vides, alors que d'autres on un cache qui déborde. L'idée est que si un cœur a un cache plein, les données évincées du cache L2 privé sont déplacées dans le cache L2 d'un autre cœur, qui lui est partiellement vide. Le cache L2 en question est alors partitionné en deux : une portion pour les données associée à son cœur, une portion pour les données des L2 des autres cœurs. 

Pour que la technique fonctionne, le processeur mesure le remplissage de chaque cache L2. De plus, il faut gérer la politique de remplacement des lignes de cache. Une ligne de cache évincée du cache doit être déplacé dans un autre L2, pas dans les niveaux de cache inférieur, ni dans la mémoire. Du moins, tant qu'il reste de la place dans le cache L3. De plus, une lecture/écriture dans le cache L3 demande de localiser le cache L2 contenant la donnée. Pour cela, les caches L2 sont tous consultés lors d'un accès au L3, c'est la solution la plus simple, elle marche très bien si le taux de défaut du cache L2 est faible.

Une telle optimisation ressemble beaucoup à un cache L2/L3 distribué, mais il y a quelques différences qui sont décrites dans le paragraphe précédent. Avec un L2 distribué, tout accès au L2 déclencherait une consultation de toutes les banques du L2. Avec un cache L3 virtualisé, ce n'est pas le cas. Le cache L2 associé au cœur est consulté, et c'est seulement en cas de défaut de cache que les autres caches L2 sont consultés. De plus, avec un cache L2 distribué, il n'y a pas de déplacement d'une ligne de cache entre deux banques, entre deux caches L2 physiques. Alors qu'avec un cache L3 virtualisé, c'est le cas en cas de remplacement d'une ligne de cache dans le cache L2.

Sur le processeur Telum 1, le partage du cache L2 est assez simple. Un cache L2 fait 32 mébioctets et est découpé en deux banques de 16 mébioctets. En temps normal, les premiers 16 mébioctets sont toujours associé au cache L2, au cœur associé. Les 16 mébioctets restants peuvent soit être attribués au cache L3, soit fusionnés avec les 16 premiers mébioctets. Dans le cas où le cœur associé est en veille, n'est absolument pas utilisé, les 32 mébioctets sont attribués au cache L3. Un partage assez simple, donc. Le partage du cache L2/L3 sur les processeurs Telum 2 n'est pas connu, il est supposé être plus flexible.

==Le réseau d'interconnexion entre cœurs==

Les CPU multicœurs connectent plusieurs cœurs entre eux, tout comme les systèmes multi-processeurs connectent plusieurs processeurs entre eux. Mais les transferts de données entre cœurs se font par l'intermédiaire des caches, ce qui fait que l'implémentation est différente de celle utilisée sur les systèmes multi-processeurs. Les standards pour les interconnexions entre coeurs sont assez proches de ceux utilisés pour interconnecter des processeurs, mais les standards utilisés ne sont pas les mêmes en pratique. Là encore, les cœurs sont connectés entre eux soit par un bus, soit par un réseau d'interconnexion.

===Le bus partagé entre plusieurs cœurs===

Une solution simple relie les cœurs entre eux grâce à un '''bus partagé'''. Le cas le plus simple est celui où chaque cœur dispose de caches dédiés, qui sont alors tous reliés au bus mémoire, qui sert d'intermédiaire. Mais l'idée doit être adaptée sur les processeurs multicœurs avec des caches partagés. Voyons d'abord le cas d'un CPU avec deux niveaux de cache, dont un cache L2 est partagé entre tous les cœurs. Les caches L1 sont reliés au cache L2 partagé par un bus, qui n'a souvent pas de nom. Nous désignerons le bus entre le cache L1 et le cache L2 : '''bus partagé''', sous-entendu partagé entre tous les caches. C'est lui qui sert à connecter les cœurs entre eux.

[[File:Architecture multicoeurs à bus partagé entre caches L1 et L2.png|centre|vignette|upright=2|Architecture multicoeurs à bus partagé entre caches L1 et L2]]

Un processeur multicœur typique a une architecture avec trois niveaux de cache (L1, L2 et L3), avec un niveau L1 dédié par cœur, un niveau L2 partiellement partagé et un L3 totalement partagé. Le bus partagé est alors difficile à décrire, mais il correspond à l'ensemble des bus qui connectent les caches L1 aux caches L2, et les caches L2 au cache L3. Il s'agit alors d'un ensemble de bus, plus que d'un bus partagé unique.

===Le réseau d'interconnexion entre plusieurs cœurs===

Relier plusieurs cœurs avec des bus pose de nombreux problèmes techniques qui sont d'autant plus problématiques que le nombre de cœurs augmente. Le câblage est notamment très complexe, les contraintes électriques pour la transmission des signaux sont beaucoup plus fortes, les problèmes d'arbitrages se font plus fréquents, etc. Pour régler ces problèmes, les processeurs multicoeurs n'utilisent pas de bus partagé, mais un réseau d'interconnexion plus complexe.

Le réseau d'interconnexion peut être très complexe, avec des connexions réseau, des commutateurs, et des protocoles d'échanges entre processeurs assez complexes basés sur du passage de messages. De telles puces utilisent un '''réseau sur puce''' (''network on chip''). Mais d'autres simplifient le réseau d'interconnexion, qui se résume à un réseau ''crossbar'', voire à des mémoires FIFO pour faire l'interface entre les cœurs.

Le problème principal des réseaux sur puce est que les mémoires FIFOs sont difficiles à implémenter sur une puce de silicium. Elles prennent beaucoup de place, utilisent beaucoup de portes logiques, consomment beaucoup d'énergie, sont difficiles à concevoir pour diverses raisons (les accès concurrents/simultanés sont fréquents et font mauvais ménage avec les ''timings'' serrés de quelques cycles d'horloges requis). Il est donc impossible de placer beaucoup de mémoires FIFO dans un processeur, ce qui fait que les commutateur sont réduits à leur strict minimum : un réseau d'interconnexion, un système d'arbitrage simple parfois sans aucune FIFO, guère plus.

===Les architectures en ''tile''===

Un cas particulier de réseau sur puce est celui des '''architectures en ''tile''''', des architectures avec un grand nombre de cœurs, connectés les unes aux autres par un réseau d'interconnexion &quot;rectangulaire&quot;. Chaque cœur est associé à un commutateur (''switch'') qui le connecte au réseau d'interconnexion, l'ensemble formant une ''tile''.

[[File:Tile64-Tile.svg|centre|vignette|upright=1.5|''Tile'' de base du Tile64.]]

Le réseau est souvent organisé en tableau, chaque ''tile'' étant connectée à plusieurs voisines. Dans le cas le plus fréquent, chaque ''tile'' est connectée à quatre voisines : celle du dessus, celle du dessous, celle de gauche et celle de droite. Précisons que cette architecture n'est pas une architecture distribuée dont tous les processeurs seraient placés sur la même puce de silicium. En effet, la comparaison ne marche pas pour ce qui est de la mémoire : tous les cœurs accèdent à une mémoire partagée située en dehors de la puce de silicium. Le réseau ne connecte pas plusieurs ordinateurs séparés avec chacun leur propre mémoire, mais plusieurs cœurs qui accèdent à une mémoire partagée.

Un bon exemple d'architecture en ''tile'' serait les déclinaisons de l'architecture Tilera. Les schémas du-dessous montrent l'architecture du processeur Tile 64. Outre les ''tiles'', qui sont les éléments de calcul de l'architecture, on trouve plusieurs contrôleurs mémoire DDR, divers interfaces réseau, des interfaces série et parallèles, et d'autres entrées-sorties.

[[File:Tile64.svg|centre|vignette|upright=2|Architecture Tile64 du Tilera.]]

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Les architectures parallèles
           | prevText=Les architectures parallèles
           | next=Architectures multithreadées et Hyperthreading
           | nextText=Architectures multithreadées et Hyperthreading
}}
&lt;/noinclude&gt;</text>
      <sha1>5dr4rhk4d8x935zzknypgluizg17gu5</sha1>
    </revision>
    <revision>
      <id>745453</id>
      <parentid>745452</parentid>
      <timestamp>2025-06-27T00:13:23Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les architectures à cœurs conjoints */</comment>
      <origin>745453</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="33594" sha1="10s3ozo1om3pbahbky7e4hz3poy6k1u" xml:space="preserve">Pour réellement tirer parti du parallélisme de taches, rien ne vaut l'utilisation de plusieurs processeurs et/ou de plusieurs ordinateurs, qui exécutent chacun un ou plusieurs programmes dans leur coin. Si utiliser plusieurs ordinateurs connectés par un réseau local est une solution simple et facile à implémenter, elle est cependant assez onéreuse et demande des logiciels adaptés qui permettent de profiter d'une telle architecture matérielle. D'autres solutions multiprocesseurs ont alors vu le jour pour rendre l'usage de plusieurs processeurs plus adéquat.

==Les systèmes multiprocesseur==

Les '''systèmes multiprocesseur''' placent plusieurs processeurs sur la même carte mère. Cette méthode marchait bien mais n'était pas des plus pratique, surtout que l'utilisation de plusieurs processeurs en même temps n'était de plus pas vraiment démocratisé à cette époque. Les logiciels et les systèmes d'exploitation grand public n'étaient pas adaptés pour, la demande pour des ordinateurs multiprocesseurs était limitée à quelques professionnels et ne justifiait pas un investissement majeure dans ces technologies.

Au niveau matériel, il fallait une carte mère adaptée, qui n'était pas facilement disponible et coûtait généralement plus cher que les cartes mères à un seul processeur. Sans compter qu'il valait mieux avoir une mémoire RAM rapide et des processeurs dotés de beaucoup de mémoire cache, ce qui coûtait encore plus cher. Au final, le gain était assez faible en terme de performance, peu de logiciels grand public profitaient de l'usage de plusieurs processeurs, la technologie est restée confidentielle.

===Le réseau d'interconnexion inter-processeur===

Un système multi-processeurs doit connecter entre eux plusieurs processeurs. Pour cela, les cartes mères multi-processeurs incorporent un réseau d'interconnexion pour connecter les processeurs entre eux, et les connecter avec la mémoire et les autres entrées-sorties. Il s'agit d'un '''réseau d'interconnexion inter-processeur''', placé sur la carte mère. Les processeurs sont tous connectés en utilisant deux solutions : soit avec un bus partagé, soit avec un réseau d'interconnexion très complexe.

Une solution simple relie les processeurs/cœurs entre eux grâce à un '''bus partagé'''. Nous parlerons en détail du bus partagé dans le chapitre sur la cohérence des caches, mais nous pouvons aborder le sujet maintenant, en précisant quel est ce bus partagé. Et suivant que l'on parle de systèmes multi-processeurs ou multicœurs, le bus qui est partagé n'est pas le même. Le cas le plus simple est celui d'une architecture multi-processeurs. Les processeurs sont alors tous reliés à la mémoire RAM à travers le bus mémoire. Le bus mémoire sert de point de ralliement, de point de convergence, il est le bus partagé. Les transferts entre caches se font alors en utilisant le bus mémoire.

[[File:Architecture multicoeurs à bus partagé.png|centre|vignette|upright=2|Architecture multiprocesseurs à bus partagé]]

De nos jours, les cartes mères pour serveur n'utilisent plus de bus partagé, mais utilisent un réseau d'interconnexion plus élaboré. Le réseau en question est un vrai réseau, qui peut être un réseau en anneau, un réseau crossbar, un réseau routé, etc. Le réseau d'interconnexion relie entre eux les cœurs, l'interface avec la mémoire RAM, le cache partagé L3/L4, mais aussi le bus PCI-Express, le GPU et quelques autres circuits séparés.

[[File:Architecture multicoeurs et réseau sur puce.png|centre|vignette|upright=1.5|Architecture multicoeurs et réseau sur puce]]

Les systèmes multi-processeurs modernes utilisent des réseaux d'interconnexion standardisés, les standards les plus communs étant l'HyperTransport, l'Intel QuickPath Interconnect, l'IBM Elastic Interface, le Intel Ultra Path Interconnect, l'Infinity Fabric, etc. Ils remplacent le fameux ''front-side bus'' des tout premiers processeurs multicœurs.

Un exemple de réseau d'interconnexion est celui des architectures AMD EPYC, de microarchitecture Zen 1. Elles utilisaient des chiplets, à savoir que le processeur était composé de plusieurs puces interconnectées entre elles. Chaque puce contenait un processeur multicoeurs intégrant un cache L3, avec un réseau d'interconnexion interne au processeur sans doute basé sur un ensemble de bus. De plus, les puces étaient reliées à une puce d'interconnexion qui servait à la fois d'interface entre les processeurs, mais aussi d'interface avec la R1AM, le bus PCI-Express, etc. La puce d'interconnexion était gravée en 14 nm contre 7nm pour les chiplets des cœurs. 

{|
|[[File:AMD Epyc 7702 delidded.jpg|centre|vignette|upright=2|AMD Epyc 7702.]]
|[[File:AMD Epyc Rome Aufbau.png|centre|vignette|upright=2|Schéma fonctionnel de l'AMD Epyc.]]
|}

===Les interruptions inter-processeurs===

Les différents processeurs sont gérés par le système d'exploitation de l'ordinateur, avec l'aide d''''interruptions inter-processeurs''', des interruptions déclenchées sur un processeur et exécutées sur un autre, éventuellement par tous les autres pour certaines interruptions spécifiques. Pour générer des interruptions inter-processeur, le contrôleur d'interruption doit pouvoir rediriger des interruptions déclenchées par un processeur vers un autre.

Un exemple d'implémentation très simple est celui de la console Néo-géo, qui contenait deux processeurs. Le premier est un Motorola 68000 qui sert de processeur principal, l'autre est un Z80 qui sert de processeur dédié à l'audio. Le Z80 commande un synthétiseur sonore, et est relié à sa propre mémoire, distincte de la mémoire principale. Le MC68000 est le processeur principal et a une relation maitre-esclave avec le Z80 : le MC68000 envoie des interruptions au Z80, mais la communication ne va pas dans l'autre sens.

Les deux processeurs communiquent via l'intermédiaire d'un '''''IO arbiter chip''''', un circuit sur la carte mère connecté ua bus, qui gère les interruptions inter-processeur. Il contient un registre de 8 bits, dans lequel le MC68000 peut écrire dedans à sa guise, le registre étant adressable par le processeur. Les valeurs écrites dans ce registre sont des numéros d'interruption, qui indiquent quelle routine d'interruption exécuter. Lorsque le MC68000 écrit une valeur dedans, cela déclenche l’exécution automatique d'une interruption sur le Z80. Le code de 8 bits est envoyé au processeur Z80, en parallèle de l'interruption.

: Il est possible de voir ce ''IO arbiter chip'' comme un contrôleur d'interruptions spécialisé dans les interruptions inter-processeur.

Les anciens PC incorporaient sur leur carte mère un contrôleur d'interruption créé par Intel, le 8259A, qui ne gérait pas les interruptions inter-processeurs. Les cartes mères multiprocesseurs devaient incorporer un contrôleur spécial en complément. De nos jours, chaque cœur x86 possède son propre contrôleur d’interruption, le local APIC, qui gère les interruptions en provenance ou arrivant vers ce processeur. On trouve aussi un IO-APIC, qui gère les interruptions en provenance des périphériques et de les redistribuer vers les APIC locaux. L'IO-APIC gère aussi les interruptions inter-processeurs en faisant passer les interruptions d'un local APIC vers un autre. Tous les APIC locaux et l'IO-APIC sont reliés ensembles par un bus APIC spécialisé, par lequel ils vont pouvoir communiquer et s'échanger des demandes d'interruptions.

[[File:Contrôleurs d'interrptions sur systèmes x86 multicoeurs.png|centre|vignette|upright=1.5|Contrôleurs d’interruptions sur systèmes x86 multicœurs.]]

On peut préciser le processeur de destination en configurant certains registres du IO-APIC, afin que celui-ci redirige la demande d'interruption d'un local APIC vers celui sélectionné. Cela se fait avec l'aide d'un registre de 64 bits nommé l'''Interrupt Command Register''. Pour simplifier le mécanisme complet, chaque processeur se voit attribuer un Id au démarrage qui permet de l'identifier (en fait, cet Id est attribué au local APIC de chaque processeur). Certains bits de ce registre permettent de préciser quel est le type de transfert : doit-on envoyer l'interruption au processeur émetteur, à tous les autres processeurs, à un processeur particulier. Dans le dernier cas, certains bits du registre permettent de préciser l'Id du processeur qui va devoir recevoir l'interruption. À charge de l'APIC de faire ce qu'il faut en fonction du contenu de ce registre.

==Les processeurs multicœurs==

Puis, avec les progrès en matière de miniaturisation des processeurs, les fabricants ont eu l'idée d'utiliser les transistors qu'ils avaient pour fabriquer des '''processeurs multicœurs''', un terme que vous avez peut-être déjà entendu sans vraiment comprendre ce qu'il signifiait réellement. Les processeurs multicœurs peuvent être vus comme un regroupement de plusieurs processeurs sur la même puce de silicium.

Pour être plus précis, ils contiennent plusieurs ''cœurs'', chaque cœur pouvant exécuter un programme tout seul. Chaque cœur dispose de toute la machinerie électronique pour exécuter un programme, que ce soit un séquenceur d'instruction, des registres, une unité de calcul. Par contre, certains circuits d'un processeur ne sont présents qu'en un seul exemplaire dans un processeur multicœurs, comme les circuits de communication avec la mémoire ou les circuits d’interfaçage avec la carte mère. Suivant le nombre de cœurs présents dans notre processeur, celui-ci sera appelé un processeur double-cœur (deux cœurs), quadruple-cœur (4 cœurs), octuple-cœur (8 cœurs), etc. Ces processeurs sont devenus la norme dans les ordinateurs grand public et les logiciels et systèmes d'exploitation se sont adaptés.

Dans ce qui suit, nous utiliserons le terme cœurs pour désigner soit les cœurs d'un processeur multicœurs, soit les différents processeurs d'un ordinateur multiprocesseur. Tout le contenu de ce chapitre vaut aussi bien pour les systèmes multicœurs que multiprocesseur. Les différences entre les deux sont mineures, les deux font face aux mêmes problèmes, les mêmes solutions peuvent s'appliquer sur les deux types de systèmes.

===Le multicœurs symétrique ou asymétrique===

Dans la grosse majorité des cas, les cœurs d'un processeur multicœurs sont tous identiques. Mais ce n'est certainement pas une obligation et on peut très bien mettre plusieurs cœurs assez différents sur la même puce. On peut par exemple utiliser un cœur principal avec des cœurs plus spécialisés autour. Il faut ainsi distinguer le '''multicœurs symétrique''', dans lequel on place des processeurs identiques sur la même puce de silicium, du '''multicœurs asymétrique''' où les cœurs ne sont pas identiques.

Un exemple est celui du processeur CELL de la console de jeu PS3. Il intègre un cœur principal POWER PC v5 et 8 coeurs qui servent de processeurs auxiliaires. Le processeur principal est appelé le PPE et les processeurs auxiliaires sont les SPE. Les SPE sont reliés à une mémoire locale (''local store'') de 256 kibioctets qui communique avec le processeur principal via un bus spécial. Les SPE communiquent avec la RAM principale via des contrôleurs DMA. Les SPE possèdent des instructions permettant de commander leur contrôleur DMA et c'est le seul moyen qu'ils ont pour récupérer des informations depuis la mémoire. Et c'est au programmeur de gérer tout ça ! C'est le processeur principal qui va envoyer aux SPE les programmes qu'ils doivent exécuter. Il délègue des calculs aux SPE en écrivant dans le local store du SPE et en lui ordonnant l’exécution du programme qu'il vient d'écrire.

[[File:Schema Cell.png|centre|vignette|upright=2|Architecture du processeur CELL de la PS3. Le PPE est le processeur principal, les SPE sont des processeurs auxiliaires qui comprennent : un ''local store'' noté LS, un processeur noté SXU, et un contrôleur DMA pour échanger des informations avec la mémoire principale.]]

===Les architectures à cœurs conjoints===

Sur certains processeurs multicœurs, certains circuits sont partagés entre plusieurs cœurs. Typiquement, l'unité de calcul flottante est partagée entre deux coeurs/''threads'', les unités SIMD qu'on verra dans quelques chapitres sont aussi dans ce cas. Le partage de circuits permet d'éviter de dupliquer trop de circuits et donc d'économiser des transistors. Le problème est que ce partage est source de dépendances structurelles, ce qui peut entraîner des pertes de performances.

Cette technique consistant de partage d'unités de calcul entre coeurs s'appelle le '''cluster multithreading''', ou encore les '''architectures à cœurs conjoints''' (''Conjoined Core Architectures''). Elle est notamment utilisée sur les processeurs AMD de microarchitecture Bulldozer, incluant ses trois révisions ultérieures nommées Piledriver, Steamroller et Excavator. Un exemple est celui des processeurs AMD FX-8150 et FX-8120.

Sur ces processeurs, les instructions sont chargées dans deux files d'instructions séparées, une par ''thread'' matériel. Les instructions sont ensuite décodées par un décodeur unique et renommées dans une unité de renommage unique. Par la suite, il y a deux voies entières séparées et une voie flottante partagée. Chaque voie entière a sa propre fenêtre d'instruction entière, son tampon de ré-ordonnancement, ses unités de calcul dédiées, ses registres, sa ''load-store queue'', son cache L1. Par contre, la voie flottante partage les unités de calcul flottantes et n'a qu'une seule fenêtre d'instruction partagée par les deux ''threads''.

[[File:AMD Bulldozer microarchitecture.png|centre|vignette|upright=3|Microarchitecture Bulldozer d'AMD.]]

La révision Steamroller sépara le ''front-end'' en deux voies distinctes, une par ''thread''. Concrètement, elle ajouta un second décodeur d'instruction, une seconde file de micro-opération et une seconde unité de renommage de registres, afin d'améliorer les performances. Niveaux optimisations mineures, les stations de réservation ont été augmentées, elles peuvent mémoriser plus de micro-opérations, idem pour les bancs de registre et les files de lecture/écriture. Un cache de micro-opérations a été ajouté, de même que des optimisations quant au renommage de registre. Des ALU ont aussi été ajoutées, des FPU retirées.

[[File:AMD excavator microarchitecture.png|centre|vignette|upright=3|Microarchitecture Excavator d'AMD.]]

===Les architectures ''many core''===

Les architectures ''many core'' ont un très grand nombre de cœurs, plus d'une cinquantaine, voire plusieurs centaines ou milliers. La différence est surtout une question de degré, mais aussi de but recherché.

Les architectures multicœurs sont surtout conçues pour les ordinateurs personnels, éventuellement les serveurs. Elles recherchent un bon compromis entre un grand nombre de cœurs, et une bonne performance pour les programmes non-parallèles. En clair, elles évitent de sacrifier les performances pour les applications non-parallèles, ce qui fait que leurs cœurs sont généralement très puissants, avec beaucoup d'optimisations micro-architecturales.

Les architectures ''many core'' font le compromis inverse : elles ont beaucoup de cœurs, mais ceux-ci ne sont pas très puissants, surtout pour les applications non-parallèles. Les cœurs des architectures ''many core'' sont généralement des cœurs sans exécution dans le désordre, sans prédiction de branchements, sans renommage de registres, voire sans pipeline ni parallélisme d'instruction.

==Le partage des caches==

Quand on conçoit un processeur multicœur, il ne faut pas oublier ce qui arrive à la pièce maîtresse de tout processeur actuel : le cache ! Pour le moment nous allons oublier le fait que les processeurs ont une hiérarchie de caches, avec des caches L1, L2, L3 et autres. Nous allons partir du principe qu'un processeur simple cœur a un seul cache, et voir comment adapter le cache à la présence de plusieurs cœurs. Nous allons rapidement lever cette hypothèse, pour étudier le cas où un processeur multicœur a une hiérarchie de caches, mais seulement après avoir vu le cas le plus simple à un seul cache.

===Le partage des caches sans hiérarchie de caches : caches dédiés et partagés===

Avec un seul niveau de cache, sans hiérarchie, deux solutions sont possibles. La première consiste à garder un seul cache, et de le partager entre les cœurs. L'autre solution est de dupliquer le cache et d'utiliser un cache par cœur. Les deux solutions sont appelées différemment. On parle de '''caches dédiés''' si chaque cœur possède son propre cache, et de '''cache partagé''' avec un cache partagé entre tous les cœurs. Ces deux méthodes ont des inconvénients et des avantages.

{|
|[[File:Caches dédiés.png|vignette|Caches dédiés]]
|[[File:Caches partagés.png|vignette|Cache partagé]]
|}

Le premier point sur lequel comparer caches dédiés et partagés est celui de la capacité du cache. La quantité de mémoire cache que l'on peut placer dans un processeur est limitée, car le cache prend beaucoup de place, près de la moitié des circuits du processeur. Aussi, un processeur incorpore une certaine quantité de mémoire cache, qu'il faut répartir entre un ou plusieurs caches. Les caches dédiés et partagés ne donnent pas le même résultat. D'un côté, le cache partagé fait que toute la mémoire cache est dédiée au cache partagé, qui est très gros. De l'autre, on doit répartir la capacité du cache entre plusieurs caches séparés, individuellement plus petits. En conséquence, on a le choix entre un petit cache pour chaque processeur ou un gros cache partagé.

Le choix entre les deux n'est pas simple, mais doit tenir compte du fait que les programmes exécutés sur les cœurs n'ont pas les mêmes besoins. Certains programmes sont plus gourmands et demandent beaucoup de cache, alors que d'autres utilisent peu la mémoire cache. Avec un cache dédié, tous les programmes ont accès à la même quantité de cache, car les caches des différents cœurs sont de la même taille. Les caches dédiés étant assez petits, les programmes plus gourmands devront se débrouiller avec un petit cache, alors que les autres programmes auront du cache en trop. A l'opposé, un cache partagé répartit le cache de manière optimale : un programme gourmand peut utiliser autant de cache qu'il veut, laissant juste ce qu'il faut aux programmes moins gourmands. le cache peut être répartit plus facilement selon les besoins des différents programmes.

[[File:Cache partagé contre cache dédié.png|centre|vignette|upright=2.5|Cache partagé contre cache dédié]]

Un autre avantage des caches partagés est quand plusieurs cœurs accèdent aux même données. C'est un cas très courant, souvent lié à l'usage de mémoire partagé ou de ''threads''. Avec des caches dédiés, chaque cœur a une copie des données partagées. Mais avec un cache partagé, il n'y a qu'une seule copie de chaque donnée, ce qui utilise moins de mémoire cache. Imaginons que l'on sait 8 caches dédiés de 8 Kibioctets, soit 64 kibioctets au total, comparé à un cache partagé de même capacité totale. Les doublons dans les caches dédiés réduiront la capacité mémoire utile, effective, comparé à un cache partagé. S'il y a 1 Kibioctet de mémoire partagé, 8 kibioctets seront utilisés pour stocker ces données en doublons, seulement 1 kibioctet sur un cache partagé. Ajoutons aussi que la cohérence des caches est grandement simplifiée avec l'usage d'un cache partagé, vu que les données ne sont pas dupliquées dans plusieurs caches.

Mais le partage du cache peut se transformer en inconvénient si les programmes entrent en compétition pour le cache, que ce soit pour y placer des données ou pour les accès mémoire. Deux programmes peuvent vouloir accéder au cache en même temps, voire carrément se marcher sur les pieds. La résolution des conflits d'accès au cache est résolu soit en prenant un cache multiport, avec un port dédié par cœur, soit par des mécanismes d'arbitrages avec des circuits dédiés. Le revers de la médaille tient au temps de latence. Plus un cache est gros, plus il est lent. En conséquence, des caches dédiés seront plus rapides qu'un  gros cache partagé plus lent.

===Le partage des caches adapté à une hiérarchie de caches===

Dans la réalité, un processeur multicœur ne contient pas qu'un seul cache, mais une hiérarchie de caches avec des caches L1, L2 et L3, parfois L4. Dans cette hiérarchie, certains caches sont partagés entre plusieurs cœurs, les autres sont dédiés. Le cache L1 n'est jamais partagé, car il doit avoir un temps d'accès très faible. Pour les autres caches, tout dépend du processeur.

[[File:Dual Core Generic.svg|vignette|Cache L2 partagé.]]

Les premiers processeurs multicœurs commerciaux utilisaient deux niveaux de cache : des caches L1 dédiés et un cache L2 partagé. Le cache L2 partagé était relié aux caches L1, grâce à un système assez complexe d'interconnexions. Le cache de niveau L2 était souvent simple port, car les caches L1 se chargent de filtrer les accès aux caches de niveau inférieurs.

Les processeurs multicœurs modernes ont des caches L3 et même L4, de grande capacité, ce qui a modifié le partage des caches. Le cache le plus proche de la mémoire, le cache de dernier niveau L3 ou L4, est systématiquement partagé, car son rôle est d'être un cache lent mais gros. Le cas du cache L2 dépend des architectures : il est partagé sur certains processeurs, dédié sur d'autres.

Dans le cas le plus courant, il y a plusieurs caches L2 qui sont chacun partagés entre plusieurs cœurs mais pas à tous. En effet, on peut limiter le partage du cache à quelques cœurs particuliers pour des raisons de performances.

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2.0|Partage des caches sur un processeur multicœur.]]

D'autres processeurs ont des caches L2 dédiés. Il s'agit surtout des processeurs multicœurs anciens, parmi les premières générations de processeurs multicœurs. Un exemple est celui de la microarchitecture Nehalem d'Intel. Il avait des caches L1 et L2 dédiés, mais un cache L3 partagé.

[[File:Nehalem EP.png|centre|vignette|upright=2.0|Partage des caches sur un processeur Intel d'architecture Nehalem.]]

===Les caches partagés centralisés et distribués===

Un point important est que quand on parle de cache partagé ou de cache dédié, on ne parle que de la manière dont les cœurs peuvent accéder au cache, pas de la manière dont le caches est réellement localisé sur la puce. En théorie, qui dit plusieurs caches dédiés signifie que l'on a vraiment plusieurs caches séparés sur la puce. Et chaque cache dédié est proche du cœur qui lui est attribué. Et pour les caches partagés unique, une portion de la puce de silicium contient le cache, que cette portion est un énorme bloc de transistors. Il est généralement placé au milieu de la puce ou sur un côté, histoire de facilement le connecter à tous les cœurs.

Mais pour les caches séparés, ce n'est pas toujours le cas. Avoir un cache énorme poserait des problèmes sur les architectures avec beaucoup de cœurs. En réalité, le cache est souvent découpé en plusieurs banques, reliées à un contrôleur du cache par un système d'interconnexion assez complexe. Les banques sont physiquement séparées, et il arrive qu'elles soient placées proche d'un cœur chacune. L'organisation des banques ressemble beaucoup à l'organisation des caches dédiés, avec une banque étant l'équivalent d'un cache dédié. La différence est que les cœurs peuvent lire et écrire dans toutes les banques, grâce au système d'interconnexion et au contrôleur de cache.

Tel était le cas sur les processeurs AMD Jaguar. Ils avaient un cache L2 de 2 mébioctets, partagés entre tous les cœurs, qui était composé de 4 banques de 512 Kibioctets. Les quatre banques du cache étaient reliées aux 4 cœurs par un réseaux d'interconnexion assez complexe.

[[File:AMDJaguarModule.png|centre|vignette|upright=2|AMD Jaguar Module]]

La différence entre les deux solutions pour les caches partagés porte le nom de cache centralisés versus distribués. Un gros cache unique sur la puce est un '''cache centralisé''', et c'est généralement un cache partagé. Mais un cache composé de plusieurs banques dispersées sur la puce est un '''cache distribué''', qui peut être aussi bien dédié que partagé.

===Les caches virtualisés===

Il faut noter que quelques processeurs utilisent cette technique pour fusionnent le cache L2 et le cache L3. Par exemple, les processeurs IBM Telum utilisent des caches L3 virtualisés, dans leurs versions récentes. Le processeur Telum 2 contient 10 caches L2 de 36 mébioctets chacun, soit 360 mébioctets de cache. L'idée est que ces 360 mébioctets sont partagés à la demande entre cache L2 dédié et cache L3. On parle alors de '''cache virtualisé'''.

Un cache de 36 mébioctet est associé à un cœur, auquel il est directement relié. Les cœurs n'utilisent pas tous leur cache dédié à 100% Il arrive que des cœurs aient des caches partiellement vides, alors que d'autres on un cache qui déborde. L'idée est que si un cœur a un cache plein, les données évincées du cache L2 privé sont déplacées dans le cache L2 d'un autre cœur, qui lui est partiellement vide. Le cache L2 en question est alors partitionné en deux : une portion pour les données associée à son cœur, une portion pour les données des L2 des autres cœurs. 

Pour que la technique fonctionne, le processeur mesure le remplissage de chaque cache L2. De plus, il faut gérer la politique de remplacement des lignes de cache. Une ligne de cache évincée du cache doit être déplacé dans un autre L2, pas dans les niveaux de cache inférieur, ni dans la mémoire. Du moins, tant qu'il reste de la place dans le cache L3. De plus, une lecture/écriture dans le cache L3 demande de localiser le cache L2 contenant la donnée. Pour cela, les caches L2 sont tous consultés lors d'un accès au L3, c'est la solution la plus simple, elle marche très bien si le taux de défaut du cache L2 est faible.

Une telle optimisation ressemble beaucoup à un cache L2/L3 distribué, mais il y a quelques différences qui sont décrites dans le paragraphe précédent. Avec un L2 distribué, tout accès au L2 déclencherait une consultation de toutes les banques du L2. Avec un cache L3 virtualisé, ce n'est pas le cas. Le cache L2 associé au cœur est consulté, et c'est seulement en cas de défaut de cache que les autres caches L2 sont consultés. De plus, avec un cache L2 distribué, il n'y a pas de déplacement d'une ligne de cache entre deux banques, entre deux caches L2 physiques. Alors qu'avec un cache L3 virtualisé, c'est le cas en cas de remplacement d'une ligne de cache dans le cache L2.

Sur le processeur Telum 1, le partage du cache L2 est assez simple. Un cache L2 fait 32 mébioctets et est découpé en deux banques de 16 mébioctets. En temps normal, les premiers 16 mébioctets sont toujours associé au cache L2, au cœur associé. Les 16 mébioctets restants peuvent soit être attribués au cache L3, soit fusionnés avec les 16 premiers mébioctets. Dans le cas où le cœur associé est en veille, n'est absolument pas utilisé, les 32 mébioctets sont attribués au cache L3. Un partage assez simple, donc. Le partage du cache L2/L3 sur les processeurs Telum 2 n'est pas connu, il est supposé être plus flexible.

==Le réseau d'interconnexion entre cœurs==

Les CPU multicœurs connectent plusieurs cœurs entre eux, tout comme les systèmes multi-processeurs connectent plusieurs processeurs entre eux. Mais les transferts de données entre cœurs se font par l'intermédiaire des caches, ce qui fait que l'implémentation est différente de celle utilisée sur les systèmes multi-processeurs. Les standards pour les interconnexions entre coeurs sont assez proches de ceux utilisés pour interconnecter des processeurs, mais les standards utilisés ne sont pas les mêmes en pratique. Là encore, les cœurs sont connectés entre eux soit par un bus, soit par un réseau d'interconnexion.

===Le bus partagé entre plusieurs cœurs===

Une solution simple relie les cœurs entre eux grâce à un '''bus partagé'''. Le cas le plus simple est celui où chaque cœur dispose de caches dédiés, qui sont alors tous reliés au bus mémoire, qui sert d'intermédiaire. Mais l'idée doit être adaptée sur les processeurs multicœurs avec des caches partagés. Voyons d'abord le cas d'un CPU avec deux niveaux de cache, dont un cache L2 est partagé entre tous les cœurs. Les caches L1 sont reliés au cache L2 partagé par un bus, qui n'a souvent pas de nom. Nous désignerons le bus entre le cache L1 et le cache L2 : '''bus partagé''', sous-entendu partagé entre tous les caches. C'est lui qui sert à connecter les cœurs entre eux.

[[File:Architecture multicoeurs à bus partagé entre caches L1 et L2.png|centre|vignette|upright=2|Architecture multicoeurs à bus partagé entre caches L1 et L2]]

Un processeur multicœur typique a une architecture avec trois niveaux de cache (L1, L2 et L3), avec un niveau L1 dédié par cœur, un niveau L2 partiellement partagé et un L3 totalement partagé. Le bus partagé est alors difficile à décrire, mais il correspond à l'ensemble des bus qui connectent les caches L1 aux caches L2, et les caches L2 au cache L3. Il s'agit alors d'un ensemble de bus, plus que d'un bus partagé unique.

===Le réseau d'interconnexion entre plusieurs cœurs===

Relier plusieurs cœurs avec des bus pose de nombreux problèmes techniques qui sont d'autant plus problématiques que le nombre de cœurs augmente. Le câblage est notamment très complexe, les contraintes électriques pour la transmission des signaux sont beaucoup plus fortes, les problèmes d'arbitrages se font plus fréquents, etc. Pour régler ces problèmes, les processeurs multicoeurs n'utilisent pas de bus partagé, mais un réseau d'interconnexion plus complexe.

Le réseau d'interconnexion peut être très complexe, avec des connexions réseau, des commutateurs, et des protocoles d'échanges entre processeurs assez complexes basés sur du passage de messages. De telles puces utilisent un '''réseau sur puce''' (''network on chip''). Mais d'autres simplifient le réseau d'interconnexion, qui se résume à un réseau ''crossbar'', voire à des mémoires FIFO pour faire l'interface entre les cœurs.

Le problème principal des réseaux sur puce est que les mémoires FIFOs sont difficiles à implémenter sur une puce de silicium. Elles prennent beaucoup de place, utilisent beaucoup de portes logiques, consomment beaucoup d'énergie, sont difficiles à concevoir pour diverses raisons (les accès concurrents/simultanés sont fréquents et font mauvais ménage avec les ''timings'' serrés de quelques cycles d'horloges requis). Il est donc impossible de placer beaucoup de mémoires FIFO dans un processeur, ce qui fait que les commutateur sont réduits à leur strict minimum : un réseau d'interconnexion, un système d'arbitrage simple parfois sans aucune FIFO, guère plus.

===Les architectures en ''tile''===

Un cas particulier de réseau sur puce est celui des '''architectures en ''tile''''', des architectures avec un grand nombre de cœurs, connectés les unes aux autres par un réseau d'interconnexion &quot;rectangulaire&quot;. Chaque cœur est associé à un commutateur (''switch'') qui le connecte au réseau d'interconnexion, l'ensemble formant une ''tile''.

[[File:Tile64-Tile.svg|centre|vignette|upright=1.5|''Tile'' de base du Tile64.]]

Le réseau est souvent organisé en tableau, chaque ''tile'' étant connectée à plusieurs voisines. Dans le cas le plus fréquent, chaque ''tile'' est connectée à quatre voisines : celle du dessus, celle du dessous, celle de gauche et celle de droite. Précisons que cette architecture n'est pas une architecture distribuée dont tous les processeurs seraient placés sur la même puce de silicium. En effet, la comparaison ne marche pas pour ce qui est de la mémoire : tous les cœurs accèdent à une mémoire partagée située en dehors de la puce de silicium. Le réseau ne connecte pas plusieurs ordinateurs séparés avec chacun leur propre mémoire, mais plusieurs cœurs qui accèdent à une mémoire partagée.

Un bon exemple d'architecture en ''tile'' serait les déclinaisons de l'architecture Tilera. Les schémas du-dessous montrent l'architecture du processeur Tile 64. Outre les ''tiles'', qui sont les éléments de calcul de l'architecture, on trouve plusieurs contrôleurs mémoire DDR, divers interfaces réseau, des interfaces série et parallèles, et d'autres entrées-sorties.

[[File:Tile64.svg|centre|vignette|upright=2|Architecture Tile64 du Tilera.]]

&lt;noinclude&gt;
{{NavChapitre | book=Fonctionnement d'un ordinateur
           | prev=Les architectures parallèles
           | prevText=Les architectures parallèles
           | next=Architectures multithreadées et Hyperthreading
           | nextText=Architectures multithreadées et Hyperthreading
}}
&lt;/noinclude&gt;</text>
      <sha1>10s3ozo1om3pbahbky7e4hz3poy6k1u</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/Sommaire</title>
    <ns>0</ns>
    <id>69360</id>
    <revision>
      <id>745378</id>
      <parentid>733626</parentid>
      <timestamp>2025-06-26T12:26:31Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745378</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1673" sha1="ryxzfx9z9he87jqs2429ga4rw9q93cv" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]


[[Mathc complexes/Introduction|Introduction]]
----
----
'''Quelques sujets abordés :''' (voir la [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX '''Playlist'''])
----
'''[[Mathc complexes/a277| Matrices pour les Transformations de Fourier Discrètes]].'''  

[[Mathc complexes/a24| Déterminant]]. '''[[Mathc complexes/a207| Produit en croix]].''' [[Mathc complexes/a25| L'Inverse par le Déterminant]].

'''[[Mathc_complexes/a27| Résoudre un Système d'Équations]].''' [[Mathc_complexes/a35| Variables Libres]]. [[Mathc complexes/053| '''Analyse d'un réseau''' (avec des coefficients '''Réelles''')  ]]. '''[[Mathc complexes/a26| Les Bases]].''' [[Mathc complexes/a245| Projections sur un Sous-Espace Vectoriel]].

[[Mathc_complexes/a19| Produit Scalaire]]. '''[[Mathc complexes/a297|La QR décomposition]].''' [[Mathc_complexes/a326| Les Vecteurs propres dans '''C''']]. [[Mathc complexes/04k| Les Vecteurs propres dans '''R''']]. '''[[Mathc_complexes/a115| Fonctions matricielles]].''' [[Mathc_complexes/a115| Décomposition polaire]]. '''[[Mathc_complexes/a64| Décomposition par les Vecteurs X ]].'''  [[Mathc complexes/a329| Pseudo Inverse Gauche]]. '''[[Mathc complexes/a329| Pseudo Inverse Droit]].''' [[Mathc_complexes/a18| Trois algorithmes pour le pseudo inverse gauche]]. 
----
----
{{Partie{{{type|}}}|[[Mathc complexes/a29| '''La bibliothèque.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/h08a| '''Propriétés et Applications.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/a202| '''Octave.''']]}}
----
{{Lien modifier|Mathc complexes/Sommaire|modifier le sommaire}}

{{AutoCat}}</text>
      <sha1>ryxzfx9z9he87jqs2429ga4rw9q93cv</sha1>
    </revision>
    <revision>
      <id>745379</id>
      <parentid>745378</parentid>
      <timestamp>2025-06-26T12:28:23Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745379</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1675" sha1="ajczze2pgelxpppn5r2404kcnrs8o85" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]


[[Mathc complexes/Introduction|Introduction]]
----
----
'''Quelques sujets abordés :''' (voir la [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX '''Playlist'''])
----
'''[[Mathc complexes/a277| Matrices pour les Transformations de Fourier Discrètes]].'''  

[[Mathc complexes/a24| Déterminant]]. '''[[Mathc complexes/a207| Produit en croix]].''' [[Mathc complexes/a25| L'Inverse par le Déterminant]].

'''[[Mathc_complexes/a27| Résoudre un Système d'Équations]].''' [[Mathc_complexes/a35| Variables Libres]]. [[Mathc complexes/053| '''Analyse d'un réseau''' (avec des coefficients '''Réelles''')  ]]. '''[[Mathc complexes/a26| Les Bases]].''' [[Mathc complexes/a245| Projections sur un Sous-Espace Vectoriel]].

[[Mathc_complexes/a19| Produit Scalaire]]. '''[[Mathc complexes/a297|La QR décomposition]].''' [[Mathc_complexes/a326| Les Vecteurs propres dans '''C''']]. [[Mathc complexes/04k| Les Vecteurs propres dans '''R''']]. '''[[Mathc_complexes/a115| Fonctions matricielles]].''' [[Mathc_complexes/a115| Décomposition polaire]]. 

'''[[Mathc_complexes/a64| Décomposition par les Vecteurs X ]].'''  [[Mathc complexes/a329| Pseudo Inverse Gauche]]. '''[[Mathc complexes/a329| Pseudo Inverse Droit]].''' [[Mathc_complexes/a18| Trois algorithmes pour le pseudo inverse gauche]]. 
----
----
{{Partie{{{type|}}}|[[Mathc complexes/a29| '''La bibliothèque.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/h08a| '''Propriétés et Applications.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/a202| '''Octave.''']]}}
----
{{Lien modifier|Mathc complexes/Sommaire|modifier le sommaire}}

{{AutoCat}}</text>
      <sha1>ajczze2pgelxpppn5r2404kcnrs8o85</sha1>
    </revision>
    <revision>
      <id>745402</id>
      <parentid>745379</parentid>
      <timestamp>2025-06-26T15:36:21Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745402</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1761" sha1="r63ur36asw7u6bamzlx4nfye5lab7mr" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]


[[Mathc complexes/Introduction|Introduction]]
----
----
'''Quelques sujets abordés :''' (voir la [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX '''Playlist'''])
----
'''[[Mathc complexes/a277| Matrices pour les Transformations de Fourier Discrètes]].'''  

[[Mathc complexes/a24| Déterminant]]. '''[[Mathc complexes/a207| Produit en croix]].''' [[Mathc complexes/a25| L'Inverse par le Déterminant]].

'''[[Mathc_complexes/a27| Résoudre un Système d'Équations]].''' [[Mathc_complexes/a35| Variables Libres]]. [[Mathc complexes/053| '''Analyse d'un réseau''' (Coefficients '''Réelles''')  ]]. [[Mathc complexes/05a| Analyse d'un circuit '''électrique''' (Coefficients '''Réelles''')]]. '''[[Mathc complexes/a26| Les Bases]].''' [[Mathc complexes/a245| Projections sur un Sous-Espace Vectoriel]].

[[Mathc_complexes/a19| Produit Scalaire]]. '''[[Mathc complexes/a297|La QR décomposition]].''' [[Mathc_complexes/a326| Les Vecteurs propres dans '''C''']]. [[Mathc complexes/04k| Les Vecteurs propres dans '''R''']]. '''[[Mathc_complexes/a115| Fonctions matricielles]].''' [[Mathc_complexes/a115| Décomposition polaire]]. 

'''[[Mathc_complexes/a64| Décomposition par les Vecteurs X ]].'''  [[Mathc complexes/a329| Pseudo Inverse Gauche]]. '''[[Mathc complexes/a329| Pseudo Inverse Droit]].''' [[Mathc_complexes/a18| Trois algorithmes pour le pseudo inverse gauche]]. 
----
----
{{Partie{{{type|}}}|[[Mathc complexes/a29| '''La bibliothèque.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/h08a| '''Propriétés et Applications.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/a202| '''Octave.''']]}}
----
{{Lien modifier|Mathc complexes/Sommaire|modifier le sommaire}}

{{AutoCat}}</text>
      <sha1>r63ur36asw7u6bamzlx4nfye5lab7mr</sha1>
    </revision>
    <revision>
      <id>745403</id>
      <parentid>745402</parentid>
      <timestamp>2025-06-26T15:37:51Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745403</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1735" sha1="fwh1mgpeyxtr46wz09juhzzj9gtvpir" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]


[[Mathc complexes/Introduction|Introduction]]
----
----
'''Quelques sujets abordés :''' (voir la [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX '''Playlist'''])
----
'''[[Mathc complexes/a277| Matrices pour les Transformations de Fourier Discrètes]].'''  

[[Mathc complexes/a24| Déterminant]]. '''[[Mathc complexes/a207| Produit en croix]].''' [[Mathc complexes/a25| L'Inverse par le Déterminant]].

'''[[Mathc_complexes/a27| Résoudre un Système d'Équations]].''' [[Mathc_complexes/a35| Variables Libres]]. [[Mathc complexes/053| '''Analyse d'un réseau''' (Dans '''ℝ''')  ]]. [[Mathc complexes/05a| Analyse d'un circuit '''électrique''' (Dans '''ℝ''')]]. '''[[Mathc complexes/a26| Les Bases]].''' [[Mathc complexes/a245| Projections sur un Sous-Espace Vectoriel]].

[[Mathc_complexes/a19| Produit Scalaire]]. '''[[Mathc complexes/a297|La QR décomposition]].''' [[Mathc_complexes/a326| Les Vecteurs propres dans '''C''']]. [[Mathc complexes/04k| Les Vecteurs propres dans '''R''']]. '''[[Mathc_complexes/a115| Fonctions matricielles]].''' [[Mathc_complexes/a115| Décomposition polaire]]. 

'''[[Mathc_complexes/a64| Décomposition par les Vecteurs X ]].'''  [[Mathc complexes/a329| Pseudo Inverse Gauche]]. '''[[Mathc complexes/a329| Pseudo Inverse Droit]].''' [[Mathc_complexes/a18| Trois algorithmes pour le pseudo inverse gauche]]. 
----
----
{{Partie{{{type|}}}|[[Mathc complexes/a29| '''La bibliothèque.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/h08a| '''Propriétés et Applications.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/a202| '''Octave.''']]}}
----
{{Lien modifier|Mathc complexes/Sommaire|modifier le sommaire}}

{{AutoCat}}</text>
      <sha1>fwh1mgpeyxtr46wz09juhzzj9gtvpir</sha1>
    </revision>
    <revision>
      <id>745404</id>
      <parentid>745403</parentid>
      <timestamp>2025-06-26T15:39:18Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745404</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1721" sha1="k10zu3g9osywjrrv7fjt0habiibo31q" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]


[[Mathc complexes/Introduction|Introduction]]
----
----
'''Quelques sujets abordés :''' (voir la [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX '''Playlist'''])
----
'''[[Mathc complexes/a277| Matrices pour les Transformations de Fourier Discrètes]].'''  

[[Mathc complexes/a24| Déterminant]]. '''[[Mathc complexes/a207| Produit en croix]].''' [[Mathc complexes/a25| L'Inverse par le Déterminant]].

'''[[Mathc_complexes/a27| Résoudre un Système d'Équations]].''' [[Mathc_complexes/a35| Variables Libres]]. [[Mathc complexes/053| '''Analyse d'un réseau''' dans '''ℝ''']]. [[Mathc complexes/05a| Analyse d'un circuit '''électrique''' dans '''ℝ''']]. '''[[Mathc complexes/a26| Les Bases]].''' [[Mathc complexes/a245| Projections sur un Sous-Espace Vectoriel]].

[[Mathc_complexes/a19| Produit Scalaire]]. '''[[Mathc complexes/a297|La QR décomposition]].''' [[Mathc_complexes/a326| Vecteurs propres dans '''C''']]. [[Mathc complexes/04k| Vecteurs propres dans '''R''']]. '''[[Mathc_complexes/a115| Fonctions matricielles]].''' [[Mathc_complexes/a115| Décomposition polaire]]. 

'''[[Mathc_complexes/a64| Décomposition par les Vecteurs X ]].'''  [[Mathc complexes/a329| Pseudo Inverse Gauche]]. '''[[Mathc complexes/a329| Pseudo Inverse Droit]].''' [[Mathc_complexes/a18| Trois algorithmes pour le pseudo inverse gauche]]. 
----
----
{{Partie{{{type|}}}|[[Mathc complexes/a29| '''La bibliothèque.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/h08a| '''Propriétés et Applications.''']]}}

{{Partie{{{type|}}}|[[Mathc complexes/a202| '''Octave.''']]}}
----
{{Lien modifier|Mathc complexes/Sommaire|modifier le sommaire}}

{{AutoCat}}</text>
      <sha1>k10zu3g9osywjrrv7fjt0habiibo31q</sha1>
    </revision>
  </page>
  <page>
    <title>Les cartes graphiques/La hiérarchie mémoire d'un GPU</title>
    <ns>0</ns>
    <id>74269</id>
    <revision>
      <id>745380</id>
      <parentid>745292</parentid>
      <timestamp>2025-06-26T12:55:37Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les caches généralistes */</comment>
      <origin>745380</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22520" sha1="fazh0fld0swwawqobhv6uw53h939qob" xml:space="preserve">Dans ce chapitre, nous allons voir comment est organisée la mémoire d'un GPU, ou plutôt devrait-on dire les mémoires d'un GPU. Eh oui : un GPU contient beaucoup de mémoires différentes. La hiérarchie mémoire des GPUs est assez particulière, que ce soit au niveau des caches ou de la mémoire, parfois des registres. Un GPU contient évidemment une mémoire vidéo, de grande taille, capable de stocker textures, vertices, images et bien d'autres choses nécessaires pour un rendu 3D. On y trouve souvent des mémoires caches dédiées aux textures ou aux vertices.

Les GPUs récents contiennent aussi des caches tout court qui ne sont spécialisés dans les textures ou vertices. De plus, les caches sont complétés par des ''Local Store'', des mémoires normales de petite taille. Elles sont gérés par le logiciel, le programmeur, alors que les caches sont gérés par des circuits de contrôle qui s'occupent du chargement ou de l'éviction des données du cache. Elles servent donc de cache géré par le logiciel, si on peut dire. Un GPU moderne dispose de plusieurs ''local store'' : au moins par cœur.

==La mémoire vidéo==

La mémoire vidéo d'une carte graphique dédiée est nécessaire pour stocker l'image à afficher à l'écran, mais aussi pour mémoriser temporairement des informations importantes. Dans le cas le plus simple, elle sert simplement de ''Framebuffer'' : elle stocke l'image à afficher à l'écran. Au fil du temps, elle s'est vu ajouter d'autres fonctions, comme stocker les textures et les sommets de l'image à calculer, ainsi que divers résultats temporaires.

===Les spécificités des RAM des cartes vidéo dédiées===

Sur les cartes graphiques dédiées, la mémoire vidéo est très proche des mémoires RAM qu'on trouve sous forme de barrettes dans nos PC, à quelques différences près. Le point le plus important est que la mémoire vidéo d'une carte dédiée n'est pas présente sous la forme de barrettes de mémoire. À la place, les puces de mémoire sont soudées sur la puce. La conséquence est que l'on ne peut pas upgrader la RAM d'une carte vidéo. Ce serait sympathique, mais ne serait pas d'une grande utilité, car les jeux vidéos gourmands en mémoire vidéo sont aussi gourmands en puissance de calcul. Upgrader la RAM d'une carte graphique ne sert à rien si celle-ci n'a pas assez de puissance pour jouer à des jeux récents avec un framerate convenable.

Le fait que la mémoire est soudée simplifie la conception de la carte graphique, mais cela a des avantages au niveau électrique, qui permettent d'améliorer les performances. Niveau performances, la mémoire vidéo a des performances radicalement différentes de la RAM des PC. Elle a un temps d'accès très long, de plusieurs centaines de cycles d'horloge. Cela a des conséquences sur l'architecture de la carte graphique, notamment au niveau des processeurs de ''shaders'', qui sont conçus pour gérer ces temps d'accès long, comme on l'a vu dans le précédent chapitre. Par contre, elle a un très grand débit, autrement dit une bande passante élevée, proche de la centaine de gigaoctets par secondes sur les cartes graphiques modernes. Pour rappel, la bande passante d'une mémoire dépend de deux paramètres : sa fréquence et la largueur de son bus mémoire. Détaillons le dernier, qui explique en grande partie pourquoi la mémoire vidéo a un débit supérieur à la mémoire système.

===Le bus mémoire et sa largeur===

Le bus mémoire est ce qui connecte la mémoire au reste de la carte graphique. La largueur de ce bus n'est autre que la quantité de données que celui-ci peut transmettre à chaque cycle d'horloge, le nombre de bits que l'on peut lire/écrire en un cycle d'horloge. Sur la RAM système, le bus est de 64 bits sur les mémoires DDR modernes, mais peut monter à 128 bits en utilisant des techniques comme le ''dual channel'', voire en 192/256 bits avec des techniques de ''triple/quad channel'' qui sont rarement utilisées. Globalement, la configuration classique sur un PC moderne est 128 bits, avec quelques machines bas de gamme en 64 bits. Sur les cartes graphiques modernes, les bus de 128 bits ou moins sont utilisés sur les cartes graphiques de faible performance, le reste ayant un bus mémoire de 192, 256, 384, voire 512 bits. En clair, elles permettent de lire/écrire plus de données par cycle d'horloge qu'une RAM système, de 2 à 8 fois plus.

Le fait que le bus est plus large est lié au fait que les puces mémoires sont soudées. La mémoire vidéo des cartes dédiées est composée de pleins de puces mémoires accessibles en parallèle, ce qui permet de charger des blocs de plusieurs centaines d'octets en une seule fois. Les barrettes de mémoire ont des limites au nombres de broches que leur connecteur peut accepter, qui est proche de 300 pour les DDR actuelles (beaucoup de ces broches ne transfèrent pas des données, ce qui fait qu'on a bien 64 broches dédiées aux données seulement). Sans connecteurs, on est limité à ce que la puce du GPU peut accepter, et on est alors entre 4000 à 6000 broches sur les sockets de CPU ou de GPU actuels.

[[File:Puces mémories d'un GPU et d'une barrette de mémoire.png|centre|vignette|upright=2|Puces mémoires d'un GPU et d'une barrette de mémoire.]]

Pour résumer, sur les cartes graphiques dédiées, la RAM vidéo a un débit proche de la centaine de gigaoctets par secondes. Avec une mémoire RAM unifiée, vous pouvez facilement diviser cette estimation par 10.

===La mémoire vidéo est très lente===

La mémoire vidéo a donc un débit très élevé. Mais par contre, elle a un temps d'accès très lent. Concrètement, cela veut dire qu'un accès mémoire va prendre beaucoup de temps. Par exemple, si je veux lire une texture, entre le moment où j'envoie une demande de lecture à la mémoire vidéo, et le moment celle-ci me renvoie les premiers texels, il va se passer entre 200 à 1000 cycles d'horloge processeur. Par contre, une fois les premiers texels reçus, les texels suivants sont disponibles au cycle suivant, et ainsi de suite. En clair, les données lues mettent du temps avant d'arriver, mais elles arrivent par gros paquets une fois ce temps d'attente passé.

La différence entre débit et temps d'accès est primordiale sur les GPU modernes comme anciens. Toute l'architecture de la carte graphique est conçue de manière à prendre en compte ce temps d'attente. Les techniques employées sont multiples, et ne sont pas inconnues à ceux qui ont déjà lu un cours d'architecture des ordinateurs : mémoire caches, hiérarchie de caches, ''multithreading'' matériel au niveau du processeur, optimisations des accès mémoire comme des ''Load-Store Queues'' larges, des ''coalesing write buffers'', etc. Mais toutes ces techniques sont techniquement incorporées dans les processeurs de ''shaders'' et dans les circuits fixes. Aussi nous ne pouvons pas en parler dans ce chapitre. A une exception près : l'usage de caches et de ''local stores''.

==Les caches d'un GPU==

Les cartes graphiques sont censées avoir peu de caches. Les anciennes cartes graphiques se débrouillaient avec des caches spécialisés pour les textures ou pour les sommets, ce qui leur vaut les noms de caches de texture et de cache de sommets. Ce n'est que par la suite, quand les GPU commencèrent à être utilisés pour du calcul généraliste (scientifique, notamment), que la situation changea. Les GPU utilisèrent alors de plus en plus de caches généralistes, capables de stocker n'importe quelle forme de données.

Les caches en question sont intégrés dans les processeurs de ''shaders'' sur les GPU modernes. Même les caches de texture ou de sommets. Les deux sont d'ailleurs fusionnés sur les GPU modernes, vu que leur jeu d'instruction est unifié et qu'ils peuvent exécuter aussi bien des ''vertex shaders'' que des ''pixel shaders''. Sur les GPU plus anciens, avec des circuits fixes, ces caches étaient intégrés aux circuits non-programmables de gestion des textures et de la géométrie. Les caches de sommet et de texture étaient alors séparés.

===Le cache de textures===

Le '''cache de textures''', comme son nom l'indique, est un cache spécialisé dans les textures. Toutes les cartes graphiques modernes disposent de plusieurs unités de texture, qui disposent chacune de son ou ses propres caches de textures. Pas de cache partagé, ce serait peu utile et trop compliqué à implémenter.

De plus, les cartes graphiques modernes ont plusieurs caches de texture par unité de texture. Généralement, elles ont deux caches de textures : un petit cache rapide, et un gros cache lent. Les deux caches sont fortement différents. L'un est un gros cache, qui fait dans les 4 kibioctets, et l'autre est un petit cache, faisant souvent moins d'1 kibioctet. Mais le premier est plus lent que le second. Sur d'autres cartes graphiques récentes, on trouve plus de 2 caches de textures, organisés en une hiérarchie de caches de textures similaire à la hiérarchie de cache L1, L2, L3 des processeurs modernes.

Notons que ce cache interagit avec les techniques de compression de texture. Les textures sont en effet des images, qui sont donc compressées. Et elles restent compressées en mémoire vidéo, car les textures décompressées prennent beaucoup plus de place, entre 5 à 8 fois plus. Les textures sont décompressées lors des lectures : le processeur de shaders charge quelques octets, les décompresse, et utilise les données décompressées ensuite. Le cache s'introduit quelque part avant ou après la décompression.

On peut décompresser les textures avant de les placer dans le cache, ou laisser les textures compressées dans le cache. Tout est une question de compromis. Décompresser les textures dans le cache fait que la lecture dans le cache est plus rapide, car elle n'implique pas de décompression, mais le cache contient moins de données. A l'inverse, compresser les textures permet de charger plus de données dans le cache, mais rend les lectures légèrement plus lentes. C'est souvent la seconde solution qui est utilisée et ce pour deux raisons. Premièrement, la compression de texture est terriblement efficace, souvent capable de diviser par 6 la taille d'une texture, ce qui augmente drastiquement la taille effective du cache. Deuxièmement, les circuits de décompression sont généralement très rapides, très simples, et n'ajoutent que 1 à 3 cycles d'horloge lors d'une lecture.

Les anciens jeux vidéo ne faisaient que lire les textures, sans les modifier. Aussi, le cache de texture des cartes graphiques anciennes est seulement accessible en lecture, pas en écriture. Cela simplifiait fortement les circuits du cache, réduisant le nombre de transistors utilisés par le cache, réduisant sa consommation énergétique, augmentait sa rapidité, etc. Mais les jeux vidéos 3D récents utilisent des techniques dites de ''render-to-texture'', qui permettent de calculer certaines données et à les écrire en mémoire vidéo pour une utilisation ultérieure. Les textures peuvent donc être modifiées et cela se marie mal avec un cache en lecture seule.

Rendre le cache de texture accessible en écriture est une solution, mais qui demande d'ajouter beaucoup de circuits pour une utilisation somme toute peu fréquente. Une autre solution, plus adaptée, réinitialise le cache de textures quand on modifie une texture, que ce soit totalement ou partiellement. Une fois le cache vidé, les accès mémoire ultérieurs n'ont pas d'autre choix que d'aller lire la texture en mémoire et de remplir le cache avec les données chargées depuis la RAM. Les données de texture en RAM étant les bonnes, cela garantit l’absence d'erreur.

: Ces deux techniques peuvent être adaptées dans le cas où plusieurs caches de textures séparées existent sur une même carte graphique. Les écritures doivent invalider toutes les copies dans tous les caches de texture. Cela nécessite d'ajouter des circuits qui propagent l'invalidation dans tous les autres caches.

===Les caches généralistes===

La hiérarchie mémoire des GPU modernes ressemble à celle des CPU, avec une hiérarchie de caches. Pour rappel, les processeurs multicœurs modernes ont souvent trois à quatre niveaux de caches, appelés les caches L1, L2, L3 et éventuellement L4. Les GPU ont une organisation similaire, sauf que le nombre de cœurs est beaucoup plus grand que sur un processeur moderne.
* Pour le premier niveau, on a deux caches L1 par cœur/processeur : un cache pour les instructions et un cache pour les données.
* Pour le second niveau, on a un cache L2 qui peut stocker indifféremment données et instruction et qui est partagé entre plusieurs cœurs/processeurs.
* Le cache L3 est un cache partagé entre tous les cœurs/processeurs. 

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2|Partage des caches sur un processeur multicoeurs]]

Les caches d'instruction des GPU sont adaptés aux contraintes du rendu 3D. Le principe du rendu 3D est d'appliquer un shader assez simple sur un grand nombre de données. Les shaders sont donc des programmes assez légers, qui ont peu d'instructions. Les caches d'instructions des GPU sont généralement assez petits, quelques dizaines ou centaines de kilooctets. Et malgré cela, il n'est pas rare qu'un ''shader'' tienne tout entier dans le cache d'instruction.

La seconde caractéristique est qu'un même programme s’exécute sur beaucoup de données. Il n'est pas rare que plusieurs processeurs de shaders exécutent le même ''shader''. Aussi, certains GPU partagent un même cache d’instruction entre plusieurs processeurs de ''shader'', comme c'est le cas sur les GPU AMD d'architecture GCN où un cache d'instruction de 32 kB est partagé entre 4 cœurs.

Pour les caches de données, il faut savoir qu'un shader a peu de chances de réutiliser une donnée qu'il a chargé précédemment. Les processeurs de shaders ont beaucoup de registres, ce qui fait que si accès ultérieur à une donnée il doit y avoir, elle passe généralement par les registres. Cette faible réutilisation fait que les caches de données ne sont pas censé être très utiles. Il y a cependant des exceptions liées aux textures, comme vu plus haut.

Une de ces exception est liée au fait qu'un shader a besoin de certaines informations spécifiques, généralement constantes, pour faire son travail. Toutes les instances du shader manipulent ces données, elles ont besoin de les lire, pour les utiliser lors de l’exécution, les copier dans des registres, etc. Les GPU incorporent des '''caches de constantes''' pour accélérer l'accès à ces données. Ainsi, quand un shader lit une donnée, elle est chargée dans le cache de constante, ce qui fait que les futures instances auront accès à celle-ci dans le cache. Ces caches de constante sont séparés des autres caches de données pour une raison bien précise : les constantes en question sont d'accès peu fréquent. Généralement, on a un accès au début de chaque instance de shader, guère plus. Vu que ce sont des données peu fréquemment utilisées, elles sont censée être évincées en priorité du cache de données, qui privilégie les données fréquemment lues/écrites. Avec un cache séparé, on n'a pas ce problème. Au passage, ce cache de constante a des chances d'être partagé entre plusieurs cœurs, des cœurs différents ayant de fortes chances d’exécuter des instances différentes d'un même shader.

Il faut noter que sur la plupart des cartes graphiques modernes, les caches de données et le cache de texture sont un seul et même cache. Même chose pour le cache de sommets, utilisé par les unités géométrique, qui est fusionné avec les caches de données. La raison est que une économie de circuits qui ne coute pas grand chose en termes de performance. Rappelons que les processeurs de shaders sont unifiés à l'heure actuelle, c'est à dire qu'elles peuvent exécuter pixel shader et vertex shader. En théorie, chaque unité de shader devrait incorporer un cache de sommets et un cache de textures. Mais le processeur de shader exécute soit un pixel shader, soit un vertex shader, mais pas les deux en même temps. Donc, autant utiliser un seul cache, qui sert alternativement de cache de vertex et de cache de texture, afin d'économiser des circuits. Une fois les deux fusionnés, on obtient un cache de donnée généraliste, capable de traiter sommets et pixels, voire d'autres données. La seule difficulté tient au filtrage de textures et à sa décompression, mais cela demande juste de router les données lues vers l'unité de texture ou directement vers les registres/unités de calcul, ce qui est facile à faire.

==La mémoire partagée : un ''local store''==

En plus d'utiliser des caches, les GPU modernes utilisent des ''local stores'', aussi appelés ''scratchpad memories''. Ce sont des mémoires RAM intermédiaires entre la RAM principale et les registres. Ces local stores peuvent être vus comme des caches, mais que le programmeur doit gérer manuellement. Dans la réalité, ce sont des mémoires RAM très rapides mais de petite taille, qui sont adressées comme n'importe quelle mémoire RAM, en utilisant des adresses directement.

[[File:Scratch-Pad-Memory.jpg|centre|vignette|upright=2.0|Scratch-Pad-Memory (SPM).]]

Sur les GPU modernes, chaque processeur de ''shader'' possède un unique ''local store'', appelée la '''mémoire partagée'''. Il n'y a pas de hiérarchie des ''local store'', similaire à la hiérarchie des caches.

[[File:Cuda5.png|centre|vignette|upright=2.0|Local stores d'un GPU.]]

La faible capacité de ces mémoires, tout du moins comparé à la grande taille de la mémoire vidéo, les rend utile pour stocker temporairement des résultats de calcul &quot;peu imposants&quot;. L'utilité principale est donc de réduire le trafic avec la mémoire centrale, les écritures de résultats temporaires étant redirigés vers les local stores. Ils sont surtout utilisés hors du rendu 3D, pour les applications de type GPGPU, où le GPU est utilisé comme architecture multicœurs pour du calcul scientifique.

===L'implémentation des ''local store''===

Vous vous attendez certainement à ce que je dise que les ''local store'' sont des mémoires séparées des mémoires caches et qu'il y a réellement des puces de mémoire RAM distinctes dans les processeurs de ''shaders''. Mais en réalité, ce n'est pas le cas pour tous les ''local store''. Le dernier niveau de ''local store'', la mémoire partagée, est bel et bien une mémoire SRAM à part des autres, avec ses propres circuits. Mais les cartes graphiques très récentes fusionnent la mémoire locale avec le cache L1.

L'avantage est une économie de transistors assez importante. De plus, cette technologie permet de partitionner le cache/''local store'' suivant les besoins. Par exemple, si la moitié du ''local store'' est utilisé, l'autre moitié peut servir de cache L1. Si le ''local store'' n'est pas utilisé, comme c'est le cas pour la majorité des rendu 3D, le cache/''local store'' est utilisé intégralement comme cache L1.

Et si vous vous demandez comment c'est possible de fusionner un cache et une mémoire RAM, voici comment le tout est implémenté. L'implémentation consiste à couper le cache en deux circuits, dont l'un est un ''local store'', et l'autre transforme le ''local store'' en cache. Ce genre de cache séparé en deux mémoires est appelé un ''phased cache'', pour ceux qui veulent en savoir plus, et ce genre de cache est parfois utilisés sur les processeurs modernes, dans des processeurs dédiés à l'embarqué ou pour certaines applications spécifiques.

Le premier circuit vérifie la présence des données à lire/écrire dans le cache. Lors d'un accès mémoire, il reçoit l'adresse mémoire à lire, et détermine si une copie de la donnée associée est dans le cache ou non. Pour cela, il utilise un système de tags qu'on ne détaillera pas ici, mais qui donne son nom à l'unité de vérification : l''''unité de tag'''. Son implémentation est très variable suivant le cache considéré, mais une simple mémoire RAM suffit généralement.

En plus de l'unité de tags, il y a une mémoire qui stocke les données, la mémoire cache proprement dite. Par simplicité, cette mémoire est une simple mémoire RAM adressable avec des adresses mémoires des plus normales, chaque ligne de cache correspondant à une adresse. La mémoire RAM de données en question n'est autre que le ''local store''. En clair, le cache s'obtient en combinant un ''local store'' avec un circuit qui s'occupe de vérifier de vérifier les succès ou défaut de cache, et qui éventuellement identifie la position de la donnée dans le cache.

[[File:Phased cache.png|centre|vignette|upright=1.5|Phased cache]]

Pour que le tout puisse servir alternativement de ''local store'' ou de cache, on doit contourner ou non l'unité de tags. Lors d'un accès au cache, on envoie l'adresse à lire/écrire à l'unité de tags. Lors d'un accès au ''local store'', on envoie l'adresse directement sur la mémoire RAM de données, sans intervention de l'unité de tags. Le contournement est d'autant plus simple que les adresses pour le ''local store'' sont distinctes des adresses de la mémoire vidéo, les espaces d'adressage ne sont pas les mêmes, les instructions utilisées pour lire/écrire dans ces deux mémoires sont aussi potentiellement différentes.

[[File:Hydride cache - local store.png|centre|vignette|upright=2.0|Hydride cache - local store]]

Il faut préciser que cette organisation en ''phased cache'' est assez naturelle. Les caches de texture utilisent cette organisation pour diverses raisons. Vu que cache L1 et cache de texture sont le même cache, il est naturel que les caches L1 et autres aient suivi le mouvement en conservant la même organisation. La transformation du cache L1 en hydride cache/''local store'' était donc assez simple à implémenter et s'est donc faite facilement.

{{NavChapitre | book=Les cartes graphiques
           | prev=La microarchitecture des processeurs de shaders
           | prevText=La microarchitecture des processeurs de shaders
           | next=La mémoire unifiée et la mémoire vidéo dédiée
           | netxText=La mémoire unifiée et la mémoire vidéo dédiée
}}{{autocat}}</text>
      <sha1>fazh0fld0swwawqobhv6uw53h939qob</sha1>
    </revision>
    <revision>
      <id>745381</id>
      <parentid>745380</parentid>
      <timestamp>2025-06-26T13:00:03Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les caches généralistes */</comment>
      <origin>745381</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21938" sha1="dur5cw21bfqai46ykc3arpi5x79g67t" xml:space="preserve">Dans ce chapitre, nous allons voir comment est organisée la mémoire d'un GPU, ou plutôt devrait-on dire les mémoires d'un GPU. Eh oui : un GPU contient beaucoup de mémoires différentes. La hiérarchie mémoire des GPUs est assez particulière, que ce soit au niveau des caches ou de la mémoire, parfois des registres. Un GPU contient évidemment une mémoire vidéo, de grande taille, capable de stocker textures, vertices, images et bien d'autres choses nécessaires pour un rendu 3D. On y trouve souvent des mémoires caches dédiées aux textures ou aux vertices.

Les GPUs récents contiennent aussi des caches tout court qui ne sont spécialisés dans les textures ou vertices. De plus, les caches sont complétés par des ''Local Store'', des mémoires normales de petite taille. Elles sont gérés par le logiciel, le programmeur, alors que les caches sont gérés par des circuits de contrôle qui s'occupent du chargement ou de l'éviction des données du cache. Elles servent donc de cache géré par le logiciel, si on peut dire. Un GPU moderne dispose de plusieurs ''local store'' : au moins par cœur.

==La mémoire vidéo==

La mémoire vidéo d'une carte graphique dédiée est nécessaire pour stocker l'image à afficher à l'écran, mais aussi pour mémoriser temporairement des informations importantes. Dans le cas le plus simple, elle sert simplement de ''Framebuffer'' : elle stocke l'image à afficher à l'écran. Au fil du temps, elle s'est vu ajouter d'autres fonctions, comme stocker les textures et les sommets de l'image à calculer, ainsi que divers résultats temporaires.

===Les spécificités des RAM des cartes vidéo dédiées===

Sur les cartes graphiques dédiées, la mémoire vidéo est très proche des mémoires RAM qu'on trouve sous forme de barrettes dans nos PC, à quelques différences près. Le point le plus important est que la mémoire vidéo d'une carte dédiée n'est pas présente sous la forme de barrettes de mémoire. À la place, les puces de mémoire sont soudées sur la puce. La conséquence est que l'on ne peut pas upgrader la RAM d'une carte vidéo. Ce serait sympathique, mais ne serait pas d'une grande utilité, car les jeux vidéos gourmands en mémoire vidéo sont aussi gourmands en puissance de calcul. Upgrader la RAM d'une carte graphique ne sert à rien si celle-ci n'a pas assez de puissance pour jouer à des jeux récents avec un framerate convenable.

Le fait que la mémoire est soudée simplifie la conception de la carte graphique, mais cela a des avantages au niveau électrique, qui permettent d'améliorer les performances. Niveau performances, la mémoire vidéo a des performances radicalement différentes de la RAM des PC. Elle a un temps d'accès très long, de plusieurs centaines de cycles d'horloge. Cela a des conséquences sur l'architecture de la carte graphique, notamment au niveau des processeurs de ''shaders'', qui sont conçus pour gérer ces temps d'accès long, comme on l'a vu dans le précédent chapitre. Par contre, elle a un très grand débit, autrement dit une bande passante élevée, proche de la centaine de gigaoctets par secondes sur les cartes graphiques modernes. Pour rappel, la bande passante d'une mémoire dépend de deux paramètres : sa fréquence et la largueur de son bus mémoire. Détaillons le dernier, qui explique en grande partie pourquoi la mémoire vidéo a un débit supérieur à la mémoire système.

===Le bus mémoire et sa largeur===

Le bus mémoire est ce qui connecte la mémoire au reste de la carte graphique. La largueur de ce bus n'est autre que la quantité de données que celui-ci peut transmettre à chaque cycle d'horloge, le nombre de bits que l'on peut lire/écrire en un cycle d'horloge. Sur la RAM système, le bus est de 64 bits sur les mémoires DDR modernes, mais peut monter à 128 bits en utilisant des techniques comme le ''dual channel'', voire en 192/256 bits avec des techniques de ''triple/quad channel'' qui sont rarement utilisées. Globalement, la configuration classique sur un PC moderne est 128 bits, avec quelques machines bas de gamme en 64 bits. Sur les cartes graphiques modernes, les bus de 128 bits ou moins sont utilisés sur les cartes graphiques de faible performance, le reste ayant un bus mémoire de 192, 256, 384, voire 512 bits. En clair, elles permettent de lire/écrire plus de données par cycle d'horloge qu'une RAM système, de 2 à 8 fois plus.

Le fait que le bus est plus large est lié au fait que les puces mémoires sont soudées. La mémoire vidéo des cartes dédiées est composée de pleins de puces mémoires accessibles en parallèle, ce qui permet de charger des blocs de plusieurs centaines d'octets en une seule fois. Les barrettes de mémoire ont des limites au nombres de broches que leur connecteur peut accepter, qui est proche de 300 pour les DDR actuelles (beaucoup de ces broches ne transfèrent pas des données, ce qui fait qu'on a bien 64 broches dédiées aux données seulement). Sans connecteurs, on est limité à ce que la puce du GPU peut accepter, et on est alors entre 4000 à 6000 broches sur les sockets de CPU ou de GPU actuels.

[[File:Puces mémories d'un GPU et d'une barrette de mémoire.png|centre|vignette|upright=2|Puces mémoires d'un GPU et d'une barrette de mémoire.]]

Pour résumer, sur les cartes graphiques dédiées, la RAM vidéo a un débit proche de la centaine de gigaoctets par secondes. Avec une mémoire RAM unifiée, vous pouvez facilement diviser cette estimation par 10.

===La mémoire vidéo est très lente===

La mémoire vidéo a donc un débit très élevé. Mais par contre, elle a un temps d'accès très lent. Concrètement, cela veut dire qu'un accès mémoire va prendre beaucoup de temps. Par exemple, si je veux lire une texture, entre le moment où j'envoie une demande de lecture à la mémoire vidéo, et le moment celle-ci me renvoie les premiers texels, il va se passer entre 200 à 1000 cycles d'horloge processeur. Par contre, une fois les premiers texels reçus, les texels suivants sont disponibles au cycle suivant, et ainsi de suite. En clair, les données lues mettent du temps avant d'arriver, mais elles arrivent par gros paquets une fois ce temps d'attente passé.

La différence entre débit et temps d'accès est primordiale sur les GPU modernes comme anciens. Toute l'architecture de la carte graphique est conçue de manière à prendre en compte ce temps d'attente. Les techniques employées sont multiples, et ne sont pas inconnues à ceux qui ont déjà lu un cours d'architecture des ordinateurs : mémoire caches, hiérarchie de caches, ''multithreading'' matériel au niveau du processeur, optimisations des accès mémoire comme des ''Load-Store Queues'' larges, des ''coalesing write buffers'', etc. Mais toutes ces techniques sont techniquement incorporées dans les processeurs de ''shaders'' et dans les circuits fixes. Aussi nous ne pouvons pas en parler dans ce chapitre. A une exception près : l'usage de caches et de ''local stores''.

==Les caches d'un GPU==

Les cartes graphiques sont censées avoir peu de caches. Les anciennes cartes graphiques se débrouillaient avec des caches spécialisés pour les textures ou pour les sommets, ce qui leur vaut les noms de caches de texture et de cache de sommets. Ce n'est que par la suite, quand les GPU commencèrent à être utilisés pour du calcul généraliste (scientifique, notamment), que la situation changea. Les GPU utilisèrent alors de plus en plus de caches généralistes, capables de stocker n'importe quelle forme de données.

Les caches en question sont intégrés dans les processeurs de ''shaders'' sur les GPU modernes. Même les caches de texture ou de sommets. Les deux sont d'ailleurs fusionnés sur les GPU modernes, vu que leur jeu d'instruction est unifié et qu'ils peuvent exécuter aussi bien des ''vertex shaders'' que des ''pixel shaders''. Sur les GPU plus anciens, avec des circuits fixes, ces caches étaient intégrés aux circuits non-programmables de gestion des textures et de la géométrie. Les caches de sommet et de texture étaient alors séparés.

===Le cache de textures===

Le '''cache de textures''', comme son nom l'indique, est un cache spécialisé dans les textures. Toutes les cartes graphiques modernes disposent de plusieurs unités de texture, qui disposent chacune de son ou ses propres caches de textures. Pas de cache partagé, ce serait peu utile et trop compliqué à implémenter.

De plus, les cartes graphiques modernes ont plusieurs caches de texture par unité de texture. Généralement, elles ont deux caches de textures : un petit cache rapide, et un gros cache lent. Les deux caches sont fortement différents. L'un est un gros cache, qui fait dans les 4 kibioctets, et l'autre est un petit cache, faisant souvent moins d'1 kibioctet. Mais le premier est plus lent que le second. Sur d'autres cartes graphiques récentes, on trouve plus de 2 caches de textures, organisés en une hiérarchie de caches de textures similaire à la hiérarchie de cache L1, L2, L3 des processeurs modernes.

Notons que ce cache interagit avec les techniques de compression de texture. Les textures sont en effet des images, qui sont donc compressées. Et elles restent compressées en mémoire vidéo, car les textures décompressées prennent beaucoup plus de place, entre 5 à 8 fois plus. Les textures sont décompressées lors des lectures : le processeur de shaders charge quelques octets, les décompresse, et utilise les données décompressées ensuite. Le cache s'introduit quelque part avant ou après la décompression.

On peut décompresser les textures avant de les placer dans le cache, ou laisser les textures compressées dans le cache. Tout est une question de compromis. Décompresser les textures dans le cache fait que la lecture dans le cache est plus rapide, car elle n'implique pas de décompression, mais le cache contient moins de données. A l'inverse, compresser les textures permet de charger plus de données dans le cache, mais rend les lectures légèrement plus lentes. C'est souvent la seconde solution qui est utilisée et ce pour deux raisons. Premièrement, la compression de texture est terriblement efficace, souvent capable de diviser par 6 la taille d'une texture, ce qui augmente drastiquement la taille effective du cache. Deuxièmement, les circuits de décompression sont généralement très rapides, très simples, et n'ajoutent que 1 à 3 cycles d'horloge lors d'une lecture.

Les anciens jeux vidéo ne faisaient que lire les textures, sans les modifier. Aussi, le cache de texture des cartes graphiques anciennes est seulement accessible en lecture, pas en écriture. Cela simplifiait fortement les circuits du cache, réduisant le nombre de transistors utilisés par le cache, réduisant sa consommation énergétique, augmentait sa rapidité, etc. Mais les jeux vidéos 3D récents utilisent des techniques dites de ''render-to-texture'', qui permettent de calculer certaines données et à les écrire en mémoire vidéo pour une utilisation ultérieure. Les textures peuvent donc être modifiées et cela se marie mal avec un cache en lecture seule.

Rendre le cache de texture accessible en écriture est une solution, mais qui demande d'ajouter beaucoup de circuits pour une utilisation somme toute peu fréquente. Une autre solution, plus adaptée, réinitialise le cache de textures quand on modifie une texture, que ce soit totalement ou partiellement. Une fois le cache vidé, les accès mémoire ultérieurs n'ont pas d'autre choix que d'aller lire la texture en mémoire et de remplir le cache avec les données chargées depuis la RAM. Les données de texture en RAM étant les bonnes, cela garantit l’absence d'erreur.

: Ces deux techniques peuvent être adaptées dans le cas où plusieurs caches de textures séparées existent sur une même carte graphique. Les écritures doivent invalider toutes les copies dans tous les caches de texture. Cela nécessite d'ajouter des circuits qui propagent l'invalidation dans tous les autres caches.

===Les caches généralistes===

La hiérarchie mémoire des GPU modernes ressemble à celle des CPU, avec une hiérarchie de caches. Pour rappel, les processeurs multicœurs modernes ont souvent trois à quatre niveaux de caches, appelés les caches L1, L2, L3 et éventuellement L4. Les GPU ont une organisation similaire, sauf que le nombre de cœurs est beaucoup plus grand que sur un processeur moderne.
* Pour le premier niveau, on a deux caches L1 par cœur/processeur : un cache pour les instructions et un cache pour les données.
* Pour le second niveau, on a un cache L2 qui peut stocker indifféremment données et instruction et qui est partagé entre plusieurs cœurs/processeurs.
* Le cache L3 est un cache partagé entre tous les cœurs/processeurs. 

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2|Partage des caches sur un processeur multicoeurs]]

Les caches d'instruction des GPU sont adaptés aux contraintes du rendu 3D. Le principe du rendu 3D est d'appliquer un shader assez simple sur un grand nombre de données. Les shaders sont donc des programmes assez légers, qui ont peu d'instructions. Les caches d'instructions des GPU sont généralement assez petits, quelques dizaines ou centaines de kilooctets. Et malgré cela, il n'est pas rare qu'un ''shader'' tienne tout entier dans le cache d'instruction.

La seconde caractéristique est qu'un même programme s’exécute sur beaucoup de données. Il n'est pas rare que plusieurs processeurs de shaders exécutent le même ''shader''. Aussi, certains GPU partagent un même cache d’instruction entre plusieurs processeurs de ''shader'', comme c'est le cas sur les GPU AMD d'architecture GCN où un cache d'instruction de 32 kB est partagé entre 4 cœurs.

Pour les caches de données, il faut savoir qu'un shader a peu de chances de réutiliser une donnée qu'il a chargé précédemment. Les processeurs de shaders ont beaucoup de registres, ce qui fait que si accès ultérieur à une donnée il doit y avoir, elle passe généralement par les registres. Cette faible réutilisation fait que les caches de données ne sont pas censé être très utiles. Il y a cependant des exceptions liées aux textures, comme vu plus haut.

Une de ces exceptions est liée au fait qu'un shader a besoin de certaines &quot;constantes&quot; pour faire son travail. Toutes les instances du shader manipulent ces constantes, les lisent, les copient dans des registres, etc. Les constantes en question sont d'accès peu fréquent, qui se limite souvent à un accès au début de chaque instance de shader, guère plus. Pour profiter du partage des constantes entre instances d'un shader, les GPU incorporent des '''caches de constantes''' pour accélérer l'accès à ces données. Ainsi, quand un shader lit une donnée, elle est chargée dans le cache de constante, ce qui fait que les autres instances liront ces constantes dans le cache.

Les caches de constante sont séparés des autres caches de données, car ce sont des données peu fréquemment utilisées, qui sont censées être évincées en priorité du cache de données, qui privilégie les données fréquemment lues/écrites. Avec un cache séparé, les constantes restent dans le cache. Au passage, ce cache de constante a des chances d'être partagé entre plusieurs cœurs, des cœurs différents ayant de fortes chances d’exécuter des instances différentes d'un même shader.

Il faut noter que sur la plupart des cartes graphiques modernes, les caches de données et le cache de texture sont un seul et même cache. Même chose pour le cache de sommets, utilisé par les unités géométrique, qui est fusionné avec les caches de données. La raison est que une économie de circuits qui ne coute pas grand chose en termes de performance. Rappelons que les processeurs de shaders sont unifiés à l'heure actuelle, c'est à dire qu'elles peuvent exécuter pixel shader et vertex shader. Au lieu d'incorporer un cache de sommets et un cache de textures, autant utiliser un seul cache qui sert alternativement de cache de vertex et de cache de texture, afin d'économiser des circuits.

==La mémoire partagée : un ''local store''==

En plus d'utiliser des caches, les GPU modernes utilisent des ''local stores'', aussi appelés ''scratchpad memories''. Ce sont des mémoires RAM intermédiaires entre la RAM principale et les registres. Ces local stores peuvent être vus comme des caches, mais que le programmeur doit gérer manuellement. Dans la réalité, ce sont des mémoires RAM très rapides mais de petite taille, qui sont adressées comme n'importe quelle mémoire RAM, en utilisant des adresses directement.

[[File:Scratch-Pad-Memory.jpg|centre|vignette|upright=2.0|Scratch-Pad-Memory (SPM).]]

Sur les GPU modernes, chaque processeur de ''shader'' possède un unique ''local store'', appelée la '''mémoire partagée'''. Il n'y a pas de hiérarchie des ''local store'', similaire à la hiérarchie des caches.

[[File:Cuda5.png|centre|vignette|upright=2.0|Local stores d'un GPU.]]

La faible capacité de ces mémoires, tout du moins comparé à la grande taille de la mémoire vidéo, les rend utile pour stocker temporairement des résultats de calcul &quot;peu imposants&quot;. L'utilité principale est donc de réduire le trafic avec la mémoire centrale, les écritures de résultats temporaires étant redirigés vers les local stores. Ils sont surtout utilisés hors du rendu 3D, pour les applications de type GPGPU, où le GPU est utilisé comme architecture multicœurs pour du calcul scientifique.

===L'implémentation des ''local store''===

Vous vous attendez certainement à ce que je dise que les ''local store'' sont des mémoires séparées des mémoires caches et qu'il y a réellement des puces de mémoire RAM distinctes dans les processeurs de ''shaders''. Mais en réalité, ce n'est pas le cas pour tous les ''local store''. Le dernier niveau de ''local store'', la mémoire partagée, est bel et bien une mémoire SRAM à part des autres, avec ses propres circuits. Mais les cartes graphiques très récentes fusionnent la mémoire locale avec le cache L1.

L'avantage est une économie de transistors assez importante. De plus, cette technologie permet de partitionner le cache/''local store'' suivant les besoins. Par exemple, si la moitié du ''local store'' est utilisé, l'autre moitié peut servir de cache L1. Si le ''local store'' n'est pas utilisé, comme c'est le cas pour la majorité des rendu 3D, le cache/''local store'' est utilisé intégralement comme cache L1.

Et si vous vous demandez comment c'est possible de fusionner un cache et une mémoire RAM, voici comment le tout est implémenté. L'implémentation consiste à couper le cache en deux circuits, dont l'un est un ''local store'', et l'autre transforme le ''local store'' en cache. Ce genre de cache séparé en deux mémoires est appelé un ''phased cache'', pour ceux qui veulent en savoir plus, et ce genre de cache est parfois utilisés sur les processeurs modernes, dans des processeurs dédiés à l'embarqué ou pour certaines applications spécifiques.

Le premier circuit vérifie la présence des données à lire/écrire dans le cache. Lors d'un accès mémoire, il reçoit l'adresse mémoire à lire, et détermine si une copie de la donnée associée est dans le cache ou non. Pour cela, il utilise un système de tags qu'on ne détaillera pas ici, mais qui donne son nom à l'unité de vérification : l''''unité de tag'''. Son implémentation est très variable suivant le cache considéré, mais une simple mémoire RAM suffit généralement.

En plus de l'unité de tags, il y a une mémoire qui stocke les données, la mémoire cache proprement dite. Par simplicité, cette mémoire est une simple mémoire RAM adressable avec des adresses mémoires des plus normales, chaque ligne de cache correspondant à une adresse. La mémoire RAM de données en question n'est autre que le ''local store''. En clair, le cache s'obtient en combinant un ''local store'' avec un circuit qui s'occupe de vérifier de vérifier les succès ou défaut de cache, et qui éventuellement identifie la position de la donnée dans le cache.

[[File:Phased cache.png|centre|vignette|upright=1.5|Phased cache]]

Pour que le tout puisse servir alternativement de ''local store'' ou de cache, on doit contourner ou non l'unité de tags. Lors d'un accès au cache, on envoie l'adresse à lire/écrire à l'unité de tags. Lors d'un accès au ''local store'', on envoie l'adresse directement sur la mémoire RAM de données, sans intervention de l'unité de tags. Le contournement est d'autant plus simple que les adresses pour le ''local store'' sont distinctes des adresses de la mémoire vidéo, les espaces d'adressage ne sont pas les mêmes, les instructions utilisées pour lire/écrire dans ces deux mémoires sont aussi potentiellement différentes.

[[File:Hydride cache - local store.png|centre|vignette|upright=2.0|Hydride cache - local store]]

Il faut préciser que cette organisation en ''phased cache'' est assez naturelle. Les caches de texture utilisent cette organisation pour diverses raisons. Vu que cache L1 et cache de texture sont le même cache, il est naturel que les caches L1 et autres aient suivi le mouvement en conservant la même organisation. La transformation du cache L1 en hydride cache/''local store'' était donc assez simple à implémenter et s'est donc faite facilement.

{{NavChapitre | book=Les cartes graphiques
           | prev=La microarchitecture des processeurs de shaders
           | prevText=La microarchitecture des processeurs de shaders
           | next=La mémoire unifiée et la mémoire vidéo dédiée
           | netxText=La mémoire unifiée et la mémoire vidéo dédiée
}}{{autocat}}</text>
      <sha1>dur5cw21bfqai46ykc3arpi5x79g67t</sha1>
    </revision>
    <revision>
      <id>745382</id>
      <parentid>745381</parentid>
      <timestamp>2025-06-26T13:00:50Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les caches généralistes */</comment>
      <origin>745382</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22021" sha1="7tzfnw6wprsgho42cxwxdkghxgfz4ii" xml:space="preserve">Dans ce chapitre, nous allons voir comment est organisée la mémoire d'un GPU, ou plutôt devrait-on dire les mémoires d'un GPU. Eh oui : un GPU contient beaucoup de mémoires différentes. La hiérarchie mémoire des GPUs est assez particulière, que ce soit au niveau des caches ou de la mémoire, parfois des registres. Un GPU contient évidemment une mémoire vidéo, de grande taille, capable de stocker textures, vertices, images et bien d'autres choses nécessaires pour un rendu 3D. On y trouve souvent des mémoires caches dédiées aux textures ou aux vertices.

Les GPUs récents contiennent aussi des caches tout court qui ne sont spécialisés dans les textures ou vertices. De plus, les caches sont complétés par des ''Local Store'', des mémoires normales de petite taille. Elles sont gérés par le logiciel, le programmeur, alors que les caches sont gérés par des circuits de contrôle qui s'occupent du chargement ou de l'éviction des données du cache. Elles servent donc de cache géré par le logiciel, si on peut dire. Un GPU moderne dispose de plusieurs ''local store'' : au moins par cœur.

==La mémoire vidéo==

La mémoire vidéo d'une carte graphique dédiée est nécessaire pour stocker l'image à afficher à l'écran, mais aussi pour mémoriser temporairement des informations importantes. Dans le cas le plus simple, elle sert simplement de ''Framebuffer'' : elle stocke l'image à afficher à l'écran. Au fil du temps, elle s'est vu ajouter d'autres fonctions, comme stocker les textures et les sommets de l'image à calculer, ainsi que divers résultats temporaires.

===Les spécificités des RAM des cartes vidéo dédiées===

Sur les cartes graphiques dédiées, la mémoire vidéo est très proche des mémoires RAM qu'on trouve sous forme de barrettes dans nos PC, à quelques différences près. Le point le plus important est que la mémoire vidéo d'une carte dédiée n'est pas présente sous la forme de barrettes de mémoire. À la place, les puces de mémoire sont soudées sur la puce. La conséquence est que l'on ne peut pas upgrader la RAM d'une carte vidéo. Ce serait sympathique, mais ne serait pas d'une grande utilité, car les jeux vidéos gourmands en mémoire vidéo sont aussi gourmands en puissance de calcul. Upgrader la RAM d'une carte graphique ne sert à rien si celle-ci n'a pas assez de puissance pour jouer à des jeux récents avec un framerate convenable.

Le fait que la mémoire est soudée simplifie la conception de la carte graphique, mais cela a des avantages au niveau électrique, qui permettent d'améliorer les performances. Niveau performances, la mémoire vidéo a des performances radicalement différentes de la RAM des PC. Elle a un temps d'accès très long, de plusieurs centaines de cycles d'horloge. Cela a des conséquences sur l'architecture de la carte graphique, notamment au niveau des processeurs de ''shaders'', qui sont conçus pour gérer ces temps d'accès long, comme on l'a vu dans le précédent chapitre. Par contre, elle a un très grand débit, autrement dit une bande passante élevée, proche de la centaine de gigaoctets par secondes sur les cartes graphiques modernes. Pour rappel, la bande passante d'une mémoire dépend de deux paramètres : sa fréquence et la largueur de son bus mémoire. Détaillons le dernier, qui explique en grande partie pourquoi la mémoire vidéo a un débit supérieur à la mémoire système.

===Le bus mémoire et sa largeur===

Le bus mémoire est ce qui connecte la mémoire au reste de la carte graphique. La largueur de ce bus n'est autre que la quantité de données que celui-ci peut transmettre à chaque cycle d'horloge, le nombre de bits que l'on peut lire/écrire en un cycle d'horloge. Sur la RAM système, le bus est de 64 bits sur les mémoires DDR modernes, mais peut monter à 128 bits en utilisant des techniques comme le ''dual channel'', voire en 192/256 bits avec des techniques de ''triple/quad channel'' qui sont rarement utilisées. Globalement, la configuration classique sur un PC moderne est 128 bits, avec quelques machines bas de gamme en 64 bits. Sur les cartes graphiques modernes, les bus de 128 bits ou moins sont utilisés sur les cartes graphiques de faible performance, le reste ayant un bus mémoire de 192, 256, 384, voire 512 bits. En clair, elles permettent de lire/écrire plus de données par cycle d'horloge qu'une RAM système, de 2 à 8 fois plus.

Le fait que le bus est plus large est lié au fait que les puces mémoires sont soudées. La mémoire vidéo des cartes dédiées est composée de pleins de puces mémoires accessibles en parallèle, ce qui permet de charger des blocs de plusieurs centaines d'octets en une seule fois. Les barrettes de mémoire ont des limites au nombres de broches que leur connecteur peut accepter, qui est proche de 300 pour les DDR actuelles (beaucoup de ces broches ne transfèrent pas des données, ce qui fait qu'on a bien 64 broches dédiées aux données seulement). Sans connecteurs, on est limité à ce que la puce du GPU peut accepter, et on est alors entre 4000 à 6000 broches sur les sockets de CPU ou de GPU actuels.

[[File:Puces mémories d'un GPU et d'une barrette de mémoire.png|centre|vignette|upright=2|Puces mémoires d'un GPU et d'une barrette de mémoire.]]

Pour résumer, sur les cartes graphiques dédiées, la RAM vidéo a un débit proche de la centaine de gigaoctets par secondes. Avec une mémoire RAM unifiée, vous pouvez facilement diviser cette estimation par 10.

===La mémoire vidéo est très lente===

La mémoire vidéo a donc un débit très élevé. Mais par contre, elle a un temps d'accès très lent. Concrètement, cela veut dire qu'un accès mémoire va prendre beaucoup de temps. Par exemple, si je veux lire une texture, entre le moment où j'envoie une demande de lecture à la mémoire vidéo, et le moment celle-ci me renvoie les premiers texels, il va se passer entre 200 à 1000 cycles d'horloge processeur. Par contre, une fois les premiers texels reçus, les texels suivants sont disponibles au cycle suivant, et ainsi de suite. En clair, les données lues mettent du temps avant d'arriver, mais elles arrivent par gros paquets une fois ce temps d'attente passé.

La différence entre débit et temps d'accès est primordiale sur les GPU modernes comme anciens. Toute l'architecture de la carte graphique est conçue de manière à prendre en compte ce temps d'attente. Les techniques employées sont multiples, et ne sont pas inconnues à ceux qui ont déjà lu un cours d'architecture des ordinateurs : mémoire caches, hiérarchie de caches, ''multithreading'' matériel au niveau du processeur, optimisations des accès mémoire comme des ''Load-Store Queues'' larges, des ''coalesing write buffers'', etc. Mais toutes ces techniques sont techniquement incorporées dans les processeurs de ''shaders'' et dans les circuits fixes. Aussi nous ne pouvons pas en parler dans ce chapitre. A une exception près : l'usage de caches et de ''local stores''.

==Les caches d'un GPU==

Les cartes graphiques sont censées avoir peu de caches. Les anciennes cartes graphiques se débrouillaient avec des caches spécialisés pour les textures ou pour les sommets, ce qui leur vaut les noms de caches de texture et de cache de sommets. Ce n'est que par la suite, quand les GPU commencèrent à être utilisés pour du calcul généraliste (scientifique, notamment), que la situation changea. Les GPU utilisèrent alors de plus en plus de caches généralistes, capables de stocker n'importe quelle forme de données.

Les caches en question sont intégrés dans les processeurs de ''shaders'' sur les GPU modernes. Même les caches de texture ou de sommets. Les deux sont d'ailleurs fusionnés sur les GPU modernes, vu que leur jeu d'instruction est unifié et qu'ils peuvent exécuter aussi bien des ''vertex shaders'' que des ''pixel shaders''. Sur les GPU plus anciens, avec des circuits fixes, ces caches étaient intégrés aux circuits non-programmables de gestion des textures et de la géométrie. Les caches de sommet et de texture étaient alors séparés.

===Le cache de textures===

Le '''cache de textures''', comme son nom l'indique, est un cache spécialisé dans les textures. Toutes les cartes graphiques modernes disposent de plusieurs unités de texture, qui disposent chacune de son ou ses propres caches de textures. Pas de cache partagé, ce serait peu utile et trop compliqué à implémenter.

De plus, les cartes graphiques modernes ont plusieurs caches de texture par unité de texture. Généralement, elles ont deux caches de textures : un petit cache rapide, et un gros cache lent. Les deux caches sont fortement différents. L'un est un gros cache, qui fait dans les 4 kibioctets, et l'autre est un petit cache, faisant souvent moins d'1 kibioctet. Mais le premier est plus lent que le second. Sur d'autres cartes graphiques récentes, on trouve plus de 2 caches de textures, organisés en une hiérarchie de caches de textures similaire à la hiérarchie de cache L1, L2, L3 des processeurs modernes.

Notons que ce cache interagit avec les techniques de compression de texture. Les textures sont en effet des images, qui sont donc compressées. Et elles restent compressées en mémoire vidéo, car les textures décompressées prennent beaucoup plus de place, entre 5 à 8 fois plus. Les textures sont décompressées lors des lectures : le processeur de shaders charge quelques octets, les décompresse, et utilise les données décompressées ensuite. Le cache s'introduit quelque part avant ou après la décompression.

On peut décompresser les textures avant de les placer dans le cache, ou laisser les textures compressées dans le cache. Tout est une question de compromis. Décompresser les textures dans le cache fait que la lecture dans le cache est plus rapide, car elle n'implique pas de décompression, mais le cache contient moins de données. A l'inverse, compresser les textures permet de charger plus de données dans le cache, mais rend les lectures légèrement plus lentes. C'est souvent la seconde solution qui est utilisée et ce pour deux raisons. Premièrement, la compression de texture est terriblement efficace, souvent capable de diviser par 6 la taille d'une texture, ce qui augmente drastiquement la taille effective du cache. Deuxièmement, les circuits de décompression sont généralement très rapides, très simples, et n'ajoutent que 1 à 3 cycles d'horloge lors d'une lecture.

Les anciens jeux vidéo ne faisaient que lire les textures, sans les modifier. Aussi, le cache de texture des cartes graphiques anciennes est seulement accessible en lecture, pas en écriture. Cela simplifiait fortement les circuits du cache, réduisant le nombre de transistors utilisés par le cache, réduisant sa consommation énergétique, augmentait sa rapidité, etc. Mais les jeux vidéos 3D récents utilisent des techniques dites de ''render-to-texture'', qui permettent de calculer certaines données et à les écrire en mémoire vidéo pour une utilisation ultérieure. Les textures peuvent donc être modifiées et cela se marie mal avec un cache en lecture seule.

Rendre le cache de texture accessible en écriture est une solution, mais qui demande d'ajouter beaucoup de circuits pour une utilisation somme toute peu fréquente. Une autre solution, plus adaptée, réinitialise le cache de textures quand on modifie une texture, que ce soit totalement ou partiellement. Une fois le cache vidé, les accès mémoire ultérieurs n'ont pas d'autre choix que d'aller lire la texture en mémoire et de remplir le cache avec les données chargées depuis la RAM. Les données de texture en RAM étant les bonnes, cela garantit l’absence d'erreur.

: Ces deux techniques peuvent être adaptées dans le cas où plusieurs caches de textures séparées existent sur une même carte graphique. Les écritures doivent invalider toutes les copies dans tous les caches de texture. Cela nécessite d'ajouter des circuits qui propagent l'invalidation dans tous les autres caches.

===Les caches généralistes===

La hiérarchie mémoire des GPU modernes ressemble à celle des CPU, avec une hiérarchie de caches. Pour rappel, les processeurs multicœurs modernes ont souvent trois à quatre niveaux de caches, appelés les caches L1, L2, L3 et éventuellement L4. Les GPU ont une organisation similaire, sauf que le nombre de cœurs est beaucoup plus grand que sur un processeur moderne.
* Pour le premier niveau, on a deux caches L1 par cœur/processeur : un cache pour les instructions et un cache pour les données.
* Pour le second niveau, on a un cache L2 qui peut stocker indifféremment données et instruction et qui est partagé entre plusieurs cœurs/processeurs.
* Le cache L3 est un cache partagé entre tous les cœurs/processeurs. 

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2|Partage des caches sur un processeur multicoeurs]]

Les caches d'instruction des GPU sont adaptés aux contraintes du rendu 3D. Le principe du rendu 3D est d'appliquer un shader assez simple sur un grand nombre de données. Les shaders sont donc des programmes assez légers, qui ont peu d'instructions. Les caches d'instructions des GPU sont généralement assez petits, quelques dizaines ou centaines de kilooctets. Et malgré cela, il n'est pas rare qu'un ''shader'' tienne tout entier dans le cache d'instruction.

La seconde caractéristique est qu'un même programme s’exécute sur beaucoup de données. Il n'est pas rare que plusieurs processeurs de shaders exécutent le même ''shader''. Aussi, certains GPU partagent un même cache d’instruction entre plusieurs processeurs de ''shader'', comme c'est le cas sur les GPU AMD d'architecture GCN où un cache d'instruction de 32 kB est partagé entre 4 cœurs.

Pour les caches de données, il faut savoir qu'un shader a peu de chances de réutiliser une donnée qu'il a chargé précédemment. Les processeurs de shaders ont beaucoup de registres, ce qui fait que si accès ultérieur à une donnée il doit y avoir, elle passe généralement par les registres. Cette faible réutilisation fait que les caches de données ne sont pas censé être très utiles. Il y a cependant des exceptions, qui expliquent que les cartes graphiques incorporent un cache de texture et un cache de sommet (pour le tampon de sommet).

Il faut noter que sur la plupart des cartes graphiques modernes, les caches de données et le cache de texture sont un seul et même cache. Même chose pour le cache de sommets, utilisé par les unités géométrique, qui est fusionné avec les caches de données. La raison est que une économie de circuits qui ne coute pas grand chose en termes de performance. Rappelons que les processeurs de shaders sont unifiés à l'heure actuelle, c'est à dire qu'elles peuvent exécuter pixel shader et vertex shader. Au lieu d'incorporer un cache de sommets et un cache de textures, autant utiliser un seul cache qui sert alternativement de cache de vertex et de cache de texture, afin d'économiser des circuits.

Une de ces exceptions est liée au fait qu'un shader a besoin de certaines &quot;constantes&quot; pour faire son travail. Toutes les instances du shader manipulent ces constantes, les lisent, les copient dans des registres, etc. Les constantes en question sont d'accès peu fréquent, qui se limite souvent à un accès au début de chaque instance de shader, guère plus. Pour profiter du partage des constantes entre instances d'un shader, les GPU incorporent des '''caches de constantes''' pour accélérer l'accès à ces données. Ainsi, quand un shader lit une donnée, elle est chargée dans le cache de constante, ce qui fait que les autres instances liront ces constantes dans le cache.

Les caches de constante sont séparés des autres caches de données, car ce sont des données peu fréquemment utilisées, qui sont censées être évincées en priorité du cache de données, qui privilégie les données fréquemment lues/écrites. Avec un cache séparé, les constantes restent dans le cache. Au passage, ce cache de constante a des chances d'être partagé entre plusieurs cœurs, des cœurs différents ayant de fortes chances d’exécuter des instances différentes d'un même shader.

==La mémoire partagée : un ''local store''==

En plus d'utiliser des caches, les GPU modernes utilisent des ''local stores'', aussi appelés ''scratchpad memories''. Ce sont des mémoires RAM intermédiaires entre la RAM principale et les registres. Ces local stores peuvent être vus comme des caches, mais que le programmeur doit gérer manuellement. Dans la réalité, ce sont des mémoires RAM très rapides mais de petite taille, qui sont adressées comme n'importe quelle mémoire RAM, en utilisant des adresses directement.

[[File:Scratch-Pad-Memory.jpg|centre|vignette|upright=2.0|Scratch-Pad-Memory (SPM).]]

Sur les GPU modernes, chaque processeur de ''shader'' possède un unique ''local store'', appelée la '''mémoire partagée'''. Il n'y a pas de hiérarchie des ''local store'', similaire à la hiérarchie des caches.

[[File:Cuda5.png|centre|vignette|upright=2.0|Local stores d'un GPU.]]

La faible capacité de ces mémoires, tout du moins comparé à la grande taille de la mémoire vidéo, les rend utile pour stocker temporairement des résultats de calcul &quot;peu imposants&quot;. L'utilité principale est donc de réduire le trafic avec la mémoire centrale, les écritures de résultats temporaires étant redirigés vers les local stores. Ils sont surtout utilisés hors du rendu 3D, pour les applications de type GPGPU, où le GPU est utilisé comme architecture multicœurs pour du calcul scientifique.

===L'implémentation des ''local store''===

Vous vous attendez certainement à ce que je dise que les ''local store'' sont des mémoires séparées des mémoires caches et qu'il y a réellement des puces de mémoire RAM distinctes dans les processeurs de ''shaders''. Mais en réalité, ce n'est pas le cas pour tous les ''local store''. Le dernier niveau de ''local store'', la mémoire partagée, est bel et bien une mémoire SRAM à part des autres, avec ses propres circuits. Mais les cartes graphiques très récentes fusionnent la mémoire locale avec le cache L1.

L'avantage est une économie de transistors assez importante. De plus, cette technologie permet de partitionner le cache/''local store'' suivant les besoins. Par exemple, si la moitié du ''local store'' est utilisé, l'autre moitié peut servir de cache L1. Si le ''local store'' n'est pas utilisé, comme c'est le cas pour la majorité des rendu 3D, le cache/''local store'' est utilisé intégralement comme cache L1.

Et si vous vous demandez comment c'est possible de fusionner un cache et une mémoire RAM, voici comment le tout est implémenté. L'implémentation consiste à couper le cache en deux circuits, dont l'un est un ''local store'', et l'autre transforme le ''local store'' en cache. Ce genre de cache séparé en deux mémoires est appelé un ''phased cache'', pour ceux qui veulent en savoir plus, et ce genre de cache est parfois utilisés sur les processeurs modernes, dans des processeurs dédiés à l'embarqué ou pour certaines applications spécifiques.

Le premier circuit vérifie la présence des données à lire/écrire dans le cache. Lors d'un accès mémoire, il reçoit l'adresse mémoire à lire, et détermine si une copie de la donnée associée est dans le cache ou non. Pour cela, il utilise un système de tags qu'on ne détaillera pas ici, mais qui donne son nom à l'unité de vérification : l''''unité de tag'''. Son implémentation est très variable suivant le cache considéré, mais une simple mémoire RAM suffit généralement.

En plus de l'unité de tags, il y a une mémoire qui stocke les données, la mémoire cache proprement dite. Par simplicité, cette mémoire est une simple mémoire RAM adressable avec des adresses mémoires des plus normales, chaque ligne de cache correspondant à une adresse. La mémoire RAM de données en question n'est autre que le ''local store''. En clair, le cache s'obtient en combinant un ''local store'' avec un circuit qui s'occupe de vérifier de vérifier les succès ou défaut de cache, et qui éventuellement identifie la position de la donnée dans le cache.

[[File:Phased cache.png|centre|vignette|upright=1.5|Phased cache]]

Pour que le tout puisse servir alternativement de ''local store'' ou de cache, on doit contourner ou non l'unité de tags. Lors d'un accès au cache, on envoie l'adresse à lire/écrire à l'unité de tags. Lors d'un accès au ''local store'', on envoie l'adresse directement sur la mémoire RAM de données, sans intervention de l'unité de tags. Le contournement est d'autant plus simple que les adresses pour le ''local store'' sont distinctes des adresses de la mémoire vidéo, les espaces d'adressage ne sont pas les mêmes, les instructions utilisées pour lire/écrire dans ces deux mémoires sont aussi potentiellement différentes.

[[File:Hydride cache - local store.png|centre|vignette|upright=2.0|Hydride cache - local store]]

Il faut préciser que cette organisation en ''phased cache'' est assez naturelle. Les caches de texture utilisent cette organisation pour diverses raisons. Vu que cache L1 et cache de texture sont le même cache, il est naturel que les caches L1 et autres aient suivi le mouvement en conservant la même organisation. La transformation du cache L1 en hydride cache/''local store'' était donc assez simple à implémenter et s'est donc faite facilement.

{{NavChapitre | book=Les cartes graphiques
           | prev=La microarchitecture des processeurs de shaders
           | prevText=La microarchitecture des processeurs de shaders
           | next=La mémoire unifiée et la mémoire vidéo dédiée
           | netxText=La mémoire unifiée et la mémoire vidéo dédiée
}}{{autocat}}</text>
      <sha1>7tzfnw6wprsgho42cxwxdkghxgfz4ii</sha1>
    </revision>
    <revision>
      <id>745383</id>
      <parentid>745382</parentid>
      <timestamp>2025-06-26T13:03:18Z</timestamp>
      <contributor>
        <username>Mewtow</username>
        <id>31375</id>
      </contributor>
      <minor />
      <comment>/* Les caches généralistes */</comment>
      <origin>745383</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22009" sha1="f1b9agrbbfhafxx543jc31hfk6mr2zb" xml:space="preserve">Dans ce chapitre, nous allons voir comment est organisée la mémoire d'un GPU, ou plutôt devrait-on dire les mémoires d'un GPU. Eh oui : un GPU contient beaucoup de mémoires différentes. La hiérarchie mémoire des GPUs est assez particulière, que ce soit au niveau des caches ou de la mémoire, parfois des registres. Un GPU contient évidemment une mémoire vidéo, de grande taille, capable de stocker textures, vertices, images et bien d'autres choses nécessaires pour un rendu 3D. On y trouve souvent des mémoires caches dédiées aux textures ou aux vertices.

Les GPUs récents contiennent aussi des caches tout court qui ne sont spécialisés dans les textures ou vertices. De plus, les caches sont complétés par des ''Local Store'', des mémoires normales de petite taille. Elles sont gérés par le logiciel, le programmeur, alors que les caches sont gérés par des circuits de contrôle qui s'occupent du chargement ou de l'éviction des données du cache. Elles servent donc de cache géré par le logiciel, si on peut dire. Un GPU moderne dispose de plusieurs ''local store'' : au moins par cœur.

==La mémoire vidéo==

La mémoire vidéo d'une carte graphique dédiée est nécessaire pour stocker l'image à afficher à l'écran, mais aussi pour mémoriser temporairement des informations importantes. Dans le cas le plus simple, elle sert simplement de ''Framebuffer'' : elle stocke l'image à afficher à l'écran. Au fil du temps, elle s'est vu ajouter d'autres fonctions, comme stocker les textures et les sommets de l'image à calculer, ainsi que divers résultats temporaires.

===Les spécificités des RAM des cartes vidéo dédiées===

Sur les cartes graphiques dédiées, la mémoire vidéo est très proche des mémoires RAM qu'on trouve sous forme de barrettes dans nos PC, à quelques différences près. Le point le plus important est que la mémoire vidéo d'une carte dédiée n'est pas présente sous la forme de barrettes de mémoire. À la place, les puces de mémoire sont soudées sur la puce. La conséquence est que l'on ne peut pas upgrader la RAM d'une carte vidéo. Ce serait sympathique, mais ne serait pas d'une grande utilité, car les jeux vidéos gourmands en mémoire vidéo sont aussi gourmands en puissance de calcul. Upgrader la RAM d'une carte graphique ne sert à rien si celle-ci n'a pas assez de puissance pour jouer à des jeux récents avec un framerate convenable.

Le fait que la mémoire est soudée simplifie la conception de la carte graphique, mais cela a des avantages au niveau électrique, qui permettent d'améliorer les performances. Niveau performances, la mémoire vidéo a des performances radicalement différentes de la RAM des PC. Elle a un temps d'accès très long, de plusieurs centaines de cycles d'horloge. Cela a des conséquences sur l'architecture de la carte graphique, notamment au niveau des processeurs de ''shaders'', qui sont conçus pour gérer ces temps d'accès long, comme on l'a vu dans le précédent chapitre. Par contre, elle a un très grand débit, autrement dit une bande passante élevée, proche de la centaine de gigaoctets par secondes sur les cartes graphiques modernes. Pour rappel, la bande passante d'une mémoire dépend de deux paramètres : sa fréquence et la largueur de son bus mémoire. Détaillons le dernier, qui explique en grande partie pourquoi la mémoire vidéo a un débit supérieur à la mémoire système.

===Le bus mémoire et sa largeur===

Le bus mémoire est ce qui connecte la mémoire au reste de la carte graphique. La largueur de ce bus n'est autre que la quantité de données que celui-ci peut transmettre à chaque cycle d'horloge, le nombre de bits que l'on peut lire/écrire en un cycle d'horloge. Sur la RAM système, le bus est de 64 bits sur les mémoires DDR modernes, mais peut monter à 128 bits en utilisant des techniques comme le ''dual channel'', voire en 192/256 bits avec des techniques de ''triple/quad channel'' qui sont rarement utilisées. Globalement, la configuration classique sur un PC moderne est 128 bits, avec quelques machines bas de gamme en 64 bits. Sur les cartes graphiques modernes, les bus de 128 bits ou moins sont utilisés sur les cartes graphiques de faible performance, le reste ayant un bus mémoire de 192, 256, 384, voire 512 bits. En clair, elles permettent de lire/écrire plus de données par cycle d'horloge qu'une RAM système, de 2 à 8 fois plus.

Le fait que le bus est plus large est lié au fait que les puces mémoires sont soudées. La mémoire vidéo des cartes dédiées est composée de pleins de puces mémoires accessibles en parallèle, ce qui permet de charger des blocs de plusieurs centaines d'octets en une seule fois. Les barrettes de mémoire ont des limites au nombres de broches que leur connecteur peut accepter, qui est proche de 300 pour les DDR actuelles (beaucoup de ces broches ne transfèrent pas des données, ce qui fait qu'on a bien 64 broches dédiées aux données seulement). Sans connecteurs, on est limité à ce que la puce du GPU peut accepter, et on est alors entre 4000 à 6000 broches sur les sockets de CPU ou de GPU actuels.

[[File:Puces mémories d'un GPU et d'une barrette de mémoire.png|centre|vignette|upright=2|Puces mémoires d'un GPU et d'une barrette de mémoire.]]

Pour résumer, sur les cartes graphiques dédiées, la RAM vidéo a un débit proche de la centaine de gigaoctets par secondes. Avec une mémoire RAM unifiée, vous pouvez facilement diviser cette estimation par 10.

===La mémoire vidéo est très lente===

La mémoire vidéo a donc un débit très élevé. Mais par contre, elle a un temps d'accès très lent. Concrètement, cela veut dire qu'un accès mémoire va prendre beaucoup de temps. Par exemple, si je veux lire une texture, entre le moment où j'envoie une demande de lecture à la mémoire vidéo, et le moment celle-ci me renvoie les premiers texels, il va se passer entre 200 à 1000 cycles d'horloge processeur. Par contre, une fois les premiers texels reçus, les texels suivants sont disponibles au cycle suivant, et ainsi de suite. En clair, les données lues mettent du temps avant d'arriver, mais elles arrivent par gros paquets une fois ce temps d'attente passé.

La différence entre débit et temps d'accès est primordiale sur les GPU modernes comme anciens. Toute l'architecture de la carte graphique est conçue de manière à prendre en compte ce temps d'attente. Les techniques employées sont multiples, et ne sont pas inconnues à ceux qui ont déjà lu un cours d'architecture des ordinateurs : mémoire caches, hiérarchie de caches, ''multithreading'' matériel au niveau du processeur, optimisations des accès mémoire comme des ''Load-Store Queues'' larges, des ''coalesing write buffers'', etc. Mais toutes ces techniques sont techniquement incorporées dans les processeurs de ''shaders'' et dans les circuits fixes. Aussi nous ne pouvons pas en parler dans ce chapitre. A une exception près : l'usage de caches et de ''local stores''.

==Les caches d'un GPU==

Les cartes graphiques sont censées avoir peu de caches. Les anciennes cartes graphiques se débrouillaient avec des caches spécialisés pour les textures ou pour les sommets, ce qui leur vaut les noms de caches de texture et de cache de sommets. Ce n'est que par la suite, quand les GPU commencèrent à être utilisés pour du calcul généraliste (scientifique, notamment), que la situation changea. Les GPU utilisèrent alors de plus en plus de caches généralistes, capables de stocker n'importe quelle forme de données.

Les caches en question sont intégrés dans les processeurs de ''shaders'' sur les GPU modernes. Même les caches de texture ou de sommets. Les deux sont d'ailleurs fusionnés sur les GPU modernes, vu que leur jeu d'instruction est unifié et qu'ils peuvent exécuter aussi bien des ''vertex shaders'' que des ''pixel shaders''. Sur les GPU plus anciens, avec des circuits fixes, ces caches étaient intégrés aux circuits non-programmables de gestion des textures et de la géométrie. Les caches de sommet et de texture étaient alors séparés.

===Le cache de textures===

Le '''cache de textures''', comme son nom l'indique, est un cache spécialisé dans les textures. Toutes les cartes graphiques modernes disposent de plusieurs unités de texture, qui disposent chacune de son ou ses propres caches de textures. Pas de cache partagé, ce serait peu utile et trop compliqué à implémenter.

De plus, les cartes graphiques modernes ont plusieurs caches de texture par unité de texture. Généralement, elles ont deux caches de textures : un petit cache rapide, et un gros cache lent. Les deux caches sont fortement différents. L'un est un gros cache, qui fait dans les 4 kibioctets, et l'autre est un petit cache, faisant souvent moins d'1 kibioctet. Mais le premier est plus lent que le second. Sur d'autres cartes graphiques récentes, on trouve plus de 2 caches de textures, organisés en une hiérarchie de caches de textures similaire à la hiérarchie de cache L1, L2, L3 des processeurs modernes.

Notons que ce cache interagit avec les techniques de compression de texture. Les textures sont en effet des images, qui sont donc compressées. Et elles restent compressées en mémoire vidéo, car les textures décompressées prennent beaucoup plus de place, entre 5 à 8 fois plus. Les textures sont décompressées lors des lectures : le processeur de shaders charge quelques octets, les décompresse, et utilise les données décompressées ensuite. Le cache s'introduit quelque part avant ou après la décompression.

On peut décompresser les textures avant de les placer dans le cache, ou laisser les textures compressées dans le cache. Tout est une question de compromis. Décompresser les textures dans le cache fait que la lecture dans le cache est plus rapide, car elle n'implique pas de décompression, mais le cache contient moins de données. A l'inverse, compresser les textures permet de charger plus de données dans le cache, mais rend les lectures légèrement plus lentes. C'est souvent la seconde solution qui est utilisée et ce pour deux raisons. Premièrement, la compression de texture est terriblement efficace, souvent capable de diviser par 6 la taille d'une texture, ce qui augmente drastiquement la taille effective du cache. Deuxièmement, les circuits de décompression sont généralement très rapides, très simples, et n'ajoutent que 1 à 3 cycles d'horloge lors d'une lecture.

Les anciens jeux vidéo ne faisaient que lire les textures, sans les modifier. Aussi, le cache de texture des cartes graphiques anciennes est seulement accessible en lecture, pas en écriture. Cela simplifiait fortement les circuits du cache, réduisant le nombre de transistors utilisés par le cache, réduisant sa consommation énergétique, augmentait sa rapidité, etc. Mais les jeux vidéos 3D récents utilisent des techniques dites de ''render-to-texture'', qui permettent de calculer certaines données et à les écrire en mémoire vidéo pour une utilisation ultérieure. Les textures peuvent donc être modifiées et cela se marie mal avec un cache en lecture seule.

Rendre le cache de texture accessible en écriture est une solution, mais qui demande d'ajouter beaucoup de circuits pour une utilisation somme toute peu fréquente. Une autre solution, plus adaptée, réinitialise le cache de textures quand on modifie une texture, que ce soit totalement ou partiellement. Une fois le cache vidé, les accès mémoire ultérieurs n'ont pas d'autre choix que d'aller lire la texture en mémoire et de remplir le cache avec les données chargées depuis la RAM. Les données de texture en RAM étant les bonnes, cela garantit l’absence d'erreur.

: Ces deux techniques peuvent être adaptées dans le cas où plusieurs caches de textures séparées existent sur une même carte graphique. Les écritures doivent invalider toutes les copies dans tous les caches de texture. Cela nécessite d'ajouter des circuits qui propagent l'invalidation dans tous les autres caches.

===Les caches généralistes===

La hiérarchie mémoire des GPU modernes ressemble à celle des CPU, avec une hiérarchie de caches. Pour rappel, les processeurs multicœurs modernes ont souvent trois à quatre niveaux de caches, appelés les caches L1, L2, L3 et éventuellement L4. Les GPU ont une organisation similaire, sauf que le nombre de cœurs est beaucoup plus grand que sur un processeur moderne.
* Pour le premier niveau, on a deux caches L1 par cœur/processeur : un cache pour les instructions et un cache pour les données.
* Pour le second niveau, on a un cache L2 qui peut stocker indifféremment données et instruction et qui est partagé entre plusieurs cœurs/processeurs.
* Le cache L3 est un cache partagé entre tous les cœurs/processeurs. 

[[File:Partage des caches sur un processeur multicoeurs.png|centre|vignette|upright=2|Partage des caches sur un processeur multicoeurs]]

Les caches d'instruction des GPU sont adaptés aux contraintes du rendu 3D. Le principe du rendu 3D est d'appliquer un shader assez simple sur un grand nombre de données. Les shaders sont donc des programmes assez légers, qui ont peu d'instructions. Les caches d'instructions des GPU sont généralement assez petits, quelques dizaines ou centaines de kilooctets. Et malgré cela, il n'est pas rare qu'un ''shader'' tienne tout entier dans le cache d'instruction.

La seconde caractéristique est qu'un même programme s’exécute sur beaucoup de données. Il n'est pas rare que plusieurs processeurs de shaders exécutent le même ''shader''. Aussi, certains GPU partagent un même cache d’instruction entre plusieurs processeurs de ''shader'', comme c'est le cas sur les GPU AMD d'architecture GCN où un cache d'instruction de 32 kB est partagé entre 4 cœurs.

Pour les caches de données, il faut savoir qu'un shader a peu de chances de réutiliser une donnée qu'il a chargé précédemment. Les processeurs de shaders ont beaucoup de registres, ce qui fait que si accès ultérieur à une donnée il doit y avoir, elle passe généralement par les registres. Cette faible réutilisation fait que les caches de données ne sont pas censé être très utiles. Il y a cependant des exceptions, qui expliquent que les cartes graphiques incorporent un cache de texture et un cache de sommet (pour le tampon de sommet).

Il faut noter que sur la plupart des cartes graphiques modernes, les caches de données et le cache de texture sont un seul et même cache. Même chose pour le cache de sommets, utilisé par les unités géométrique, qui est fusionné avec les caches de données. La raison est que une économie de circuits qui ne coute pas grand chose en termes de performance. Rappelons que les processeurs de shaders sont unifiés à l'heure actuelle, c'est à dire qu'elles peuvent exécuter pixel shader et vertex shader. Au lieu d'incorporer un cache de sommets et un cache de textures, autant utiliser un seul cache qui sert alternativement de cache de vertex et de cache de texture, afin d'économiser des circuits.

===Les caches de constante===

Un shader a besoin de certaines &quot;constantes&quot; pour faire son travail. Toutes les instances du shader manipulent ces constantes, les lisent, les copient dans des registres, etc. Les constantes en question sont d'accès peu fréquent, qui se limite souvent à un accès au début de chaque instance de shader, guère plus. Pour profiter du partage des constantes entre instances d'un shader, les GPU incorporent des '''caches de constantes''' pour accélérer l'accès à ces données. Ainsi, quand un shader lit une donnée, elle est chargée dans le cache de constante, ce qui fait que les autres instances liront ces constantes dans le cache.

Les caches de constante sont séparés des autres caches de données, car ce sont des données peu fréquemment utilisées, qui sont censées être évincées en priorité du cache de données, qui privilégie les données fréquemment lues/écrites. Avec un cache séparé, les constantes restent dans le cache. Au passage, ce cache de constante a des chances d'être partagé entre plusieurs cœurs, des cœurs différents ayant de fortes chances d’exécuter des instances différentes d'un même shader.

==La mémoire partagée : un ''local store''==

En plus d'utiliser des caches, les GPU modernes utilisent des ''local stores'', aussi appelés ''scratchpad memories''. Ce sont des mémoires RAM intermédiaires entre la RAM principale et les registres. Ces local stores peuvent être vus comme des caches, mais que le programmeur doit gérer manuellement. Dans la réalité, ce sont des mémoires RAM très rapides mais de petite taille, qui sont adressées comme n'importe quelle mémoire RAM, en utilisant des adresses directement.

[[File:Scratch-Pad-Memory.jpg|centre|vignette|upright=2.0|Scratch-Pad-Memory (SPM).]]

Sur les GPU modernes, chaque processeur de ''shader'' possède un unique ''local store'', appelée la '''mémoire partagée'''. Il n'y a pas de hiérarchie des ''local store'', similaire à la hiérarchie des caches.

[[File:Cuda5.png|centre|vignette|upright=2.0|Local stores d'un GPU.]]

La faible capacité de ces mémoires, tout du moins comparé à la grande taille de la mémoire vidéo, les rend utile pour stocker temporairement des résultats de calcul &quot;peu imposants&quot;. L'utilité principale est donc de réduire le trafic avec la mémoire centrale, les écritures de résultats temporaires étant redirigés vers les local stores. Ils sont surtout utilisés hors du rendu 3D, pour les applications de type GPGPU, où le GPU est utilisé comme architecture multicœurs pour du calcul scientifique.

===L'implémentation des ''local store''===

Vous vous attendez certainement à ce que je dise que les ''local store'' sont des mémoires séparées des mémoires caches et qu'il y a réellement des puces de mémoire RAM distinctes dans les processeurs de ''shaders''. Mais en réalité, ce n'est pas le cas pour tous les ''local store''. Le dernier niveau de ''local store'', la mémoire partagée, est bel et bien une mémoire SRAM à part des autres, avec ses propres circuits. Mais les cartes graphiques très récentes fusionnent la mémoire locale avec le cache L1.

L'avantage est une économie de transistors assez importante. De plus, cette technologie permet de partitionner le cache/''local store'' suivant les besoins. Par exemple, si la moitié du ''local store'' est utilisé, l'autre moitié peut servir de cache L1. Si le ''local store'' n'est pas utilisé, comme c'est le cas pour la majorité des rendu 3D, le cache/''local store'' est utilisé intégralement comme cache L1.

Et si vous vous demandez comment c'est possible de fusionner un cache et une mémoire RAM, voici comment le tout est implémenté. L'implémentation consiste à couper le cache en deux circuits, dont l'un est un ''local store'', et l'autre transforme le ''local store'' en cache. Ce genre de cache séparé en deux mémoires est appelé un ''phased cache'', pour ceux qui veulent en savoir plus, et ce genre de cache est parfois utilisés sur les processeurs modernes, dans des processeurs dédiés à l'embarqué ou pour certaines applications spécifiques.

Le premier circuit vérifie la présence des données à lire/écrire dans le cache. Lors d'un accès mémoire, il reçoit l'adresse mémoire à lire, et détermine si une copie de la donnée associée est dans le cache ou non. Pour cela, il utilise un système de tags qu'on ne détaillera pas ici, mais qui donne son nom à l'unité de vérification : l''''unité de tag'''. Son implémentation est très variable suivant le cache considéré, mais une simple mémoire RAM suffit généralement.

En plus de l'unité de tags, il y a une mémoire qui stocke les données, la mémoire cache proprement dite. Par simplicité, cette mémoire est une simple mémoire RAM adressable avec des adresses mémoires des plus normales, chaque ligne de cache correspondant à une adresse. La mémoire RAM de données en question n'est autre que le ''local store''. En clair, le cache s'obtient en combinant un ''local store'' avec un circuit qui s'occupe de vérifier de vérifier les succès ou défaut de cache, et qui éventuellement identifie la position de la donnée dans le cache.

[[File:Phased cache.png|centre|vignette|upright=1.5|Phased cache]]

Pour que le tout puisse servir alternativement de ''local store'' ou de cache, on doit contourner ou non l'unité de tags. Lors d'un accès au cache, on envoie l'adresse à lire/écrire à l'unité de tags. Lors d'un accès au ''local store'', on envoie l'adresse directement sur la mémoire RAM de données, sans intervention de l'unité de tags. Le contournement est d'autant plus simple que les adresses pour le ''local store'' sont distinctes des adresses de la mémoire vidéo, les espaces d'adressage ne sont pas les mêmes, les instructions utilisées pour lire/écrire dans ces deux mémoires sont aussi potentiellement différentes.

[[File:Hydride cache - local store.png|centre|vignette|upright=2.0|Hydride cache - local store]]

Il faut préciser que cette organisation en ''phased cache'' est assez naturelle. Les caches de texture utilisent cette organisation pour diverses raisons. Vu que cache L1 et cache de texture sont le même cache, il est naturel que les caches L1 et autres aient suivi le mouvement en conservant la même organisation. La transformation du cache L1 en hydride cache/''local store'' était donc assez simple à implémenter et s'est donc faite facilement.

{{NavChapitre | book=Les cartes graphiques
           | prev=La microarchitecture des processeurs de shaders
           | prevText=La microarchitecture des processeurs de shaders
           | next=La mémoire unifiée et la mémoire vidéo dédiée
           | netxText=La mémoire unifiée et la mémoire vidéo dédiée
}}{{autocat}}</text>
      <sha1>f1b9agrbbfhafxx543jc31hfk6mr2zb</sha1>
    </revision>
  </page>
  <page>
    <title>Wikilivres:GUS2Wiki</title>
    <ns>4</ns>
    <id>78643</id>
    <revision>
      <id>745416</id>
      <parentid>745137</parentid>
      <timestamp>2025-06-26T21:36:38Z</timestamp>
      <contributor>
        <username>Alexis Jazz</username>
        <id>81580</id>
      </contributor>
      <comment>Updating gadget usage statistics from [[Special:GadgetUsage]] ([[phab:T121049]])</comment>
      <origin>745416</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3796" sha1="5kfaosacpc6bqel582gheslkgg8ib5j" xml:space="preserve">{{#ifexist:Project:GUS2Wiki/top|{{/top}}|This page provides a historical record of [[Special:GadgetUsage]] through its page history. To get the data in CSV format, see wikitext. To customize this message or add categories, create [[/top]].}}
Les données suivantes sont en cache et ont été mises à jour pour la dernière fois le 2025-06-25T07:16:55Z. {{PLURAL:5000|1=Un seul|5000}} résultat{{PLURAL:5000||s}} au maximum {{PLURAL:5000|est|sont}} disponible{{PLURAL:5000||s}} dans le cache.
{| class=&quot;sortable wikitable&quot;
! Gadget !! data-sort-type=&quot;number&quot; | Nombre d’utilisateurs !! data-sort-type=&quot;number&quot; | Utilisateurs actifs
|-
|AncreTitres || 33 || 1
|-
|ArchiveLinks || 12 || 1
|-
|Barre de luxe || 36 || 2
|-
|BoutonsLiens || 42 || 1
|-
|CategoryAboveAll || 18 || 0
|-
|CategorySeparator || 23 || 1
|-
|CoinsArrondis || 100 || 2
|-
|CollapseSidebox || 36 || 1
|-
|CouleurContributions || 32 || 0
|-
|CouleursLiens || 25 || 0
|-
|DeluxeAdmin || 5 || 1
|-
|DeluxeEdit || 36 || 2
|-
|DeluxeHistory || 44 || 1
|-
|DeluxeImport || 19 || 1
|-
|DeluxeRename || 17 || 2
|-
|DeluxeSummary || 35 || 2
|-
|DevTools || 17 || 2
|-
|DirectPageLink || 25 || 2
|-
|Emoticons || 44 || 1
|-
|EmoticonsToolbar || 46 || 1
|-
|FastRevert || 37 || 2
|-
|FixArrayAltLines || 23 || 2
|-
|FlecheHaut || 67 || 2
|-
|GoogleTrans || 28 || 1
|-
|HotCats || 81 || 3
|-
|JournalDebug || 22 || 2
|-
|JournalEnTable || 2 || 2
|-
|LeftPaneSwitch || 5 || 1
|-
|ListeABordure || 30 || 2
|-
|LiveRC || 30 || 0
|-
|LocalLiveClock || 27 || 2
|-
|Logo || 41 || 0
|-
|MobileView || 17 || 2
|-
|NavigAdmin || 38 || 1
|-
|OngletEditCount || 45 || 1
|-
|OngletEditZeroth || 67 || 1
|-
|OngletGoogle || 28 || 2
|-
|OngletPurge || 55 || 1
|-
|OptimizedSuivi || 18 || 0
|-
|Popups || 59 || 0
|-
|RenommageCategorie || 6 || 2
|-
|RestaurationDeluxe || 12 || 1
|-
|RevertDiff || 36 || 4
|-
|ScriptAutoVersion || 17 || 2
|-
|ScriptSidebox || 32 || 1
|-
|ScriptToolbar || 43 || 1
|-
|SisterProjects || 16 || 1
|-
|SkinPreview || 4 || 1
|-
|Smart patrol || 3 || 2
|-
|SourceLanguage || 25 || 1
|-
|SousPages || 56 || 2
|-
|SpaceToolbar || 30 || 1
|-
|TableUnicode || 56 || 1
|-
|Tableau || 67 || 2
|-
|TitreDeluxe || 56 || 2
|-
|TitreHierarchique || 17 || 1
|-
|UTCLiveClock || 27 || 1
|-
|UnicodeEditRendering || 29 || 2
|-
|WikEd || 29 || 0
|-
|autonum || 1 || 0
|-
|massblock || 3 || 1
|-
|monBrouillon || 19 || 1
|-
|perpagecustomization || 17 || 1
|-
|recentchangesbox || 15 || 0
|-
|searchFocus || 18 || 0
|-
|searchbox || 30 || 2
|}
* [[Spécial:GadgetUsage]]
* [[m:Meta:GUS2Wiki/Script|GUS2Wiki]]
&lt;!-- data in CSV format:
AncreTitres,33,1
ArchiveLinks,12,1
Barre de luxe,36,2
BoutonsLiens,42,1
CategoryAboveAll,18,0
CategorySeparator,23,1
CoinsArrondis,100,2
CollapseSidebox,36,1
CouleurContributions,32,0
CouleursLiens,25,0
DeluxeAdmin,5,1
DeluxeEdit,36,2
DeluxeHistory,44,1
DeluxeImport,19,1
DeluxeRename,17,2
DeluxeSummary,35,2
DevTools,17,2
DirectPageLink,25,2
Emoticons,44,1
EmoticonsToolbar,46,1
FastRevert,37,2
FixArrayAltLines,23,2
FlecheHaut,67,2
GoogleTrans,28,1
HotCats,81,3
JournalDebug,22,2
JournalEnTable,2,2
LeftPaneSwitch,5,1
ListeABordure,30,2
LiveRC,30,0
LocalLiveClock,27,2
Logo,41,0
MobileView,17,2
NavigAdmin,38,1
OngletEditCount,45,1
OngletEditZeroth,67,1
OngletGoogle,28,2
OngletPurge,55,1
OptimizedSuivi,18,0
Popups,59,0
RenommageCategorie,6,2
RestaurationDeluxe,12,1
RevertDiff,36,4
ScriptAutoVersion,17,2
ScriptSidebox,32,1
ScriptToolbar,43,1
SisterProjects,16,1
SkinPreview,4,1
Smart patrol,3,2
SourceLanguage,25,1
SousPages,56,2
SpaceToolbar,30,1
TableUnicode,56,1
Tableau,67,2
TitreDeluxe,56,2
TitreHierarchique,17,1
UTCLiveClock,27,1
UnicodeEditRendering,29,2
WikEd,29,0
autonum,1,0
massblock,3,1
monBrouillon,19,1
perpagecustomization,17,1
recentchangesbox,15,0
searchFocus,18,0
searchbox,30,2
--&gt;</text>
      <sha1>5kfaosacpc6bqel582gheslkgg8ib5j</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/a26</title>
    <ns>0</ns>
    <id>79758</id>
    <revision>
      <id>745384</id>
      <parentid>745370</parentid>
      <timestamp>2025-06-26T14:09:32Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745384</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1501" sha1="hht2wwssrabp4jv4zl3sscnar4xvrv9" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/h08a| '''Propriétés et Applications''']]
:
:


'''L'étude de ce chapitre peut ce faire à l'aide de cette [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX Playlist]..'''
:
.
:
 {{Partie{{{type|}}}| '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}| Résoudre un système d'équations :}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a27| Gauss-Jordan]]}}
:
 {{Partie{{{type|}}}|[[Mathc complexes/a302| L'inverse]]}}
:
.
:
{{Partie{{{type|}}}| Application : '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/053| Analyse d'un '''réseau''' (avec des coefficients '''Réelles''')  ]]}}
:
 {{Partie{{{type|}}}|[[Mathc complexes/05a| Analyse d'un circuit '''électrique''' ]]}}
:
.
:
 {{Partie{{{type|}}}| '''Partial Pivoting''' }}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a35| Variables libres]]}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a157| Rendre un système '''compatibles''' en introduisant des paramètres]]}}
:
. 
:
 {{Partie{{{type|}}}| '''Les bases''' }}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a220| Trouver une base pour ... ]]}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/c233| Matrices de changement de base]]}} 
:
 {{Partie{{{type|}}}|[[Mathc complexes/03p|  Matrice d'une application linéaire par rapport à la base &quot;B&quot;]]}} 
:
.
:
 {{Partie{{{type|}}}| '''Les projections''' }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/a245| Projection sur un sous-espace vectoriel]]}} 
:

{{AutoCat}}</text>
      <sha1>hht2wwssrabp4jv4zl3sscnar4xvrv9</sha1>
    </revision>
    <revision>
      <id>745386</id>
      <parentid>745384</parentid>
      <timestamp>2025-06-26T14:13:58Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745386</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1537" sha1="6v86br08gglnn44589sdhl88t1jyp4d" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/h08a| '''Propriétés et Applications''']]
:
:


'''L'étude de ce chapitre peut ce faire à l'aide de cette [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX Playlist]..'''
:
.
:
 {{Partie{{{type|}}}| '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}| Résoudre un système d'équations :}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a27| Gauss-Jordan]]}}
:
 {{Partie{{{type|}}}|[[Mathc complexes/a302| L'inverse]]}}
:
.
:
{{Partie{{{type|}}}| Application : '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/053| Analyse d'un '''réseau''' (avec des coefficients '''Réelles''')]]}}
:
 {{Partie{{{type|}}}|[[Mathc complexes/05a| Analyse d'un circuit '''électrique''' (avec des coefficients '''Réelles''')]]}}
:
.
:
 {{Partie{{{type|}}}| '''Partial Pivoting''' }}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a35| Variables libres]]}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a157| Rendre un système '''compatibles''' en introduisant des paramètres]]}}
:
. 
:
 {{Partie{{{type|}}}| '''Les bases''' }}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a220| Trouver une base pour ... ]]}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/c233| Matrices de changement de base]]}} 
:
 {{Partie{{{type|}}}|[[Mathc complexes/03p|  Matrice d'une application linéaire par rapport à la base &quot;B&quot;]]}} 
:
.
:
 {{Partie{{{type|}}}| '''Les projections''' }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/a245| Projection sur un sous-espace vectoriel]]}} 
:

{{AutoCat}}</text>
      <sha1>6v86br08gglnn44589sdhl88t1jyp4d</sha1>
    </revision>
    <revision>
      <id>745457</id>
      <parentid>745386</parentid>
      <timestamp>2025-06-27T11:48:36Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745457</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1695" sha1="tih2rkv90oos96nt8w64nli09rsheo3" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/h08a| '''Propriétés et Applications''']]
:
:


'''L'étude de ce chapitre peut ce faire à l'aide de cette [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX Playlist]..'''
:
.
:
 {{Partie{{{type|}}}| '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}| Résoudre un système d'équations :}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a27| Gauss-Jordan]]}}
:
 {{Partie{{{type|}}}|[[Mathc complexes/a302| L'inverse]]}}
:
.
:
{{Partie{{{type|}}}| Application : '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/053| Analyse d'un '''réseau''' (avec des coefficients '''Réelles''')]]}}
:
 {{Partie{{{type|}}}|[[Mathc complexes/05a| Analyse d'un circuit '''électrique''' (avec des coefficients '''Réelles''')]]}}
:
.
:
 {{Partie{{{type|}}}| '''Partial Pivoting''' }}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a35| Variables libres]]}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a157| Rendre un système '''compatibles''' en introduisant des paramètres]]}}
:
.
:
{{Partie{{{type|}}}| Application : '''Partial Pivoting'''  }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/05h| Équilibrer une équation '''chimique''']]}}
:
.
:
 {{Partie{{{type|}}}| '''Les bases''' }}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a220| Trouver une base pour ... ]]}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/c233| Matrices de changement de base]]}} 
:
 {{Partie{{{type|}}}|[[Mathc complexes/03p|  Matrice d'une application linéaire par rapport à la base &quot;B&quot;]]}} 
:
.
:
 {{Partie{{{type|}}}| '''Les projections''' }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/a245| Projection sur un sous-espace vectoriel]]}} 
:

{{AutoCat}}</text>
      <sha1>tih2rkv90oos96nt8w64nli09rsheo3</sha1>
    </revision>
    <revision>
      <id>745460</id>
      <parentid>745457</parentid>
      <timestamp>2025-06-27T11:56:13Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745460</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1656" sha1="dus7kzn3bgy3jpbga9y03ebwnwgl1jy" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/h08a| '''Propriétés et Applications''']]
:
:


'''L'étude de ce chapitre peut ce faire à l'aide de cette [https://youtube.com/playlist?list=PLi6peGpf8EPMnU50SHdNTVMVm0C32g5ZX Playlist]..'''
:
.
:
 {{Partie{{{type|}}}| '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}| Résoudre un système d'équations :}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a27| Gauss-Jordan]]}}
:
 {{Partie{{{type|}}}|[[Mathc complexes/a302| L'inverse]]}}
:
.
:
{{Partie{{{type|}}}| Application : '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/053| Analyse d'un '''réseau''' dans '''R''']]}}
:
 {{Partie{{{type|}}}|[[Mathc complexes/05a| Analyse d'un circuit '''électrique''' dans '''R''']]}}
:
.
:
 {{Partie{{{type|}}}| '''Partial Pivoting''' }}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a35| Variables libres]]}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a157| Rendre un système '''compatibles''' en introduisant des paramètres]]}}
:
.
:
{{Partie{{{type|}}}| Application : '''Partial Pivoting'''  }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/05h| Équilibrer une équation '''chimique''' dans '''R''']]}}
:
.
:
 {{Partie{{{type|}}}| '''Les bases''' }}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/a220| Trouver une base pour ... ]]}}
:
 {{Partie{{{type|}}}|[[Mathc_complexes/c233| Matrices de changement de base]]}} 
:
 {{Partie{{{type|}}}|[[Mathc complexes/03p|  Matrice d'une application linéaire par rapport à la base &quot;B&quot;]]}} 
:
.
:
 {{Partie{{{type|}}}| '''Les projections''' }}
:
 {{Partie{{{type|}}}|[[Mathc complexes/a245| Projection sur un sous-espace vectoriel]]}} 
:

{{AutoCat}}</text>
      <sha1>dus7kzn3bgy3jpbga9y03ebwnwgl1jy</sha1>
    </revision>
  </page>
  <page>
    <title>Formation musicale/Caractéristiques et notation des sons musicaux</title>
    <ns>0</ns>
    <id>79814</id>
    <revision>
      <id>745456</id>
      <parentid>735660</parentid>
      <timestamp>2025-06-27T09:53:50Z</timestamp>
      <contributor>
        <username>Cdang</username>
        <id>1202</id>
      </contributor>
      <comment>/* Autres mesures */ 6/8 + 2/4</comment>
      <origin>745456</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="90113" sha1="8nzlplny4f21v9phguwl3dq6bqeodkc" xml:space="preserve">{{Bases de solfège}}

&lt;span style=&quot;font-size:25px;&quot;&gt;3. Caractéristiques et notation des sons musicaux&lt;/span&gt;
----

Nous avons vu précédemment que la musique était faite de sons organisés. Le musicien et la musicienne — compositeur et compositrice, interprète — veut donc produire des sons « calibrés », ayant des caractéristiques précises.

Nous pouvons distinguer trois caractéristiques fondamentales :
* le rythme ;
* la hauteur ;
* le timbre.
Nous évoquons ci-dessous des éléments de la notation dans la musique occidentale ; le sujet de la notation est étudié plus profondément au chapitre ''[[../Représentation musicale|Représentation musicale]]''.

== Le rythme ==

Le rythme désigne les instants auxquels sont émis les sons ainsi que leur durée.

L'humain possède naturellement cycles plus ou moins réguliers : battements du cœur, respiration, cycle de veille-sommeil… Certains sont nécessaire à la vie, d'autres sont une adaptation à un environnement ayant lui-même des cycles : alternance jour-nuit, cycle des saisons, cycle de la Lune et des marées.

Naturellement, un humain a une démarche régulière : l'alternance des pas est régulière. En absence de déficience psychomotrice (handicap, douleur), la durée de chaque pas est identique sur une courte période ; mais par moment, on peut être immobile, marcher lentement, rapidement ou courir. Par ailleurs, même une personne qui boite a un pas régulier : du fait de la claudication, les pas gauche et droit n'ont pas la même durée mais tous les pas gauches ont la même durée et tous les pas droits ont la même durée ; la succession « un pas gauche et un pas droit » a toujours la même durée sur une courte période.

De la même manière, la musique est en général rythmée. La durée du pas est appelée « pulsation ». La durée des sons est divisée en « temps », un temps a la durée d'une pulsation.

=== Tempo ===

Sur une partition, la durée de la pulsation est appelée « tempo ». L'indication tempo peut se faire avec un mot, en général italien comme ''{{lang|it|adagio}}'' (« à l'aise, doucement ») ou ''{{lang|it|allegro}}'' (« gai, allègre »), et/ou avec une indication de la pulsation en donnant le nombre de pulsation par minute : « ♩ = 60 » indique que l'on a soixante noires par minute (donc une noire par seconde).

=== Première approche de la notion ===

Pour appréhender la notion de rythme, nous pouvons utiliser la marche et des percussions. On choisit une percussion ayant un son grave et une percussion ayant un son aigu, par exemple :
* percussions corporelles : frappe du sternum (os au milieu de la poitrine) avec le poing ou le plat de la main pour le grave, frappe des mains pour l'aigu ;
* tambourin pour le grave et cymbales pour l'aigu ;
* deux types de clave ou de woodblock, un grave et un aigu ;
* …
Nous notons la percussion grave « poum » et la percussion aiguë « tzim ». Pour un groupe, la moitié a une percussion grave, l'autre une percussion aiguë, ce qui permet de travailler la synchronisation de groupe et la notion d'ensemble.

En marchant, on produit un son à chaque pas :
* en alternance sur deux pas '''grave'''/aigu/'''grave'''/aigu… : '''poum'''/tzim/'''poum'''/tzim …;
* en rythme de valse, alternance sur trois pas : '''grave'''/aigu/aigu/'''grave'''/aigu/aigu… : '''poum'''/tzim/tzim/'''poum'''/tzim/tim…
* en rythme de ''We Will Rock You'' (Queen, album ''News of the World'', 1977), alternance sur quatre pas : '''grave'''/'''grave'''/aigu/''silence''/'''grave'''/'''grave'''/aigu/''silence''… : '''poum'''/'''poum'''/tzim/''silence''/'''poum'''/'''poum'''/tzim/''silence''…
Cette déambulation peut se faire sur une musique adaptée ou en chantant. Par exemple, pour ''We Will Rock You'', on peut chanter les paroles du refrain ou bien d'autres paroles comme « On est content d'être là ». On peut aussi faire ces exercices assis, sans déambuler, une personne ou un métronome donnant la cadence.

{|
|+ Synchronisation des paroles et des rythmes sur ''We Will Rock You''
|-
| colspan=2  |''We''
| colspan=2  |''will''
| colspan=2  |''we''
| colspan=2  |''will''
| ''rock'' || ''you''
| colspan=2 | …
| colspan=4 | …
|-
| colspan=2  |On
| colspan=2  |est
| colspan=2  |con-
| colspan=2  |-tent
| d'êtr' || là
| colspan=2 | …
| colspan=4 | …
|-
| '''poum''' || '''poum''' || tzim || …
| '''poum''' || '''poum''' || tzim || …
| '''poum''' || '''poum''' || tzim || …
| '''poum''' || '''poum''' || tzim || …
|}

=== Rythmes à division binaires ===

Dans les rythme à division binaire, chaque temps se dévise en deux parties égales, appelées « demi-temps ».

==== Mesure à quatre temps ====

[[Fichier:Carre 4 pas apprentissage rythme.svg|vignette|upright=1.5|Le carré : figure à quatre pas utilisée pour l'apprentissage du rythme.]]

Pour appréhender la chose, commençons par une figure simple, le « carré » (voir image ci-contre) : on part pieds joints (0), on avance un pied (1), on amène l'autre pied à côté (2), on recule un pied (3) puis on amène le pied avant à côté de l'autre (4). Les pas doivent se faire de manière régulière, chaque pas ayant la même durée ; à la fin, nous sommes donc dans la même position qu'au début. C'est une figure à quatre pas, à quatre temps.

{{clear}}

Nous pouvons émettre des sons durant ce carré. Par exemple, nous commençons par faire le carré une fois en comptant les pas (« un, deux, trois, quatre ») sans frapper des mains (« a vide ») puis :
# Lors du premier carré, nous tapons des mains sur le temps 1.
# Lors du deuxième, nous tapons des mains sur les temps 1 et 3.
# Lors du troisième, nous tapons des mains à chaque temps.

Chaque carré (succession des pas 1-2-3-4) est appelé une « mesure ». Pour représenter les moments d'émission, pour les « coder », nous utilisons deux symboles :
* lorsque l'on tape des mains, on utilise une « noire », un rond noir avec une hampe : ♩ ;
* lorsque l'on ne tape pas des mains, on utilise un « soupir », une ligne verticale en zigzag 𝄽, [[Fichier:Crotchet rest alt plain-svg.svg|6px]].

{| class=&quot;wikitable&quot;
|+ Tableau d'interprétation
|-
! scope=&quot;col&quot; rowspan=&quot;2&quot; style=&quot;width:20%&quot; | Mesure
! scope=&quot;row&quot; colspan=&quot;4&quot; | Pas
|- align=&quot;center&quot;
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 1&lt;br /&gt;[[Fichier:Carre 4 pas apprentissage rythme pas1.svg]]
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 2&lt;br /&gt;[[Fichier:Carre 4 pas apprentissage rythme pas2.svg]]
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 3&lt;br /&gt;[[Fichier:Carre 4 pas apprentissage rythme pas3.svg]]
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 4&lt;br /&gt;[[Fichier:Carre 4 pas apprentissage rythme pas4.svg]]
|-
! scope=&quot;row&quot; | 0
| ''un'' || ''deux'' || ''trois'' || ''quatre''
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 1
| 👏 || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''  || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''  || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''
|- style=&quot;font-size:x-large;&quot;
| ♩ || 𝄽 || 𝄽 || 𝄽
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 2
| 👏 || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''  || 👏  || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''
|- style=&quot;font-size:x-large;&quot;
| ♩ || 𝄽 || ♩ || 𝄽
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 3
| 👏 || 👏  || 👏  || 👏
|- style=&quot;font-size:x-large;&quot;
| ♩ || ♩ || ♩ || ♩
|}
Le codage en musique classique est donc le suivant :
[[Fichier:Ligne rythme C noires et soupirs commentaires.svg|class=transparent|center|Ligne rythmique à 4/4 élémentaire : noires et soupirs.]]
La partition comporte :
* une longue ligne horizontale, pour écrire droit : c'est la « portée » ;
* un chiffrage « 4/4 », que l'on prononce « quatre-quatre » : le premier « 4 » indique qu'il y a quatre temps par mesure, le deuxième « 4 » représente les noires, il y a donc une noire par temps ; elle est aussi souvent chiffrée « C » ;
* des lignes verticales « 𝄀 » pour séparer les mesures, ce sont les « barres de mesure » ;
* les symboles définis ci-dessus : noires et soupirs ;
* une double barre de mesure « 𝄂 » pour indiquer la fin du morceau.
[[Fichier:Ligne rythme C noires et soupirs son.midi|thumb|Ligne rythmique à 4/4 élémentaire : noires et soupirs.]]
Vous pouvez écouter le résultat avec le fichier son ci-contre. Les pulsations marquant les temps (les pas) sont rendues par des coups de baguette. Le morceau commence par une mesure « à vide », avec juste des pulsations, afin de « prendre le rythme ».

Pour aider à la lecture, on peut mettre en place des marques de temps : on met un trait sous les signes qui correspondent aux temps.

[[Fichier:Ligne rythme C noires et soupirs marques temps.svg|class=transparent|center|Ligne rythmique à 4/4 élémentaire : noires et soupirs.]]

On peut varier l'exercice de la manière suivante :
* on marche en ligne droite ou en cercle au lieu de faire un carré ;
ou sans marcher :
* on marque les temps en frappant des mains (au lieu de faire des pas) ;
* on émet des sons par de claquements de langue ;
ou encore :
* on marque les temps en frappant la cuisse gauche de sa main gauche ;
* on émet des sons en frappant sa cuisse droite de sa main droite.
On peut ainsi s'adapter aux capacités motrices et de coordination selon les spécificités du public (âge, handicap…).

Les frappes de main ou les claquements de langue sont des sons courts. On peut à la place produire des sons longs en prononçant des syllabes, par exemple « pa » et « dou » :
* un son de quatre temps est codé par une « ronde », un rond blanc sans hampe, [[Fichier:1-1 note semibreve.svg|class=transparent|8px]] ;
* un son de deux temps est codé par une « blanche », un rond blanc avec hampe, [[Fichier:Blanche tête en bas.svg|class=transparent|8px]].
{| class=&quot;wikitable&quot;
|+ Tableau d'interprétation
|-
! scope=&quot;col&quot; rowspan=&quot;2&quot; style=&quot;width:20%&quot; | Mesure
! scope=&quot;row&quot; colspan=&quot;4&quot; | Pas
|- align=&quot;center&quot;
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 1&lt;br /&gt;[[Fichier:Carre 4 pas apprentissage rythme pas1.svg]]
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 2&lt;br /&gt;[[Fichier:Carre 4 pas apprentissage rythme pas2.svg]]
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 3&lt;br /&gt;[[Fichier:Carre 4 pas apprentissage rythme pas3.svg]]
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 4&lt;br /&gt;[[Fichier:Carre 4 pas apprentissage rythme pas4.svg]]
|-
! scope=&quot;row&quot; | 0
| ''un'' || ''deux'' || ''trois'' || ''quatre''
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 1
| pa- || -a- || -a- || -a
|- style=&quot;font-size:x-large;&quot;
| colspan=&quot;4&quot; align=&quot;left&quot; | 𝅝
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 2
| pa- || -a  || dou-  || -ou
|- style=&quot;font-size:x-large;&quot;
| colspan=&quot;2&quot; | 𝅗𝅥
| colspan=&quot;2&quot; | 𝅗𝅥
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 3
| pa || dou  || pa  || dou
|- style=&quot;font-size:x-large;&quot;
| ♩ || ♩ || ♩ || ♩
|}
Le codage est donc le suivant :
[[Fichier:Ligne rythme C ronde blanches noires marques temps et paroles.svg|class=transparent|center|Ligne rythmique à 4/4 élémentaire : ronde, blanches et noires.]]
ou, sans les marques de temps :
[[Fichier:Ligne rythme C ronde blanches noires paroles.svg|class=transparent|center|Ligne rythmique à 4/4 élémentaire : ronde, blanches et noires.]]

Comme la ronde dure quatre temps, il y a quatre marques de temps entre elle et la note suivante. De même, entre une blanche et la note suivante, il y a deux marques de temps.

'''Exercices'''

Pour la ligne rythmique suivante :
# Mettre en place les marques de temps.
# Remplir le tableau d'interprétation.
# Exécuter la partition (lire la partition à voix haute en respectant les durées et les syllabes).

[[Fichier:Ligne rythme C noires et soupirs contretemps syncope.svg|class=transparent|center|Ligne rythmique à 4/4 avec syncopes.]]

{| class=&quot;wikitable&quot;
|+ Tableau d'interprétation (à remplir)
|-
! scope=&quot;col&quot; rowspan=&quot;2&quot; style=&quot;width:20%&quot; | Temps
! scope=&quot;row&quot; colspan=&quot;4&quot; | Pas
|- align=&quot;center&quot;
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 1
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 2
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 3
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 4
|-
! scope=&quot;row&quot; | 0
| ''un'' || ''deux'' || ''trois'' || ''quatre''
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 1
| colspan=&quot;4&quot; align=&quot;center&quot; | …
|}

{{boîte déroulante/début|titre=Solution}}
[[Fichier:Ligne rythme C noires et soupirs contretemps syncope marques temps.svg|class=transparent|center|Ligne rythmique à 4/4 avec syncopes.]]

{| class=&quot;wikitable&quot;
|+ Tableau d'interprétation (solution)
|-
! scope=&quot;col&quot; rowspan=&quot;2&quot; style=&quot;width:20%&quot; | Temps
! scope=&quot;row&quot; colspan=&quot;4&quot; | Pas
|- align=&quot;center&quot;
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 1
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 2
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 3
! scope=&quot;col&quot; style=&quot;width:20%&quot; | 4
|-
! scope=&quot;row&quot; | 0
| ''un'' || ''deux'' || ''trois'' || ''quatre''
|-
! scope=&quot;row&quot; | 1
| pa || &amp;lt;''silence''&amp;gt; || &amp;lt;''silence''&amp;gt; || dou
|-
! scope=&quot;row&quot; | 2
| &amp;lt;''silence''&amp;gt; || pa || &amp;lt;''silence''&amp;gt; || dou
|-
! scope=&quot;row&quot; | 3
| &amp;lt;''silence''&amp;gt; || pa || dou || &amp;lt;''silence''&amp;gt;
|-
! scope=&quot;row&quot; | 4
| &amp;lt;''silence''&amp;gt; || &amp;lt;''silence''&amp;gt; || dou- || -ou
|-
! scope=&quot;row&quot; | 5
| pa || dou- || -ou || pa
|}
{{boîte déroulante/fin}}

La mesure à quatre temps est extrêmement répandue. Citons par exemple le premier mouvement ''Allegro maestoso'' de la ''Sonate pour piano n&lt;sup&gt;o&lt;/sup&gt; 8'' en ''la'' majeur de Wolfgang Amadeus Mozart (K. 310, 1777). La plupart des morceaux de musique jazz, rock ou pop sont écrits à 4/4 ; citons par exemple ''{{lang|en|Mack the Knife}}'', interprétation par Louis Armstrong de la chanson ''{{lang|de|Die Moritat von Mackie Messer}}'' de Kurt Weill pour ''L'Opéra de quat'sous'' (''{{lang|de|Die Dreigroschenoper}}'', 1928, livret de Bertolt Brecht).
* {{lien web
 |url=https://www.dailymotion.com/video/x55cb4c
 |titre=Mozart : Sonate pour piano n° 8 en la mineur K. 310 - I. Allegro maestoso Eloïse Bella Kohn
 | auteur = France Musique
 | site = Dailymotion
 | date = 2017 | consulté le = 2021-02-01
}}
* {{lien web
 |url=https://www.dailymotion.com/video/x7wv8nv
 |titre=Louis Armstrong Mack the Knife
 | auteur = laurentjohnny
 | site = Dailymotion
 | date = 2020 | consulté le = 2021-02-01
}}

==== Mesure à deux temps ====
La mesure à deux temps est la moitié d'une mesure à quatre temps. Elle est chiffrée « 2/4 » (deux noires par mesure), que l'on prononce « deux-quatre ». Voici un exemple de ligne rythmique à deux temps :

[[Fichier:Ligne rythme 2 4 noires et soupirs.svg|class=transparent|center|Ligne rythmique simple à 2/4.]]

Le morceau ''Marche militaire'' de Robert Schumann ''({{lang|de|Soldatenmarsch}})'', dans le cycle ''Album pour la jeunesse'' (''{{lang|de|Album für die Jugend}}'', 1848), est par exemple écrit à 2/4.
* {{lien web
 | url = https://www.youtube.com/watch?v=AQoDI_CVr-4
 | titre = Schumann - Soldatenmarsch Opus 68 no 2
 | auteur =  pticonful
 | site=YouTube
 | date = 2012-05-16 | consulté le = 2021-02-01
}}

==== Mesure à trois temps ====
Une mesure à trois temps se fait sur trois pas. Par exemple :
* départ pieds joints ;
* première mesure : trois pas en avant, arrivée pieds joints ;
* deuxième mesure : trois pas en arrière, arrivée pieds joints ;
* troisième mesure : trois pas en avant, arrivée pieds joints ;
* quatrième mesure : trois pas en arrière, arrivée pieds joints ;
* …
[[Fichier:Trois pas apprentissage rythme.svg|vignette|center|upright=2.5|Figure à trois pas utilisée pour l'apprentissage du rythme.]]
Les valses sont des exemples typiques de mesures à trois temps.

Nous pouvons par exemple interpréter l'exercice suivant ; par commodité, nous mettons deux mesures par ligne :

{| class=&quot;wikitable&quot;
|+ Tableau d'interprétation
|-
! scope=&quot;col&quot; rowspan=&quot;2&quot; style=&quot;width:16%&quot; | Mesure
! scope=&quot;row&quot; colspan=&quot;6&quot; | Pas
|- align=&quot;center&quot;
! scope=&quot;col&quot; style=&quot;width:14%&quot; | 1&lt;br /&gt;[[File:Trois pas apprentissage rythme pas 1.svg]]
! scope=&quot;col&quot; style=&quot;width:14%&quot; | 2&lt;br /&gt;[[File:Trois pas apprentissage rythme pas 2.svg]]
! scope=&quot;col&quot; style=&quot;width:14%&quot; | 3&lt;br /&gt;[[File:Trois pas apprentissage rythme pas 3.svg]]
! scope=&quot;col&quot; style=&quot;width:14%&quot; | 1&lt;br /&gt;[[File:Trois pas apprentissage rythme pas 4.svg]]
! scope=&quot;col&quot; style=&quot;width:14%&quot; | 2&lt;br /&gt;[[File:Trois pas apprentissage rythme pas 5.svg]]
! scope=&quot;col&quot; style=&quot;width:14%&quot; | 3&lt;br /&gt;[[File:Trois pas apprentissage rythme pas 6.svg]]
|-
! scope=&quot;row&quot; | 0
| ''un'' || ''deux'' || ''trois'' || ''un'' || ''deux'' || ''trois''
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 1 &lt;nowiki&gt;|&lt;/nowiki&gt; 2
| 👏 || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''  || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''  || 👏 || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''  || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''
|- style=&quot;font-size:x-large;&quot;
| ♩ || 𝄽 || 𝄽 ||| ♩ || 𝄽 || 𝄽 
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 3 &lt;nowiki&gt;|&lt;/nowiki&gt; 4
| 👏 || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''  || 👏  || 👏  || ''&lt;nowiki&gt;&lt;&lt;/nowiki&gt;silence&lt;nowiki&gt;&gt;&lt;/nowiki&gt;''  || 👏  
|- style=&quot;font-size:x-large;&quot;
| ♩ || 𝄽 || ♩ || ♩ || 𝄽 || ♩ 
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 5 &lt;nowiki&gt;|&lt;/nowiki&gt; 6
| 👏 || 👏  || 👏  || 👏 || 👏  || 👏
|- style=&quot;font-size:x-large;&quot;
| ♩ || ♩ || ♩ || ♩ || ♩ || ♩
|}

[[Fichier:Ligne rythme 3 4 noires et soupirs marques temps.svg|vignette|upright=2|Codage de l'exercice à trois temps ci-dessus.]]
Le chiffrage de la mesure est « 3/4 », « trois-quatre » : (trois noires par mesure). Pour le reste, la représentation est similaire aux mesures à quatre temps. Pour faciliter la lecture, nous pouvons là encore mettre des marques de temps sous la portée.

Nous pouvons ici aussi utiliser des blanches, mais il nous faut aussi une figure représentant trois temps : il s'agit de la « blanche pointée », une blanche suivie d'un point « 𝅗𝅥𝅭 ».

'''Exercice'''

Pour la ligne rythmique suivante :
# Mettre en place les marques de temps.
# Remplir le tableau d'interprétation.
# Exécuter la partition (lire la partition à voix haute en respectant les durées et les syllabes).

[[File:Ligne rythme 3 4 blanches noires et soupirs.svg|class=transparent|center|Ligne rythmique simple avec marques de temps et paroles.]]

{| class=&quot;wikitable&quot;
|+ Tableau d'interprétation (à remplir)
|-
! scope=&quot;col&quot; rowspan=&quot;2&quot; style=&quot;width:25%&quot; | Temps
! scope=&quot;row&quot; colspan=&quot;3&quot; | Pas
|- align=&quot;center&quot;
! scope=&quot;col&quot; style=&quot;width:25%&quot; | 1
! scope=&quot;col&quot; style=&quot;width:25%&quot; | 2
! scope=&quot;col&quot; style=&quot;width:25%&quot; | 3
|-
! scope=&quot;row&quot; | 0
| ''un'' || ''deux'' || ''trois''
|-
! scope=&quot;row&quot; rowspan=&quot;2&quot; | 1
| colspan=&quot;3&quot; align=&quot;center&quot; | …
|}

{{boîte déroulante/début|titre=Solution}}
[[File:Ligne rythme 3 4 blanches noires et soupirs marques temps.svg|class=transparent|center|Ligne rythmique simple avec marques de temps et paroles.]]

{| class=&quot;wikitable&quot;
|+ Tableau d'interprétation (solution)
|-
! scope=&quot;col&quot; rowspan=&quot;2&quot; style=&quot;width:25%&quot; | Temps
! scope=&quot;row&quot; colspan=&quot;3&quot; | Pas
|- align=&quot;center&quot;
! scope=&quot;col&quot; style=&quot;width:25%&quot; | 1
! scope=&quot;col&quot; style=&quot;width:25%&quot; | 2
! scope=&quot;col&quot; style=&quot;width:25%&quot; | 3
|-
! scope=&quot;row&quot; | 0
| ''un'' || ''deux'' || ''trois''
|-
! scope=&quot;row&quot; | 1
| pa- || -a- ||-a
|-
! scope=&quot;row&quot; | 2
| pa- || -a || dou
|-
! scope=&quot;row&quot; | 3
| pa || dou- || -ou
|-
! scope=&quot;row&quot; | 4
| pa- || -a || &amp;lt;''silence''&amp;gt;
|-
! scope=&quot;row&quot; | 5
| &amp;lt;''silence''&amp;gt; || dou- || -ou
|}
{{boîte déroulante/fin}}

Par exemple, le morceau de Robert Schumann ''Curieuse histoire ({{lang|de|Kuriose Geschichte}})'', du recueil ''Scènes d'enfants'' (''{{lang|de|Kinderszenen}}'', 1838), est écrit en 3/4. C'est également le cas de certaines danses comme les menuets ou les valses, et de leur descendantes les javas ; citons par exemple ''le Beau Danube bleu'' (''{{lang|de|An der schönen blauen Donau}}'', 1866) de Johann Strauss fils ou encore les valses de Django Reinhardt. Les scherzos sont aussi à trois temps, comme par exemple ''L'Apprenti sorcier'' de Paul Dukas (1897).
* {{lien web
 | url = https://www.youtube.com/watch?v=DghL45KLeBo
 | titre = Schumann: Kinderszenen, Op.15 - 2. Kuriose Geschichte
 | auteur = Martha Argerich
 | site = YouTube
 | date = 2018-12-12 | consulté le = 2021-02-01
}}
* {{lien web
 | url = https://www.dailymotion.com/video/x7d11o
 | titre = Karajan Le beau danuble bleu Johann Strauss
 | auteur = richardvallouise
 | site = Dailymotion
 | date = 2009 | consulté le = 2021-02-01
}}
* {{lien web
 | url = https://www.youtube.com/watch?v=2bqP32YUZtE
 | titre = VALSE A DJANGO acoustic &amp; electric version
 | auteur =  melekscorpions
 | site = YouTube
 | date = 2014-09-30 | consulté le = 2021-02-01
}}
* {{lien web
 | url=https://www.youtube.com/watch?v=sZ4AM0ayFBA
 | titre=Menuet des Trompettes - Lully
 | auteur=Cadmus1000
 | site=YouTube
 | date=2017-08-07 | consulté le=2021-02-01
}}
* {{lien web
 | url=https://www.dailymotion.com/video/x7yj4uo
 | titre=Dukas : L'Apprenti sorcier (Orchestre national de France)
 | auteur=France musique
 | site=Dailymotion
 | date=2021-01-07 | consulté le=2021-02-01
}}
{{boîte déroulante/début|titre=Quelques standards de jazz à trois temps}}
{{colonnes|nombre=2|
* {{lang|en|''Circle''}}, Miles Davis (album {{lang|en|''Miles Smiles''}}, 1967) ;
* {{lang|en|''Barbara''}}, Horace Silver (album {{lang|en|''Silver ’n Brass''}}, 1975) ;
* {{lang|en|''Booker's Waltz''}}, Booker Little (album {{lang|en|''At the Five Spot''}}, 1961) ;
* {{lang|en|''Dungeon Waltz''}}, Booker Little (album {{lang|en|''Max Roach, the Little Brooker plus 4''}}, 1958) ;
* {{lang|en|''Fire Waltz''}}, Mal Waldron (album {{lang|en|''At the Five Spot''}}, 1961) ;
* {{lang|en|''Footprints''}}, Wayne Shorter (album {{lang|en|''Adam’s Apple''}}, 1966) ;
* {{lang|en|''Gravy Waltz''}}, Steve Allen et Ray Brown (1963) ;
* {{lang|en|''Katrina Ballerina''}}, Woody Shaw (album {{lang|en|''United''}}, 1981) ;
* {{lang|en|''Limbo''}}, Wayne Shorter (album de Miles Davis {{lang|en|''Sorcerer''}}, 1967) ;
* {{lang|en|''Lotus Blossom''}}, Billy Strayhorn (album de Duke Ellington {{lang|en|''Piano in the Background''}}, 1960 ; précédemment enregistré sous le titre {{lang|en|''Charlotte Russe''}} par Johnny Hodges and His Orchestra en 1951) ;
* {{lang|en|''Lover''}}, Richard Rogers et Lorenz Hart (film musical de Rouben Mamoulian {{lang|en|''Love Me Tonight''}}, 1932) ;
* {{lang|en|''Theme from Mr. Broadway''}}, Dave Brubeck (série télévisée de Garson Kanin {{lang|en|''Mr. Broadway''}}, 1964) ;
* {{lang|en|''Moon River''}}, Henry Mancini et Johnny Mercer (film de Blake Edwards ''Diamants sur canapé'', {{lang|en|''Breakfast at Tiffany’s''}}, 1961) ;
* {{lang|en|''Nature Boy''}}, eden ahbez (album {{lang|en|''The King Cole Trio (Vol. 3)''}} de Nat King Cole, 1948) ;
* {{lang|en|''Oh, What a Beautiful Mornin’''}} , Richard Rogers et Oscar Hammerstein II (comédie musicale {{lang|en|''Oklahoma!''}}, 1943) ;
* {{lang|en|''Question &amp; Answer''}}, Pat Metheny (album {{lang|en|''Question &amp; Answer''}}, 1990) ;
* {{lang|en|''Serenade to a Soul Sister''}}, Horace Silver (album {{lang|en|''Serenade to a Soul Sister''}}, 1968) ;
* {{lang|en|''Simone''}}, Frank Foster (album {{lang|en|''Leo Rising''}}, 1996) ;
* {{lang|en|''Summer in Central Park''}}, Horace Silver (album {{lang|en|''In Pursuit of the 27th Man''}}, 1973) ;
* {{lang|en|''What’ll I Do?''}}, Irving Berlin (1923).
}}
{{boîte déroulante/fin}}
{{boîte déroulante/début|titre=Quelques morceaux de musique populaire à trois temps}}
{{colonnes|nombre=2|
* la troisième partie du solo de {{lang|en|''Alexander the Great'', Iron Maiden}} (album ''{{lang|en|Somewhere in Time}}'', 1986) ;&lt;br /&gt;{{lien web
 | url=https://www.youtube.com/watch?v=6BH9HvZx3nI
 | titre=Alexander the Great (356-323 B.C.) (2015 Remaster)
 | auteur=Iron Maiden
 | site=YouTube
 | date=2018-11-14 | consulté le=2021-02-12
}}, de 4 min 52 sec. à 7 min 09 sec. ;
* ''Les Amoureux des bancs publics'', Georges Brassens (album ''Le Vent'', 1954) ;
* ''{{lang|en|Annie's Song}}'', John Denver (album ''{{lang|en|Back Home Again}}'', 1974) ;
* {{lang|en|''America'', Simon and Garfunkel}} (album {{lang|en|''Bookends''}}, 1968) ;&lt;br /&gt;{{lien web
 | url=https://www.youtube.com/watch?v=sFAoWwUwknc
 | titre=America (from The Concert in Central Park)
 | auteur=Simon and Garfunkel
 | site=YouTube
 | date=2015-08-25 | consulté le=2021-02-12
}} ;
* ''{{lang|de|Ballade von der Hanna Cash}}'', Bertold Brecht et Ernst Busch ;
* {{lang|en|''Bookends Theme'', Simon and Garfunkel}} (album {{lang|en|''Bookends''}}, 1968) ;&lt;br /&gt;{{lien web
 | url=https://www.youtube.com/watch?v=MCdNqQN4BCU
 | titre=Bookends Theme (Reprise)
 | auteur=Simon and Garfunkel
 | site=YouTube
 | date=2017-02-18 | consulté le=2021-02-12
}} ;
* ''La Butte rouge'', Montéhus et Georges Krier (1923) ;
* ''{{lang|en|Catch the Wind}}'', Donovan (1965) ;
* ''{{lang|es|La Cucaracha}}'', traditionnel espagnol ;
* ''{{lang|de|Denn Ich Will}}'',  Richard Schönherz et Manuel Rigoni (album ''{{lang|de|Neue LIeder}}'', 1973) ;
* ''{{lang|de|Hamburger Süßholz}}'', Walter Moßmann ;
* ''Hiroshima'', Georges Moustaki (album ''Danse'', 1972) ;
* ''La Java bleue'', Géo Koger, Noël Renard et Vincent Scotto (Fréhel, dans le film ''Une Java'' de Claude Orval, 1939) ;
* ''{{lang|en|Mary Hamilton (The Fower Maries}}'', traditionnel écossais ({{pc|xvi}}&lt;sup&gt;e&lt;/sup&gt; siècle) ;
* ''{{lang|en|Morning Has Broken}}'', Eleanor Farjeon sur l'air d'un traditionnel gallois ''Bunessan'' (1931) ;
* ''Morts les enfants'',  Renaud Séchan et Franck Langolff (Renaud, album ''Mistral gagnant'', 1986) ;
* ''{{lang|en|Norwegian Wood (This Bird Has Flown)}}'', John Lennon et Paul McCartney (The Beattles, album ''{{lang|en|Rubber Soul}}'', 1965) ;
* {{lang|en|''Old Friends'', Simon and Garfunkel}} (album {{lang|en|''Bookends''}}, 1968) ;&lt;br /&gt;{{lien web
 | url=https://www.youtube.com/watch?v=6YpK-qrGQrg
 | titre=Old Friends / Bookends (from The Concert in Central Park)
 | auteur=Simon and Garfunkel
 | site=YouTube
 | date=2015-08-25 | consulté le=2021-02-12
}} ;
* ''La Peur (Un chat qui miaule)'', Georges Zwingel et René PesentiZwingel, interprété par Fréhel (1935) ;
* {{lang|en|''Prodigal Son''}}, Iron Maiden (album {{lang|en|''Killers''}}, 1982) ;
* {{lang|en|''The Rose of Tralee''}}, Charles et Stephen Glover (1840-1850) ;
* {{lang|en|''Scarborough Fair''}}, traditionnel anglais ; écouter par exemple la version de {{lang|en|Simon and Garfunkel}} (album ''{{lang|en|Parsley, Sage, Rosemary and Thyme}}'', 1966) ;&lt;br /&gt;{{lien web
 | url=https://www.youtube.com/watch?v=4Ccgk8PXz64
 | titre=Scarborough Fair (from The Concert in Central Park)
 | auteur=Simon and Garfunkel
 | site=YouTube
 | date=2015-08-25 | consulté le=2021-02-12
}} ;
* ''{{lang|en|Senjustu}}'', Iron Maiden (album ''{{lang|en|Senjustu}}'', 2021) ;&lt;br /&gt;{{lien web
 | url=https://www.youtube.com/watch?v=vxgTpbKUANQ
 | titre=Iron Maiden - Senjutsu (Official Audio)
 | auteur= Iron Maiden
 | site=YouTube
 | date=2021-09-03 | consulté le=2024-05-21
}} ;
* ''{{lang|en|Strange World}}'', Iron Maiden (album ''{{lang|en|Iron Maiden}}'', 1980) ;&lt;br /&gt;{{lien web
 | url=https://www.youtube.com/watch?v=ZKPojGi0aKw
 | titre=Iron Maiden - Strange World (1998 Remastered Version) #07
 | auteur=The Grande
 | site=YouTube
 | date=2016-09-20 | consulté le=2024-05-21
}} ;
* {{lang|en|''Still Life''}}, Iron Maiden (album {{lang|en|''Piece of Mind''}}, 1983) ;
* ''{{lang|en|The Times They Are a-Changin'}}'', Bob Dylan (album  ''{{lang|en|The Times They Are a-Changin'}}'', 1964) ;
* ''La Valse brune'', Georges Krier (première interprétation par Georges Villard, 1909);&lt;br /&gt;{{lien web
 | url=https://www.youtube.com/watch?v=fhDviOycn7k
 | titre=La Valse brune
 | auteur=Lucienne Delyle
 | site=YouTube
 | date=2016-01-08 | consulté le=2021-02-12
}} ;
* ''{{lang|es|Vientos del Pueblo}}'', Víctor Jara (album ''{{lang|es|Manifiesto}}'', 1973) ;
* ''{{lang|de|Der Volspolizist}}'', chant de l'Organisation des pionniers Ernst Thälmann (2&lt;eup&gt;2&lt;/sup&gt; moitié du {{pc|xx}}&lt;sup&gt;e&lt;/sup&gt; siècle).
}}
{{boîte déroulante/fin}}

==== Divisions du temps ====
Les mesures présentées ci-dessus s'appellent « à division binaires » car le temps se divise en deux parties égales, en deux demi-temps. Une note d'un demi-temps est représentée par une croche : une croche seule est une note noire avec une hampe en crochet, &lt;span style=&quot;font-size:large&quot;&gt;♪&lt;/span&gt; ; mais on peut regrouper plusieurs croches et les hampes sont alors reliées par une barre de ligature, &lt;span style=&quot;font-size:large&quot;&gt;♫&lt;/span&gt;, on parle alors de « croches ramées ».

Le silence d'un demi-temps est représenté par un « sept » &lt;span style=&quot;font-size:large&quot;&gt;𝄾&lt;/span&gt;.

==== Représentation par des barres ====
[[Fichier:Figures notes comme barres.svg|vignette|Quelques figures de note représentées par des longueurs de barre.]]

[[Fichier:Computer music piano roll.png|vignette|Le rouleau de piano est utilisé de nos jours sous forme numérique dans certains logiciels de musique.]]

On représente fréquemment une durée par une barre d'une certaine longueur ; c'est par exemple la méthode utilisée pour les frises historiques (ou frise chronologique). On peut donc représenter les figures de note par des barres de différente longueur. Ainsi, la barre représentant la blanche est deux fois plus longue que la barre représentant la noire, et la croche est représentée par une barre dont la longueur est la moitié de celle de la noire.

Ce principe de représentation a été proposé par le philosophe Karl Christian Friedrich Krause au {{pc|xix}}{{e}} siècle et est utilisé par le papier perforé qui sert pour les orgues de Barbarie et les pianos mécaniques (rouleau de piano). Il est utilisé aujourd'hui par certains jeux sur console, PC ou écran tactile (smartphone, tablette) comme ''{{lang|en|Guitar Hero}}'', ''{{lang|en|Piano Music Go!}}'' ou ''{{lang|en|Magic Tiles}}''.

De nombreuses applications pour « apprendre à jouer du piano » utilisent également cette notation de « rouleau de piano » comme ''La Touche musicale'', ''{{lang|en|Online Pianist}}'', ''Synthesia'' ou ''Pianu''.

{{clear}}

=== Rythmes à division ternaire ternaires ===

[[Fichier:Ligne rythme 6 8 noires pointees croches et silences marques temps.svg|vignette|Exemple de mesures à 6/8 avec les marques de temps.]]

[[Fichier:Figures notes comme barres ternaire.svg|vignette|Quelques figures de note ternaires représentées par des longueurs de barre.]]

Les mesures à division ternaires sont des mesures pour lesquelles le temps est divisé en trois parties égales. Le numérateur (chiffre du haut) du chiffrage est un 3, 6, un 9 ou un 12. Le dénominateur (chiffre du bas) est en général un 8, représentant la croche.

Par exemple, une mesure à « 6/8 », que l'on prononce « six-huit », est une mesure comportant six croches. C'est une mesure à deux temps ternaires, chaque temps comportant trois croches.

Puisqu'un temps dure trois croches, la figure qui remplit un temps est la noire pointée, c'est-à-dire une noire suivie d'un point « 𝅘𝅥𝅭 ». Le silence équivalent est le soupir pointé « 𝄽𝅭 ».

Une mesure à « 9/8 », « neuf-huit », est une mesure à trois temps ternaires : elle comporte neuf croches regroupées en trois noires pointées. Une mesure à « 12/8 », « douze-huit », est une mesure à quatre temps ternaires : elle comporte douze croches regroupées en quatre noires pointées.

=== Mélange de division binaire et ternaire ===
Dans une mesure à division binaire, il est possible d'introduire du ternaire donc de diviser un temps en trois notes de durée égale. On appelle ceci un « triolet » ; on place pour cela un « 3 » au-dessus ou en dessous du groupe de trois croches.

Dans une mesure à division ternaire, il est possible de diviser un temps en deux ; il suffit d'utiliser pour cela des croches pointées « 𝅘𝅥𝅮𝅭 ». On peut aussi utiliser deux croches et placer un « 2 » au-dessus ou en dessous, cela porte alors le nom de « duolet ».

Ce mélange division binaire/ternaire est appelé de manière générale « hémiole ».

L'hémiole peut aussi concerne un mélange de mesures binaires et ternaires. Dans le Baroque par exemple, on a fréquemment des hémioles en fin de phrases : deux mesures à trois temps (3/4) sont interprétées comme trois mesures à deux temps (2/4). Sur les deux mesures à 3/4, on n'a pas deux accents (un sur chaque premier temps de mesure), mais trois accents : un sur le premier temps de la première mesure, un sr le troisième temps de la première mesure, et un sur le deuxième temps de la deuxième mesure.

; Exemple d'hémiole en Baroque (deux dernières mesures)
:  &lt;score raw=&quot;1&quot; lang=&quot;lilypond&quot;&gt;
\version &quot;2.18.2&quot;

\paper {
  indent = #0
  paper-width = #200
}

\header {
  tagline = ##f
}

\score {
  \new Staff \relative c'' {
    \clef &quot;G&quot;
    \time 3/4
    c4-&gt; d e
    e-&gt; d e
    c-&gt; d b4-&gt;~
    b c2-&gt; \bar &quot;|.&quot;
  }
  
  \layout {}
  \midi {}
}
&lt;/score&gt;

En jazz, il est fréquent de prendre un morceau à trois temps (3/4) et de le jouer comme un morceau à quatre temps (12/8) : on décompose chaque mesure à 3 temps en deux temps égaux. Typiquement, une mesure à 3/4 est composée de deux noires pintées ; les 6 croches sont regroupées par 3 et non par 2. C'est quelque chose qui se fait fréquemment avec des morceaux comme ''Footprints'' de Wayne Shorter (album ''Adam's Apple'', 1966) et ''Afro Blue'' de Mango Santamaria (1959).

; Exemple d'hémiole en jazz (3/4 joué à 12/8)
:  &lt;score raw=&quot;1&quot; lang=&quot;lilypond&quot;&gt;
\version &quot;2.18.2&quot;

\paper {
  indent = #0
  paper-width = #200
}

\header {
  tagline = ##f
}

\score {
  \new Staff \relative c'' {
    \clef &quot;G&quot;
    \time 3/4
    \repeat &quot;unfold&quot; 2{g8-&gt; [ ( g ] g ) g-&gt; ( g [ g ])} \bar &quot;||&quot;
    \repeat &quot;unfold&quot; 2{g4. g} \bar &quot;||&quot;
  }
  
  \layout {}
  \midi {}
}
&lt;/score&gt;

=== Prolongation des durées ===
La division, binaire ou ternaire, donne un nombre fini de durées possibles, essentiellement :
* en binaire : 4 temps, deux temps, un temps, un demi-temps, un quart de temps ;&lt;br /&gt;si le temps est représenté par une noire, alors les figures correspondantes sont la ronde, la blanche, la noire, la croche, la double-croche et les silences équivalents ;
* en ternaire : 4 temps, deux temps, un temps, deux tiers de temps, un tiers de temps, un sixième de temps ;&lt;br /&gt;si le temps est représenté par une noire pointée, alors les figures correspondantes sont la ronde pointée, la blanche pointée, la noire pointée, la noire, la croche, la double-croche et les silences équivalents.
De manière plus générale, le point de prolongation permet d'augmenter la durée d'une note de la moitié de sa valeur :
* de manière générale :
** ronde = 2 blanches, ronde pointée = 1 ronde et 1 blanche,
** blanche = 2 noires, blanche pointée = 1 blanche et 1 noire,
** noire = 2 croches, noire pointée = 1 noire et 1 croche,
** croche = 2 double croches, croche pointée = 1 croche et 1 double croche ;
* en binaire, si noire = 1 temps, alors :
** ronde pointée = 3 blanches = 6 temps,
** blanche pointée = 3 noires = 3 temps,
** noire pointée = 3 croches = 1 temps ½,
** croche pointée = 3 double croches = ¾ de temps ;
* en ternaire, si noire pointée = 1 temps :
** ronde pointée = deux blanches pointées = 4 temps,
** blanche pointée = 2 noires pointées = 2 temps ;
** noire pointée = 3 croches = 1 temps ;
** croche pointée = ½ temps.
On peut mettre un double point : on ajoute à la valeur la moitié de sa valeur (pour le premier point) puis le quart de sa valeur (la moitié de la moitié de sa valeur, pour le second point). Par exemple, ronde doublement pointée vaut une ronde plus une blanche (moitié de la ronde) plus une noire (quart de la ronde).

L'autre manière d'augmenter les durées consiste à lier des notes par une liaison de prolongation. La liaison de prolongation se présente comme un arc, une parenthèse horizontale entre ''deux notes de même hauteur'' : « ︵ » ou « ︶ ». Si deux noires de même hauteur sont liées « 𝅘𝅥‿𝅘𝅥 », alors on obtient une note dont la durée est deux noires, c'est-à-dire une blanche ; on peut ainsi avoir des notes qui sont à cheval entre deux mesures.

Les valeurs pointées peuvent donc se noter également par des liaisons de prolongation : une noire pointée peut de noter par une noire liée à une croche, « 𝅘𝅥‿𝅘𝅥𝅮 ». Là encore, cela permet de prolonger les durées à cheval sur une barre de mesure ; la notation avec une liaison est aussi plus explicite que la notation pointée, et donc plus facilement lisible pour les débutants ou dans des situations un peu complexes.

=== Autres mesures ===
Les mesures dont le numérateur est « 2 », « 3 » ou « 4 » sont donc des mesures binaires, et celles dont les numérateurs sont « 6 », « 9 » ou « 12 » sont des mesures ternaires. Ce sont les six types de mesure les plus utilisées en musique occidentale.

Mais dans la musique orientale, on trouve des mesures avec des nombres de temps par mesure différents. On peut avoir une mesure à cinq temps, par exemple « 5/4 » ; on peut le voir comme une mesure à « 3/4 » suivie d'une mesure à « 2/4 », ou le contraire. Par exemple, les morceaux ''{{lang|en|Take Five}}'' de Paul Desmond (Dave Brubeck Quartet, album ''{{lang|en|Time Out}}'', 1959), et ''One for the Road'' de Judas Priest (album ''Killing Machine'', 1978), sont à cinq temps. C'est aussi le cas du générique de la série télévisée ''Mission Impossible'', composé par Lalo Schifrin en 1966 dont le rythme caractéristique est indiqué ci-dessous ; la mesure à 5/4 est séparée en deux sous-mesures à 6/8 et 2/4 par une barre de mesure pointillée, on peut donc la voir comme une mesure à quatre temps inégaux (deux temps ternaires et deux temps binaires, ♩𝅭 ♩𝅭 ♩ ♩).

[[Fichier:Ligne rythme 5 4 decomposee 3 4 et 2 4.svg|class=transparent|center|Ligne rythmique à 5/4 décomposée en sous-mesures à 3/4 et 2/4.]]

Le morceau ''{{lang|en|Money}}'' de Pink Floyd (album ''{{lang|en|The Dark Side of the Moon}}'', 1973) est à sept temps, une mesure étant formée de la succession d'une mesure à 3/4 et d'une mesure à 4/4.

[[Fichier:Ligne rythme 7 4 decomposee 3 4 et 4 4.svg|class=transparent|center|Ligne rythmique à 7/4 décomposée en sous-mesures à 3/4 et 4/4.]]

Le morceau ''{{lang|en|Blue Rondo a la Turk}}'' de Dave Brubeck (Dave Brubeck Quartet, album ''{{lang|en|Time Out}}'', 1959) est à neuf temps mais ce n'est pas une mesure à trois temps ternaires : c'est une mesure à quatre temps inégaux composée de trois temps binaires et un temps ternaire (donc 2 + 2 + 2 + 3 = 9 croches), notée « 2 + 2 + 2 + 3/8 » ou bien « 4 + 2 + 3/8 ». Cette mesure provient d'une danse turque, le karsilamas ''({{lang|tr|karşılama}})'', d'où le « à la turc ». De Turquie, ces rythmes ont diffusé dans les Balkans, on les retrouve par exemple chez Béla Bartók, notamment dans certaines pièces de la suite ''Mikrokosmos'' (1939).
* {{lien web
 | url=https://www.youtube.com/watch?v=PHdU5sHigYQ
 | titre=Dave Brubeck - Take Five (Original Video)
 | auteur=TheDathi
 | site=YouTube
 | consulté le=2021-01-30
}}
* {{lien web
 | url=https://www.youtube.com/watch?v=-0kcet4aPpQ
 | titre=Pink Floyd - Money (Official Music Video)
 | auteur=Pink Floyd
 | site=YouTube
 | date = 2014-06-25 | consulté le=2021-07-31
}}
* {{lien web
 | url=https://www.youtube.com/watch?v=fjgjU9C8UUc
 | titre=Lalo Schifrin - Mission Impossible - Live
 | auteur=vv0422
 | site=YouTube
 | date=2011-10-24 | consulté le=2021-01-30
}}
* {{lien web
 | url=https://www.youtube.com/watch?v=s8E5A27PJHk
 | titre=Dave Brubeck Quartet - Blue Rondo a la Turk
 | auteur=Charley Holland
 | site=Youtube
 | consulté le=2021-01-30
}}
* {{lien web
 | url=https://www.youtube.com/watch?v=uMs8K9sZ2Qg
 | titre=Bartok - 6 Dances in Bulgarian Rhythm from Mikrokosmos
 | auteur=Pentameron
 | site=YouTube
 | consulté le=2021-01-30
}}

Certains morceaux sont écrit dans une mesure donnée mais ont ponctuellement une mesure d’un chiffrage différent. Par exemple, dans le morceau ''{{lang|en|One}}'' de Metallica (album ''{{lang|en|…And Justice for All}}'', 1988), l'introduction à la guitare est faite d’un thème de sept mesures à 4/4 et d’une huitième mesure à 2/4 ; la troisième fois, la huitième mesure est à 4/4 puis la suite de l’introduction est à 3/4. Le couplet est composé de sept mesures à 3/4 et se termine par une huitième mesure à 2/4 :
: 3/4 𝄽 ''{{lang|en|I can’t remember}}'' | … | 𝄾 ''{{lang|en|this terrible silence}}'' | 2/4 ''{{lang|en|stops me}}''
Le refrain, quant à lui, se compose de trois mesures à 4/4.
* {{lien web
 | url=https://www.youtube.com/watch?v=WM8bTdBs-cw
 | titre=Metallica: One (Official Music Video)
 | auteur=Metallica
 | site=YouTube
 | consulté le=2021-07-19
}}

=== Tempo, pulsation ===
Le tempo désigne la vitesse d'exécution d'un morceau : un morceau peut être joué plus ou moins rapidement, donc avec un tempo lent ou un tempo rapide.

Le tempo est caractérisé par la pulsation ''({{lang|en|beat}})'' ; la pulsation est un phénomène cyclique, qui revient régulièrement, et qui indique quand doivent tomber les temps. La pulsation peut être donnée par une personne, par exemple le chef d'orchestre qui bat la mesure ou un des musiciens qui compte au début du morceau (« 1… 2… 1, 2, 3, 4 ») ; elle peut être donnée par un appareil appelé métronome qui émet un son (« tac » pour un métronome mécanique, « bip » pour un métronome électronique) et éventuellement a un mouvement (balancier d'un métronome mécanique). Un ou plusieurs instrumentistes peuvent avoir la responsabilité de donner la pulsation durant le morceau, typiquement la grosse caisse dans une fanfare ou la batterie dans un groupe de musique populaire.

Ci-dessous, nous représentons une ligne rythmique à 4/4 avec les pulsations marquées par un métronome.

[[Fichier:Ligne rythme C ronde blanches noires metronome.svg|class=transparent|center|Ligne de rythme simple en 4/4 avec pulsations du métronome sur chaque temps.]]

Sur une partition, le tempo peut être indiqué par un adjectif, souvent en italien : ''{{lang|it|largo}}'' (large, lent), ''{{lang|it|andante}}'' (allant), ''{{lang|it|allegro}}'' (allègre, gai)… Elle peut aussi être indiqué par un nombre, le nombre de pulsations par minute (BPM, ''{{lang|en|beats per minute}}'').

Le métronome est un outil important de l'apprentissage de la musique : il permet d'imposer une contrainte au musicien et de développer son sens de la régularité, ce qui lui servira lorsqu'il jouera en formation, avec d'autres musiciens. En jazz, on met souvent le métronome à la moitié de la pulsation indiquée, le métronome ne donnant pas chaque temps mais les temps 2 et 4 d'une mesure à quatre temps ; cela permet de travailler l'accentuation des temps faibles ''({{lang|en|afterbeats}})''.

Ci-dessous, nous représentons la même ligne rythmique mais avec des pulsations de métronome uniquement sur les temps faibles.

[[Fichier:Ligne rythme C ronde blanches noires metronome jazz.svg|class=transparent|center|Ligne de rythme simple en 4/4 avec pulsations du métronome sur les temps faibles.]]

=== Entre la régularité et la variation ===

Ci-dessus, nous avons considéré une pulsation régulière qui ne varie pas, et des sons émis sur les pulsations. La musique ne suit pas toujours ce schéma. Dans les partitions de plain-chant par exemple, il n'y a pas de mesure, d'indication de rapidité ni d'indication de durée des notes.

Par ailleurs, il y a parfois des accélérations (que l'on désigne par le terme italien ''{{lang|it|accelerando}}''), des ralentis (''{{lang|it|ritenuto}}'', ''{{lang|it|rallentando}}'' ou ''{{lang|it|ritardando}}'') ou des moments en suspens (point d'orgue, point d'arrêt, 𝄐). Dans certains cas, on s'attache à jouer exactement sur les pulsations ; dans d'autre, on cherche à être légèrement en avance ou légèrement en retard sur le temps. Tout ceci dépend de ce que l'on veut exprimer. En musique classique, les solistes ont une liberté d'interprétation des durées, de même qu'en jazz ; les rythmes notés sur la partition ne sont alors pas là pour assurer une synchronisation parfaite des instruments, mais pour assurer des « rendez-vous », que les instruments en soient au même point à des endroits clefs du morceau, typiquement lors des changements de parties.

Le rythme est un élément important de la dynamique du morceau, mais ce n'est pas le seul. Le jeu ou le chant peuvent être doux ou saccadé, avec une impression de calme ou de précipitation, joué fort ou doucement, les instruments peuvent jouer ensemble ou l'un après l'autre… Ceci se retrouve dans les autres arts de représentation : la danse, le théâtre ou les arts du cirque.

* {{lien web
 | url = https://www.youtube.com/watch?v=kIHG2Jprqso
 | titre = Arts du Cirque: les effets et procédés chorégraphiques
 | auteur =  Prof EPS K. MENET
 | site = YouTube
 | date = 2017-12-17 | consulté le = 2021-01-17
}}

Notons enfin que même lorsqu'il ne s'agit que de musique, l'effet visuel peut être important. Ainsi, au sein d'un pupitre (ensemble de musiciens jouant la même partie), les violonistes et altistes, violoncellistes et contrebassistes synchronisent les mouvements d'archet (ce qui évite aussi de se gêner) ; les spectateurs et spectatrices voient les mouvements du chef d'orchestre, des coulisses des trombones, des baguettes des percussionnistes. En musique de chambre, les regards et mouvement de corps des instrumentistes les aident à se synchroniser. Un soliste fait souvent des mouvements expressifs pour accompagner son jeu.

=== Schémas rythmiques courants ===

Les règles énoncées ci-dessus permettent de décrypter toutes les partitions « classiques » — il existe des notations particulières pour des « effets spéciaux », notamment en musique contemporaine. Mais il y a parfois des schémas qui sont difficiles à lire alors qu'ils sont faciles à jouer. C'est le cas par exemple de la syncope : on voit des vidéos d'enfants chantant ''Libérée, délivrée (Let It Go)'', tiré du dessin animé ''La Reine des neiges (Frozen'', 2013'')'', morceau qui comporte des syncopes ; la syncope est donc un schéma rythmique facile à reproduire par imitation, pourtant, la première fois que l'élève en lit une, il ou elle ne sait en général pas comment l'interpréter.

L'apprentissage de la lecture du rythme passe donc par l'étude de schémas rythmique courants, que le musicien ou la musicienne saura reconnaître et interpréter.

==== Le contretemps ====

Le contretemps, c'est lorsque la note est jouée sur la deuxième partie d'un temps. Le schéma classique est, lorsque la pulsation est à la noire : demi-soupir suivi d'une croche :
: 𝄾 𝅘𝅥𝅮
On obtient un effet « sautillant ». Par exemple, dans la musique reggae, les accords sont habituellement joués à contre-temps. On pourra écouter le morceau ''Could You Be Loved'' de Bob Marley (album ''Uprising'', 1980) à partir de 13 secondes : les accords de guitare sont à contretemps, on a les temps qui sont marqués par la grosse caisse et la caisse claire, et les accords de guitare qui s'intercalent.
: {{lien web |url=https://www.youtube.com/watch?v=1ti2YCFgCoI |titre=Bob Marley &amp; The Wailers - Could You Be Loved |site=chaîje Bob Marley sur YouTube |date=2022-07-15 |consulté le=2023-12-15}}

==== La syncope ====

La syncope, c'est lorsqu'une note est à cheval sur deux temps. Le schéma classique est, lorsque la pulsation est à la noire : croche suivi d'une noire puis d'une croche :
: 𝅘𝅥𝅮 𝅘𝅥 𝅘𝅥𝅮
La syncope peut se poursuivre sur plusieurs notes :
: 𝅘𝅥𝅮 𝅘𝅥 𝅘𝅥 𝅘𝅥 𝅘𝅥𝅮
Une des croches peut être remplacée par un demi-soupir.
: 𝄾 𝅘𝅥 𝅘𝅥 𝅘𝅥 𝄾
La syncope peut aussi commencer ou se terminer par une noire pointée :
: 𝅘𝅥 𝅭 𝅘𝅥 𝅘𝅥 𝅘𝅥𝅮
La syncope peut être à cheval sur deux mesures, auquel cas on a recours à des croches liées.

[[Fichier:Syncopes exemples croche noire.svg|Exemples de syncopes]]

Le terme syncope peut aussi désigner une note longue qui commence sur un temps faible et se termine sur un temps fort. Le schéma classique est, lorsque la pulsation est à la noire : noire suivie d'une blanche puis d'une noire :
: 𝅘𝅥 𝅗𝅥 𝅘𝅥

Comme signalé plus avant, la chanson ''Libérée, délivrée ({{lang|en|Let It Go}})'' contient de nombreuses syncopes :
: {{lien web |url=https://www.youtube.com/watch?v=BS0T8Cd4UhA |titre=Let It Go - Behind The Mic Multi-Language Version (from &quot;Frozen&quot;) |site=DisneyMusicVEVO sur YouTube |date=2014-04-01 |consulté le=2023-12-15}}

==== La syncopette ====

La syncopette est l'équivalent d'une syncope, mais à l'intérieur d'un temps et non plus à cheval sur un temps. Le schéma classique est, lorsque la pulsation est à la noire : double-croche suivie d'une croche puis d'une double-croche :
: 𝅘𝅥𝅯 𝅘𝅥𝅮 𝅘𝅥𝅯
[[Fichier:Syncopettes exemples croche double-croche.svg|Exemples de syncopettes.]]

==== La barcarole ====

La barcarole, ou barcarolle, est un schéma qui se trouve dans les mesures ternaires (typiquement 3/8, 3/8, 9/8 12/8). Elle consiste en une succession répétée d'une croche et d'une croche :
: 𝅘𝅥 𝅘𝅥𝅮
Ce rythme évoque le balancement d'une barque sur l'eau, d'où son nom (de l'italien ''{{lang|it|barca}}'', la barque) : il s'agit à l'origine d'airs chantés par les gondoliers de Venise.

Écouter par exemple ''Barcarolle'' dans l'opérette ''Les Contes d'Hoffmann'' (Jacques Offenbach, 1881).
: {{lien web |url=https://www.youtube.com/watch?v=0u0M4CMq7uI |titre=Anna Netrebko &amp; Elīna Garanča – Offenbach: Les Contes d'Hoffmann: Barcarolle |site=Deutsche Grammophon - DG sur YouTube |date=2009-11-09 |consulté le=2023-12-15}}

==== La sicilienne ====

La sicilienne est un schéma qui se trouve dans les mesures ternaires (typiquement 3/8, 3/8, 9/8 12/8). Elle consiste en une succession de croche pointée, double croche et croche :
: 𝅘𝅥𝅮 𝅭 𝅘𝅥𝅯 𝅘𝅥𝅮
[[Fichier:Sicilienne exemple.svg|Exemple de sicilienne.]]

On peut entendre des siciliennes dans l’''Alegretto'' de la ''Sonate pour hautbois et piano'' de Camille Saint-Saëns (1921), à 1 min 54 de la vidéo suivante :
: {{lien web |url=https://www.youtube.com/watch?v=XjIu4T3BOW8 |titre=Philibert Perrine // Révélations Classiques de l’Adami 2016 // Camille Saint Saëns |site=chaîne Adami sur YouTube |date=2017-05-02 |consulté le=2023-12-15}}

==== Le swing ====

Le swing est une manière de jouer chaloupée, utilisée en jazz et en blues. En première approche, cela consiste à jouer des croches ternaires : lorsque l'on a deux croches, on joue en fait une succession noire - croche en triolet, à la manière d'une barcarole.

De manière un peu plus fine : la manière dont on joue les croches dépend du tempo. Sur un tempo rapide, on joue des croches quasiment égales. Sur un tempo moyen (80 - 120 à la noire), on joue des croches ternaires, ce que l'on appelle aussi le ''{{lang|en|shuffle}}''. Sur un tempo lent, on va être très « au fond du temps » et l'on va interpréter une succession croche pointé - double-croche.

: {{lien web |url=https://www.youtube.com/watch?v=n2_X4VTCoEo |titre=The Doors - Roadhouse Blues |site=215Days/YouTube |date=2012-12-07 |consulté le=2023-12-15}} : un boogie en ''{{lang|en|shuffle}}''.
: {{lien web |url=https://www.youtube.com/watch?v=sRS9xNlSExA |titre=Sammy Nestico – This is the Moment / Chopin University Big Band |site=Uniwersytet Muzyczny Fryderyka Chopina/YouTube |date=2022-05-18 |consulté le=2023-12-15}} : un morceau joué « au fond du temps » (la version originale est encore plus « au fond du temps »).

==== La polyrythmie ====

La polyrythmie, c'est lorsque l'on peut superposer plusieurs accentuations ; un cas particulier est la superposition de rythmiques binaires et ternaires, on parle alors « d'hémiole ». Par exemple :
* une mesure à 3/4 comporte six croches ; si l'on accentue chaque temps, alors on accentue les 1{{re}}, 3{{e}} et 5{{e}} croches ;
* une mesure à 6/8 comporte aussi six croches, si l'on accentue chaque temps, alors on accentue les 1{{re}} et 4{{e}} croches.
Ainsi, sur un morceau à 3/4, on peut ponctuellement placer les accents comme si l'on était à 6/8 ; en jazz, il est fréquent de jouer les valses à 12/8 (en regroupant deux mesures à 3/4). Et à l'inverse, sur un morceau à 6/8, on peut ponctuellement placer les accents comme si l'on était à 3/4. Sur un morceau à 2/4, on peut regrouper trois mesures et les jouer à 6/4, donc en accentuant la première noire de la première mesure, et la seconde noire de la deuxième mesure.

Le morceau ''{{lang|en|Blue Rond a la Turk}}'' de Dave Brubeck (album ''{{lang|en|Time Out}}'', 1959) est construit sur des mesures de neuf croches ; il alterne trois mesures à 2 + 2 + 2 + 3/9 (donc accents sur les 1{{re}}, 3{{re}}, 5{{e}} et 7{{e}} croches) et une mesure à 9/8 (accents sur les 1{{re}}, 4{{e}} et 7{{e}} croches).

== La hauteur ==

Un son peut être aigu ou grave, cette caractéristique est appelée « hauteur du son ». Le fait d'organiser les sons passe par le choix de certaines hauteurs de son, donc à choisir certaines notes particulières parmi un infinité possibles.

=== Les notes « naturelles » ===

Un son est une vibration de l'air. L'air vibre car il est mis en mouvement par un objet, qui par exemple chute ou bien se brise, ou un phénomène, par exemple le vent qui siffle dans les arbres ou un bruit de frottement. La plupart du temps, cela crée des sons « désorganisés », de type souffle, grésillement, claquement ou craquement. Mais le cri d'un animal est différent, il est « organisé » : en forçant le passage à travers les cordes vocales, l'air met ces cordes vocales en vibration, cette vibration dépend de la tension des muscles et obéit à des lois physiques déterminées.

La capacité à distinguer les bruits « désorganisés » — qui comprennent les bruits d'un animal rodant dans les herbes hautes — et « organisés » — animal, et notamment congénère humain, communiquant une information — a probablement été déterminant pour la survie. L'évolution a donc sélectionné des êtres dont le cerveau est capable de distinguer les sons organisés des sons désorganisés, et de comparer les sons organisés pour reconnaître la nature du signal.

Un son peut être décomposé en vibrations élémentaires caractérisées par une fréquence, qui est le nombre de vibrations par seconde ; la fréquence la plus basse du son est appelée « fondamentale ». Un son « désorganisé » se compose de vibrations sans rapport particulier entres elles. Dans un son « organisé », les vibrations ont une fréquence qui est un multiple entier de la fondamentale. Ces sons ont donc une « hauteur » clairement identifiée, qui correspond à la fréquence fondamentale. L'oreille, et le cerveau, permettent de dire que « deux notes sont identiques » ou « différentes ».

La manière la plus simple de créer un son organisé est de tendre une corde et de la pincer. On peut montrer par une étude mécanique que cette corde ne peut vibrer que selon certaines fréquences, qui dépendent de sa masse, de sa longueur et de sa tension (la force qui sert à la tendre), et ces fréquences sont toutes des multiples de la fondamentale.

Quand deux sons sont émis en même temps, leurs vibrations se superposent. Considérons ici uniquement des sons « organisés » :
* si la fréquence fondamentale de l'un est la même que l'autre, alors les vibrations se superposent parfaitement ; le cerveau interprète cela comme étant « la même note », une « note de même hauteur » ; on parle « d'unisson » ;
* si la fréquence d'un des sons est le double de l'autre, alors les vibrations se superposent également parfaitement, mais un son est plus aigu que l'autre ; nous interprétons cela comme étant « la même note, mais plus aiguë », ce que l'on appelle une octave (car, dans la musique classique, cet écart est décomposé en une échelle de huit degrés) ;
* si les fréquences sont très proches, il se produit un phénomène de battements désagréable ; on parle de « dissonance ».

=== La gamme de sept notes ===

{{son|Progression continue sur une octave|Progression continue octave do3 do4.ogg}}

Avec la voix, on peut monter de manière continue d'une note à son octave supérieure. Il y a donc un nombre « infini » de notes différentes. Toutefois, utiliser « n'importe quelle note » ne mènerait pas à un résultat satisfaisant — harmonieux, agréable — mais ces critères sont subjectifs. Dans la musique européenne, on a donc distingué sept notes au sein d'une octave, et on les a nommées : ''do'' ou ''ut'', ''ré'', ''mi'', ''fa'', ''sol'', ''la'' et ''si'' ; dans d'autres langues, notamment en anglais, les notes sont appelées par des lettres : C, D, E, F, A, G et B.

Ce découpage en sept notes est arbitraire et pas du tout universel. En particulier, de nombreuses cultures — notamment en Chine et en Afrique — ont choisi seulement cinq notes, d'autres cultures utilisent les degrés ayant un écart différent. Ce découpage a par ailleurs été bousculé dans la musique contemporaine.

Par ailleurs, des notes ont été insérées entre ces sept notes, on parle de « notes altérées » par un dièse ♯ — la note est plus aiguë — ou un bémol ♭ — la note est plus grave. Par exemple, la note ''do'' dièse est insérée entre le ''do'' et le ''ré'' ; la note ''ré'' bémol est également insérée entre le ''do'' et le ''ré'', c'est la même note que le ''do'' dièse.

Ainsi, on a au final douze notes dans une octave, séparées par un « demi-ton ». Cette gamme par demi-tons est appelée « gamme chromatique » ; avec les dièses, elle s'écrit
: ''do'' — ''do''♯ — ''ré'' — ''ré''♯ — ''mi'' — ''fa'' — ''fa''♯ — ''sol'' — ''sol''♯ —  ''la'' — ''la''♯ — ''si''
: C — C♯ — D — D♯ — E — F — F♯ — G — G♯ — A — A♯ — B
et avec les bémols :
: ''do'' — ''ré''♭ — ''ré'' — ''mi''♭ — ''mi'' — ''fa'' — ''sol''♭ — ''sol'' — ''la''♭ — ''la'' — ''si''♭ — ''si''
: C — D♭ — D — E♭ — E — F — G♭ — G — A♭ — A — B♭ — B.
Là encore, ce découpage en douze demi-tons n'est pas universel. En particulier, certaines cultures utilisent des quarts de ton.

On remarque que certaines notes sont identiques, ce sont des « enharmonies » : ''do''♯ = ''ré''♭ ; ''ré''♯ = ''mi''♭, ''mi''♯ = ''fa''…

{{citation bloc |1=il n’y a que douze notes [dans la musique]. Tu dois étudier ce que les autres en ont fait.
 |2=Nadia Boulanger
 |3={{lien web |auteur=Mustapha Kessous |titre=« “Quincy” : Quincy Jones, une histoire sans fausse note » |site=Le Monde |date=2018-12-27 |consulté le=2021-07-05 |url=https://www.lemonde.fr/televisions-radio/article/2018/12/27/quincy-quincy-jones-une-histoire-sans-fausse-note_5402506_1655027.html}}
}}

=== Noter la hauteur ===
[[Fichier:Papier musique vierge.svg|vignette|Papier à musique vierge.]]

La notation musicale sera vue de manière plus complète dans le chapitre suivant. Nous avons choisi de présenter le cœur de la musique — la constitution des mélodies, des harmonies — avant la notation formelle, puisque la notation a été créée pour servir ces mélodies et harmonies. Mais nous avons toutefois besoin d'un certain nombre d'éléments de notation pour présenter les gammes et intervalles.

; Note
: Une note représente la hauteur et la durée d'un son ; il s'agit d'une figure ronde, de couleur noire ou blanche, avec ou sans hampe, qui est placée sur une portée (voir ci-après). Plus la note est haute, plus le son est aigu. Comme la valeur rythmique ne nous intéresse pas, nous utiliserons ici toujours des « noires » (note de couleur noire avec une hampe simple) ou des « rondes » (note de couleur blanche sans hampe).
: Les notes sont appelées : ''do'' (ou ''ut''), ''ré'', ''mi'', ''fa'', ''sol'', ''la'' et ''si''. Ces noms ont été donnés par Guido d'Arezzo et sont les premières lettres des 7 vers de la première strophe de l'''Hymne de Saint-Jean Baptiste'', un chant grégorien latin. Auparavant, on utilisait des lettres — de A pour ''la'' à G pour ''sol'', système encore utilisé par les anglo-saxons.

; Portée
: La portée est un ensemble de cinq lignes, qui sert à repérer la hauteur d'une note. La note peut être sur une ligne ou sur un interligne (entre deux lignes). La première ligne est la ligne du bas, la cinquième ligne est la ligne du haut.
: Si une note est trop aiguë ou trop grave pour être représentée sur la portée, on utilise des lignes supplémentaires.

; Clef
: La clef est un symbole placé en début de ligne qui sert à donner la référence de la hauteur. Nous n'utiliserons ici que la clef de ''sol'' 𝄞 : elle indique que la note située sur la deuxième ligne est un ''sol''.

; Altération
: Une altération est un signe placé devant la note et qui sert à augmenter ou diminuer la hauteur du son. Le dièse, noté ♯, rend la note plus aiguë, le bémol, noté ♭, rend la note plus grave, et le bécarre, noté ♮, annule une altération. Il existe aussi le double-dièse, noté ♯♯ ou 𝄪, et le double-bémol noté 𝄫.

----
; Remarque
: Le dièse « ♯ » est un signe différent du symbole numérique « # » (appelé « croisillon ») présent sur les claviers d'ordinateur.
----

La correspondance entre les figures et le nom des notes est donc :
: [[Image:Clef de sol 2 nom des notes.png|300px]]

; Apprendre à dessiner une clef de ''sol''

: Pour dessiner une clef de ''sol'', on part de la deuxième ligne (la ligne du ''sol''). Puis, on fait un escargot en tournant dans le sens des aiguilles d'une montre ; la spirale fait un tour complet et touche la première et la troisième ligne. Ensuite, on dessine un « ℓ » cursif, on redescend sous la portée et on termine par une crosse, un « J ».

[[File:Apprendre dessiner clef sol.svg|vignette|center|upright=2|Apprendre à dessiner une clef de ''sol''.]]

== Le timbre ==
Le timbre est ce qui distingue les différents instruments et les différentes manières de jouer.

=== Choix de l'instrument ===

Les instruments sont parfois choisis par contrainte : on utilise ce que l'on a sous la main. Une personne seule qui veut chanter en s'accompagnant aura en général recours à un piano ou une guitare, parfois un ukulélé. Mais avec un piano électronique, il y a la possibilité de choisir la sonorité utilisée, l'instrument que l'on imite.

Lorsque l'on a le choix entre plusieurs instruments, on va alors choisir ceux que l'on utilise en fonction de leur sonorité. Lorsque l'on compose pour une formation — un groupe, un orchestre, une fanfare, un ''{{lang|en|brass bang}}'', un ''{{lang|en|big band}}''…—, chaque instrument joue une mélodie, appelée « voix », et l'on compose en fonction de la tessiture de l'instrument — l'étendue de notes qu'il peut jouer — et de sa sonorité.

=== Manière de jouer ===

Mais la sonorité va aussi varier selon la manière dont on joue.

Le premier élément est la « dynamique » : c'est le volume de jeu. Par moment, on joue fort — on utilise le terme italien ''{{lang|it|forte}}'' (prononcé « forté »), et l'on note « 𝆑 » —, à d'autre moment ou joue doucement — ''{{lang|it|piano}}'', 𝆏. Parfois on commence doucement et l'on augmente le volume progressivement — ''{{lang|it|crescendo}}'' (« cré-chêne-do »), « 𝆒 » — ou au contraire on commence fort et on diminue — ''{{lang|it|decrescendo}}'' (« dé-cré-chêne-do »), « 𝆓 ».

Avec certains instruments, on peut lier les notes ou au contraire les détacher. On peut parfois varier l'attaque, c'est-à-dire le début de la note : faire une attaque franche ou au contraire douce. On peut parfois varier la fin de la note : l'interrompre brusquement, la faire durer jusqu'à la note suivante, ou bien la laisser sonner et s'atténuer naturellement. On peut parfois glisser d'une note à une autre. Parfois on augmente brusquement le volume, on fait ce que l'on appelle un « accent » noté « &gt; » (le signe ressemble au ''{{lang|it|decrescendo}}'' mais alors que le ''{{lang|it|decrescendo}}'' s'étend sur plusieurs notes, l'accent est sur une seule note). On parle « d'articulation ».

Certains instruments peuvent être joués de différentes manières. Par exemple, avec un violon ou les instruments de la même famille (alto, violoncelle, contrebasse), on peut jouer en frottant les cordes avec le crin de l'archet (manière habituelle), en les frottant plus près du chevalet ''({{lang|it|sul ponticello}})'' ou au contraire sur la touche ''({{lang|it|sul tasto}})'', en les frappant avec le bois de l'archet ''({{lang|it|col legno}})'', en pinçant les cordes avec l'index ''({{lang|it|pizzicato}})'', en frappant la caisse de résonance avec les doigts, en effleurant la corde plutôt que de l'appuyer sur la touche (harmonique)…

Le compositeur ou la compositrice peut indiquer une intention, laissant l'interprète trouver la manière de jouer, par exemple « jouer avec douceur » ''({{lang|it|dolce}})'' ou « jouer avec fougue » ''({{lang|it|con fuoco}})''.

== L'interprétation ==

L'interprétation de la musique prend en comptes des éléments qui ne sont pas notés. Les éléments d'interprétations dépendent du style.

{{citation bloc |1=La notation musicale, aussi fidèle que possible à ce que le transcripteur entend, ne reproduit que partiellement et imparfaitement la musique et reflète encore bien moins l'art d'un chanteur traditionnel que celui d'un chanteur lyrique ou de variété. Il manquera toujours à tout système de notation une chose essentielle : le style. |2={{chapitre |prénom1=Emmanuelle |nom1=Huteau |prénom2=Michel |nom2=Colleu |prénom3=Bernard |nom3=Subert |prénom4=Jean-Pierre |nom4=Bertrand |prénom5=René |nom5=Zosso |titre chapitre=Rendre consultable, transcrire et documenter des chants de culture orale |titre ouvrage=Le Havre en chansons. 70 chants traditionnels et populaires des Havrais |passage=22 |éditeur=OPCI/Ethnodoc, GIP Le Havre 2017 et Conservatoire Arthur Honegger |année=2017 |isbn=978-2-919264-29-2}} }}

Par exemple, dans le cas du baroque :
* la musique baroque est une musique qui se danse, on doit donc « sentir » les appuis des danseurs et danseuses ;
* en particulier, on accentue, sans s'appesantir, les temps forts (premier temps des mesures à deux et trois temps ; premier et troisième temps des mesures à quatre temps) ; les notes intermédiaires « s'évanouissent », par « désinence » ;
* les valeurs pointées sont « surpointées » : par exemple un « croche pointée-double » est joué « croche doublement pointée-triple » ;
* la fin d'une partie comporte souvent une « hémiole » : les temps forts, les notes accentuées, sont décalées ce qui donne une sensation de rupture de rythme, alors même que le tempo reste identique ;
* les notes longues sont souvent agrémentées par des appoggiatures, tremblements (mordants supérieurs), pincés (mordants inférieurs), trilles… à la volonté de l'interprète ;
* les trilles sont attaquées par la note supérieure et non par la note principale.

Dans le cas du jazz :
* les notes accentuées sont, à quatre temps, les 2{{e}} et 4{{e}} temps ''({{lang|en|afterbeat}})'' ;
* lorsque l'on joue swing, la première croche d'un temps est plus longue que la seconde ; à tempo lent, on a un rythme de type « croche pointée-double » (♫ = ♪𝅭 𝅘𝅥𝅯), à tempo moyen on a un ''{{lang|en|shuffle}}'' « croche-double en triolet », à tempo rapide on a des croches égales ;
* mais tous les morceaux ne sont pas joué swing, certains sont à croches égales ;
* les accents «  𝅻 » et notes courtes (piquées, ''{{lang|it|staccato}}'') «  𝅼 » sont exagérées, de même que les marcato «  𝅿 » ;
* lorsque le thème est joué par un instrument seul, le rythme est en général « flottant » (comme un jeu ''{{lang|it|rubato}}'').

; Ressource
* {{lien web |url=https://www.youtube.com/watch?v=MCtR1JLtZ1w |titre=RIGUEUR ET SOUPLESSE - Le petit traité d'interprétation de François Lazarevitch |site=Les Musiciens de Saint-Julien/YouTube |date=2022-08-18 |consulté le=2024-02-09}}

== Niveau expert : vibrations et caractéristiques du son ==

=== Physiologie de l'audition ===
[[Fichier:OreilleMoyenneSchema.jpg|vignette|Oreille externe (pavillon, à gauche) et oreille moyenne (en couleur). Le tympan est numéroté 1.]]
Nous entendons grâce à nos oreilles, et à notre cerveau : l'oreille capte les variations de pression de l'air, et le cerveau les interprète comme des sons.

La partie extérieure de l'oreille est le pavillon : il sert à guider les sons vers le tympan.

Le tympan est une paroi (numéroté 1 sur le schéma ci-contre) qui se met à vibrer : il est poussé quand la pression s'élève, et est tiré vers l'extérieur lorsque la pression diminue. Ce mouvement d'aller-retour met en marche une mécanique qui provoque un influx nerveux dans le nerf auditif, une information qui est transmise au cerveau où elle est traitée.

{{clear}}

=== Physique de l'émission des sons ===
Les sons sont créés de deux manières :
* par une surface qui vibre : il peut s'agir d'une peau de tambour, d'une lame de xylophone, ou bien d'une caisse de résonance qui est mise en mouvement par la vibration d'une corde (violon, guitare, piano…) ; de manière moderne, il peut s'agir de la membrane d'un haut-parleur mise en mouvement par un électro-aimant ;
* par une perturbation d'un flux d'air : dans un instrument à vent (trompette, clarinette, sifflet, flûte, saxophone, orgue…), un flux d'air (souffle) est perturbé par une embouchure, et un tuyau plus ou moins long lui donne des caractéristiques précises qui permet de former le son.

[[Fichier:Drum vibration mode01.gif|vignette|Vibration d'une peau de tambour.]]
Considérons le cas le plus simple : la peau de tambour. Si l'on frappe la peau, elle se met à osciller comme le montre l'image ci-contre. La vitesse à laquelle elle oscille, la fréquence), dépend de la manière dont elle est tendue, de son épaisseur, de sa raideur… En faisant des allers-retours, elle va alternativement pousser et « aspirer » l'air, provoquant des variations de pression de l'air.

Plus la peau vibre vite, plus le son est aigu ; plus elle vibre lentement, plus le son est grave. Ceci est caractérisé par le fréquence ''f'' : la fréquence est le nombre d'aller-retours que fait la peau en une seconde. Elle s'exprime en « hertz », abrégé « Hz ».
: '''La hauteur d'un son est caractérisée par sa fréquence ''f'', exprimée en hertz (Hz). Plus la fréquence est élevée, plus le son est aigu ; plus elle est basse, plus le son est grave.'''
L'humain entend des sons ayant une fréquence comprise entre {{unité|20|Hz}} et {{unité|20000|Hz}}. La note de référence, le ''la''&lt;sup&gt;3&lt;/sup&gt; (également noté A4), a une fréquence fixée à {{unité|440|Hz}}&lt;ref&gt;Cette valeur est fixée par la norme internationale ISO 16:1975.&lt;/ref&gt; ; on parle du « ''la'' 440 ». Cette référence permet à des instrumentistes de pays différents de jouer ensemble ; cependant, cette référence peut varier selon les endroits, le style (baroque, classique, doom métal…), l'époque.

Plus l'amplitude est grande, plus le son est fort : si on frappe très fort la peau, le mouvement sera important, la peau se déplacera beaucoup (en millimètres) vers le haut et vers le bas, le son sera fort ''(forte)''. À l'inverse, si on frappe doucement, l'amplitude du mouvement sera faible, le son sera faible ''(piano)''. L'amplitude du mouvement de la peau détermine l'amplitude de variation de la pression de l'air.
: '''Le volume sonore (''forte'', ''piano'') dépend de l'amplitude de la variation de pression. Si l'amplitude est importante, le son est fort ''(forte)'' ; si l'amplitude est faible, le son est faible ''(piano)''.'''

{{clear}}

[[Fichier:Falenawodzieanim.gif|vignette|La propagation des vaguelettes dans l'eau montre la manière dont le son se propage dans l'air.]]
Ces variations de pression vont ensuite se propager jusqu'aux oreilles, de la même manière que des cercles dans l'eau : lorsqu'une pierre tombe dans l'eau, elle perturbe la surface, et ces perturbations, les vaguelettes, vont se propager au loin.

La vitesse du son dans l'air est d'environ {{unité|340|m/s}} soit {{unité|1200|km/h}}.

{{clear}}
[[Fichier:Drum vibration mode02.gif|vignette|Un deuxième mode de vibration de la peau de tambour.]]
[[Fichier:Drum vibration mode12.gif|vignette|Un troisième mode de vibration de la peau de tambour.]]
Mais la peau peut vibrer de plusieurs manières. La combinaison de ces différents modes de vibration rend le son plus riche ; c'est cette combinaison qui donne le timbre, la sonorité particulière à l'instrument, qui fait que deux tambours ne sonnent pas de la même manière.
: '''La complexité de la variation de pression détermine le timbre, la sonorité.'''

{{clear}}

[[Fichier:Vibration corde trois modes.gif|vignette|trois modes de vibration d'une corde.]]
[[Fichier:Vibration corde trois harmoniques combinees.gif|vignette|Vibration de corde de complexité croissante : vibration simple en haut (son « pur ») et vibration complexe en bas (son « riche »).]]
Dans le cas d'un instrument à corde, la caisse de résonance ne vibre pas librement. Sa vibration est imposée par la vibration d'une corde.

Pour faire vibrer la corde, on peut :
* la pincer, comme avec une guitare, une harpe, un clavecin ;
* la frapper, comme avec un piano, un tympanon, un berimbau ;
* la frotter, comme avec un violon, alto, violoncelle, contrebasse, une vielle.
Comme pour la peau du tambour, les caractéristiques de vibration de la corde déterminent les caractéristiques du son :
* fréquence de vibration pour la hauteur (aigu-grave) : cette fréquence dépend :
** de la longueur de la corde : plus la corde est longue, plus la fréquence est faible (son grave), plus elle est courte, plus la fréquence est élevée (son aigu),
** de la tension de la corde : plus la corde est tendue, plus la fréquence est élevée (son aigu), pus la corde est lâche, plus la fréquence est faible (son grave),
** de la masse linéaire de la corde (poids d'un mètre de corde) : plus la corde est lourde, plus la fréquence est faible (son grave), plus elle est légère, plus la fréquence est élevée (son aigu) ;
* l'amplitude de vibration pour le volume ''(forte-piano)'' ;
* la complexité de la vibration pour le timbre, la sonorité ; cette complexité dépend de la corde, de son mode d'excitation (pincée, frappée, frottée) mais aussi des caractéristiques de la caisse de résonance (puisque c'est elle au final qui crée le son).

{{clear}}

[[Fichier:Onde stationnaire tuyau ouvert trois modes.gif|vignette|Variation de pression dans un tuyau d'air : le noir correspond à une pression élevée et le blanc à une pression faible.]]
Dans le cas d'un instrument à vent, on a un courant d'air, un souffle, qui traverse un tuyau (éventuellement percé, comme dans le cas d'une flûte). Ce courant d'air est perturbé à l'entrée, il se forme des tourbillons. La forme et la longueur du tuyau va transformer ces tourbillons en variations périodiques de pression. En sortie de tuyau, on a donc directement des variations de pression qui vont se propager jusqu'à l'oreille.

Comme pour la corde et la peau de tambour, les caractéristiques des variations de pression déterminent les caractéristiques du son :
* fréquence de vibration pour la hauteur (aigu-grave) : cette fréquence dépend de la longueur du tuyau, et de la température ; c'est la raison pour laquelle les instruments doivent se chauffer avant de jouer, afin d'avoir une hauteur stable (le son monte avec la température) ;
* l'amplitude de variation de pression pour le volume ''(forte-piano)'' : plus on souffle fort, plus les perturbations sont importantes, plus le son est fort ;
* la complexité des variations de pression pour le timbre, la sonorité : ceci est essentiellement déterminé par la manière dont le courant d'air est perturbé et la forme du tuyau.
Le courant d'air peut être perturbé :
* par un biseau, dans le cas des flûtes et de certains tuyaux d'orgue ; le biseau peut être une lame que l'on met en travers du son, mais il peut aussi être dû au fiat que l'on souffle « de travers » comme pour une flûte traversière ou une flûte de pan ;
* par une ou deux « lames » qui vibrent : ces lames s'appellent des « anches », c'est le principe de l'harmonica, de l'accordéon, de la clarinette, du saxophone, du hautbois, du basson…
* par la vibration des lèvres, c'est le cas des « cuivres » : trompette, trombone, tuba, cor, didgeridoo…

== Niveau expert : Construction des échelles de notes ==

=== Construction pythagoricienne et gamme de sept tons ===

Revenons sur la superposition des vibrations :
* comme nous l'avons vu précédemment, quand deux notes ont des fondamentales de fréquences doubles l'une de l'autre, elles sont plus ou moins perçues comme identiques, mais pourtant différentes, l'une étant plus aiguë que l'autre (octave) ;
* quand deux notes ont des fondamentales de fréquences respectivement double et triple d'une même base, elles sont fortement perçues comme harmonieuse ; cette situation est appelée « quinte » (dans la musique occidentale, on divise cet intervalle en cinq degrés).
En utilisant cette relation, Pythagore, et avant lui les Babyloniens, ont construit une échelle de notes toutes séparées par des quintes, ce qui a donné une gamme de sept tons, dite heptatonique (''do'', ''ré'', ''mi'', ''fa'', ''sol'', ''la'', ''si'') qui forme la base de la musique occidentale.

Pour quoi sept notes ? Parce qu'à l'époque, sept astres sont connus : le Soleil, la Lune et les cinq planètes visibles à l'œil nu (Mercure, Vénus, Mars, Jupiter et Saturne). Mais d'autres cultures se sont limitées à cinq notes pour utiliser les gammes pentatoniques (Asie, Afrique).

[[File:Corde vibrante fixee moitie et tiers.gif|thumb|Vibration d'une corde entière (haut), immobilisée à la moitié (milieu) et au tiers (bas).]]

Prenons par exemple une corde vibrant avec une fréquence de base ƒ&lt;sub&gt;0&lt;/sub&gt; de cent dix vibrations par seconde, dite « cent dix hertz » et notée {{unité|110|Hz}}. Si nous pinçons la corde à sa moitié, seule une moitié de corde vibre et étant deux fois plus légère, elle vibre deux fois plus vite, avec une fréquence 2 × ƒ&lt;sub&gt;0&lt;/sub&gt; soit {{unité|220|Hz}} ; pinçons la corde pour que seul un tiers vibre, la vibration est trois fois plus rapide, avec une fréquence et 3 × ƒ&lt;sub&gt;0&lt;/sub&gt; soit {{unité|330|Hz}}. Pythagore considère que ce rapport de 3/2 entre la note à {{unité|330|Hz}} et celle à {{unité|220|Hz}} est un rapport idéal, une quinte.

Continuons vers le haut : la quinte suivante s'obtient en multipliant à nouveau par 3/2, soit 3/2 × {{unité|330|Hz}} = {{unité|495|Hz}}. Redescendons d'une octave pour se rapprocher de ƒ&lt;sub&gt;0&lt;/sub&gt; : on divise la fréquence par 2 soit 495/2 = {{unité|247.5|Hz}}. À l'inverse progressions ver le bas : la quinte d'en dessous s'obtient en divisant par 3/2, soit {{unité|220|Hz}}/(3/2) = {{unité|146.67|Hz}}. Montons d'une octave pour se rapprocher de ƒ&lt;sub&gt;0&lt;/sub&gt; : on multiplie la fréquence par 2 soit 146,67 × 2 = {{unité|293.3|Hz}}.

La sixième note ainsi générée en montant est presque une octave de la première note : (3/2)&lt;sup&gt;6&lt;/sup&gt; = 11,4 est proche de 12, un multiple de 2. On peut ainsi construire une gamme de cinq notes, dite gamme pentatonique. Les cinq fréquences obtenues en multipliant par 3/2 s'étendent sur une grande plage de hauteurs ; on les ramène à l'intérieur d'une seule octave (ici entre 220 et {{unité|440|Hz}} (exclus), simplement en les divisant par 2 un « nombre suffisant de fois »).

Dans le tableau suivant, la gamme pentatonique ''do''-''ré''-''mi''-''sol''-''la'' est contenue dans les cinq lignes centrales (lignes 2 à 6) ; les deux notes permettant de compléter la gamme heptatonique sont les lignes extrêmes (la première et la dernière).

Le tableau se lit de la manière suivante : en partant du ''la'' à 110&amp;nbsp;Hz, si l'on descend de deux quintes (quinte –2, la fréquence est divisée deux fois par 3/2), on obtient un ''sol'' ; il faut remonter ce ''sol'' de trois octaves (la fréquence est multipliée trois fois par 2) pour être dans la gamme [220&amp;nbsp;Hz ; 440&amp;nbsp;Hz[. Si l'on monte de deux quintes (quinte 2, la fréquence est multipliée par (3/2)&lt;sup&gt;2&lt;/sup&gt;), on obtient un ''si'' ; ce ''si'' est déjà dans la gamme [220&amp;nbsp;Hz ; 440&amp;nbsp;Hz[.

{| class=&quot;wikitable&quot;
|+ Fréquences multiples de 110
|-
! scope=&quot;col&quot; |  Quinte
! scope=&quot;col&quot; | Puissance&lt;br /&gt; de 3/2 (quintes)
! scope=&quot;col&quot; | Puissance&lt;br /&gt; de 2 (octaves)
! scope=&quot;col&quot; | Fréquence&lt;br /&gt; (Hz)
! scope=&quot;col&quot; | Note
|-
| –4 || 1/(3/2)&lt;sup&gt;4&lt;/sup&gt; || 2&lt;sup&gt;4&lt;/sup&gt; || 347,7 || ''fa''
|-
| –3 || 1/(3/2)&lt;sup&gt;3&lt;/sup&gt; || 2&lt;sup&gt;3&lt;/sup&gt; || 260,7 || ''do''
|-
| –2 || 1/(3/2)&lt;sup&gt;2&lt;/sup&gt; || 2&lt;sup&gt;3&lt;/sup&gt; || 391,1 || ''sol''
|-
| –1 || 1/(3/2) || 2&lt;sup&gt;2&lt;/sup&gt; || 293,3 || ''ré''
|-
|  0 || 1 || 2 || 220 || ''la''
|-
| 1 || 3/2 || 2 || 330 || ''mi''
|-
| 2 || (3/2)&lt;sup&gt;2&lt;/sup&gt;|| 1 || 247,5 || ''si''
|}

Mais on peut aussi poursuivre cette construction. À la douzième quinte, on obtient une fréquence qui est également presque une octave de la première note (l'écart par rapport à l'octave parfaite est de 5 % pour la sixième quinte, et de 0,2 % pour la douzième quinte). On peut donc définir douze degré de cette manière. Comme précédemment, on les ramène à l'intérieur d'une seule octave. Comme il est compliqué de construire une musique avec autant de notes, on n'en retient qu'un nombre limité, typiquement cinq ou sept, mais on garde parfois les douze (musique dodécaphonique) qui forment une gamme.

Ces douze degrés sont appelés des « demi-tons ».

{| class=&quot;wikitable&quot;
|+ Quintes pures pythagoriciennes
|-
! scope=&quot;col&quot; | Quinte
! scope=&quot;col&quot; | Facteur
! scope=&quot;col&quot; | Fréquence&lt;br /&gt;(Hz)
! scope=&quot;col&quot; | Note
|-
| 0 || 1 || 220 || ''la''
|-
| 7 || 1,07 || 234,9 || ''la''♯/''si''♭
|-
| 2 || 1,13 || 247,5 || ''si''
|-
| 9 || 1,20 || 264,3 || ''do''
|-
| 4 || 1,27 || 278,4 || ''do''♯/''ré''♭
|-
| 11 || 1,35 || 297,3 || ''ré''
|-
| 6 || 1,42 || 313,2 || ''ré''♯/''mi''♭
|-
| 1 || 1,5 || 330 || ''mi''
|-
| 8 || 1,60 || 352,4 || ''fa''
|-
| 3 || 1,69 || 371,3 || ''fa''♯/''sol''♭
|-
| 10 || 1,80 || 396,4 || ''sol''
|-
| 5 || 1,90 || 417,7 || ''sol''♯/''la''♭
|-
| 12 || 2,03 (≃ 2) || 446,0 (≃ 440) || ''la''
|}

Nous voyons que les sept premières notes que nous avions générées (premier tableau), les notes « naturelles » (dont le nom ne comporte ni dièse, ni bémol), sont diversement espacées : il y a une note qui s'intercale entre les notes ''do''-ré'' ; ''ré''-''mi'' ; ''fa''-''sol'' ; ''sol''-''la'' ; ''la''-si''. Et il n'y a pas de note qui s'intercale entre les notes ''mi''-''fa'' et ''si''-''do''.

Nous disons donc qu'il y a un demi-ton entre les notes ''mi''-''fa'' et ''si''-''do'' ; et qu'il y a un ton complet (deux demi-tons) entre les autres notes consécutives.

Certaines musiques, notamment arabe, turque et perse, utilisent d'autres degrés, qualifiés de « quarts de tons ».

=== Commas ===

Nous voyons que dans la construction précédente, l'empilement de sept quintes pythagoriciennes donne une fréquence de {{unité|446|Hz}} alors que l'octave donne {{unité|440|Hz}}. Il y a donc un écart de {{unité|6|Hz}} sur 440 donc de 100 × 6/440 = 1,36 %. Si nous faisons la construction inverse, c'est-à-dire que nous partons du ''la'' à {{unité|440|Hz}} et que nous descendons les quintes, nous allons donc obtenir des notes un peu plus basses.

Par ailleurs, nous remarquons que pour passer d'une note à la note suivante, on multiplie parfois par 1,0535 (2&lt;sup&gt;8&lt;/sup&gt;/3&lt;sup&gt;5&lt;/sup&gt;) et parfois par 1,0679 (3&lt;sup&gt;7&lt;/sup&gt;/2&lt;sup&gt;11&lt;/sup&gt;) ; il y a donc des grands demi-tons et des petits demi-tons avec toujours cet écart de 100 × (1,0679 – 1,0535)/1,0535 = 1,36 %. Le ton a ainsi été découpé en neuf parties appelées « commas »&lt;ref&gt;Il s'agit ici du « comma de Holder ». Il y a plusieurs définitions du comma, mais celle-ci est la plus simple et suffit largement pour notre propos.&lt;/ref&gt; ; ainsi, il n'y a pas de demi-ton exact mais un grand demi-ton de cinq commas et un petit demi-ton de quatre commas.

[[Image:Solfege echelle commas.svg|thumb|150px|Commas, demi-tons diatoniques et chromatiques]]

La distance séparant les notes naturelles mi-fa et si-do est de quatre commas ; on l'appelle « demi-ton diatonique ». La distance séparant une note naturelle de la note altérée, par un dièse ou un bémol, fait cinq commas et est appelée « demi-ton chromatique ». L'octave contient 5 tons (soit 5 × 9 = 45 commas) et 2 demi-tons diatoniques (2 × 4 = 8 commas) soit 53 commas.

On a :
: 1 ton = ½ ton diatonique + ½ ton chromatique.

On voit donc que dans ce système, le ré ♭ est légèrement plus grave que le ''do'' ♯ :
* ''do''–''do'' ♭ : demi-ton chromatique ;
* ''do''-''si'' : demi-ton diatonique ;
* ''do''-''ré'' ♭ : demi-ton diatonique ;
* ''do''–''do'' ♯ : demi-ton chromatique ;
* ''do'' ♯-''ré'' : demi-ton diatonique.
{{définition|
* Un demi-ton diatonique est un demi-ton séparant des notes conjointes de nom différent ; par exemple ''si''-''do'', ''do''-''ré''♭ ou ''do''♯-''ré''.
* Un demi-ton chromatique est un demi-ton séparant des notes de même nom ; par exemple ''do''♭-''do'' et ''do''-''do''♯.
}}

Attention : ''mi''♯-''sol''♭ n'est pas un demi-ton diatonique, puisque les notes ne sont pas conjointes. Il fait trois commas (puisque ''fa''-''sol''♭ est un demi-ton diatoniques donc de quatre commas, et  que le ''mi''♯ est plus haut d'un comma que le ''fa'').

=== Gamme tempérée ===

Vers la fin du {{pc|xv}}&lt;sup&gt;e&lt;/sup&gt;-début du {{pc|xvi}}&lt;sup&gt;e&lt;/sup&gt; siècle, on invente une nouvelle gamme découpée en demi-tons tous égaux, on parle de « tempérament égal » ou de « gamme tempérée ». L'idée est de multiplier toujours par la même quantité ''k'' pour monter d'un demi-ton. Si on multiplie douze fois par ''k'', on doit obtenir une octave juste donc ''k''&lt;sup&gt;12&lt;/sup&gt; = 2. Le facteur pour monter d'un demi-ton est donc ''k'' = 2&lt;sup&gt;1/12&lt;/sup&gt; = {{formatnum:1.0595}}.

Il n'y a alors plus de comma ; le demi-ton diatonique et le demi-ton chromatique ont la même grandeur, et valent exacte la moitié d'un ton.

{| class=&quot;wikitable&quot;
|+ Fréquences des notes (en hertz) dans la gamme tempérée
|-
! scope=col | Note
! scope=col | Fréquence&lt;br /&gt;(Hz)
|-
|''la''
|220
|-
|''la''♯ ou ''si''♭
|233,1
|-
|''si'' ou ''do''♭
|246,9
|-
| ''do'' ou ''si''♯
|261,6
|-
| ''do''♯ ou ''ré''♭
|277,2
|-
| ''ré''
|293,7
|-
| ''ré''♯ ou ''mi''♭
|311,1
|-
| ''mi'' ou ''fa''♭
|329,6
|-
| ''fa'' ou ''mi''♯
|349,2
|-
| ''fa''♯ ou ''sol''♭
|370,0
|-
| ''sol''
|392,0
|-
| ''sol''♯ ou ''la''♭
|415,3
|-
|''la''
|440
|}

La gamme tempérée est une gamme relativement récente, créée pour les instruments à « son fixe » comme le piano — la plupart des instruments permettent de moduler le son, en faisant varier la position des doigts sur une touche lisse pour le violon, en faisant varier la pression de l'air pour les vents… Les instruments frettés, comme les guitares, avaient autrefois des frettes coulissantes afin de régler le tempérament ; les frettes sont maintenant fixes pour un tempérament égal.

[[File:Echelles lineaires frequence notes pythagore et temprament egal.svg|class=transparent|center|Comparaison des gammes pythagoricienne et tempérée.]]

Voir les articles de Wikipédia ''[[w:Tempérament|Tempérament]]'' et ''[[w:Gammes_et_tempéraments_dans_la_musique_occidentale|Gamme et tempéraments]]''.

=== Cercle des quintes ===
[[Fichier:YB4003Cycle des quintes temperees.png|vignette|Cercle des quintes.]]

La musique « tonale » ayant à l'origine été construite sur une succession de quinte, le diagramme dit « cercle des quintes » fournit un moyen mnémotechnique et pédagogique pour comprendre certaines choses. Ce diagramme est construit en mettant les notes séprarées quintes justes les unes à côté des autres autour d'un cercle.

Nous verrons l'utilisation de ce cercle plus loin, mais rappelons-nous d'une chose : deux notes voisines sur le cercle ont un rapport de fréquence harmonieux (1,5), et sonnent donc agréablement lorsqu'on les joue ensemble ou bien l'une après l'autre.

=== Pythagore contre Aristoxène ===
Si Pythagore (env. –580 à –495) a construit l'échelle musicale sur les mathématiques, [[w:fr:Aristoxène|Aristoxène]] (env. –360 à –300) estime quant à lui que c'est le ressenti qui doit servir à construire l'harmonie. De fait, de nombreuses musiques dans le monde ne suivent pas l'échelle pythagoricienne, et le tempérament égal est lui-même un écart au rapport mathématique des fréquences…

== Références ==
{{références}}

----
''[[../Transmettre la musique|Transmettre la musique]]'' &amp;lt; [[../|↑]] &amp;gt; ''[[../Gammes et intervalles|Gammes et intervalles]]''

[[Catégorie:Formation musicale (livre)|Caracteristiques et notation des sons musicaux]]</text>
      <sha1>8nzlplny4f21v9phguwl3dq6bqeodkc</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc matrices/a217</title>
    <ns>0</ns>
    <id>80106</id>
    <revision>
      <id>745387</id>
      <parentid>703760</parentid>
      <timestamp>2025-06-26T14:17:08Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745387</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1709" sha1="77v47mwt1d4t4wl4auzvjxolnlha7mz" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 1a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I1 + I2 = I3


 Au noeud B :
 
     Entrées = Sortie
     I3      = I1 + I2

 Soit :
 
 a) I1 + I2 - I3 = 0


 Partie gauche du circuit :
 
    I2 R2 - I1 R1 =0
 
 b) - I1 R1 + I2 R2 = 0


 Partie droite du circuit :
 
    120 - I2 R2 - I3 R3 =0
 
 c) I2 R2 + I3 R3 = 120


 Partie extérieure du circuit :
 
    120 - I3 R3 - I1 R1 = 0
 
 d) I1 R1 + I3 R3  = 120

 
 Donc:
 
 a)  I1    + I2    - I3     = 0    
 b) -I1 R1 + I2 R2          = 0
 c)          I2 R2 + I3 R3  = 120 
 d)  I1 R1         + I3 R3  = 120
  
  
 Avec R1 = 60, R2 = 30, R3 = 20  

 a)  I1    + I2    - I3     = 0    
 b) -I1 60 + I2 30          = 0
 c)          I2 30 + I3 20  = 120 
 d)  I1 60         + I3 20  = 120


 Arrangeons le système
    I1    I2    I3
    
    +1    +1    -1    = 0    
   -60   +30    +0    = 0
    +0   +30   +20    = 120 
   +60    +0   +20    = 120

  
Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
// I1    I2    I3    
   +1,   +1,   -1,   +0,    +0,
  -60,  +30,   +0,   +0,    +0,  
   +0,  +30,  +20,   +0,    +120,
  +60,   +0,  +20,   +0,    +120
};
&lt;/syntaxhighlight&gt; 


[[File:Electrical Networks Using Linear Systems 1b.png|thumb|]]

La solution est donné par la résolution du système :

   I1    I2    I3  
   +1    +0    +0    +0    +1 
   +0    +1    +0    +0    +2 
   -0    -0    +1    -0    +3 
   +0    +0    +0    +0    +0 


  I1 = 1A; I2 = 2A; I3 = 3A;


{{AutoCat}}</text>
      <sha1>77v47mwt1d4t4wl4auzvjxolnlha7mz</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc matrices/a219</title>
    <ns>0</ns>
    <id>80109</id>
    <revision>
      <id>745389</id>
      <parentid>703812</parentid>
      <timestamp>2025-06-26T14:25:05Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745389</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3779" sha1="856o7lzgmpyokhz9hof4dvitcooaahf" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 2a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I1      = I2 + I3

 Au noeud B :
 
     Entrées = Sortie
     I3      = I4 + I5

 Au noeud C :
 
     Entrées = Sortie
     I2 + I5 = I6

 Au noeud D :
 
     Entrées = Sortie
     I6 + I4 = I1

 Soit :
 
 a) +I1 -I2 -I3              = 0
            +I3 -I4 -I5      = 0
        +I2         +I5 -I6  = 0
   -I1          +I4     +I6  = 0


 Partie gauche du circuit :
 
    90 -I2 R2 - I6 R61 =   0
 
 b)    -I2 R2 - I6 R6  = -90


 Partie droite haute du circuit :
 
    I2 R2 - I3 R3 - I5 R5 = 0
 
 c) I2 R2 - I3 R3 - I5 R5 = 0


 Partie droite basse du circuit :
 
      I6 R6 + I5 R5 - I4 R4 = 0
 
 d) - I4 R4 + I5 R5 + I6 R6 = 0
 

 Partie extérieure du circuit :
 
    90 - I3 R3 - I4 R4 = 0
 
 e)  - I3 R3 - I4 R4 = -90

 
 Donc:
 
 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 R2                          -I6 R6 = -90
 c)        +I2 R2  -I3 R3          -I5 R5         =   0 
 d)                        -I4 R4  +I5 R5  +I6 R6 =   0
 e)                -I3 R3  -I4 R4                 = -90
 
  
 Avec R2 = 50, R3 = 20, R4 = 50, 
      R5 = 10, R6 = 20 

 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 50                          -I6 20 = -90
 c)        +I2 50  -I3 20          -I5 10         =   0 
 d)                        -I4 50  +I5 10  +I6 20 =   0
 e)                -I3 20  -I4 50                 = -90


 Arrangeons le système
      I1   I2   I3   I4   I5   I6
    
      +1   -1   -1   +0   +0   +0   0  0     0
      +0   +0   +1   -1   -1   +0   0  0     0
      +0   +1   +0   +0   +1   -1   0  0     0
      -1   +0   +0   +1   +0   +1   0  0     0
      +0  -50   +0   +0   +0  -20   0  0   -90
      +0  +50  -20   +0  -10   +0   0  0     0 
      +0   +0   +0  -50  +10  +20   0  0     0
      +0   +0  -20  -50   +0   +0   0  0   -90

  
Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//    I1    I2    I3    I4    I5    I6    
      +1,   -1,   -1,   +0,   +0,   +0,   0,  0,     0,
      +0,   +0,   +1,   -1,   -1,   +0,   0,  0,     0,
      +0,   +1,   +0,   +0,   +1,   -1,   0,  0,     0,
      -1,   +0,   +0,   +1,   +0,   +1,   0,  0,     0,
      +0,  -50,   +0,   +0,   +0,  -20,   0,  0,   -90,
      +0,  +50,  -20,   +0,  -10,   +0,   0,  0,     0, 
      +0,   +0,   +0,  -50,  +10,  +20,   0,  0,     0,
      +0,   +0,  -20,  -50,   +0,   +0,   0,  0,   -90,
};
&lt;/syntaxhighlight&gt; 


[[File:Electrical Networks Using Linear Systems 2b.png|thumb|]]

La solution est donné par la résolution du système :


  I1     I2     I3     I4     I5     I6 
 +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +3.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 
 I1 = 3,    I2 = 1,   I3 = 2,   I4 = 1,   I5 = 1,   I6 = 2,


{{AutoCat}}</text>
      <sha1>856o7lzgmpyokhz9hof4dvitcooaahf</sha1>
    </revision>
    <revision>
      <id>745390</id>
      <parentid>745389</parentid>
      <timestamp>2025-06-26T14:25:44Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745390</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3776" sha1="tgz7x7awzqe9fvnnk2j45iqqkd3wqon" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 2a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I1      = I2 + I3

 Au noeud B :
 
     Entrées = Sortie
     I3      = I4 + I5

 Au noeud C :
 
     Entrées = Sortie
     I2 + I5 = I6

 Au noeud D :
 
     Entrées = Sortie
     I6 + I4 = I1

 Soit :
 
 a) +I1 -I2 -I3              = 0
            +I3 -I4 -I5      = 0
        +I2         +I5 -I6  = 0
   -I1          +I4     +I6  = 0


 Partie gauche du circuit :
 
    90 -I2 R2 - I6 R61 =   0
 
 b)    -I2 R2 - I6 R6  = -90


 Partie droite haute du circuit :
 
    I2 R2 - I3 R3 - I5 R5 = 0
 
 c) I2 R2 - I3 R3 - I5 R5 = 0


 Partie droite basse du circuit :
 
      I6 R6 + I5 R5 - I4 R4 = 0
 
 d) - I4 R4 + I5 R5 + I6 R6 = 0
 

 Partie extérieure du circuit :
 
    90 - I3 R3 - I4 R4 = 0
 
 e)  - I3 R3 - I4 R4 = -90

 
 Donc:
 
 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 R2                          -I6 R6 = -90
 c)        +I2 R2  -I3 R3          -I5 R5         =   0 
 d)                        -I4 R4  +I5 R5  +I6 R6 =   0
 e)                -I3 R3  -I4 R4                 = -90


 Avec R2 = 50, R3 = 20, R4 = 50, 
      R5 = 10, R6 = 20 

 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 50                          -I6 20 = -90
 c)        +I2 50  -I3 20          -I5 10         =   0 
 d)                        -I4 50  +I5 10  +I6 20 =   0
 e)                -I3 20  -I4 50                 = -90


 Arrangeons le système
      I1   I2   I3   I4   I5   I6
    
      +1   -1   -1   +0   +0   +0   0  0     0
      +0   +0   +1   -1   -1   +0   0  0     0
      +0   +1   +0   +0   +1   -1   0  0     0
      -1   +0   +0   +1   +0   +1   0  0     0
      +0  -50   +0   +0   +0  -20   0  0   -90
      +0  +50  -20   +0  -10   +0   0  0     0 
      +0   +0   +0  -50  +10  +20   0  0     0
      +0   +0  -20  -50   +0   +0   0  0   -90

  
Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//    I1    I2    I3    I4    I5    I6    
      +1,   -1,   -1,   +0,   +0,   +0,   0,  0,     0,
      +0,   +0,   +1,   -1,   -1,   +0,   0,  0,     0,
      +0,   +1,   +0,   +0,   +1,   -1,   0,  0,     0,
      -1,   +0,   +0,   +1,   +0,   +1,   0,  0,     0,
      +0,  -50,   +0,   +0,   +0,  -20,   0,  0,   -90,
      +0,  +50,  -20,   +0,  -10,   +0,   0,  0,     0, 
      +0,   +0,   +0,  -50,  +10,  +20,   0,  0,     0,
      +0,   +0,  -20,  -50,   +0,   +0,   0,  0,   -90,
};
&lt;/syntaxhighlight&gt; 


[[File:Electrical Networks Using Linear Systems 2b.png|thumb|]]

La solution est donné par la résolution du système :


  I1     I2     I3     I4     I5     I6 
 +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +3.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 
 I1 = 3,    I2 = 1,   I3 = 2,   I4 = 1,   I5 = 1,   I6 = 2,


{{AutoCat}}</text>
      <sha1>tgz7x7awzqe9fvnnk2j45iqqkd3wqon</sha1>
    </revision>
    <revision>
      <id>745391</id>
      <parentid>745390</parentid>
      <timestamp>2025-06-26T14:26:55Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745391</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3763" sha1="dy8silv9iihzdxdnvcqpi4d96zgufpb" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 2a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I1      = I2 + I3

 Au noeud B :
 
     Entrées = Sortie
     I3      = I4 + I5

 Au noeud C :
 
     Entrées = Sortie
     I2 + I5 = I6

 Au noeud D :
 
     Entrées = Sortie
     I6 + I4 = I1

 Soit :
 
 a) +I1 -I2 -I3              = 0
            +I3 -I4 -I5      = 0
        +I2         +I5 -I6  = 0
   -I1          +I4     +I6  = 0

 Partie gauche du circuit :
 
    90 -I2 R2 - I6 R61 =   0
 
 b)    -I2 R2 - I6 R6  = -90

 Partie droite haute du circuit :
 
    I2 R2 - I3 R3 - I5 R5 = 0
 
 c) I2 R2 - I3 R3 - I5 R5 = 0

 Partie droite basse du circuit :
 
      I6 R6 + I5 R5 - I4 R4 = 0
 
 d) - I4 R4 + I5 R5 + I6 R6 = 0
 
 Partie extérieure du circuit :
 
    90 - I3 R3 - I4 R4 = 0
 
 e)  - I3 R3 - I4 R4 = -90

 Donc:
 
 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 R2                          -I6 R6 = -90
 c)        +I2 R2  -I3 R3          -I5 R5         =   0 
 d)                        -I4 R4  +I5 R5  +I6 R6 =   0
 e)                -I3 R3  -I4 R4                 = -90

 Avec R2 = 50, R3 = 20, R4 = 50, 
      R5 = 10, R6 = 20 

 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 50                          -I6 20 = -90
 c)        +I2 50  -I3 20          -I5 10         =   0 
 d)                        -I4 50  +I5 10  +I6 20 =   0
 e)                -I3 20  -I4 50                 = -90

 Arrangeons le système
      I1   I2   I3   I4   I5   I6
    
      +1   -1   -1   +0   +0   +0   0  0     0
      +0   +0   +1   -1   -1   +0   0  0     0
      +0   +1   +0   +0   +1   -1   0  0     0
      -1   +0   +0   +1   +0   +1   0  0     0
      +0  -50   +0   +0   +0  -20   0  0   -90
      +0  +50  -20   +0  -10   +0   0  0     0 
      +0   +0   +0  -50  +10  +20   0  0     0
      +0   +0  -20  -50   +0   +0   0  0   -90

Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//    I1    I2    I3    I4    I5    I6    
      +1,   -1,   -1,   +0,   +0,   +0,   0,  0,     0,
      +0,   +0,   +1,   -1,   -1,   +0,   0,  0,     0,
      +0,   +1,   +0,   +0,   +1,   -1,   0,  0,     0,
      -1,   +0,   +0,   +1,   +0,   +1,   0,  0,     0,
      +0,  -50,   +0,   +0,   +0,  -20,   0,  0,   -90,
      +0,  +50,  -20,   +0,  -10,   +0,   0,  0,     0, 
      +0,   +0,   +0,  -50,  +10,  +20,   0,  0,     0,
      +0,   +0,  -20,  -50,   +0,   +0,   0,  0,   -90,
};
&lt;/syntaxhighlight&gt; 


[[File:Electrical Networks Using Linear Systems 2b.png|thumb|]]

La solution est donné par la résolution du système :


  I1     I2     I3     I4     I5     I6 
 +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +3.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 
 I1 = 3,    I2 = 1,   I3 = 2,   I4 = 1,   I5 = 1,   I6 = 2,

{{AutoCat}}</text>
      <sha1>dy8silv9iihzdxdnvcqpi4d96zgufpb</sha1>
    </revision>
    <revision>
      <id>745392</id>
      <parentid>745391</parentid>
      <timestamp>2025-06-26T14:27:27Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745392</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3762" sha1="mhqvlgn1kv1bb6vizc1jsf4u4mhmqnt" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 2a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I1      = I2 + I3

 Au noeud B :
 
     Entrées = Sortie
     I3      = I4 + I5

 Au noeud C :
 
     Entrées = Sortie
     I2 + I5 = I6

 Au noeud D :
 
     Entrées = Sortie
     I6 + I4 = I1

 Soit :
 
 a) +I1 -I2 -I3              = 0
            +I3 -I4 -I5      = 0
        +I2         +I5 -I6  = 0
   -I1          +I4     +I6  = 0

 Partie gauche du circuit :
 
    90 -I2 R2 - I6 R61 =   0
 
 b)    -I2 R2 - I6 R6  = -90

 Partie droite haute du circuit :
 
    I2 R2 - I3 R3 - I5 R5 = 0
 
 c) I2 R2 - I3 R3 - I5 R5 = 0

 Partie droite basse du circuit :
 
      I6 R6 + I5 R5 - I4 R4 = 0
 
 d) - I4 R4 + I5 R5 + I6 R6 = 0

 Partie extérieure du circuit :
 
    90 - I3 R3 - I4 R4 = 0
 
 e)  - I3 R3 - I4 R4 = -90

 Donc:
 
 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 R2                          -I6 R6 = -90
 c)        +I2 R2  -I3 R3          -I5 R5         =   0 
 d)                        -I4 R4  +I5 R5  +I6 R6 =   0
 e)                -I3 R3  -I4 R4                 = -90

 Avec R2 = 50, R3 = 20, R4 = 50, 
      R5 = 10, R6 = 20 

 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 50                          -I6 20 = -90
 c)        +I2 50  -I3 20          -I5 10         =   0 
 d)                        -I4 50  +I5 10  +I6 20 =   0
 e)                -I3 20  -I4 50                 = -90

 Arrangeons le système
      I1   I2   I3   I4   I5   I6
    
      +1   -1   -1   +0   +0   +0   0  0     0
      +0   +0   +1   -1   -1   +0   0  0     0
      +0   +1   +0   +0   +1   -1   0  0     0
      -1   +0   +0   +1   +0   +1   0  0     0
      +0  -50   +0   +0   +0  -20   0  0   -90
      +0  +50  -20   +0  -10   +0   0  0     0 
      +0   +0   +0  -50  +10  +20   0  0     0
      +0   +0  -20  -50   +0   +0   0  0   -90

Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//    I1    I2    I3    I4    I5    I6    
      +1,   -1,   -1,   +0,   +0,   +0,   0,  0,     0,
      +0,   +0,   +1,   -1,   -1,   +0,   0,  0,     0,
      +0,   +1,   +0,   +0,   +1,   -1,   0,  0,     0,
      -1,   +0,   +0,   +1,   +0,   +1,   0,  0,     0,
      +0,  -50,   +0,   +0,   +0,  -20,   0,  0,   -90,
      +0,  +50,  -20,   +0,  -10,   +0,   0,  0,     0, 
      +0,   +0,   +0,  -50,  +10,  +20,   0,  0,     0,
      +0,   +0,  -20,  -50,   +0,   +0,   0,  0,   -90,
};
&lt;/syntaxhighlight&gt; 


[[File:Electrical Networks Using Linear Systems 2b.png|thumb|]]

La solution est donné par la résolution du système :


  I1     I2     I3     I4     I5     I6 
 +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +3.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 
 I1 = 3,    I2 = 1,   I3 = 2,   I4 = 1,   I5 = 1,   I6 = 2,

{{AutoCat}}</text>
      <sha1>mhqvlgn1kv1bb6vizc1jsf4u4mhmqnt</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc matrices/a221</title>
    <ns>0</ns>
    <id>80112</id>
    <revision>
      <id>745394</id>
      <parentid>703829</parentid>
      <timestamp>2025-06-26T14:34:25Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745394</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3778" sha1="facf4d61cewnstbtm7lzw3753p5j21v" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 3a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I2 + I3 = I1

 Au noeud B :
 
     Entrées = Sortie
     I4      = I3 + I5

 Au noeud C :
 
     Entrées = Sortie
     I6 + I5 = I4

 Au noeud D :
 
     Entrées = Sortie
     I1      = I6 + I2

 Soit :
 
 a) -I1  +I2  +I3                 = 0
              -I3  +I4  -I5       = 0
                   -I4  +I5  +I6  = 0
    +I1  -I2                 -I6  = 0

 Partie gauche du circuit :
 
  -90 +I1 R1 + I2 R2 =   0
 
 b)     +I1 R1 +I2 R2 =   +90

 Partie centrale du circuit :
 
    -I2 R2 + I3 R3 + I4 R4 + I6 R6 = 0
 
 c) -I2 R2 +I3 R3 +I4 R4 +I6 R6 = 0

 Partie droite du circuit :
  
    90 - I5 R5 - I4 R4 = 0
 
 d)    -I4 R4 -I5 R5  = -90

 Partie extérieure du circuit :
 
    -90 + I1 R1 + I3 R3 + 90 - I5 R5 + I6 R6 = 0
 
 e)     +I1 R1 +I3 R3  -I5 R5 +I6 R6 = 0

 Donc:
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 R1  +I2 R2                                  = +90
 c)         -I2 R2  +I3 R3  +I4 R4          +I6 R6  =  +0
 d)                         -I4 R4  -I5 R5          = -90
 e) +I1 R1          +I3 R3          -I5 R5  +I6 R6  =  +0

 Avec R1 = 15, R2 = 60, R3 = 15, R4 = 15, R5 = 60, R6 = 15 
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 15  +I2 60                                  = +90
 c)         -I2 60  +I3 15  +I4 15          +I6 15  =  +0
 d)                         -I4 15  -I5 60          = -90
 e) +I1 15          +I3 15          -I5 60  +I6 15  =  +0

 Arrangeons le système
     I1   I2   I3   I4   I5   I6
    
 a)  -1   +1   +1   +0   +0   +0     +0
     +0   +0   -1   +1   -1   +0     +0
     +0   +0   +0   -1   +1   +1     +0
     +1   -1   +0   +0   +0   -1     +0
 b) +15  +60   +0   +0   +0   +0    +90
 c)  +0  -60  +15  +15   +0  +15     +0
 d)  +0   +0   +0  -15  -60   +0    -90
 e) +15   +0  +15   +0  -60  +15     +0

Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//   I1    I2    I3    I4    I5    I6    
     -1,   +1,   +1,   +0,   +0,   +0,   +0, +0,   +0,
     +0,   +0,   -1,   +1,   -1,   +0,   +0, +0,   +0,
     +0,   +0,   +0,   -1,   +1,   +1,   +0, +0,   +0,
     +1,   -1,   +0,   +0,   +0,   -1,   +0, +0,   +0,
    +15,  +60,   +0,   +0,   +0,   +0,   +0, +0,  +90,
     +0,  -60,  +15,  +15,   +0,  +15,   +0, +0,   +0,
     +0,   +0,   +0,  -15,  -60,   +0,   +0, +0,  -90,
    +15,   +0,  +15,   +0,  -60,  +15,   +0, +0,   +0
};
&lt;/syntaxhighlight&gt; 


[[File:Electrical Networks Using Linear Systems 3b.png|thumb|]]

La solution est donné par la résolution du système :


  I1     I2     I3     I4     I5     I6 
 +1.00  -0.00  -0.00  +0.00  -0.00  +0.00  -0.00  -0.00  +2.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 


 I1 = 2,    I2 = 1,   I3 = 1,   I4 = 2,   I5 = 1,   I6 = 1,

{{AutoCat}}</text>
      <sha1>facf4d61cewnstbtm7lzw3753p5j21v</sha1>
    </revision>
    <revision>
      <id>745395</id>
      <parentid>745394</parentid>
      <timestamp>2025-06-26T14:39:53Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745395</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3774" sha1="r3hh8r7fknznzu92te6eznnqa03ois9" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 3a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I2 + I3 = I1

 Au noeud B :
 
     Entrées = Sortie
     I4      = I3 + I5

 Au noeud C :
 
     Entrées = Sortie
     I6 + I5 = I4

 Au noeud D :
 
     Entrées = Sortie
     I1      = I6 + I2

 Soit :
 
 a) -I1  +I2  +I3                 = 0
              -I3  +I4  -I5       = 0
                   -I4  +I5  +I6  = 0
    +I1  -I2                 -I6  = 0

 Partie gauche du circuit :
 
  -90 +I1 R1 + I2 R2 =   0
 
 b)     +I1 R1 +I2 R2 =   +90

 Partie centrale du circuit :
 
    -I2 R2 + I3 R3 + I4 R4 + I6 R6 = 0
 
 c) -I2 R2 +I3 R3 +I4 R4 +I6 R6 = 0

 Partie droite du circuit :
  
    90 - I5 R5 - I4 R4 = 0
 
 d)    -I4 R4 -I5 R5  = -90

 Partie extérieure du circuit :
 
    -90 + I1 R1 + I3 R3 + 90 - I5 R5 + I6 R6 = 0
 
 e)     +I1 R1 +I3 R3  -I5 R5 +I6 R6 = 0

 Donc:
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 R1  +I2 R2                                  = +90
 c)         -I2 R2  +I3 R3  +I4 R4          +I6 R6  =  +0
 d)                         -I4 R4  -I5 R5          = -90
 e) +I1 R1          +I3 R3          -I5 R5  +I6 R6  =  +0

 Avec R1 = 15, R2 = 60, R3 = 15, R4 = 15, R5 = 60, R6 = 15 
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 15  +I2 60                                  = +90
 c)         -I2 60  +I3 15  +I4 15          +I6 15  =  +0
 d)                         -I4 15  -I5 60          = -90
 e) +I1 15          +I3 15          -I5 60  +I6 15  =  +0

 Arrangeons le système
     I1   I2   I3   I4   I5   I6
    
 a)  -1   +1   +1   +0   +0   +0     +0
     +0   +0   -1   +1   -1   +0     +0
     +0   +0   +0   -1   +1   +1     +0
     +1   -1   +0   +0   +0   -1     +0
 b) +15  +60   +0   +0   +0   +0    +90
 c)  +0  -60  +15  +15   +0  +15     +0
 d)  +0   +0   +0  -15  -60   +0    -90
 e) +15   +0  +15   +0  -60  +15     +0

Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//   I1    I2    I3    I4    I5    I6    
     -1,   +1,   +1,   +0,   +0,   +0,   +0, +0,   +0,
     +0,   +0,   -1,   +1,   -1,   +0,   +0, +0,   +0,
     +0,   +0,   +0,   -1,   +1,   +1,   +0, +0,   +0,
     +1,   -1,   +0,   +0,   +0,   -1,   +0, +0,   +0,
    +15,  +60,   +0,   +0,   +0,   +0,   +0, +0,  +90,
     +0,  -60,  +15,  +15,   +0,  +15,   +0, +0,   +0,
     +0,   +0,   +0,  -15,  -60,   +0,   +0, +0,  -90,
    +15,   +0,  +15,   +0,  -60,  +15,   +0, +0,   +0
};
&lt;/syntaxhighlight&gt; 

[[File:Electrical Networks Using Linear Systems 3b.png|thumb|]]

La solution est donné par la résolution du système :

  I1     I2     I3     I4     I5     I6 
 +1.00  -0.00  -0.00  +0.00  -0.00  +0.00  -0.00  -0.00  +2.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 

 I1 = 2,    I2 = 1,   I3 = 1,   I4 = 2,   I5 = 1,   I6 = 1,
{{AutoCat}}</text>
      <sha1>r3hh8r7fknznzu92te6eznnqa03ois9</sha1>
    </revision>
    <revision>
      <id>745396</id>
      <parentid>745395</parentid>
      <timestamp>2025-06-26T14:40:27Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745396</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3775" sha1="gc7sp44d2cb0qygz4v72lou77ka4zzu" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 3a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I2 + I3 = I1

 Au noeud B :
 
     Entrées = Sortie
     I4      = I3 + I5

 Au noeud C :
 
     Entrées = Sortie
     I6 + I5 = I4

 Au noeud D :
 
     Entrées = Sortie
     I1      = I6 + I2

 Soit :
 
 a) -I1  +I2  +I3                 = 0
              -I3  +I4  -I5       = 0
                   -I4  +I5  +I6  = 0
    +I1  -I2                 -I6  = 0

 Partie gauche du circuit :
 
  -90 +I1 R1 + I2 R2 =   0
 
 b)     +I1 R1 +I2 R2 =   +90

 Partie centrale du circuit :
 
    -I2 R2 + I3 R3 + I4 R4 + I6 R6 = 0
 
 c) -I2 R2 +I3 R3 +I4 R4 +I6 R6 = 0

 Partie droite du circuit :
  
    90 - I5 R5 - I4 R4 = 0
 
 d)    -I4 R4 -I5 R5  = -90

 Partie extérieure du circuit :
 
    -90 + I1 R1 + I3 R3 + 90 - I5 R5 + I6 R6 = 0
 
 e)     +I1 R1 +I3 R3  -I5 R5 +I6 R6 = 0

 Donc:
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 R1  +I2 R2                                  = +90
 c)         -I2 R2  +I3 R3  +I4 R4          +I6 R6  =  +0
 d)                         -I4 R4  -I5 R5          = -90
 e) +I1 R1          +I3 R3          -I5 R5  +I6 R6  =  +0

 Avec R1 = 15, R2 = 60, R3 = 15, R4 = 15, R5 = 60, R6 = 15 
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 15  +I2 60                                  = +90
 c)         -I2 60  +I3 15  +I4 15          +I6 15  =  +0
 d)                         -I4 15  -I5 60          = -90
 e) +I1 15          +I3 15          -I5 60  +I6 15  =  +0

 Arrangeons le système
     I1   I2   I3   I4   I5   I6
    
 a)  -1   +1   +1   +0   +0   +0     +0
     +0   +0   -1   +1   -1   +0     +0
     +0   +0   +0   -1   +1   +1     +0
     +1   -1   +0   +0   +0   -1     +0
 b) +15  +60   +0   +0   +0   +0    +90
 c)  +0  -60  +15  +15   +0  +15     +0
 d)  +0   +0   +0  -15  -60   +0    -90
 e) +15   +0  +15   +0  -60  +15     +0

Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//   I1    I2    I3    I4    I5    I6    
     -1,   +1,   +1,   +0,   +0,   +0,   +0, +0,   +0,
     +0,   +0,   -1,   +1,   -1,   +0,   +0, +0,   +0,
     +0,   +0,   +0,   -1,   +1,   +1,   +0, +0,   +0,
     +1,   -1,   +0,   +0,   +0,   -1,   +0, +0,   +0,
    +15,  +60,   +0,   +0,   +0,   +0,   +0, +0,  +90,
     +0,  -60,  +15,  +15,   +0,  +15,   +0, +0,   +0,
     +0,   +0,   +0,  -15,  -60,   +0,   +0, +0,  -90,
    +15,   +0,  +15,   +0,  -60,  +15,   +0, +0,   +0
};
&lt;/syntaxhighlight&gt; 

[[File:Electrical Networks Using Linear Systems 3b.png|thumb|]]

La solution est donné par la résolution du système :
 
  I1     I2     I3     I4     I5     I6 
 +1.00  -0.00  -0.00  +0.00  -0.00  +0.00  -0.00  -0.00  +2.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 

 I1 = 2,    I2 = 1,   I3 = 1,   I4 = 2,   I5 = 1,   I6 = 1,
{{AutoCat}}</text>
      <sha1>gc7sp44d2cb0qygz4v72lou77ka4zzu</sha1>
    </revision>
    <revision>
      <id>745397</id>
      <parentid>745396</parentid>
      <timestamp>2025-06-26T14:41:39Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745397</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3777" sha1="bio5mnsk89q89gxdsxmaqc2x4iav02i" xml:space="preserve">[[Catégorie:Mathc matrices (livre)]]


[[Mathc matrices/a216| '''Application''']]


[[File:Electrical Networks Using Linear Systems 3a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I2 + I3 = I1

 Au noeud B :
 
     Entrées = Sortie
     I4      = I3 + I5

 Au noeud C :
 
     Entrées = Sortie
     I6 + I5 = I4

 Au noeud D :
 
     Entrées = Sortie
     I1      = I6 + I2

 Soit :
 
 a) -I1  +I2  +I3                 = 0
              -I3  +I4  -I5       = 0
                   -I4  +I5  +I6  = 0
    +I1  -I2                 -I6  = 0

 Partie gauche du circuit :
 
  -90 +I1 R1 + I2 R2 =   0
 
 b)     +I1 R1 +I2 R2 =   +90

 Partie centrale du circuit :
 
    -I2 R2 + I3 R3 + I4 R4 + I6 R6 = 0
 
 c) -I2 R2 +I3 R3 +I4 R4 +I6 R6 = 0

 Partie droite du circuit :
  
    90 - I5 R5 - I4 R4 = 0
 
 d)    -I4 R4 -I5 R5  = -90

 Partie extérieure du circuit :
 
    -90 + I1 R1 + I3 R3 + 90 - I5 R5 + I6 R6 = 0
 
 e)     +I1 R1 +I3 R3  -I5 R5 +I6 R6 = 0

 Donc:
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 R1  +I2 R2                                  = +90
 c)         -I2 R2  +I3 R3  +I4 R4          +I6 R6  =  +0
 d)                         -I4 R4  -I5 R5          = -90
 e) +I1 R1          +I3 R3          -I5 R5  +I6 R6  =  +0

 Avec R1 = 15, R2 = 60, R3 = 15, R4 = 15, R5 = 60, R6 = 15 
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 15  +I2 60                                  = +90
 c)         -I2 60  +I3 15  +I4 15          +I6 15  =  +0
 d)                         -I4 15  -I5 60          = -90
 e) +I1 15          +I3 15          -I5 60  +I6 15  =  +0

 Arrangeons le système
     I1   I2   I3   I4   I5   I6
    
 a)  -1   +1   +1   +0   +0   +0     +0
     +0   +0   -1   +1   -1   +0     +0
     +0   +0   +0   -1   +1   +1     +0
     +1   -1   +0   +0   +0   -1     +0
 b) +15  +60   +0   +0   +0   +0    +90
 c)  +0  -60  +15  +15   +0  +15     +0
 d)  +0   +0   +0  -15  -60   +0    -90
 e) +15   +0  +15   +0  -60  +15     +0

Le code en langage C :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//   I1    I2    I3    I4    I5    I6    
     -1,   +1,   +1,   +0,   +0,   +0,   +0, +0,   +0,
     +0,   +0,   -1,   +1,   -1,   +0,   +0, +0,   +0,
     +0,   +0,   +0,   -1,   +1,   +1,   +0, +0,   +0,
     +1,   -1,   +0,   +0,   +0,   -1,   +0, +0,   +0,
    +15,  +60,   +0,   +0,   +0,   +0,   +0, +0,  +90,
     +0,  -60,  +15,  +15,   +0,  +15,   +0, +0,   +0,
     +0,   +0,   +0,  -15,  -60,   +0,   +0, +0,  -90,
    +15,   +0,  +15,   +0,  -60,  +15,   +0, +0,   +0
};
&lt;/syntaxhighlight&gt; 

[[File:Electrical Networks Using Linear Systems 3b.png|thumb|]]
 La solution est donné par la résolution du système :
  
  I1     I2     I3     I4     I5     I6 
 +1.00  -0.00  -0.00  +0.00  -0.00  +0.00  -0.00  -0.00  +2.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 
 I1 = 2,    I2 = 1,   I3 = 1,   I4 = 2,   I5 = 1,   I6 = 1,
{{AutoCat}}</text>
      <sha1>bio5mnsk89q89gxdsxmaqc2x4iav02i</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc matrices/a259</title>
    <ns>0</ns>
    <id>80174</id>
    <revision>
      <id>745458</id>
      <parentid>730770</parentid>
      <timestamp>2025-06-27T11:49:16Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <minor />
      <origin>745458</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3076" sha1="hxw2w6xx0ryivil2mk9oa6wofu28s5p" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc matrices (livre)]]
:

[[Mathc matrices/c21p| '''Propriétés et Applications''']]


----{{Partie{{{type|}}}| '''Gauss-Jordan''' [[https://youtube.com/playlist?list=PLi6peGpf8EPODYQZ0fosFTZZqKB9-CkHi Playlist]]}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/Fichiers c : test02a| Présentation du Total Pivoting et du Partial Pivoting]]}}
:
.
:
{{Partie{{{type|}}}| '''Total Pivoting'''  }}
:
{{Partie{{{type|}}}| Résoudre un système d'équations :}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a205| Gauss-Jordan]]}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a206| Variables libres]]}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a207| L'inverse]]}}
:
{{Partie{{{type|}}}|[[Mathc matrices/a208| Systèmes '''non linéaire''' ]]}}
:
{{Partie{{{type|}}}|[[Mathc matrices/a32| Choisir les solutions d'un système '''linéaire''' ou '''non linéaire''']]}}
:
.
:
{{Partie{{{type|}}}| Étude du code : '''Total Pivoting'''}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/e15| La fonction gj_TP_mR();]]}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/e09a| La fonction invgj_mR(); ]]}}
:
.
:
{{Partie{{{type|}}}| Application : '''Total Pivoting'''  }}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a209| Analyse d'un '''réseau''' ]]}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a216| Analyse d'un circuit '''électrique''' ]]}}
:
.
:
 {{Partie{{{type|}}}|Applications en géometrie }}
:
 {{Partie{{{type|}}}|[[Mathc matrices/26a| L'équation d'un '''polynôme''']]}} 
:
 {{Partie{{{type|}}}|[[Mathc matrices/26b| L'équation d'un '''conique''']]}} 
:
 {{Partie{{{type|}}}|[[Mathc matrices/26c| L'équation d'un '''cercle''']]}} 
:
.
:
 {{Partie{{{type|}}}| '''Partial Pivoting''' }}
:
:
 {{Partie{{{type|}}}| Résoudre un système d'équations :}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a203| Gauss-Jordan]]}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a204| Variables libres]]}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a39| Rendre un système '''compatibles''' en introduisant des paramètres]]}}
:
.
:
{{Partie{{{type|}}}| Étude du code :  '''Partial Pivoting'''}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/e16| La fonction gj_PP_mR(); ]]}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/c101f| Variables libres]]}}
:
.
:
{{Partie{{{type|}}}| Application : '''Partial Pivoting'''  }}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a201| Équilibrer une équation '''chimique''']]}}
:
.
:
 {{Partie{{{type|}}}|By Hand }}
:
 {{Partie{{{type|}}}|[[Mathc matrices/a30| Résoudre et Inverser avec des fractions à la main]]}}  
:
 {{Partie{{{type|}}}|[[Mathc matrices/a31| Inverser une matrice triangulaire à la main]]}}  
:
.
:
 {{Partie{{{type|}}}| '''Les bases'''}}
:
 {{Partie{{{type|}}}|[[Mathc matrices/c21s| Trouver une base pour ...]]}}  
:
 {{Partie{{{type|}}}|[[Mathc matrices/c24f| Matrices de changement de base]]}} 
:
 {{Partie{{{type|}}}|[[Mathc matrices/c24k|  Matrice d'une application linéaire par rapport à la base &quot;B&quot;]]}} 
:
.
:
 {{Partie{{{type|}}}| '''Les projections''' }}
:
 {{Partie{{{type|}}}|[[Mathc matrices/e05b| Projection sur un sous-espace vectoriel]]}} 
:
.
:
{{AutoCat}}</text>
      <sha1>hxw2w6xx0ryivil2mk9oa6wofu28s5p</sha1>
    </revision>
  </page>
  <page>
    <title>Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020</title>
    <ns>0</ns>
    <id>82108</id>
    <revision>
      <id>745444</id>
      <parentid>745332</parentid>
      <timestamp>2025-06-26T23:50:09Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <comment>Bannière supprimée</comment>
      <origin>745444</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="11846" sha1="rddu0h2fo2e1jgbnfb7yiivgtn9gm0p" xml:space="preserve">{{Page de garde|image=OSPO cover.png|description=

'''Observations préliminaires&amp;nbsp;: Observatoire des politiques d'Érudition ouverte, 2017-2020''' est un recueil de réflexions, sous forme de livre, sur des questions pertinentes au mouvement de la science ouverte. Ce tome vise à faciliter la compréhension de la science sociale ouverte à travers le Canada et à l'international, afin de contribuer à influencer et à mettre en œuvre des politiques liées à la mobilisation des connaissances. Ce faisant, il reflète les politiques pertinentes et leur impact sur les communautés de recherche, tout en signalant les tendances et les recherches actuelles; et offre une base large et approfondie pour l'élaboration de recommandations politiques sur des questions importantes, notamment la gestion de l'identité, l'accès ouvert, la gestion des données, la science citoyenne et d'autres domaines connexes.

|avancement=Terminé
|cdu=
* {{CDU item|3/31|316}}
|versions=
{{Moteur}}
}}

''Pour lire la version anglaise de ce texte, voir [[b:en:Foundational Observations: Open Scholarship Policy Observatory, 2017-2020 | Foundational Observations: Open Scholarship Policy Observatory, 2017-2020]].''

''Pour le deuxième volume de cette série, voir [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 | Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024]].

&lt;big&gt;&lt;div style=&quot;text-align: left;&quot;&gt;'''Éditrices / Éditeurs&amp;nbsp;: Alyssa Arbuckle, Ray Siemens, Tanja Niemann, Lynne Siemens'''&lt;/div&gt;&lt;/big&gt;
&lt;big&gt;&lt;div style=&quot;text-align: left;&quot;&gt;'''Auteures / Auteurs&amp;nbsp;: Sarah Milligan, Alyssa Arbuckle, Kim Silk, Caroline Winter'''&lt;/div&gt;&lt;/big&gt;

==Table des matières==

===[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Introduction | Introduction]]===
===2017===
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Politique_des_trois_organismes_sur_le_libre_accès_aux_publications | Politique des trois organismes sur le libre accès aux publications]] &lt;small&gt;(Milligan)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/L'Examen_du_soutien_fédéral_aux_sciences | L'Examen du soutien fédéral aux sciences]] &lt;small&gt;(Milligan)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Access_Copyright_c._Université_York | Access Copyright c. Université York]] &lt;small&gt;(Milligan)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Feuille_de_route_sur_la_communication_savante_de_l'ABRC | Feuille de route sur la communication savante de l'ABRC]] &lt;small&gt;(Milligan)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Recommandations_politiques_pour_le_libre_accès_aux_données_de_recherche_en_Europe_(RECODE) | Recommandations politiques pour le libre accès aux données de recherche en Europe (RECODE)]] &lt;small&gt;(Arbuckle)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Groupe_de_travail_sur_la_science_ouverte_du_G7 | Groupe de travail sur la science ouverte du G7]] &lt;small&gt;(Milligan)&lt;/small&gt;

===2018===
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Déclaration_de_principes_des_trois_organismes_sur_la_gestion_des_données_numériques | Déclaration de principes des trois organismes sur la gestion des données numériques]] &lt;small&gt;(Milligan)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Appel_de_Jussieu_pour_la_Science_ouverte_et_la_bibliodiversité | Appel de Jussieu pour la Science ouverte et la bibliodiversité]] &lt;small&gt;(Milligan)&lt;/small&gt;
*[[b:en:Foundational_Observations:_Open_Scholarship_Policy_Observatory,_2017-2020/Integrated_Digital_Scholarship_Ecosystem | Integrated Digital Scholarship Ecosystem]] &lt;small&gt;(Milligan)&lt;/small&gt;{{ref|Ce texte est uniquement disponible en anglais.|a}}
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/ORCID : Connecter la recherche et les chercheurs | ORCID : Connecter la recherche et les chercheurs]] &lt;small&gt;(Silk)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le_gouvernement_ouvert | Le gouvernement ouvert]] &lt;small&gt;(Silk)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Négociations_de_l'édition_à_libre_accès_en_Europe | Négociations de l'édition à libre accès en Europe]] &lt;small&gt;(Silk)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Comment_le_budget_fédéral_de_2018_affecte_la_recherche_au_Canada | Comment le budget fédéral de 2018 affecte la recherche au Canada]] &lt;small&gt;(Silk)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Ouvrir_les_outils_d'annotation | Ouvrir les outils d'annotation]] &lt;small&gt;(Silk)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan_S_et_cOAlition_S | Plan S et cOAlition S]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le_Canada_célèbre_la_Semaine_du_libre_accès_international_2018 | Le Canada célèbre la Semaine du libre accès international 2018]] &lt;small&gt;(Winter)&lt;/small&gt;
{{reflist}}

===2019===
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Conformité_à_la_politique_de_libre_accès_au_Canada | Conformité à la politique de libre accès au Canada]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/L'Analysis_&amp;_Policy_Observatory | L'Analysis &amp; Policy Observatory]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Film Paywall : The Business of Scholarship | Le Film Paywall : The Business of Scholarship]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La_rupture_entre_Elsevier_et_l'University_of_California | La rupture entre Elsevier et l'University of California]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La_semain_de_l'éducation_ouverte_2019 | La semain de l'éducation ouverte 2019]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/L'éducation_ouverte_en_Colombie_Britannique | L'éducation ouverte en Colombie Britannique]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le_Projet_Review,_Promotion,_and_Tenure_à_ScholCommLab | Le Projet «&amp;#8239;Review, Promotion, and Tenure&amp;#8239;» à ScholCommLab]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Déclaration_électorale_commune_de_CAUL-AOASG | Déclaration électorale commune de CAUL-AOASG]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le_directive_de_l'Union_Européenne_sur_le_droit_d'auteur_dans_le_marché_unique_numérique | Le directive de l'Union Européenne sur le droit d'auteur dans le marché unique numérique]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le_Canadian–Australian_Partnership_for_Open_Scholarship_(CAPOS) | Le Canadian–Australian Partnership for Open Scholarship (CAPOS)]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Les_médias_sociaux_pour_la_communauté_savant | Les médias sociaux pour la communauté savant]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche | Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche]] &lt;small&gt;(Winter)&lt;/small&gt;

===2020===
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Wikidata_dans_les_bibliothèques_de_recherche | Wikidata dans les bibliothèques de recherche]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La_déclaration_de_la_Sorbonne_sur_les_droits_relatifs_aux_données_de_recherche | La déclaration de la Sorbonne sur les droits relatifs aux données de recherche]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le_politique_des_trois_organismes_sur_la_gestion_des_données_de_recherche | Le politique des trois organismes sur la gestion des données de recherche]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/NOIRN_et_la_stratégie_canadienne_d’infrastructure_de_recherche_numérique | NOIRN et la stratégie canadienne d’infrastructure de recherche numérique]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Examen_et_consultation_de_la_politique_de_L’UKRI_sur_libre_accès | Examen et consultation de la politique de L’UKRI sur libre accès]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan_Stratégique_2019–2024_du_CRKN–RCDR | Plan Stratégique 2019–2024 du CRKN–RCDR]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Science_Ouverte_et_COVID-19 | Science Ouverte et COVID-19]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mind_the_Gap_et_POP!_:_En_conversation_avec_John_Maxwell | Mind the Gap et POP! : En conversation avec John Maxwell]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La_Recommandation_de_l’UNESCO_sur_la_science_ouverte | La Recommandation de l’UNESCO sur la science ouverte]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le_Persistent_Identifier_(PID)_Consortium_de_Royaume-Uni | Le Persistent Identifier (PID) Consortium de Royaume-Uni]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/L’atelier_et_rapport_Advancing_Open_d’ABRC | L’atelier et rapport Advancing Open d’ABRC]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Feuille_de_route_pour_la_science_ouverte_du_Canada | Feuille de route pour la science ouverte du Canada]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour du Plan S : La Stratégie de conservation des droits | Mise à jour du Plan S : La Stratégie de conservation des droits]] &lt;small&gt;(Winter)&lt;/small&gt;
*[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Les_principes_TRUST_pour_les_dépôts_numériques | Les principes TRUST pour les dépôts numériques]] &lt;small&gt;(Winter)&lt;/small&gt;

[[Catégorie:Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020 (livre)]]</text>
      <sha1>rddu0h2fo2e1jgbnfb7yiivgtn9gm0p</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les programmes wikipédien(ne) en residence</title>
    <ns>0</ns>
    <id>82274</id>
    <revision>
      <id>745406</id>
      <parentid>745129</parentid>
      <timestamp>2025-06-26T18:50:51Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745406</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="19013" sha1="nanxpouuu382d8pw53e2tqy5n69ultq" xml:space="preserve">''Cette observation a été rédigée par Caroline Winter et Talya Jesperson, pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En règle générale, un wikipédien(ne)s en résidence sont des éditeurs de [https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal Wikipédia] qui agissent en tant que des liaisons entre la communauté Wikipédia et une institution, par exemple une université, un organisme de recherche, ou un galerie, bibliothèque, archive ou musée. Ces postes sont parfois connus sous le nom de wikimédien(ne) en résidence - faisant référence à l'organisation mère de Wikipédia, la [https://wikimediafoundation.org/ Wikimedia Foundation] - ou wikipédien(ne) résidents honoraires.

Le premier wikipédien en résidence, Liam Wyatt, s'est porté volontaire avec le [https://www.britishmuseum.org/ British Museum] pour fournir des informations sur ses collections sur Wikipédia dans le but de rendre ses collections plus accessibles à la communauté élargie («&amp;#8239;Wikipedians&amp;#8239;» 2010; Cohen 2010). Depuis lors, [https://w.wiki/Cx6 plus de 200] d’entre eux sont en liaison avec un large éventail d'institutions à travers le monde, y compris des bibliothèques nationales, universitaires et locales; sociétés savantes; instituts et organisations de recherche; organisations intergouvernementales et à but non lucratif; organisations de médias; musées nationaux et locaux; archives nationales et spécialisées; et jardins botaniques («&amp;#8239;Wikimedians&amp;#8239;» 2020).

Les postes peuvent prendre de nombreuses formes, allant des postes de bénévole à temps partiel à court terme à un emploi permanent à temps plein («&amp;#8239;Wikimedians&amp;#8239;» 2020; «&amp;#8239;Wikipedians&amp;#8239;» 2020).

Les tâches d'un wikipédien(ne) en résidence comprennent souvent une combinaison des éléments suivants&amp;nbsp;:
* Formation, comme l’enseignement le personnel des établissements et les membres de la communauté comment contribuer à Wikipédia ou sur des questions pertinentes telles que les droits d'auteur et les licences ou la numérisation
* Diriger des événements de sensibilisation tels que des edit-a-thons, au cours desquels les participants éditent et contribuent ensemble à Wikipédia ou à d'autres projets de la Fondation Wikimedia
* Numérisation des collections ou des fonds, ajout des images à Wikimedia Commons et des métadonnées à Wikidata
* Planification stratégique pour la sensibilisation et le partage des connaissances
* Contribution d'informations à Wikipédia («&amp;#8239;Wikimedia&amp;#8239;» 2020; «&amp;#8239;Wikipédia&amp;#8239;» 2020)

==Programmes de Wikipédien(ne)s en résidence et la communauté INKE==
En 2014, les bibliothèques de l’University of Victoria (UVic), l'Electronic Textual Cultures Lab (ETCL) et la Fédération des sciences humaines –– tous partenaires d'INKE –– ont annoncé le lancement d'un programme [https://etcl.uvic.ca/hrw/ wikipédien(ne) résident honoraire] à l'UVic. [https://www.ideas-idees.ca/media/media-releases/honorary-resident-wikipedian-professor-christian-vandendorpe Christian Vandendorpe] a été nommé premier Wikipédien résident honoraire de 2014 à 2016, suivi par membre du Partenariat INKE [https://www.uvic.ca/library/home/home/news/archive/Wikipedia-A-Thon.php Constance Crompton] de 2017 à 2018, [https://etcl.uvic.ca/2019/04/09/2019-20-honorary-resident-wikipedian-dr-erin-glass/ Erin Glass] de 2019 à 2020 et [https://etcl.uvic.ca/2020/10/08/2020-2021-honorary-resident-wikipedian-silvia-gutierrez-de-la-torre/ Silvia Gutiérrez De la Torre] de 2020 à 2021.

Le projet Cultural Data / Data for Culture de Crompton, basé au Humanities + Data Lab de l’Université d’Ottawa, examine les projets Wikimedia en tant que plates-formes de connaissances ouvertes. Le projet appelle également la communauté universitaire à apporter ses connaissances aux projets Wikimedia, la source de données culturelles et humaines structurées plus grande au monde, et lisible par des humains et par des machines. Il note que Wikipédia et les autres projects de Wikimedia a besoin des spécialistes du sectueur universitaire également des éditeurs non spécialisés. La communauté universitaire peut aider a démocratiser ces connaissances et contribuer à ce que les utilisations basées sur les données de Wikimedia (The Humanities Data Lab s.d.).

Crompton plaide en faveur de la valeur de la recherche Wikidata pour les sciences humaines dans «&amp;#8239;[https://popjournal.ca/issue02/crompton Familiar Wikidata: The Case for Building a Data Source We Can Trust]&amp;#8239;», sur la base d'une recherche partagée lors du rassemblement INKE 2020: [https://mcri.inke.ca/index.html%3Fp=2937.html Open scholarship for the 2020s] (2020).

Un [https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access-blog article] sur le blog de la bibliothèque de l'Université Simon Fraser (SFU), soutient de la même manière que la participation sur Wikipédia par les contributeurs appartenant à la communauté universitaire parce qu’ils ont accès à des informations savantes de haute qualité et l'expertise du domaine nécessaire pour rendre des sujets plus complexes accessibles à un large public (Robinson-Clogg 2020).

Le [https://www.lib.sfu.ca/help/publish/dh/dhil/digital-pedagogy-network SFU-UVIC Digital Pedagogy Network], basé dans le [https://www.lib.sfu.ca/help/publish/dh/dhil Digital Humanities Innovation Lab] à la bibliothèque de SFU et en partenariat [https://etcl.uvic.ca/ avec l’Electronic Textual Cultures Lab (ETCL)] et [https://www.uvic.ca/library/ les bibliothèques d’UVi]c, entre autres, a inclus une [https://www.lib.sfu.ca/help/publish/dh/dhil/digital-pedagogy-network Indigenous Wikipedia Edit-a-thon] dans ses événements en 2016; les détails de l'événement peuvent être trouvés [https://en.wikipedia.org/wiki/Wikipedia:Meetup/IndigenousFilmandMedia en ligne].

==Wikipédien(ne)s en résidence dans la presse==
Plusieurs programmes wikipédien(ne)s en résidence ont été couverts dans les médias. La nomination inaugurale de Vandendorpe à l’UVic, par exemple, a été couverte par [http://www.cbc.ca/news/canada/british-columbia/university-of-victoria-announces-new-honorary-resident-wikipedian-1.2894838 CBC News] et le Victoria [http://www.timescolonist.com/business/on-the-street-insurance-brokerage-sold-1.1725881 ''Times Colonist''], ainsi que par [https://etcl.uvic.ca/hrw/ d’autres médias locaux]. La nomination d'Alex Jung par l'Université de Toronto en tant que premier wikipédien en résidence en 2018 a été couverte par le [https://www.thestar.com/news/gta/2018/11/01/u-of-t-libraries-hires-first-wikipedian-in-residence.html?rf ''Toronto Star''], et la nomination par l'Université Concordia d'Amber Berson en 2019 a été couverte par [https://www.cbc.ca/news/canada/montreal/wikipedia-in-residence-concordia-montreal-1.5200247 CBC News], [https://montreal.ctvnews.ca/concordia-university-s-wikipedian-in-residence-teaching-people-how-to-access-and-assess-information-1.4537133?cache=%3FclipId%3D89680 CTV News], [https://montreal.citynews.ca/video/2019/07/10/canadas-newest-wikipedian-in-residence/ City News] et le [https://montrealgazette.com/opinion/columnists/brownstein-concordias-wikipedian-in-residence-has-a-lot-on-her-plate ''Montreal Gazette''].

Les wikipédien(ne)s ont également attiré l'attention de la presse académique. En plus de la première location d'un par une université - par [https://www.timeshighereducation.com/news/berkeleys-wikipedian-helps-unlock-scholarly-silos/2012696.article l'Université de Californie à Berkeley] en 2014 - la presse académique a également couvert le programme de manière plus générale, abordant la question de [https://www.timeshighereducation.com/news/wikipedia-should-be-better-integrated-into-teaching/2018486.article Wikipédia en classe universitaire] et [https://www.timeshighereducation.com/news/wikipedian-residence-improves-public-access-science le succès des programmes pour améliorer la qualité des articles Wikipédia], par exemple.

En 2015, [https://www.timeshighereducation.com/news/university-hopes-wikipedian-residence-will-tackle-gender-gap ''Times Higher Education''] (''THE'') a couvert la création par le West Virginia University d'un poste de wikipédien(ne) en résidence chargé de combler l'écart entre les sexes de Wikipédia&amp;nbsp;: des enquêtes en 2011 et 2018 suggèrent qu'environ 90% des rédacteurs bénévoles de Wikipédia s'identifient comme des hommes («&amp;#8239;Gender Bias on Wikipedia&amp;#8239;» 2020 ; Straumsheim 2015).

De nombreux ces rôles sont basés dans des bibliothèques universitaires et, comme le souligne un article de 2019 dans [https://www.affairesuniversitaires.ca/actualites/actualites-article/wikipedia-au-service-du-milieu-universitaire/?_ga=2.61844268.1060067117.1611275827-1855156954.1605314527 ''University Affairs''], les bibliothèques universitaires et d'autres bibliothèques s'engagent également avec Wikipédia par d'autres moyens (Aschaiek 2019). S'adressant à la communauté des bibliothèques, la publication de l'American Libraries Association ''Leveraging Wikipedia, Connecting Communities of Knowledge'' (2018) met l'accent sur les objectifs communs des communautés de bibliothèques et de Wikipédia et offre des conseils sur la manière d'accroître l'engagement dans l'édition de Wikipédia dans les communautés de bibliothèques - les bibliothèques publiques également comme recherche - ce qui comprend l'embauche des wikipédien(ne)s en résidence (Proffitt 2018).

Ces programmes intéressent également la communauté au sens large. Un article de 2014 dans ''The Atlantic'' sur le programme de [https://www.theatlantic.com/technology/archive/2014/03/harvards-looking-for-a-wikipedian-in-residence/284373/ la bibliothèque de Houghton] relie le programme au mandat de la bibliothèque, en particulier son objectif de rendre ses informations et ses ressources accessibles à la communauté (Garber).

Un article publié en 2015 dans ''USA Today'' sur le programme wikipédien(ne) en résidence de West Virginia University note qu'il a été créé spécifiquement pour lutter contre [https://en.wikipedia.org/wiki/Gender_bias_on_Wikipedia les préjugés sexistes de Wikipédia], ce que d'autres postes ont également abordé depuis, notamment au Canada, la bibliothèque de l'Université Concordia wikipédienne en résidence [https://library.concordia.ca/about/wikipedian-in-residence/ Amber Berson] et l'Université de l'Alberta wikipédienne en residence [https://www.ualberta.ca/giving/giving-news/2020/august/ualbertas-first-wikipedian-in-residence.html Erin O'Neil]. De même, un article dans [https://www.macleans.ca/education/why-universities-are-hiring-wikipedeans-in-residence/ ''Macleans''] en 2019 souligne la nécessité pour les étudiants et autres utilisateurs et contributeurs de Wikipédia de réfléchir de manière critique à la plate-forme, notamment en demandant qui fournit des informations et en modérant les contributions, et quels sont les préjugés de la communauté (Hutchins).

Dans une interview publiée en 2019 dans [https://theconversation.com/on-the-job-with-a-wikipedian-in-residence-118494 ''The Conversation''], la wikipédienne en résidence pour le [https://www.sciencehistory.org/ Philadelphia’s Science History Institute], Mary Mark Ockerbloom, souligne que les positions peuvent être controversées au sein de la communauté Wikipédia, en particulier lorsqu'il s'agit de postes rémunérés, par souci de conflits d'intérêts. Ockerbloom note que ces conflits sont une préoccupation importante pour tous les éditeurs de Wikipédia, mais qu'être payé pour éditer du contenu n'est pas nécessairement un conflit, en particulier parce que Wikipédia, les institutions culturelles et les wikipédien(ne)s qu'ils utilisent partagent des objectifs communs (Hocquet 2019).

==Les reactions de la communauté universitaire==
L'émergence des programmes wikipédien(ne)s en résidence est le signe d'un changement d'attitude envers Wikipédia au sein de la communauté universitaire. Dans les années qui ont suivi le lancement de Wikipédia, de nombreux membres de la communauté académique l'ont rejeté comme inexact et peu fiable.

Maintenant, sachant que c'est là que de nombreux étudiants, membres de la communauté et chercheurs recherchent des informations, de nombreux membres de la communauté académique, y compris [https://etcl.uvic.ca/event/making-a-better-web-free-public-talk-lunch-wikipedia-edit-a-thon-with-dr-constance-crompton-university-of-ottawa/ Constance Crompton], ancienne résidente honoraire de l'Université de Victoria, demandent à la communauté d'améliorer la qualité et la fiabilité de ses informations et l'utiliser comme une plateforme pour partager la richesse des connaissances que possède la communauté (Hutchins).

==Les programmes wikipédien(ne) en résidence et la science ouverte==
En tant que ressource ouverte, collaborative, à but non lucratif et dirigée par la communauté qui vise à rendre les informations disponibles et accessibles en ligne, la mission et les objectifs de Wikipédia s'alignent étroitement avec ceux de la mouvement science ouverte.

Les programmes wikipédien(ne)s en résidence comblent souvent les lacunes de la base de connaissances de Wikipédia, en abordant et en sensibilisant aux problèmes liés aux inégalités d’accès aux connaissances et au partage des connaissances des communautés marginalisées.

De plus, Wikipédia et d'autres projets Wikimedia sont des composants importants de l'infrastructure mondiale des connaissances ouverte. Par exemple, Wikidata est un hub important pour les données ouvertes liées. Andy Mabbett, le wikipédien en résidence avec [https://orcid.org/ ORCID], note que les identifiants ORCID peuvent être utilisés comme identifiants persistants dans Wikipédia pour les universitaires, qui peuvent ne pas avoir d'identifiants [http://viaf.org/ VIAF (Virtual International Authority File]) ou d'autres identifiants persistants (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/ORCID : Connecter la recherche et les chercheurs|ORCID: Connecter la recherche et les chercheurs]]&amp;#8239;», «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche|Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche]]&amp;#8239;», «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Persistent Identifier (PID) Consortium de Royaume-Uni|Le «&amp;#8239;Persistent Identifier (PID) Consortium&amp;#8239;» de Royaume-Uni]]&amp;#8239;», et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Wikidata dans les bibliothèques de recherche|Wikidata dans les bibliothèques de recherche]]&amp;#8239;»). De cette manière, Wikidata et Wikipédia peuvent être intégrés dans l'infrastructure de recherche numérique plus large.

==Ouvrages citées==
*Aschaiek, Sharon. 2019. «&amp;#8239;Wikipédia au service du milieu universitaire&amp;#8239;». ''Affaires Universitaires''. 26 février 2019. https://www.affairesuniversitaires.ca/actualites/actualites-article/wikipedia-au-service-du-milieu-universitaire/.

*Cohen, Noam. 2010. «&amp;#8239;Venerable British Museum Enlists in the Wikipedia Revolution&amp;#8239;». ''New York Times''. 4 juin 2010. [https://www.nytimes.com/2010/06/05/arts/design/05wiki.html https://www.nytimes.com/2010/06/05/arts/design/05wiki.html].

*Crabtree, Trent. 2015. «&amp;#8239;West Virginia University to Hire ‘Wikipedian in Residence’&amp;#8239;». ''USA Today''. 24 juillet 2015. [https://www.usatoday.com/story/college/2015/07/24/west-virginia-university-to-hire-wikipedian-in-residence/37404995/ https://www.usatoday.com/story/college/2015/07/24/west-virginia-university-to-hire-wikipedian-in-residence/37404995/].

*Crompton, Constance. 2020. «&amp;#8239;Familiar Wikidata: The Case for Building a Data Source we can Trust&amp;#8239;». 31 octobre 2020. [https://popjournal.ca/issue02/crompton https://popjournal.ca/issue02/crompton].

*Garber, Megan. 2014. «&amp;#8239;Harvard’s Looking for a ‘Wikipedian in Residence’&amp;#8239;». ''The Atlantic''. 12 mars 2014. [https://www.theatlantic.com/technology/archive/2014/03/harvards-looking-for-a-wikipedian-in-residence/284373/ https://www.theatlantic.com/technology/archive/2014/03/harvards-looking-for-a-wikipedian-in-residence/284373/].

*«&amp;#8239;Gender Bias on Wikipedia&amp;#8239;». 2020. Wikipedia. 11 decembre 2020. [https://en.wikipedia.org/wiki/Gender_bias_on_Wikipedia https://en.wikipedia.org/wiki/Gender_bias_on_Wikipedia].

*Hocquet, Alexandre. 2019. «&amp;#8239;On the Job with a ‘Wikipedian in Residence’&amp;#8239;». ''The Conversation''. 10 juillet 2019. [https://theconversation.com/on-the-job-with-a-wikipedian-in-residence-118494 https://theconversation.com/on-the-job-with-a-wikipedian-in-residence-118494].

*The Humanities Data Lab. n.d. ''Cultural Data/Data for Culture''. http://humanitiesdata.ca/projects/cultural-data/.

*Hutchins, Aaron. 2019. «&amp;#8239;Why Universities are Hiring ‘Wikipedeans-in-Residence’&amp;#8239;». ''Macleans''. 3 octobre 2019. https://www.macleans.ca/education/why-universities-are-hiring-wikipedeans-in-residence/.

*Meadows, Alice. 2016. «&amp;#8239;Meet our Wikipedian-in-Residence, Andy Mabbett!&amp;#8239;» ORCiD. 15 janvier 2016. [https://info.orcid.org/meet-our-wikipedian-in-residence-andy-mabbett/ https://info.orcid.org/meet-our-wikipedian-in-residence-andy-mabbett/].

*Proffitt, Merrilee. 2018. ''Leveraging Wikipedia: Connecting Communities of Knowledge. ''ALA Editions.

*Robinson-Clogg, Graeme. 2020. «&amp;#8239;Getting Started with Wikipedia&amp;#8239;». Radical Access: Scholarly Publishing + Open Access. Simon Fraser University Library. 7 octobre 2020. [https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access/wikipedia-editing https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access/wikipedia-editing].

*Straumsheim, Carl. 2015. «&amp;#8239;University Hopes ‘Wikipedian in Residence’ will Tackle Gender Gap&amp;#8239;». ''Times Higher Education''. 20 juillet 2015. https://www.timeshighereducation.com/news/university-hopes-wikipedian-residence-will-tackle-gender-gap.

*«&amp;#8239;Wikimedian in Residence&amp;#8239;». 2020. Wikimedia. 10 decembre 2020. https://meta.wikimedia.org/wiki/Wikimedian_in_residence.

*«&amp;#8239;Wikipedian in Residence&amp;#8239;». 2020. Wikipedia. 15 decembre 2020. https://en.wikipedia.org/wiki/Wikipedian_in_residence.

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>nanxpouuu382d8pw53e2tqy5n69ultq</sha1>
    </revision>
    <revision>
      <id>745407</id>
      <parentid>745406</parentid>
      <timestamp>2025-06-26T18:54:07Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745407</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="19021" sha1="b43kr4qshib6kx2g4qrelo45rx2ps2r" xml:space="preserve">''Cette observation a été rédigée par Caroline Winter et Talya Jesperson, pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En règle générale, un wikipédien(ne)s en résidence sont des éditeurs de [https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal Wikipédia] qui agissent en tant que des liaisons entre la communauté Wikipédia et une institution, par exemple une université, un organisme de recherche, ou un galerie, bibliothèque, archive ou musée. Ces postes sont parfois connus sous le nom de wikimédien(ne) en résidence - faisant référence à l'organisation mère de Wikipédia, la [https://wikimediafoundation.org/ Wikimedia Foundation] - ou wikipédien(ne) résidents honoraires.

Le premier wikipédien en résidence, Liam Wyatt, s'est porté volontaire avec le [https://www.britishmuseum.org/ British Museum] pour fournir des informations sur ses collections sur Wikipédia dans le but de rendre ses collections plus accessibles à la communauté élargie («&amp;#8239;Wikipedians&amp;#8239;» 2010; Cohen 2010). Depuis lors, [https://w.wiki/Cx6 plus de 200] d’entre eux sont en liaison avec un large éventail d'institutions à travers le monde, y compris des bibliothèques nationales, universitaires et locales; sociétés savantes; instituts et organisations de recherche; organisations intergouvernementales et à but non lucratif; organisations de médias; musées nationaux et locaux; archives nationales et spécialisées; et jardins botaniques («&amp;#8239;Wikimedians&amp;#8239;» 2020).

Les postes peuvent prendre de nombreuses formes, allant des postes de bénévole à temps partiel à court terme à un emploi permanent à temps plein («&amp;#8239;Wikimedians&amp;#8239;» 2020; «&amp;#8239;Wikipedians&amp;#8239;» 2020).

Les tâches d'un wikipédien(ne) en résidence comprennent souvent une combinaison des éléments suivants&amp;nbsp;:
* Formation, comme l’enseignement le personnel des établissements et les membres de la communauté comment contribuer à Wikipédia ou sur des questions pertinentes telles que les droits d'auteur et les licences ou la numérisation
* Diriger des événements de sensibilisation tels que des edit-a-thons, au cours desquels les participants éditent et contribuent ensemble à Wikipédia ou à d'autres projets de la Fondation Wikimedia
* Numérisation des collections ou des fonds, ajout des images à Wikimedia Commons et des métadonnées à Wikidata
* Planification stratégique pour la sensibilisation et le partage des connaissances
* Contribution d'informations à Wikipédia («&amp;#8239;Wikimedia&amp;#8239;» 2020; «&amp;#8239;Wikipédia&amp;#8239;» 2020)

==Programmes de Wikipédien(ne)s en résidence et la communauté INKE==
En 2014, les bibliothèques de l’University of Victoria (UVic), l'Electronic Textual Cultures Lab (ETCL) et la Fédération des sciences humaines –– tous partenaires d'INKE –– ont annoncé le lancement d'un programme [https://etcl.uvic.ca/hrw/ wikipédien(ne) résident honoraire] à l'UVic. [https://www.ideas-idees.ca/media/media-releases/honorary-resident-wikipedian-professor-christian-vandendorpe Christian Vandendorpe] a été nommé premier Wikipédien résident honoraire de 2014 à 2016, suivi par membre du Partenariat INKE [https://www.uvic.ca/library/home/home/news/archive/Wikipedia-A-Thon.php Constance Crompton] de 2017 à 2018, [https://etcl.uvic.ca/2019/04/09/2019-20-honorary-resident-wikipedian-dr-erin-glass/ Erin Glass] de 2019 à 2020 et [https://etcl.uvic.ca/2020/10/08/2020-2021-honorary-resident-wikipedian-silvia-gutierrez-de-la-torre/ Silvia Gutiérrez De la Torre] de 2020 à 2021.

Le projet Cultural Data / Data for Culture de Crompton, basé au Humanities + Data Lab de l’Université d’Ottawa, examine les projets Wikimedia en tant que plates-formes de connaissances ouvertes. Le projet appelle également la communauté universitaire à apporter ses connaissances aux projets Wikimedia, la source de données culturelles et humaines structurées plus grande au monde, et lisible par des humains et par des machines. Il note que Wikipédia et les autres projects de Wikimedia a besoin des spécialistes du sectueur universitaire également des éditeurs non spécialisés. La communauté universitaire peut aider a démocratiser ces connaissances et contribuer à ce que les utilisations basées sur les données de Wikimedia (The Humanities Data Lab s.d.).

Crompton plaide en faveur de la valeur de la recherche Wikidata pour les sciences humaines dans «&amp;#8239;[https://popjournal.ca/issue02/crompton Familiar Wikidata: The Case for Building a Data Source We Can Trust]&amp;#8239;», sur la base d'une recherche partagée lors du rassemblement INKE 2020: [https://mcri.inke.ca/index.html%3Fp=2937.html Open scholarship for the 2020s] (2020).

Un [https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access-blog article] sur le blog de la bibliothèque de l'Université Simon Fraser (SFU), soutient de la même manière que la participation sur Wikipédia par les contributeurs appartenant à la communauté universitaire parce qu’ils ont accès à des informations savantes de haute qualité et l'expertise du domaine nécessaire pour rendre des sujets plus complexes accessibles à un large public (Robinson-Clogg 2020).

Le [https://www.lib.sfu.ca/help/publish/dh/dhil/digital-pedagogy-network SFU-UVIC Digital Pedagogy Network], basé dans le [https://www.lib.sfu.ca/help/publish/dh/dhil Digital Humanities Innovation Lab] à la bibliothèque de SFU et en partenariat [https://etcl.uvic.ca/ avec l’Electronic Textual Cultures Lab (ETCL)] et [https://www.uvic.ca/library/ les bibliothèques d’UVi]c, entre autres, a inclus une [https://www.lib.sfu.ca/help/publish/dh/dhil/digital-pedagogy-network Indigenous Wikipedia Edit-a-thon] dans ses événements en 2016; les détails de l'événement peuvent être trouvés [https://en.wikipedia.org/wiki/Wikipedia:Meetup/IndigenousFilmandMedia en ligne].

==Wikipédien(ne)s en résidence dans la presse==
Plusieurs programmes wikipédien(ne)s en résidence ont été couverts dans les médias. La nomination inaugurale de Vandendorpe à l’UVic, par exemple, a été couverte par [http://www.cbc.ca/news/canada/british-columbia/university-of-victoria-announces-new-honorary-resident-wikipedian-1.2894838 CBC News] et le Victoria [http://www.timescolonist.com/business/on-the-street-insurance-brokerage-sold-1.1725881 ''Times Colonist''], ainsi que par [https://etcl.uvic.ca/hrw/ d’autres médias locaux]. La nomination d'Alex Jung par l'Université de Toronto en tant que premier wikipédien en résidence en 2018 a été couverte par le [https://www.thestar.com/news/gta/2018/11/01/u-of-t-libraries-hires-first-wikipedian-in-residence.html?rf ''Toronto Star''], et la nomination par l'Université Concordia d'Amber Berson en 2019 a été couverte par [https://www.cbc.ca/news/canada/montreal/wikipedia-in-residence-concordia-montreal-1.5200247 CBC News], [https://montreal.ctvnews.ca/concordia-university-s-wikipedian-in-residence-teaching-people-how-to-access-and-assess-information-1.4537133?cache=%3FclipId%3D89680 CTV News], [https://montreal.citynews.ca/video/2019/07/10/canadas-newest-wikipedian-in-residence/ City News] et le [https://montrealgazette.com/opinion/columnists/brownstein-concordias-wikipedian-in-residence-has-a-lot-on-her-plate ''Montreal Gazette''].

Les wikipédien(ne)s ont également attiré l'attention de la presse académique. En plus de la première location d'un par une université - par [https://www.timeshighereducation.com/news/berkeleys-wikipedian-helps-unlock-scholarly-silos/2012696.article l'Université de Californie à Berkeley] en 2014 - la presse académique a également couvert le programme de manière plus générale, abordant la question de [https://www.timeshighereducation.com/news/wikipedia-should-be-better-integrated-into-teaching/2018486.article Wikipédia en classe universitaire] et [https://www.timeshighereducation.com/news/wikipedian-residence-improves-public-access-science le succès des programmes pour améliorer la qualité des articles Wikipédia], par exemple.

En 2015, [https://www.timeshighereducation.com/news/university-hopes-wikipedian-residence-will-tackle-gender-gap ''Times Higher Education''] (''THE'') a couvert la création par le West Virginia University d'un poste de wikipédien(ne) en résidence chargé de combler l'écart entre les sexes de Wikipédia&amp;nbsp;: des enquêtes en 2011 et 2018 suggèrent qu'environ 90% des rédacteurs bénévoles de Wikipédia s'identifient comme des hommes («&amp;#8239;Gender Bias on Wikipedia&amp;#8239;» 2020 ; Straumsheim 2015).

De nombreux ces rôles sont basés dans des bibliothèques universitaires et, comme le souligne un article de 2019 dans [https://www.affairesuniversitaires.ca/actualites/actualites-article/wikipedia-au-service-du-milieu-universitaire/?_ga=2.61844268.1060067117.1611275827-1855156954.1605314527 ''University Affairs''], les bibliothèques universitaires et d'autres bibliothèques s'engagent également avec Wikipédia par d'autres moyens (Aschaiek 2019). S'adressant à la communauté des bibliothèques, la publication de l'American Libraries Association ''Leveraging Wikipedia, Connecting Communities of Knowledge'' (2018) met l'accent sur les objectifs communs des communautés de bibliothèques et de Wikipédia et offre des conseils sur la manière d'accroître l'engagement dans l'édition de Wikipédia dans les communautés de bibliothèques - les bibliothèques publiques également comme recherche - ce qui comprend l'embauche des wikipédien(ne)s en résidence (Proffitt 2018).

Ces programmes intéressent également la communauté au sens large. Un article de 2014 dans ''The Atlantic'' sur le programme de [https://www.theatlantic.com/technology/archive/2014/03/harvards-looking-for-a-wikipedian-in-residence/284373/ la bibliothèque de Houghton] relie le programme au mandat de la bibliothèque, en particulier son objectif de rendre ses informations et ses ressources accessibles à la communauté (Garber).

Un article publié en 2015 dans ''USA Today'' sur le programme wikipédien(ne) en résidence de West Virginia University note qu'il a été créé spécifiquement pour lutter contre [https://en.wikipedia.org/wiki/Gender_bias_on_Wikipedia les préjugés sexistes de Wikipédia], ce que d'autres postes ont également abordé depuis, notamment au Canada, la bibliothèque de l'Université Concordia wikipédienne en résidence [https://library.concordia.ca/about/wikipedian-in-residence/ Amber Berson] et l'Université de l'Alberta wikipédienne en residence [https://www.ualberta.ca/giving/giving-news/2020/august/ualbertas-first-wikipedian-in-residence.html Erin O'Neil]. De même, un article dans [https://www.macleans.ca/education/why-universities-are-hiring-wikipedeans-in-residence/ ''Macleans''] en 2019 souligne la nécessité pour les étudiants et autres utilisateurs et contributeurs de Wikipédia de réfléchir de manière critique à la plate-forme, notamment en demandant qui fournit des informations et en modérant les contributions, et quels sont les préjugés de la communauté (Hutchins).

Dans une interview publiée en 2019 dans [https://theconversation.com/on-the-job-with-a-wikipedian-in-residence-118494 ''The Conversation''], la wikipédienne en résidence pour le [https://www.sciencehistory.org/ Philadelphia’s Science History Institute], Mary Mark Ockerbloom, souligne que les positions peuvent être controversées au sein de la communauté Wikipédia, en particulier lorsqu'il s'agit de postes rémunérés, par souci de conflits d'intérêts. Ockerbloom note que ces conflits sont une préoccupation importante pour tous les éditeurs de Wikipédia, mais qu'être payé pour éditer du contenu n'est pas nécessairement un conflit, en particulier parce que Wikipédia, les institutions culturelles et les wikipédien(ne)s qu'ils utilisent partagent des objectifs communs (Hocquet 2019).

==Les reactions de la communauté universitaire==
L'émergence des programmes wikipédien(ne)s en résidence est le signe d'un changement d'attitude envers Wikipédia au sein de la communauté universitaire. Dans les années qui ont suivi le lancement de Wikipédia, de nombreux membres de la communauté académique l'ont rejeté comme inexact et peu fiable.

Maintenant, sachant que c'est là que de nombreux étudiants, membres de la communauté et chercheurs recherchent des informations, de nombreux membres de la communauté académique, y compris [https://etcl.uvic.ca/event/making-a-better-web-free-public-talk-lunch-wikipedia-edit-a-thon-with-dr-constance-crompton-university-of-ottawa/ Constance Crompton], ancienne résidente honoraire de l'Université de Victoria, demandent à la communauté d'améliorer la qualité et la fiabilité de ses informations et l'utiliser comme une plateforme pour partager la richesse des connaissances que possède la communauté (Hutchins).

==Les programmes wikipédien(ne) en résidence et la science ouverte==
En tant que ressource ouverte, collaborative, à but non lucratif et dirigée par la communauté qui vise à rendre les informations disponibles et accessibles en ligne, la mission et les objectifs de Wikipédia s'alignent étroitement avec ceux de la mouvement science ouverte.

Les programmes wikipédien(ne)s en résidence comblent souvent les lacunes de la base de connaissances de Wikipédia, en abordant et en sensibilisant aux problèmes liés aux inégalités d’accès aux connaissances et au partage des connaissances des communautés marginalisées.

De plus, Wikipédia et d'autres projets Wikimedia sont des composants importants de l'infrastructure mondiale des connaissances ouverte. Par exemple, Wikidata est un hub important pour les données ouvertes liées. Andy Mabbett, le wikipédien en résidence avec [https://orcid.org/ ORCID], note que les identifiants ORCID peuvent être utilisés comme identifiants persistants dans Wikipédia pour les universitaires, qui peuvent ne pas avoir d'identifiants [http://viaf.org/ VIAF (Virtual International Authority File]) ou d'autres identifiants persistants (voir «&amp;#8239;[[Observations fondamentales : Observatoire des politiques sur les savoirs ouverts, 2017-2020/ORCID : Connecter la recherche et les chercheurs|ORCID: Connecter la recherche et les chercheurs]]&amp;#8239;», «&amp;#8239;[[Observations fondamentales : Observatoire des politiques sur les savoirs ouverts, 2017-2020/Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche|Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche]]&amp;#8239;», «&amp;#8239;[[Observations fondamentales : Observatoire des politiques sur les savoirs ouverts, 2017-2020/Le Persistent Identifier (PID) Consortium de Royaume-Uni|Le «&amp;#8239;Persistent Identifier (PID) Consortium&amp;#8239;» de Royaume-Uni]]&amp;#8239;», et «&amp;#8239;[[Observations fondamentales : Observatoire des politiques sur les savoirs ouverts, 2017-2020/Wikidata dans les bibliothèques de recherche|Wikidata dans les bibliothèques de recherche]]&amp;#8239;»). De cette manière, Wikidata et Wikipédia peuvent être intégrés dans l'infrastructure de recherche numérique plus large.

==Ouvrages citées==
*Aschaiek, Sharon. 2019. «&amp;#8239;Wikipédia au service du milieu universitaire&amp;#8239;». ''Affaires Universitaires''. 26 février 2019. https://www.affairesuniversitaires.ca/actualites/actualites-article/wikipedia-au-service-du-milieu-universitaire/.

*Cohen, Noam. 2010. «&amp;#8239;Venerable British Museum Enlists in the Wikipedia Revolution&amp;#8239;». ''New York Times''. 4 juin 2010. [https://www.nytimes.com/2010/06/05/arts/design/05wiki.html https://www.nytimes.com/2010/06/05/arts/design/05wiki.html].

*Crabtree, Trent. 2015. «&amp;#8239;West Virginia University to Hire ‘Wikipedian in Residence’&amp;#8239;». ''USA Today''. 24 juillet 2015. [https://www.usatoday.com/story/college/2015/07/24/west-virginia-university-to-hire-wikipedian-in-residence/37404995/ https://www.usatoday.com/story/college/2015/07/24/west-virginia-university-to-hire-wikipedian-in-residence/37404995/].

*Crompton, Constance. 2020. «&amp;#8239;Familiar Wikidata: The Case for Building a Data Source we can Trust&amp;#8239;». 31 octobre 2020. [https://popjournal.ca/issue02/crompton https://popjournal.ca/issue02/crompton].

*Garber, Megan. 2014. «&amp;#8239;Harvard’s Looking for a ‘Wikipedian in Residence’&amp;#8239;». ''The Atlantic''. 12 mars 2014. [https://www.theatlantic.com/technology/archive/2014/03/harvards-looking-for-a-wikipedian-in-residence/284373/ https://www.theatlantic.com/technology/archive/2014/03/harvards-looking-for-a-wikipedian-in-residence/284373/].

*«&amp;#8239;Gender Bias on Wikipedia&amp;#8239;». 2020. Wikipedia. 11 decembre 2020. [https://en.wikipedia.org/wiki/Gender_bias_on_Wikipedia https://en.wikipedia.org/wiki/Gender_bias_on_Wikipedia].

*Hocquet, Alexandre. 2019. «&amp;#8239;On the Job with a ‘Wikipedian in Residence’&amp;#8239;». ''The Conversation''. 10 juillet 2019. [https://theconversation.com/on-the-job-with-a-wikipedian-in-residence-118494 https://theconversation.com/on-the-job-with-a-wikipedian-in-residence-118494].

*The Humanities Data Lab. n.d. ''Cultural Data/Data for Culture''. http://humanitiesdata.ca/projects/cultural-data/.

*Hutchins, Aaron. 2019. «&amp;#8239;Why Universities are Hiring ‘Wikipedeans-in-Residence’&amp;#8239;». ''Macleans''. 3 octobre 2019. https://www.macleans.ca/education/why-universities-are-hiring-wikipedeans-in-residence/.

*Meadows, Alice. 2016. «&amp;#8239;Meet our Wikipedian-in-Residence, Andy Mabbett!&amp;#8239;» ORCiD. 15 janvier 2016. [https://info.orcid.org/meet-our-wikipedian-in-residence-andy-mabbett/ https://info.orcid.org/meet-our-wikipedian-in-residence-andy-mabbett/].

*Proffitt, Merrilee. 2018. ''Leveraging Wikipedia: Connecting Communities of Knowledge. ''ALA Editions.

*Robinson-Clogg, Graeme. 2020. «&amp;#8239;Getting Started with Wikipedia&amp;#8239;». Radical Access: Scholarly Publishing + Open Access. Simon Fraser University Library. 7 octobre 2020. [https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access/wikipedia-editing https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access/wikipedia-editing].

*Straumsheim, Carl. 2015. «&amp;#8239;University Hopes ‘Wikipedian in Residence’ will Tackle Gender Gap&amp;#8239;». ''Times Higher Education''. 20 juillet 2015. https://www.timeshighereducation.com/news/university-hopes-wikipedian-residence-will-tackle-gender-gap.

*«&amp;#8239;Wikimedian in Residence&amp;#8239;». 2020. Wikimedia. 10 decembre 2020. https://meta.wikimedia.org/wiki/Wikimedian_in_residence.

*«&amp;#8239;Wikipedian in Residence&amp;#8239;». 2020. Wikipedia. 15 decembre 2020. https://en.wikipedia.org/wiki/Wikipedian_in_residence.

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>b43kr4qshib6kx2g4qrelo45rx2ps2r</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Mise à jour du Plan S : L’élargissement de l’adhésion de la cOAlition S</title>
    <ns>0</ns>
    <id>82275</id>
    <revision>
      <id>745405</id>
      <parentid>745130</parentid>
      <timestamp>2025-06-26T18:48:36Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745405</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="19807" sha1="qhrw13w7pypawy2o6tid9pihxra6u0x" xml:space="preserve">''Cette observation a été rédigée par Caroline Winter.''

''Cette observation fait partie d'une série consacrée aux développements liés à la cOAlition S et au Plan S depuis leur lancement en septembre 2018.''

[https://www.coalition-s.org/ Plan S] est une initiative de la cOAlition S, un consortium international d'organismes de recherche et de financement. Il appelle à un accès libre complet et immédiat (OA) de toutes les publications de recherche financées par des fonds publics (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;»).

cOAlition S lancée le 4 septembre 2018, avec le soutien de [https://www.scienceeurope.org/ Science Europe], de [https://ec.europa.eu/info/index_fr la Commission européenne] et de 11 organisations membres, bailleurs de fonds nationaux de la recherche en Europe et au Royaume-Uni (Science Europe 2018)&amp;nbsp;:
* [https://www.fwf.ac.at/de/ Austrian Science Fund] (FWF); [https://www.fwf.ac.at/en/research-funding/open-access-policy politique de libre accès]
* [https://anr.fr/fr/ Agence nationale de la recherche] (ANR) du France; [https://anr.fr/fr/lanr-et-la-recherche/engagements-et-valeurs/la-science-ouverte/ politique de libre accès]
* [http://www.sfi.ie/ Science Foundation Ireland] (SFI); [https://www.sfi.ie/funding/sfi-policies-and-guidance/open-research/ politique de libre accès]
* [https://home.infn.it/it Istituto Nazionale de Fisica Nucleare] (INFN) d’Italie; [https://home.infn.it/it/istituto/open-access politique de libre accès]
* [https://www.fnr.lu/ Luxumbourg National Research Fund] (FNR); [https://www.fnr.lu/funding-instruments/open-access-fund/ politique de libre accès]
* [https://www.nwo.nl/ Netherlands Organization for Scientific Research] (NWO); [https://www.nwo.nl/en/open-access-publishing politique de libre accès]
* [https://www.forskningsradet.no/ Research Council of Norway (RCN]); [https://www.forskningsradet.no/en/Adviser-research-policy/open-science/ politique de libre accès]
* [https://www.forskningsradet.no/en/Adviser-research-policy/open-science/ National Science Centre (NCN)] de Pologne; [https://ncn.gov.pl/finansowanie-nauki/otwarta-nauka?language=en politique de libre accès]
* [https://www.arrs.si/en/ Slovenian Research Agency (AARS)]; [https://www.gov.si/gone?src=http://www.mizs.gov.si&amp;url=http://mizs.arhiv-spletisc.gov.si/fileadmin/mizs.gov.si/pageuploads/Znanost/doc/Zakonodaja/Strategije/National_strategy_for_open_access_21._9._2015.pdf stratégie national de libre accès]
* [https://www.formas.se/ Swedish Research Council for Sustainable Development (FORMAS)]; [https://formas.se/en/start-page/applying-for-funding/how-it-works/good-to-know-before-you-apply.html#h-Openaccesstoresearchresultsanddata politique de libre accès]
* [https://www.ukri.org/ United Kingdom Research and Innovation (UKRI)]; [https://www.ukri.org/about-us/policies-standards-and-data/good-research-resource-hub/open-research/ politiques de science ouverte]

Depuis sa création, l'adhésion à la cOAlition S s'est étendue dans le monde entier; en février 2021, il comprend 26 membres d'Afrique, du Moyen-Orient et des États-Unis. Le calendrier ci-dessous indique le moment où chaque membre suivant a rejoint la cOAlition S et comprend un lien vers sa politique OA alignée sur le Plan S (cOAlition S 2021).

* [https://www.coalition-s.org/fct-joins-coalition-s/ 25 janvier 2021]: La [https://www.fct.pt/index.phtml.pt Foundation for Science and Technology of Portugal (FCT)], une agence nationale de financement de la recherche scientifique et technologique. [https://www.fct.pt/noticias/index.phtml.pt?id=618&amp;/2021/1/FCT_vai_implementar_o_Plano_S La mise en œuvre du Plan S] prend effet le 1er janvier 2022.

* [https://www.coalition-s.org/the-templeton-world-charity-foundation-joins-coalition-s/ 1er octobre 2020]&amp;nbsp;: La [https://www.templetonworldcharity.org/ Templeton World Charity Foundation], une fondation de recherche interdisciplinaire basée aux États-Unis. [https://www.templetonworldcharity.org/open-access-policy Sa nouvelle politique de libre accès] est entrée en vigueur le 1er janvier 2021.

* [https://www.coalition-s.org/the-howard-hughes-medical-institute-joins-coalition-s/ 1er octobre 2020]&amp;nbsp;: Le [https://www.hhmi.org/ Howard Hughes Medical Institute], un institut de recherche biomédicale privé basé aux États-Unis. [https://www.hhmi.org/news/hhmi-announces-open-access-publishing-policy Sa nouvelle politique de libre accès aux publications] entre en vigueur le 1er janvier 2022.

* [https://www.coalition-s.org/south-african-medical-research-council-to-champion-open-access-through-coalition-s/ 22 octobre 2019]&amp;nbsp;: La [https://www.samrc.ac.za/ South African Medical Research Council (SAMRC)], une organisation nationale de financement de la recherche médicale et la plus grande d'Afrique du Sud.

* [https://www.coalition-s.org/asap-joins-coalition-s/ 26 septembre 2019]&amp;nbsp;: [https://parkinsonsroadmap.org/ Aligning Science Against Parkinson’s (ASAP)], une initiative de recherche et un organisme de financement internationaux basés aux États-Unis. [https://parkinsonsroadmap.org/open-access-policy/ Sa politique de libre accès] entre en vigueur le 1er janvier 2022.

* [https://www.coalition-s.org/who-joins-coalition-s/ 29 août 2019]&amp;nbsp;: [https://www.who.int/fr/home L'Organisation mondiale de la santé (OMS)], une organisation internationale de la santé avec 14 États membres, dont le siège est en Suisse, est la première agence des Nations Unies à rejoindre la cOAlition S, avec le [https://www.who.int/tdr/news/2019/WHO-TDR-join-coalition-free-digital-acces/en/ Special Programme for Research and Training in Tropical Diseases (TDR)] (OMS 2021). La politique de libre accès de l'OMS est entrée en vigueur le 1er janvier 2021, et le TDR dispose de sa propre plateforme pour critique des pairs de recherche après publication, TDR Gateway.

* [https://www.coalition-s.org/vinnova-joins-coalition-s/ 22 mai 2019]&amp;nbsp;: Vinnova, l'agence nationale suédoise de financement de la recherche. [https://www.vinnova.se/en/news/2019/05/make-scientific-articles-freely-available/ Sa politique de libre accès] est entrée en vigueur le 1er janvier 2021.

* [https://www.coalition-s.org/the-higher-council-for-science-and-technology-joins-coalition-s/ 25 mars 2019]&amp;nbsp;: Le [http://www.hcst.gov.jo/ Higher Council for Science and Technology (HCST)], bailleur de fonds national de la recherche de la Jordanie, est [http://www.hcst.gov.jo/en/node/963 le premier membre de la cOAlition S du Moyen-Orient]. Sa politique de libre accès alignée sur le Plan S est entrée en vigueur le 1er janvier 2021.

* [https://www.coalition-s.org/coalition-s-welcomes-its-first-african-member-and-receives-strong-support-from-the-african-academy-of-sciences/ 23 février 2019]&amp;nbsp;: le [https://nstc.org.zm/ National Science and Technology Council (NSTC)] de la Zambie, le principal bailleur de fonds national de la recherche en cette pays, est le premier bailleur de fonds africain à adhérer, après que [https://www.aasciences.africa/news/supporting-plan-s-model-making-research-accessible-and-advancing-science-globally l'Académie africaine des sciences a approuvé le Plan S en janvier 2019]. Sa politique de libre accès est entrée en vigueur le 1 janvier 2021.

* [https://www.coalition-s.org/wellcome-and-gates-join-coalition-s/ 5 novembre 2018]&amp;nbsp;: [https://wellcome.org/ Wellcome], une organisation privée de financement de la recherche biomédicale et en santé basée au Royaume-Uni. En 2005, Wellcome a été le premier bailleur de fonds de recherche à mettre en œuvre une politique de libre accès obligatoire. Il a également [https://wellcome.org/press-release/wellcome-and-bill-melinda-gates-foundation-join-open-access-coalition annoncé] [https://wellcome.org/news/wellcome-updates-open-access-policy-align-coalition-s une nouvelle politique de libre accès] qui est entrée en vigueur le 1er janvier 2021. Wellcome est le premier membre de la cOAlition S du Royaume-Uni.

* La [https://www.gatesfoundation.org/ Bill and Melinda Gates Foundation], une fondation de recherche sur la santé et le développement basée aux États-Unis, s'est également jointe à cette date. Sa [https://www.gatesfoundation.org/How-We-Work/General-Information/Open-Access-Policy nouvelle politique de libre accès] est entrée en vigueur le 1er janvier 2021. Il s'agit du premier membre de la cOAlition S des États-Unis et, avec Wellcome, est l'un des premiers bailleurs de fonds privés à adhérer.

* [https://www.coalition-s.org/academy-of-finland-joins-coalition-s/ 29 septembre 2018]&amp;nbsp;: [https://www.aka.fi/ Academy of Finland (AKA)], un bailleur de fonds national de la recherche. Sa [https://www.aka.fi/en/research-funding/apply-for-funding/how-to-apply-for-funding/az-index-of-application-guidelines2/open-science/ politique de libre accès] est entrée en vigueur le 1er janvier 2021.

* [https://www.coalition-s.org/forte-joins-coalition-s/ 9 septembre 2018]&amp;nbsp;: [https://forte.se/en/ FORTE : Swedish Research Council for Health, Working Life and Welfare], est le premier membre à rejoindre la cOAlition S depuis son lancement. Sa [https://forte.se/en/funding/ongoing-grants/open-access/policy-publication-open-access/ politique de libre accès] est entrée en vigueur le 1er janvier 2021.

Le [https://erc.europa.eu/ European Research Council (ERC)] était l'un des premiers soutiens du Plan S, mais en juillet 2020, l’ERC Scientific Council a [https://erc.europa.eu/news/erc-scientific-council-calls-open-access-plans-respect-researchers-needs annoncé qu'il retirait son soutien à la cOAlition S]. L'annonce, qui cite le manque de soutien du plan pour la publication dans les revues «&amp;#8239;hybrides&amp;#8239;» et les conséquences pour les chercheurs en début de carrière comme raison de retirer leur soutien ont un surpris par de nombreux membres de la communauté universitaire, bien que certaines parties prenantes aient exprimé des préoccupations similaires (Burke 2020; cOAlition S 2020; Matthews 2020a, 2020b; Kamerlin 2020; Kelly 2020; Walkden 2020).

==cOAlition S dans la presse==
Les questions liées à l'élargissement de l’adhésion de la cOAlition S et à l'élargissement de la portée du Plan S ont été couvertes dans la presse universitaire. Un article de ''Physics Today'' intitulé «&amp;#8239;Transformative Open-Access Deals Spread to the US&amp;#8239;», par exemple, note des similitudes entre l’entente «&amp;#8239;lecture et publication&amp;#8239;» conclu entre l'Université de Californie et Springer Nature en juin 2020 et ceux négociés entre les éditeurs et les organisations nationales de recherche dans le cadre du Plan S (Kramer 2020).

La [https://www.elsevier.com/about/elsevier-and-open-access décision d'Elsevier d'enregistrer 160 de ses publications en tant que revues «&amp;#8239;transformative&amp;#8239;»] via la cOAlition S, [https://www.coalition-s.org/160-elsevier-journals-become-plan-s-aligned-transformative-journals/ annoncée par la cOAlition en janvier 2021], a également attiré l'attention de la presse. Un article de [https://www.chemistryworld.com/news/elsevier-flips-160-journals-to-open-access/4013038.article ''Chemistry World''], par exemple, note que cette décision coïncide avec une étape cruciale du Plan S, puisque les politiques de libre accès de nombreux membres de la cOAlition S sont entrées en vigueur le 1er janvier 2021 (Durrani 2021).

Les discussions sur la nécessité de libre accès à la recherche dans le contexte de la pandémie COVID-19 ont également fait référence à la cOAlition S. Un article de [https://bigthink.com/technology-innovation/plan-s-open-access ''Big Think''] souligne que les efforts de la cOAlition S pour éviter les frais de traitement des articles exagerés [https://www.coalition-s.org/price-and-service-transparency-frameworks/ en exigeant une plus grande transparence sur les éditeurs] sont essentiels pour éviter que le coût de l'édition en libre accès ne pèse sur les chercheurs. Il souligne qu'il est particulièrement important de permettre aux chercheurs de fournir au public l’accès à recherche en santé précise et fiable dans le contexte de la pandémie COVID-19, lorsqu'un manque de transparence peut conduire à la méfiance envers les agences de santé publique et les interventions pharmaceutiques telles que les vaccins (Beres 2021).

==cOAlition S et le partenariat INKE==
Le rapport de l'Association des bibliothèques de recherche du Canada intitulé ''Advancing Open: points de vue des spécialistes de la communication savante'' note que, bien que le mouvement science ouverte a soit en cours au Canada, nos infrastructures de recherche et de financement ne soutiendraient pas «&amp;#8239;un tel modèle transformateur de science ouverte&amp;#8239;» (MacCallum et al. 2020, 7) (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/L’atelier et rapport Advancing Open d’ABRC|L’atelier et rapport Advancing Open d’ABRC]]&amp;#8239;»).

L'ABRC a exprimé son soutien au Plan S en principe et a soumis une [https://www.carl-abrc.ca/fr/nouvelles/reponse-a-plan-s/ réponse à la première itération du Plan S]. Elle a depuis exprimé son soutien aux directives de mise en œuvre révisées du Plan S par le biais d'une [https://www.carl-abrc.ca/fr/nouvelles/avis-aiabr-iarla-plan-s/ déclaration de l'Alliance internationale des associations de bibliothèques de recherche (IARLA)] et de son soutien pour la [https://www.coalition-s.org/coalition-s-develops-rights-retention-strategy/ stratégie de conservation des droits de la cOAlition S] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour du Plan S : La Stratégie de conservation des droits|Mise à jour du Plan S : La Stratégie de conservation des droits]]&amp;#8239;»).

De même, [https://aoasg.org.au/ l'Australasian Open Access Strategy Group (AOASG)] et [https://www.caul.edu.au/ le Council of Australian University Librarians (CAUL)] ont exprimé leur soutien de principe au Plan S dans leur [https://www.caul.edu.au/sites/default/files/documents/caul-doc/plans2019response.pdf réponse à la première itération des directives de mise en œuvre], ont [https://www.caul.edu.au/news/plan-s-revised-implementation-guidelines-welcomed accueilli favorablement les directives de mise en œuvre révisées] et ont [https://www.caul.edu.au/news/caul-and-aoasg-welcome-coalition-s-rights-retention-strategy a exprimé son soutien au la stratégie de conservation des droits] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour du Plan S : La Stratégie de conservation des droits|Mise à jour du Plan S : La Stratégie de conservation des droits]]&amp;#8239;»).

==L'élargissement de l’adhésion de la cOAlition S et la science ouverte==
Alors que la cOAlition S a commencé comme un groupe d'agences de financement européennes, elle s'est depuis élargie pour inclure des membres d'Afrique, du Moyen-Orient, du Royaume-Uni et d'Amérique du Nord. Le Canada et l’Australie ont exprimé leur soutien au travail de la coalition même s’ils ne sont pas signataires, et le Plan S est devenu une pierre de touche importante contre laquelle comparer la politique ouverte de bourses. Alors que la cOAlition S continue d'élargir son effectif, la portée du Plan S continue de s'élargir, avec des implications pour les bourses d'études ouvertes dans le monde entier.

==Ouvrages citée==
*Beres, Derek. 2021. «&amp;#8239;Should Scientific Studies Be Available for Free?&amp;#8239;» Big Think. 6 janvier 2021. [https://bigthink.com/technology-innovation/plan-s-open-access https://bigthink.com/technology-innovation/plan-s-open-access].

*Burke, Maria. 2020. «&amp;#8239;Blow to Open Access Plan S as European Research Council Withdraws&amp;#8239;». ''Chemistry World.'' 7 août 2020. [https://www.chemistryworld.com/news/blow-to-open-access-plan-s-as-european-research-council-withdraws/4012244.article https://www.chemistryworld.com/news/blow-to-open-access-plan-s-as-european-research-council-withdraws/4012244.article].

*cOAlition S. 2020. «&amp;#8239;cOAlition S response to the ERC Scientific Council’s statement on Open Access and Plan S&amp;#8239;». 21 juillet 2020. [https://www.coalition-s.org/coalition-s-response-to-the-erc-scientific-councils-statement-on-open-access-and-plan-s/ https://www.coalition-s.org/coalition-s-response-to-the-erc-scientific-councils-statement-on-open-access-and-plan-s/].

*cOAlition S. 2021. «&amp;#8239;Implementation Roadmap of cOAlition S Organisations&amp;#8239;». [https://www.coalition-s.org/plan-s-funders-implementation/ https://www.coalition-s.org/plan-s-funders-implementation/].

*Durrani, Jamie. 2021. «&amp;#8239;Elsevier Flips 160 Journals to Open Access&amp;#8239;». ''Chemistry World''. 14 janvier 2021. [https://www.chemistryworld.com/news/elsevier-flips-160-journals-to-open-access/4013038.article https://www.chemistryworld.com/news/elsevier-flips-160-journals-to-open-access/4013038.article].

*Kamerlin, Shina Caroline Lynn. 2020. «&amp;#8239;Open Access, Plan S, and Researchers’ Needs&amp;#8239;». ''EMBO Reports''. 7 septembre 2020. https://www.embopress.org/doi/full/10.15252/embr.202051568.

*Kelly, Éanna. 2020. «&amp;#8239;European Research Council’s Rejection of Open Access Scheme ‘a Slap in the Face,’ says Plan S Architect&amp;#8239;». ''Science|Business''. 23 juillet 2020. [https://sciencebusiness.net/news/european-research-councils-rejection-open-access-scheme-slap-face-says-plan-s-architect https://sciencebusiness.net/news/european-research-councils-rejection-open-access-scheme-slap-face-says-plan-s-architect].

*Kramer, David. 2020. «&amp;#8239;Transformative Open-access Deals Spread to the US&amp;#8239;». ''Physics Today''. [https://physicstoday.scitation.org/do/10.1063/PT.6.2.20200710a/full/ https://physicstoday.scitation.org/do/10.1063/PT.6.2.20200710a/full/].

*MacCallum, Lindsey, Ann Barrett, Leah Vanderjagt, et Amy Buckland. 2020. ''Advancing Open: points de vue des spécialistes de la communication savante''. L’Association des bibliothèques de recherche du Canada (ABRC–CARL). https://www.carl-abrc.ca/wp-content/uploads/2020/04/GTDO_rapport3_Advancing_open_FR.pdf.

*Matthews, David. 2020a. «&amp;#8239;ERC President Quits after Coronavirus Row&amp;#8239;». ''Times Higher Education''. 8 avril 2020. [https://www.timeshighereducation.com/news/erc-president-quits-after-coronavirus-row https://www.timeshighereducation.com/news/erc-president-quits-after-coronavirus-row].

*Matthews, David. 2020b. «&amp;#8239;Blow to Plan S Open Access Project as ERC Withdraws Support&amp;#8239;». ''Times Higher Education''. 22 juillet 2020. [https://www.timeshighereducation.com/news/blow-plan-s-open-access-project-erc-withdraws-support https://www.timeshighereducation.com/news/blow-plan-s-open-access-project-erc-withdraws-support].

*OMS (Organisation mondiale de la Santé). 2021. «&amp;#8239;A propos&amp;#8239;». https://www.who.int/fr/about.

*Science Europe. 2018. «&amp;#8239;National Research Funding Organisations Participating in cOAlition S&amp;#8239;». 30 août 2018. https://www.leru.org/files/cOAlitionS_National_Funders.pdf.

*Walkden, George. 2020. «&amp;#8239;The ERC and Plan S: An Open Letter&amp;#8239;». ''Medium''. 22 juillet 2020. [https://medium.com/@georgewalkden/the-erc-and-plan-s-an-open-letter-dc757822a13d https://medium.com/@georgewalkden/the-erc-and-plan-s-an-open-letter-dc757822a13d].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>qhrw13w7pypawy2o6tid9pihxra6u0x</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les monographies en libre accès</title>
    <ns>0</ns>
    <id>82276</id>
    <revision>
      <id>745408</id>
      <parentid>745131</parentid>
      <timestamp>2025-06-26T18:58:47Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745408</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="33772" sha1="thvwxpcr2rf2gv2v1ok11anwg5v2jhz" xml:space="preserve">''Cette observation a été rédigée par Caroline Winter (avec des remerciements à John Maxwell, Gabriel Miller, Tanja Niemann, Émilie Paquin et Michael Eberle Sinatra pour leurs retours et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

À mesure que le mouvement international de libre accès prend de l'ampleur, la question de savoir comment passer à libre accès pour les monographies devient de plus en plus pressante et, ces dernières années, les efforts visant à déterminer un modèle durable de publication de monographies en libre accès se sont intensifiés.

Les monographies - études de la longueur d'un livre sur un seul sujet, généralement par un seul auteur - sont particulièrement importantes dans les sciences humaines et sociales, où elles sont non seulement cruciales pour communiquer des résultats approfondis, soutenus et complexes, mais sont également importantes pour le développement professionnel et de carrière, comme pour l'octroi de la permanence (Hill 345; Maxwell, Bordini et Shamash 2017; MLA 2007; Schimanski et Alperin 2018; Townsend 2003; voir aussi «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Projet Review, Promotion, and Tenure à ScholCommLab|Le Projet «&amp;#8239;Review, Promotion, and Tenure&amp;#8239;» à ScholCommLab]]&amp;#8239;») .

Au cours des dernières années, de nombreuses études ont été entreprises pour mieux comprendre la publication de monographies et pour tracer des pistes pour la faire évoluer vers libre accès. Quatre rapports majeurs ont été publiés rien qu'en 2019 - ils sont résumés dans une revue de Tom Hill (2020)&amp;nbsp;:
* [https://www.universitiesuk.ac.uk/policy-and-analysis/reports/Documents/2019/UUK-Open-Access-Evidence-Review.pdf ''Open Access and Monographs: Evidence Review''] (2019), commandé par Universities UK
* [https://repository.jisc.ac.uk/7413/3/Towards_a_Roadmap_for_Open_Access_Monographs_June_2019.pdf ''Towards a Roadmap for Open Access Monographs''] (2019), par Knowledge Exchange
* [https://figshare.com/articles/The_future_of_open_access_books_Findings_from_a_global_survey_of_academic_book_authors/8166599 ''The Future of Open Access Books: Findings from a Global Survey of Academic Book Authors''] (Ros et al. 2019), par Springer Nature
* [https://digitalscience.figshare.com/articles/The_State_of_Open_Monographs/8197625 ''The State of Open Access Monographs''] (Grimme et al. 2019), un rapport par Digital Science

Ces rapports et d'autres mettent en évidence plusieurs facteurs qui contribuent à rendre la transition vers libre accès particulièrement difficile pour les monographies et font des recommandations pour y remédier. Cependant, étant donné que l'écosystème de publication de monographies internationales existant est complexe et diversifié, et que le paysage de l'édition et les structures de marché varient considérablement d'un pays et d'un continent à l'autre, les solutions qui ont du sens dans un contexte de marché peuvent ne pas l'être dans un autre.

==Plans d'affaires==
L'écosystème d'édition de monographies est également distinct de l'écosystème d'édition de revues, comme indiqué dans l'enquête de Penier, Eve et Grady (2019). Par rapport aux articles de revues, les monographies coûtent cher à produire, d'autant plus que l'impression reste le format d'édition dominant, et que leur développement et leur impact se déroulent généralement sur une période plus longue que celle d'un article de revue (Hill 345; Weigart et Stone).

En outre, les tirages et les chiffres de vente des monographies sont généralement faibles, de l'ordre de 200 à 500 exemplaires, et sont souvent publiés avec une perte financière pour la presse (Maxwell et al. 2017). Les presses académiques et universitaires sont souvent des organisations à but non lucratif, cependant, mandatées pour publier comme un moyen de contribuer au dossier scientifique plutôt que de générer des profits. La durabilité est donc la principale préoccupation dans le développement de modèles commerciaux en libre accès, plutôt que la rentabilité. La publication de monographies numériques en libre accès a le potentiel de réduire les coûts de publication. Par conséquent, si les revenus que les éditeurs à but non lucratif tirent de la vente de monographies pouvaient être remplacés, publier en libre accès pourrait fournir un moyen de rendre l'édition en libre accès plus durable (Weigart et Stone).

==Droits d'auteur et licences==
Licences ouvertes est un principe fondamental du mouvement Libre Accès. Dans les sciences humaines et sociales, où les monographies sont plus courantes et où la recherche met souvent au premier plan l'expression originale des idées et aborde des questions potentiellement controversées ou sensibles, les licences et les droits d'auteur sont des considérations particulièrement importantes. Hill note, par exemple, que les licences [https://creativecommons.org/ Creative Commons] les plus ouvertes ont tendance à être moins populaires parmi les auteurs de monographies, ainsi que celles qui permettent une réutilisation commerciale (Universities UK 2019; Pyne et al. 2019; voir aussi Hill).

En outre, des préoccupations ont été soulevées quant au fait que des mandats de licence ouverts pourraient favoriser l'appropriation coloniale des connaissances et des cultures autochtones; ces préoccupations doivent être abordées en coopération avec les communautés autochtones (Khan 2018; voir ACUP 2019 et Gatti et al. 2020).

==Financement et infrastructure==
Hill note que l'infrastructure technologique qui permet l'interopérabilité entre les revues n'est pas encore en place pour les monographies en libre accès (2020), citant des discussions dans ''The State of Open Monographs'' et ''Towards a Roadmap for Open Access Monographs'' (Grimme et al. 2019; Adema 2019)

Afin de réaliser le changement culturel nécessaire pour passer d'un système de monographie imprimé à un système de monographie numérique ou hybride, un soutien supplémentaire est nécessaire de la part des principales parties prenantes (Universities UK 2019) ainsi que des organisations de financement (Hill 347; Pyne et al. 2019; Grimme et al. 2019).

Parmi les rapports récents liés aux monographies en libre accès, il existe un consensus selon lequel, à l'avenir, les organismes de financement doivent reconnaître et respecter les besoins des différents domaines et disciplines (Adema 2019; Hill 346; Universities UK 2019).

==L'état de la politique de monographie libre accès maintenant==
Au Canada'', ''[https://www.ic.gc.ca/eic/site/063.nsf/fra/h_F6765465.html ''la Politique des trois organismes sur le libre accès aux publications''] s'applique uniquement aux articles de recherche et aux données de recherche financés par les Instituts de recherche en santé du Canada (IRSC), et non aux monographies (Gouvernement du Canada, 2016).

Reconnaissant l'importance de la monographie pour la recherche en sciences humaines et sociales, la Fédération des sciences humaines a publié en 2015 une [http://www.idees-ideas.ca/sites/default/files/oa-aspp-policy-position-fr.pdf politique de libre accès] pour le programme de Prix d’auteurs pour l’édition savante (PAES). Développée en consultation avec les parties prenantes, cette politique affirme que «&amp;#8239;La Fédération s’attache à promouvoir et facilitera activement la publication en libre accès des livres subventionnés par le PAES&amp;#8239;» (Fédération 2015, p. 3).

En Australie, [https://www.arc.gov.au/policies-strategies/policy/arc-open-access-policy-version-20171 la politique de libre accès de l'Australian Research Council (ARC)] s'applique déjà à tous les résultats de recherche financés par l'ARC, y compris les monographies, les chapitres de livres et les volumes édités. Ceux-ci doivent être mis en libre accès dans les 12 mois suivant leur date de publication par le biais d'un dépôt institutionnel ou disciplinaire ou autre moyens (ARC 2017).

Au Royaume-Uni, [https://wellcome.org/grant-funding/guidance/open-access-guidance/open-access-policy la politique de libre accès de Wellcome Trust] s'applique également aux monographies et aux chapitres de livres, qui doivent être partagés via PubMed Central (PMC) Bookshelf et Europe PMC avec un embargo de six mois ou moins (Wellcome Trust s.d.). À compter de janvier 2021, les articles de recherche doivent être publiés en libre accès sur publication et sous licence ouverte, mais la politique actuelle continuera de s'appliquer aux monographies et aux chapitres de livres (Wellcome Trust s.d.).

Aussi au Royaume-Uni[///Volumes/etcl/Staff/Caroline%20Winter/OS%20Policy%20Obs/OA%20Monographs/le%20politique%20de%20libre%20accès%20du%20Research%20Excellent%20Framework%20(REF)%202021 , le politique de libre accès du Research Excellence Framework (REF) 2021] s'applique uniquement aux articles de recherche et aux documents de conférence publiés, mais les monographies devraient être incluses dans la politique dans les soumissions ultérieures du REF (HEFCE 2016). Pendant ce temps, un examen de la politique de UK Research and Innovation (UKRI) en libre accès est actuellement en cours, avec des consultations qui incluent des questions politiques liées aux monographies (UKRI 2020; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Examen et consultation de la politique de L’UKRI sur libre accès|Examen et consultation de la politique de l’UKRI sur libre accès]]&amp;#8239;»).

Le [https://www.coalition-s.org/ Plan S], qui a des signataires en Afrique, Europe, Moyen-Orient, Royaume-Uni et en États-Unis, s'applique en principe à toutes les publications savantes, mais reconnaît que la transition vers libre accès pour les monographies est un processus complexe qui est toujours en cours. Ses principes et lignes directrices actuels s'appliquent uniquement aux articles scientifiques, mais la cOAlition S a déclaré qu'elle publierait des principes et des conseils relatifs aux monographies d'ici la fin de 2021 (cOAlition S 2020; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour du Plan S : La Stratégie de conservation des droits|Mise à jour du Plan: La Stratégie de conservation des droits]]&amp;#8239;»).

D'ici la fin de 2021, les principaux organismes de financement en Australie, au Royaume-Uni, en Europe et aux États-Unis auront donc mis en place des politiques ouvertes relatives aux monographies en libre accès (Jisc 2019).

==Monographies en libre accès dans la presse==
Dans plusieurs articles pour ''Inside Higher Ed'', Lindsey McKenzie examine des sujets liés aux monographies en libre accès. Dans son [https://www.insidehighered.com/news/2018/06/01/most-popular-open-access-monographs enquête sur les monographies libre accès les plus téléchargées] (2018), elle note que, bien que les monographies ne se vendent généralement qu'à quelques centaines d'exemplaires, certaines monographies en libre accès sont téléchargées des milliers de fois: le titre le plus populaire de sa liste a été téléchargé 227,336 fois dans les deux ans depuis la publication (2018).

Dans un article sur [https://www.insidehighered.com/news/2019/10/22/exploring-subscriptions-support-open-access-monographs le modèle «&amp;#8239;subscribe to open&amp;#8239;» piloté par MIT Press], McKenzie note que la transition vers les monographies en libre accès n'est pas seulement une question d'accès; les modèles d'édition actuels ne fonctionnent pas bien, souffrent de la baisse des ventes et du piratage rampant, et que les nouveaux modèles doivent également fonctionner pour les petites presses afin de maintenir la bibliodiversité (2019).

Dans son article sur le [https://longleafservices.org/blog/the-sustainable-history-monograph-pilot/ Sustainable History Monographs Project] de l’University of North Carolina, elle note que la subvention de l’Andrew W. Mellon Foundation qui finance le projet est destinée uniquement à un projet pilote; un financement plus stable est nécessaire pour rendre la publication des monographies en libre accès durable à long terme (2019).

==Publication de monographies en libre accès et partenariat INKE==
En plus de la politique de libre accès de la Fédération pour le PAES, d'autres membres d'INKE contribuent également à l'avancement des monographies en libre accès.

John Maxwell et le Canadian Institute for Studies in Publishing ont publié plusieurs articles relatif à les monographies en libre accès. En 2017, Maxwell, Alessandra Bordini et Katie Shamash ont publié une évaluation de [https://quod.lib.umich.edu/j/jep/3336451.0020.101?view=text;rgn=main le Monograph Initiative de la Fondation Andrew W. Mellon], qui a octroyé 13 subventions totalisant près de dix millions de dollars à des universités à travers les États-Unis pour faire progresser la publication de monographies en libre accès (Maxwell et al.2017) .

Un [https://mindthegap.pubpub.org/ rapport de 2019 de John Maxwell et al.] étudie le paysage de l'édition de logiciels open source, y compris plusieurs outils et programmes orientés livre (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mind the Gap et POP!: En conversation avec John Maxwell|Mind the Gap et POP! : En conversation avec John Maxwell]]&amp;#8239;»). Les outils et programmes open source relatif à les livres étudiés dans le rapport comprennent

* [https://editoria.pub/ Editoria]: une plateforme Web pour l'édition et la production collaboratives de monographies
* [https://www.pubpub.org/ PubPub]: une plateforme de publication collaborative et communautaire de livres et autres publications
* [https://manifoldapp.org/ Manifold]: une plateforme de publication de livres avec des outils d'annotation et d'engagement du lecteur
* [https://omeka.org/ Omeka]: une plateforme pour la publication de collections et d'expositions numériques avec des métadonnées robustes qui pourraient également être utilisées pour publier des livres riches en médias
* [https://scalar.me/anvc/scalar/ Scalar]: une plateforme pour la rédaction et la publication de publications numériques de longue durée riches en médias.

Le rapport note que, alors que les changements dans les pratiques d'édition de revues, tels que le passage aux revues numériques ou l'édition en libre accès, n'ont pas tendance à affecter la forme de base de l'article de revue, les innovations techniques dans l'édition numérique et à livre ouvert ouvrent de nouvelles formes et de nouveaux formats pour monographies (Maxwell et al.2019).

Dans [https://www.carl-abrc.ca/fr/mini-site-page/faire-avancer-libre-acces/rapport-de-levenement/ un rapport de l'Association des  bibliothèques de recherche du Canada (ABRC–CARL) sur l'évolution du paysage de la science ouverte au Canada], les spécialistes soulignent que les communautés de recherche doivent être consultées lors des discussions sur le passage à libre accès, y compris les monographies (ABRC 2020; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/L’atelier et rapport Advancing Open d’ABRC|L’atelier et rapport Advancing Open d’ABRC]]&amp;#8239;»).

Des monographies en libre accès a également été un sujet de discussion lors de [https://inke.ca/engaging-open-social-scholarship/ Engaging Open Social Scholarship], un rassemblement en ligne des groupes [https://inke.ca/ INKE (Implementation New Knowledge Environments)] et [https://inke.ca/canadian-australian-partnership-for-open-scholarship/ CAPOS (Canadian-Australian Partnership for Open Scholarship)] en décembre 2020. Dans leur discours, [https://inke.ca/engaging-open-social-scholarship/abstracts/#Sinatra-Michael-and-Marcello-Vitali-Rosati Michael Sinatra et Marcello Vitali-Rosati de l'Université de Montréal] discute de Parcours numériques –– un modèle d'édition hybride imprimé / numérique –– et de son applicabilité aux éditions savantes.

Également à Engaging Open Social Scholarship et s'inspirant de Maxwell et al. «&amp;#8239;[https://quod.lib.umich.edu/j/jep/3336451.0020.101?view=text;rgn=main Reassembling Scholarly Communications: An Evaluation of the Andrew W. Mellon Foundation's Monograph Initiative (Final Report, May 2016)]&amp;#8239;», le conférencier invité Gabriel Miller (Fédération des sciences humaines) a discuté des défis et des recommandations pour la transition vers les monographies en libre accès dans son exposé, «&amp;#8239;[https://inke.ca/engaging-open-social-scholarship/abstracts/ Supporting the Transition to Open Access : How to Move Forward, Together]&amp;#8239;».

==Monographies en libre accès et la communauté académique élargie==
Bien que la publication de monographies en libre accès ait pris de l'ampleur au cours des dernières années, cette dynamique s'appuie sur des innovations antérieures, dont beaucoup sont en cours depuis des années, voire des décennies.

Un exemple est [https://scholarled.org/ ScholarLed], un consortium de cinq éditeurs universitaires à but non lucratif basés au Royaume-Uni et les États-Unis&amp;nbsp;: [https://www.matteringpress.org/ Mattering Press], [https://meson.press/ meson press], [https://www.openbookpublishers.com/ Open Book Publishers], [https://openhumanitiespress.org/ Open Humanities Press] et [https://punctumbooks.com/ punctum books] (n.d.). Fondé en 2018, ScholarLed est partenaire du projet [https://www.copim.ac.uk/ Community-led Publication Infrastructures for Monographs (COPIM)]. COPIM s'efforce de favoriser la transition vers la publication de monographies en libre accès en développant une infrastructure permettant la publication à moindre coût (n.d.)

[https://www.openmonographs.org/ TOME (Toward an Open Monograph Ecosystem)] est un projet pilote de cinq ans lancé en 2017 par [https://www.aau.edu/ l'Association of American Universities (AAU)], [https://www.arl.org/ l'Association of Research Libraries (ARL)] et [https://aupresses.org/ l'Association of University Presses (AUP)]. Les collèges et universités participants accordent des subventions de 15 000 $ aux professeurs pour la publication d'une monographie en libre accès. Les presses universitaires participantes produisent des éditions numériques en libre accès avec des licences Creative Commons ouvertes qui sont déposées dans des dépôts institutionnels. Son objectif est de rendre les monographies plus largement disponibles à l'aide des technologies numériques et d'une partie du Web ouvert, et de veiller à ce que l'écosystème de l'édition savante soit durable à long terme (Tome s.d.).

En mars 2021, MIT Press a annoncé une nouvelle initiative appelée [https://mitpress.mit.edu/blog/mit-press-launches-direct-open Direct to Open (D2O)], un modèle de publication à action collective dans lequel les paiements des bibliothèques participantes sont redirigés de l'achat de copies de titres au financement de la publication en libre accès de monographies savantes.

En 2017, [https://www.carl-abrc.ca/fr/groupe-de-travail-edition-savante/ le Groupe de travail sur l'édition savante au Canada (GTESC)] a publié un [https://www.carl-abrc.ca/wp-content/uploads/2017/07/GTEPC_rapport_final_FR.pdf rapport] qui a fait le point sur la publication de monographies en libre accès au Canada et a formulé des recommandations sur l'élaboration d'un cadre modèle pour le rendre durable à l'avenir. Les organisations membres du GTESC comprennent plusieurs membres du Partenariat INKE: ABRC, [https://www.crkn-rcdr.ca/fr le Réseau canadien de documentation pour la recherche (RCDR)], [https://www.erudit.org/fr/ Érudit], [https://www.idees-ideas.ca/ la Fédération des sciences humaines] et [https://pkp.sfu.ca/ le Public Knowledge Project]. Le rapport note que les politiques doivent tenir compte du fait que l'infrastructure d'édition et les cadres de financement canadiens existants sont complexes et que son marché est petit mais diversifié. Dans l'ensemble, les rédacteurs du rapport relèvent le défi essentiel de la publication de monographies en libre accès&amp;nbsp;: équilibrer la viabilité financière avec l'ouverture et l'accessibilité (GTESC 2017).

Le rapport du GTESC fait allusion aux points de désaccord de deux organisations participantes, qui sont abordés dans deux réponses au rapport de [http://acup-apuc.ca/fr/accueil/ l'Association des presses universitaires canadiennes (APUC–ACUP)] et de [https://calj-acrs.ca/fr/nouvelles/groupe-de-travail-sur-leditions-avante-au-canada l'Association canadienne des revues savantes (ACRS)]. La [http://acup-apuc.ca/2017/07/04/acup-apuc-statement-in-response-to-the-canadian-scholarly-publishing-working-group-final-report/ réponse] de l'APUC note qu’il approuve le rapport en principe mais adopte une position plus prudente à l'égard de libre accès, arguant que les modèles de publication de monographies en libre accès existants ne sont pas durables et ne garantissent pas la diversification des risques qui est essentielle pour les presses universitaires (APUC 2019). [https://calj-acrs.ca/fr/nouvelles/groupe-de-travail-sur-leditions-avante-au-canada La déclaration de l’ACRS] décrit également sa position différente à l'égard de libre accès, notant que la durabilité financière devrait être la priorité et qu'il existe de nombreuses façons de diffuser la recherche, y compris - mais sans s'y limiter - la publication en libre accès (ACRS 2017).

==Monographies en libre accès et science ouverte==
Les monographies savantes sont des éléments clés de l'écosystème de la communication savante, mais elles ont tendance à être laissées pour compte dans les politiques de libre accès des institutions et des bailleurs de fonds, qui se concentrent souvent sur des articles de revues. Cependant, comme le soulignent Maxwell, Bordini et Shamash, les monographies et les revues font partie du même écosystème complexe&amp;nbsp;: le coût croissant des abonnements aux revues est l'un des facteurs de la baisse des ventes de monographies (2017).

Les monographies en libre accès rendraient non seulement les études longues plus largement accessibles pour la lecture et l'exploration de textes, mais les rendraient également plus accessibles pour les décideurs, ce qui est particulièrement important dans les sciences sociales (Weigart et Stone). En plus de rehausser potentiellement le profil de la recherche en sciences humaines, le développement d'un modèle solide pour l'édition de monographies en libre accès pourrait également contribuer à rendre l'édition de livres universitaires plus durable à long terme.

==Ouvrages citées==
*ABRC (Association des bibliothèques de recherche du Canada). 2020. ''Advancing Open: points de vue des spécialistes de la communication savante''. [http://acup-apuc.ca/fr/2019/10/18/la-declaration-de-lapuc-acup-en-reponse-a-un-mandat-eventuel-de-libre-acces-du-prix-dauteurs-pour-lediton-savante-paes/ http://acup-apuc.ca/fr/2019/10/18/la-declaration-de-lapuc-acup-en-reponse-a-un-mandat-eventuel-de-libre-acces-du-prix-dauteurs-pour-lediton-savante-paes/].

*ACRS (Association Canadienne des revues savants). 2017. Groupe de travail sur «&amp;#8239;l’édition savant au Canada&amp;#8239;». 4 juillet 2017. [https://calj-acrs.ca/fr/nouvelles/groupe-de-travail-sur-leditions-avante-au-canada https://calj-acrs.ca/fr/nouvelles/groupe-de-travail-sur-leditions-avante-au-canada].

*Adema, Janneke, Graham Stone, et Chris Keene. ''Changing Publishing Ecologies: A Landscape Study of New University Presses and Academic-led Publishing''. Jisc. [https://repository.jisc.ac.uk/6666/1/Changing-publishing-ecologies-report.pdf https://repository.jisc.ac.uk/6666/1/Changing-publishing-ecologies-report.pdf].

*APUC (Association des presses universitaires canadiennes). 2019. «&amp;#8239;La déclaration de l’APUC/ACUP en réponse à un mandat éventuel de libre accès de Prix d’auteurs pour l’édition savante (PAES)&amp;#8239;». 18 octobre 2019. [http://acup-apuc.ca/fr/2019/10/18/la-declaration-de-lapuc-acup-en-reponse-a-un-mandat-eventuel-de-libre-acces-du-prix-dauteurs-pour-lediton-savante-paes/ http://acup-apuc.ca/fr/2019/10/18/la-declaration-de-lapuc-acup-en-reponse-a-un-mandat-eventuel-de-libre-acces-du-prix-dauteurs-pour-lediton-savante-paes/].

*APUC. 2017. «&amp;#8239;ACUP / APUC Statement in Response to the Canadian Scholarly Publishing Working Group Final Report&amp;#8239;». 4 juillet 2017. [http://acup-apuc.ca/2017/07/04/acup-apuc-statement-in-response-to-the-canadian-scholarly-publishing-working-group-final-report/ http://acup-apuc.ca/2017/07/04/acup-apuc-statement-in-response-to-the-canadian-scholarly-publishing-working-group-final-report/].

*ARC (Australian Research Council). 2017. ''ARC Open Access Policy Version 2017.1''. [https://www.arc.gov.au/policies-strategies/policy/arc-open-access-policy-version-20171 https://www.arc.gov.au/policies-strategies/policy/arc-open-access-policy-version-20171].

*cOAlition S. 2020. «&amp;#8239;Principles and Implementation&amp;#8239;». [https://www.coalition-s.org/addendum-to-the-coalition-s-guidance-on-the-implementation-of-plan-s/principles-and-implementation/ https://www.coalition-s.org/addendum-to-the-coalition-s-guidance-on-the-implementation-of-plan-s/principles-and-implementation/].

*COPIM. s.d. «&amp;#8239;Open Access, Open Infrastructures&amp;#8239;». [https://www.copim.ac.uk/ https://www.copim.ac.uk/].

*Fédération des sciences humaines. 2015. ''Le libre accès et le PAES&amp;nbsp;: Énoncé de principes''. avril 2015. [http://www.idees-ideas.ca/sites/default/files/oa-aspp-policy-position-fr.pdf http://www.idees-ideas.ca/sites/default/files/oa-aspp-policy-position-fr.pdf].

*Gatti, Rupert, Katherine Bowers, Megan Brand, Mark Turin, et Leonora Crema. 2020. ''Emerging Perspectives in Open Access Book Publishing''. 4 novembre 2020. [http://dx.doi.org/10.14288/1.0395145 http://dx.doi.org/10.14288/1.0395145].

*Gouvernement du Canada. 2016. ''Politique des trois organismes sur the le libre accès aux publication. ''[https://www.ic.gc.ca/eic/site/063.nsf/fra/h_F6765465.html https://www.ic.gc.ca/eic/site/063.nsf/fra/h_F6765465.html].

*Grimme, Sara, Cathy Holland, Peter Potter, Mike Taylor, Charles Watkinson, et Michael A. Elliott. ''The State of Open Monographs: An Analysis of the Open Access Monograph Landscape and its Integration into the Digital Scholarly Network''. Digital Science. [https://digitalscience.figshare.com/articles/The_State_of_Open_Monographs/8197625 https://digitalscience.figshare.com/articles/The_State_of_Open_Monographs/8197625].

*GTESC (Groupe de travail sur l’édition savante au Canada). 2017. ''Groupe de travail sur l’édition savante au Canada : Rapport final. Juillet 2017.'' [http://acup-apuc.ca/wp-content/uploads/2017/07/GTEPC_rapport_final_FR.pdf http://acup-apuc.ca/wp-content/uploads/2017/07/GTEPC_rapport_final_FR.pdf].

*HEFCE (Higher Education Funding Council for England). 2016. ''Consultation on the second Research Excellence Framework''. [https://webarchive.nationalarchives.gov.uk/20180405115003/http:/www.hefce.ac.uk/pubs/year/2016/201636/ https://webarchive.nationalarchives.gov.uk/20180405115003/http://www.hefce.ac.uk/pubs/year/2016/201636/].

*Hill, Tom. 2020. «&amp;#8239;Four Reports on the OA Monograph: Review&amp;#8239;». Learned Publishing 33, pp. 345–347. [https://doi.org/10.1002/leap.1311 https://doi.org/10.1002/leap.1311].

*Jisc. 2019. «&amp;#8239;OA Monographs: Policy and Practice for Supporting Researchers&amp;#8239;». [https://www.jisc.ac.uk/events/oa-monographs-policy-and-practice-for-supporting-researchers-04-jul-2019 https://www.jisc.ac.uk/events/oa-monographs-policy-and-practice-for-supporting-researchers-04-jul-2019].

*Khan, Mehtab. 2018. «&amp;#8239;Traditional Knowledge and the Commons: The Open Movement, Listening, and Learning&amp;#8239;». Creative Commons Blog. 18 septembre 2018. [https://creativecommons.org/2018/09/18/traditional-knowledge-and-the-commons-the-open-movement-listening-and-learning/ https://creativecommons.org/2018/09/18/traditional-knowledge-and-the-commons-the-open-movement-listening-and-learning/].

*Knowledge Exchange. 2019. ''Towards a Roadmap for Open Access Monographs: A Knowledge Exchange Report''. juin 2019. [https://repository.jisc.ac.uk/7413/3/Towards_a_Roadmap_for_Open_Access_Monographs_June_2019.pdf https://repository.jisc.ac.uk/7413/3/Towards_a_Roadmap_for_Open_Access_Monographs_June_2019.pdf].

*Maxwell, John, Erik Hanson, Leena Desai, Carmen Tiampo, Kim O’Donnell, Avvai Ketheeswaran, Melody Sun, Emma Walter, et Ellen Michelle. 2019. ''Mind the Gap: A Landscape Analysis of Open Source Publishing Tools and Platforms''. [https://mindthegap.pubpub.org/ https://mindthegap.pubpub.org/].

*Maxwell, John, Alessandra Bordini, et Katie Shamash. 2017. «&amp;#8239;Reassembling Scholarly Communications: An Evaluation of the Andrew W. Mellon Foundation’s Monograph Initiative (Final Report, May 2016)&amp;#8239;». ''The Journal of Electronic Publishing'' 20, issue 1. [https://doi.org/10.3998/3336451.0020.101 https://doi.org/10.3998/3336451.0020.101].

*McKenzie, Lindsay. 2018. «&amp;#8239;Open-Access Best Sellers&amp;#8239;». ''Inside Higher Ed''. 1 juin 2018. [https://www.insidehighered.com/news/2018/06/01/most-popular-open-access-monographs https://www.insidehighered.com/news/2018/06/01/most-popular-open-access-monographs].

*McKenzie, Lindsay. 2019a. «&amp;#8239;Subscribing to Open Monographs&amp;#8239;». ''Inside Higher Ed''. 22 octobre 2019. [https://www.insidehighered.com/news/2019/10/22/exploring-subscriptions-support-open-access-monographs https://www.insidehighered.com/news/2019/10/22/exploring-subscriptions-support-open-access-monographs].

*McKenzie, Lindsay. 2019b. «&amp;#8239;Making Monographs Open&amp;#8239;». ''Inside Higher Ed''. 3 mai 2019. [https://www.insidehighered.com/news/2019/05/03/north-carolina-press-seeks-sustainable-open-access-model-monographs https://www.insidehighered.com/news/2019/05/03/north-carolina-press-seeks-sustainable-open-access-model-monographs].

*MLA Task Force on Evaluating Scholarship for Tenure and Promotion. 2007. ''Report of the MLA Task Force on Evaluating Scholarship for Tenure and Promotion''. MLA (Modern Language Association). [https://www.mla.org/content/download/3362/81802/taskforcereport0608.pdf https://www.mla.org/content/download/3362/81802/taskforcereport0608.pdf].

*Penier, Izabella. Martin Paul Eve, et Tom Grady. ''COPIM Revenue Models for Open Access Monographs 2020''. COPIM. https://doi.org/10.5281/zenodo.4011836.

*Pyne, Ros, Christina Emery, Mithu Lucraft, et Anna Sophia Pinck. 2019. ''The Future of Open Access Books: Findings from a Global Survey of Academic Book Authors''. Springer Nature. [https://figshare.com/articles/The_future_of_open_access_books_Findings_from_a_global_survey_of_academic_book_authors/8166599 https://figshare.com/articles/The_future_of_open_access_books_Findings_from_a_global_survey_of_academic_book_authors/8166599].

*Schimanski, Lesley A., et Juan Pablo Alperin. 2018. «&amp;#8239;The Evaluation of Scholarship in Academic Promotion and Tenure Processes: Past, Present, and Future&amp;#8239;». ''F1000Research'' 7. octobre 2018, 1605. [https://doi.org/10.12688/f1000research.16493.1 https://doi.org/10.12688/f1000research.16493.1].

*ScholarLed. s.d. «&amp;#8239;Scaling Small&amp;#8239;». [https://scholarled.org/ https://scholarled.org].

*TOME (Toward an Open Monograph Ecosystem). s.d. «&amp;#8239;About&amp;#8239;». [https://www.openmonographs.org/about/ https://www.openmonographs.org/about/].

*Townsend, Robert B. 2003. «&amp;#8239;History and the Future of Scholarly Publishing: Field Does Better than Most at Getting Books Published, but Problems Loom&amp;#8239;». ''Perspectives''. octobre 2003. [https://www.historians.org/assets/documents/History%20and%20the%20Future%20of%20Scholarly%20Publishing.pdf https://www.historians.org/assets/documents/History%20and%20the%20Future%20of%20Scholarly%20Publishing.pdf].

*UKRI (UK Research and Innovation). 2020. «&amp;#8239;How our Open Access Policies are Changing&amp;#8239;». [https://www.ukri.org/our-work/supporting-healthy-research-and-innovation-culture/open-research/open-access-policies-review/ https://www.ukri.org/our-work/supporting-healthy-research-and-innovation-culture/open-research/open-access-policies-review/.]

*Universities UK. 2019. ''Open Access and Monographs: Evidence Review''. Octobre 2019. [https://www.universitiesuk.ac.uk/policy-and-analysis/reports/Pages/open-access-monographs-evidence-review.aspx https://www.universitiesuk.ac.uk/policy-and-analysis/reports/Pages/open-access-monographs-evidence-review.aspx].

*Weigert, Verena, et Graham Stone. 2017. «&amp;#8239;Making the Monograph Sustainable&amp;#8239;». ''Research Information''. [https://www.researchinformation.info/analysis-opinion/making-monograph-sustainable https://www.researchinformation.info/analysis-opinion/making-monograph-sustainable].

*Wellcome Trust. s.d. «&amp;#8239;Open Access Policy&amp;#8239;». [https://wellcome.org/grant-funding/guidance/open-access-guidance/open-access-policy https://wellcome.org/grant-funding/guidance/open-access-guidance/open-access-policy].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>thvwxpcr2rf2gv2v1ok11anwg5v2jhz</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Mise à jour : Gestion des données de recherche au Canada</title>
    <ns>0</ns>
    <id>82279</id>
    <revision>
      <id>745409</id>
      <parentid>745132</parentid>
      <timestamp>2025-06-26T19:00:02Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745409</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="12152" sha1="l3hy6p5q82vdncj58d2ohgipgl6erll" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec des remerciements à Jeff Moon pour ses commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En mars 2021, le gouvernement du Canada a annoncé la publication de la [https://science.gc.ca/eic/site/063.nsf/fra/h_97610.html ''Politique des trois organismes sur la gestion des données de recherche''] (Politique de GDR). Une ébauche de cette politique pour consultation a été publiée en mai 2018 (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le politique des trois organismes sur la gestion des données de recherche|Le Politique des trois organismes sur la gestion des données de recherche]]&amp;#8239;»).

S'appuyant sur la Déclaration de principes des trois organismes sur la gestion des données numèriques (2016), l'objectif de la Politique de GDR est de «&amp;#8239;promouvoir l'excellence a matière de recherche au Canada en encourageant de saines pratiques de gestion des données de recherche et d’intendance des données&amp;#8239;», reconnaissant la diversité des normes et des pratiques liées aux données de recherche et au sein des disciplines (Gouvernement du Canada 2021b; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Déclaration de principes des trois organismes sur la gestion des données numériques|Déclaration de principes des trois organismes sur la gestion des données numériques]]&amp;#8239;» et «&amp;#8239;[https://ospolicyobservatory.uvic.ca/partner-response-to-tri-agency-statement-of-principles-on-digital-data-management/ Partner Response to Tri-Agency Statement of Principles on Digital Data Management]&amp;#8239;» par Lisa Goddard [Bibliothèques UVic]).

De plus, la Politique de GDR souligne la nécessité d'une «&amp;#8239;approche qui tient compte de la particularité des collectivités&amp;#8239;» pour gérer les données associées à la recherche par et en collaboration avec les communautés des Premières Nations, Métis et Inuits au Canada (2021b), et appuie l'établissement de nouvelles orientations pour soutenir le plan stratégique [https://www.canada.ca/fr/comite-coordination-recherche/priorites/recherche-autochtone/plan-strategique-2019-2022.html ''Établir de nouvelles orientations à l’appui de la recherche et de la formation en recherche autochtone au Canada 2019-2022''].

Cette Politique de GDR s'appuie sur l'approche du Canada en matière de GDR qui comprend la [https://science.gc.ca/eic/site/063.nsf/fra/h_F6765465.html ''Politique des trois organismes sur le libre accès aux publications''] (2015) et soutient les principes [https://www.nature.com/articles/sdata201618 FAIR] (Findable, Accessible, Interoperable, and Reusable [trouvables, accessibles, interopérables et réutilisables]) pour la gestion et l'intendance des données. Bien qu'il stipule que les données de recherche recueillies grâce à un financement public devraient être «&amp;#8239;lorsque les obligations éthiques, juridiques et commerciales le permettent, être disponibles pour être réutilisées par d’autres&amp;#8239;», il déclare explicitement qu'il ne s'agit «&amp;#8239;pas une politique sur les données ouvertes&amp;#8239;» (Gouvernement du Canada 2021b).

La politique de GDR comprend des exigences pour les institutions et les chercheurs. En résumé, les établissements doivent développer des stratégies de GDR accessibles au public pour promouvoir l'importance de la GDR au sein de leur communauté et aider les chercheurs à mettre en place de solides pratiques de GDR, notamment en fournissant l'infrastructure numérique nécessaire. Les chercheurs doivent intégrer la GDR dans leurs méthodologies de recherche, et certaines opportunités de financement nécessiteront des plans de gestion des données (DMP) dans le cadre de la demande. Les chercheurs sont tenus de déposer toutes les données de recherche numériques, les métadonnées et le code dans un référentiel de données numériques reconnu et de rendre ces données aussi ouvertes que possible (Gouvernement du Canada 2021b).

Ces exigences seront mises en œuvre progressivement au cours des deux prochaines années. De nombreuses dates de mise en œuvre restent à déterminer, mais deux dates clés sont les suivantes&amp;nbsp;:
* Printemps 2022&amp;nbsp;: les Instituts de recherche en santé du Canada (IRSC), le Conseil de recherches en sciences naturelles et en génie du Canada (CRSNG) et le Conseil de recherches en sciences humaines du Canada (CRSH) détermineront les possibilités de financement qui nécessitent des plans de gestion des données (PGD) après un programme pilote initial.
* 1er mars 2023&amp;nbsp;: les stratégies institutionnelles de GDR doivent être affichées (Gouvernement du Canada 2021b).

==La gestion des données de recherche au Canada et le Partenariat INKE==
[https://www.carl-abrc.ca/fr/ L'Association des bibliothèques de recherche du Canada (ABRC–CARL)], membre du Partenariat INKE, a [https://www.carl-abrc.ca/fr/nouvelles/le-reseau-portage-de-labrc-salue-la-politique-des-trois-organismes-sur-la-gestion-des-donnees-de-recherche/ exprimé son soutien à la politique de GDR], notant que l'ABRC et Portage ont participé activement à son élaboration par le biais de consultations avec les intervenants et de la [https://portagenetwork.ca/wp-content/uploads/2018/07/Commentaires-de-Portage-sur-l%E2%80%99%C3%A9bauche-de-la-Politique-des-trois-organismes-sur-la-GDR-1.pdf publication de la réponse au l'ébauche de la politique de l'ABRC Portage] (2021). [https://portagenetwork.ca/fr/ Le Réseau Portage], une initiative de l'ABRC, a été lancé en 2015 pour soutenir la gestion et l'intendance des données de recherche au Canada, y compris le développement de partenariats pour fournir les infrastructures numériques nécessaires.

En avril 2021, Portage et la Nouvelle organisation d’infrastructure de recherche numèrique (NOIRN) ont annoncé que les opérations de Portage étaient pleinement intégrées dans NOIRN. NOIRN est un organisme national à but non lucratif fondé en 2019 dans le cadre de [https://www.ic.gc.ca/eic/site/136.nsf/fra/accueil la stratégie d’infrastructure de recherche numérique] [https://www.ic.gc.ca/eic/site/icgc.nsf/fra/accueil d'Innovation, Sciences et Développement économique (ISDE) Canada] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/NOIRN et la stratégie canadienne d’infrastructure de recherche numérique|NOIRN et la stratégie canadienne sur d'infrastructure de recherche numérique]]&amp;#8239;»). Cette intégration a été planifiée en accord avec l'ABRC et avec un financement antérieur d'ISDE, passant par [https://www.canarie.ca/fr/ CANARIE] (Portage 2021). NOIRN a récemment annoncé des informations préliminaires sur sa [https://engagedri.ca/fr/annonce-pr%C3%A9alable-de-loffre-de-financement-inaugurale offre de financement inaugurale (OFI)].

[https://science.gc.ca/eic/site/063.nsf/fra/h_98222.html L’annonce de politique] du gouvernement du Canada fait état [https://portagenetwork.ca/fr/outils-et-ressources/strategies-institutionnelles/ des ressources de Portage] conçues pour soutenir les institutions dans l’élaboration de leurs stratégies. La principale de ces ressources est [https://zenodo.org/record/4558227#.YKQxvpNKhTY un modèle de stratégie de gestion des données de recherche institutionnelle] et [https://zenodo.org/record/4558229#.YKQx7JNKhTY des conseils d'accompagnement], préparés par le Groupe de travail sur les stratégies institutionnelle de GDR de Portage (2021a). Le modèle décrit quatre composantes suggérées d'une stratégie institutionnelle de GDR - sensibiliser, évaluer la préparation institutionnelle, formaliser les pratiques de GDR et définir une feuille de route - et fournit un aperçu d'un plan que les institutions peuvent personnaliser pour répondre à leurs besoins (Portage 2018). Huit nouvelles vidéos fournissant des conseils sur le premier et le deuxième de ces composants seront bientôt publiés.

En plus de ce modèle, l'ABRC Portage s'est associé à l'Université de l'Alberta pour développer un outil de planification de la gestion des données ouvert, national et bilingue - [https://assistant.portagenetwork.ca/ l'Assistant PGD]. L'ABRC Portage a également collaboré à des initiatives nationales de dépôt multidisciplinaire, notamment en soutenant une instance nationale de Dataverse par le biais du [https://dataverse.scholarsportal.info/fr/ Scholars Portal Dataverse] du [https://ocul.on.ca/ Ontario Council of University Libraries (OCUL)] et en collaborant avec [https://www.computecanada.ca/?lang=fr Calcul Canada] pour développer, piloter et lancer [https://www.frdr-dfdr.ca/repo/?locale=fr le Dépôt fédéré de données de recherche  (DFDR)].

==La politique de GDR des trois organismes et la science ouverte==
La Politique de GDR souligne que la gestion des données est une composante essentielle de l'excellence de la recherche car elle permet d'assurer la reproductibilité et l'accessibilité des données créées avec des fonds publics. La déclaration de soutien de l'ABRC fait écho à ce point, soulignant les facteurs culturels impliqués&amp;nbsp;: «&amp;#8239;Étant donnée la conscientisation grandissante sur l'importance des données dans le traitement des grands enjeux sociétaux, la GDR est devenue un élément essentiel de la recherche et de l'érudition dans toutes des disciplines et au-delà des frontières. Une solide culture de gestion des données profite aux chercheurs, aux organismes de financement, aux établissements et à la société en général. Elle soutient la découverte et alimente l'innovation&amp;#8239;» (2021).

Parce qu’elle facilite l’intendance, la préservation et l’accessibilité des données de recherche, la nouvelle Politique de GDR du Canada joue un rôle important dans la promotion des sciences ouvertes.

==Ouvrages cités==
*Association des bibliothèques de recherche du Canada. 2021. «&amp;#8239;Le réseau Portage de l’ABRC salue la Politique de trois organismes sur la gestion des données de recherche&amp;#8239;». 16 mars 2021. [https://www.carl-abrc.ca/fr/nouvelles/le-reseau-portage-de-labrc-salue-la-politique-des-trois-organismes-sur-la-gestion-des-donnees-de-recherche/ https://www.carl-abrc.ca/fr/nouvelles/le-reseau-portage-de-labrc-salue-la-politique-des-trois-organismes-sur-la-gestion-des-donnees-de-recherche/].

*Gouvernement du Canada. 2021a. «&amp;#8239;Lettre ouverte&amp;nbsp;: Lancement de la ''Politique des trois organismes sur la gestion des données de recherche'' et d’une nouvelle exigence pour les établissements d’enseignement postsecondaire et les hôpitaux de recherche&amp;#8239;». [https://science.gc.ca/eic/site/063.nsf/fra/h_98222.html https://science.gc.ca/eic/site/063.nsf/fra/h_98222.html].

*Gouvernement du Canada. 2021b. ''Politique des trois organismes sur la gestion des données de recherche''. [https://science.gc.ca/eic/site/063.nsf/fra/h_97610.html https://science.gc.ca/eic/site/063.nsf/fra/h_97610.html].

*Portage. 2021. «&amp;#8239;Le réseau Portage se joint à la NOIRN pour continuer de faire progresser la gestion des données de recherche au Canada&amp;#8239;». [https://portagenetwork.ca/fr/nouvelles/le-reseau-portage-se-joint-a-la-noirn-pour-continuer-de-faire-progresser-la-gestion-des-donnees-de-recherche-au-canada/ https://portagenetwork.ca/fr/nouvelles/le-reseau-portage-se-joint-a-la-noirn-pour-continuer-de-faire-progresser-la-gestion-des-donnees-de-recherche-au-canada/].

*Le Group de travail sur les stratégies institutionnelles de GRD et Groupe d’experts national sur la formation du réseau Portage. 2020. ''Modèle – Stratégie Institutionnelle de gestion des données de recherche V. 2.0''. 1 mars 2020. [https://doi.org/10.5281/zenodo.4558228 https://doi.org/10.5281/zenodo.4558228].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>l3hy6p5q82vdncj58d2ohgipgl6erll</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les accords de libre accès</title>
    <ns>0</ns>
    <id>82280</id>
    <revision>
      <id>745410</id>
      <parentid>745133</parentid>
      <timestamp>2025-06-26T19:04:31Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745410</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="23664" sha1="nvwllbfbv3enw5jobmkdhr5cjzgm01j" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec nos remerciements à Lise Brin (ABRC) et Rebecca Ross (RCDR) pour leurs commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En mars 2021, l'University of California a annoncé un accord de libre accès révolutionnaire avec Elsevier, le plus grand éditeur scientifique au monde (2021). En vertu de l'accord, tous les articles avec un auteur principal basé à l'UC seront en libre accès dès leur publication, et les chercheurs de l'UC auront accès à la lecture d'articles dans les revues Elsevier. Au cours des deux dernières années, UC a conclu neuf accords de transformation, dont un avec Springer Nature, un autre grand éditeur, en juin 2020 (UC 2021 ; Brainard 2020).

Cet accord de «&amp;#8239;lecture et de publication&amp;#8239;» entre les bibliothèques et les éditeurs, qui comprend des dispositions pour les auteurs institutionnels ainsi que l'accès institutionnel aux publications, est un type d'accord transformatif, l'un des nombreux types d'accords et de modèles de publication destinés à promouvoir le libre accès.

==Accords transformatifs==
L'ESAC (Efficiency and Standards for Article Charges Initiative) définit «&amp;#8239;accord transformatif&amp;#8239;» comme une term générique pour des accords négociés entre les éditeurs et les institutions (inclus les bibliothèques et des consortiums) dans lesquels des fonds précédemment dépensés en abonnements sont réaffectées pour soutenir la publication an libre accès. Ces accords aider a changer le modèle commercial progressivement et définitivement vers a celui en lequel les éditeurs sont rémunérés à un prix équitable pour leurs services de publication en libre accès. (s.d.)

Bien qu'il existe différents types d'accords transformateurs, ils visent tous à transformer l'écosystème de l'édition vers le libre accès. L'EASC tient [https://esac-initiative.org/about/transformative-agreements/agreement-registry/ un registre mondial des accords de transformation] qui comprend des informations sur la nature de l'accord, le coût, la couverture et d'autres détails.

Lisa Janicke Hinchliffe (2020a) décrit quatre composantes des accords transformateurs : les coûts, les droits d'auteur, la transparence et la transition. En plus de réorienter les fonds des bibliothèques, les accords transformatifs peuvent rendre la publication en libre accès plus rentable pour les chercheurs, qui n'ont pas besoin de payer les frais de traitement d’article de leur poche, et ils peuvent être plus rentables pour les bibliothèques, bien que ce ne soit pas toujours le cas. Dans l'entente entre le RCDR et Sage, par exemple, le prix total augmentera de 6 % sur trois ans (RCDR 2021). La plupart des accords transformateurs exigent que les auteurs conservent le droit d'auteur sur leur travail, qui est publié sous une licence de publication ou une licence Creative Commons. Pour plus de transparence, les contrats sont souvent disponibles ouvertement (voir [https://esac-initiative.org/about/transformative-agreements/agreement-registry/ le registre de l'EASC]). Les accords transformatifs sont transitoires dans le sens où ils visent à s'éloigner complètement de la lecture par abonnement (2019 ; EASC 2020).

==Accords de lecture et de publication==
Dans les accords de lecture et de publication, les frais d'abonnement à la bibliothèque et les frais de traitement des articles pour la publication en libre accès sont regroupés.

En mars 2020, Jisc a annoncé qu'elle avait négocié un accord de lecture et de publication entre les universités britanniques et Wiley, un accord destiné à accélérer le mouvement vers libre accès au Royaume-Uni (Grove 2020). Un autre résultat visé était de simplifier le processus de libre accès pour les auteurs et de les aider à se conformer aux mandats des bailleurs de fonds et aux directives du Plan S (Jisc 2020) (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;»]). Dans une mise à jour de septembre 2020, Jisc a signalé qu'au cours des neuf mois écoulés depuis l'entrée en vigueur de l'accord, il y avait eu une augmentation de 82% des articles britanniques publiés en libre accès par rapport à 2019 et 91% par rapport à 2018, avec une adoption de 97%, ce qui signifie que seulement 3% des auteurs ont choisi de ne pas publier leur travail en libre accès (Vernon 2020).

==Accords de publication et de lecture==
Dans les accords de publication et de lecture, les paiements d'une bibliothèque à un éditeur couvrent uniquement la publication (par exemple, les frais de traitement d’article), mais l'accès au contenu publié en lecture est inclus sans frais supplémentaires. La différence entre les accords de publication et de lecture et de lecture et de publication devient claire dans le cas des accords entre les éditeurs et les consortiums de bibliothèques. Comme le souligne Hinchliffe (2019), le coût d'un accord de lecture et de publication est partagé par tous les membres du consortium de bibliothèques, mais dans le cadre d'un accord de publication et de lecture, le coût est partagé uniquement par les bibliothèques des institutions avec des universitaires qui publient des recherches.

==Accords de publication pure==
Les accords de publication pure sont similaires aux accords de transformation en ce qu'ils couvrent les coûts de publication, mais ils sont différents en ce qu'ils s'appliquent aux revues qui sont déjà entièrement en libre accès et ne redirigent donc pas les fonds qui auraient autrement payé pour l'accès par abonnement (Hinchliffe 2020b). Un exemple est l'accord de 2020 entre UC et PLOS, en vertu duquel les bibliothèques UC paie une partie des frais de traitement d’article pour tout auteur UC qui publie dans une revue PLOS (Hinchliffe 2020b; PLOS 2020).

==Abonné a libre accès==
Des accords «&amp;#8239;abonné a libre accès&amp;#8239;» redirige le paiement de l'abonnement d'une bibliothèque de la fourniture d'un accès en lecture (pour cette bibliothèque) aux articles de revues à la mise à disposition de ces articles à tous les lecteurs, quelle que soit leur affiliation institutionnelle. Ces accords s'appuient sur les accords d'abonnement existants : les bibliothèques acceptent de continuer à s'abonner à la revue pour accéder à son contenu à un tarif réduit. Si toutes les bibliothèques de l'accord continuent de s'abonner année après année, le contenu devient également disponible pour les non-abonnés, mais si certaines bibliothèques de l'accord se retirent, c'est-à-dire cessent de s'abonner, le contenu est à nouveau payant pour tous, sauf les bibliothèques abonnées (Hinchliffe 2020).

Ce modèle a été développé et piloté par ''Annual Reviews'', mais Martin Paul Eve a décrit un modèle similaire d'abonnement à un modèle ouvert de consortium avec un délai de trois ans (plutôt qu'un an) qui comprend des désincitations pour les bibliothèques de désabonnement ainsi que des incitations pour les abonnés continus (2018).

Les directeurs d’''Annual Reviews ''notent que deux avantages de ce modèle sont qu'il n'implique pas les frais de traitement d’article et qu'il permet aux bibliothèques de soutenir le libre accès tout en ayant accès à des publications de valeur pour leurs communautés à un coût réduit (Michael 2019). Bien qu’''Annual Reviews ''demandent aux auteurs de transférer leurs droits d'auteur à l'éditeur, d'autres accords de licence sont possibles (Hinchliffe 2020a).

[https://www.berghahnjournals.com/ Berghahn Journals] pilote un modèle similaire d'abonné a libre accès développé avec [https://libraria.cc/ Libraria] en partenariat avec [https://knowledgeunlatched.org/ Knowledge Unlatched] (Berghahn 2020). Le projet pilote Berghahn Open Anthro (BOA-S2O) dure trois ans et été lancé en 2020. Il comprend 13 revues d'anthropologie et, dans sa deuxième année, comptait 305 abonnés dans le monde. Dans ce modèle, les auteurs conservent les droits d'auteur sur leur travail, qui est distribué sous une licence Creative Commons.

En mars 2020, EDP Sciences [https://www.edpsciences.org/en/news-highlights/2002-mathematical-modelling-of-natural-phenomena-transitions-to-open-access-under-the-subscribe-to-open-model a annoncé qu'elle pilotait également un modèle d’abonné a libre accès pour sa revue ''Mathematical Modeling of Natural Phenomena''], expliquant que, dans ce modèle, les institutions soutiennent les revues pour le bien commun de la communauté universitaire et démontrent leur engagement à rendre libre accès durable à long terme (2020). En novembre 2020, [https://www.edpsciences.org/en/news-highlights/2194-jisc-and-edp-sciences-conclude-a-flexible-maths-journals-agreement-2021-2023 EDP Sciences a annoncé un accord d’abonné a libre accès avec JISC] portant sur cinq titres supplémentaires (2020a).

De Gruyter a également [https://www.sspnet.org/community/news/de-gruyter-transforms-journal-bibliothek-forschung-und-praxis-to-open-access-via-subscribe-to-open-model/ adopté un modèle pilote d'abonnement au modèle ouvert pour sa revue ''Bibliothek Forschung und Praxis''] en septembre 2020, qui est disponible sous licence CC-BY. L'éditeur note qu'il a l'intention d'adopter ce modèle pour d'autres revues, expliquant que ce modèle permet de renversé les revues vers libre accès de manière transparente, avec, peu de perturbations et sans frais supplémentaires. En plus, il parce qui’ll n'implique pas des frais de traitement d’article, léditeur note que c'est une approche juste et équitable (De Gruyter 2020).

[https://ems.press/subscribe-to-open EMS Press] a également adopté un modèle abonné a libre accès pour l'ensemble de son portefeuille de revues, citant de nombreux avantages pour les parties prenantes, tout comme [https://iwaponline.com/s2o/pages/About IWA Publishing].

==Accords transformateurs et partenariat INKE==
[https://www.crkn-rcdr.ca/fr/principes-de-licences-du-rcdr Les Principes du licences] du Réseau canadien de documentation pour la recherche (RCDR-CRKN), révisés en 2020, comprennent le soutien à divers modèles de libre accès, y compris les accords transformatifs. Les Principes de négociation comprennent «&amp;#8239;cherch[ant] des accords où les montants déboursés pour le libre accès diminuent les frais d'abonnement au Canada et à l’international&amp;#8239;» (RCDR s.d., 2). Les principes mettent également l'accent sur l'équité d'accès et la transparence et stipulent que le RCDR s'associera avec des fournisseurs qui «&amp;#8239;accepter la transition du modèle d’abonnement vers le libre accès complet ; reconnaître que les accords de transformation sont une solution temporaire au libre accès&amp;#8239;» (2).

En février 2021, [https://www.crkn-rcdr.ca/fr/le-reseau-canadien-de-documentation-pour-la-recherche-annonce-un-accord-transformatif-avec-sage le RCDR a annoncé un accord de lecture et de publication avec SAGE], par lequel les chercheurs de 69 établissements membres participants du RCDR peuvent publier des articles en libre accès dans les revues SAGE Choice sans payer des frais de traitement des articles, et les articles seront publiés sous une licence Creative Commons (RCDR 2021). Le contrat de licence et une liste des membres participants sont disponibles sur [https://www.crkn-rcdr.ca/fr/accord-transformatif-entre-le-rcdr-et-sage le site Web du RCDR].

==Accords transformateurs et communauté universitaire au sens large==
Les accords transformatifs sont de plus en plus courants et de nombreux membres de la communauté de science ouvertes les considèrent comme une innovation positive. cOAlitionS, par exemple, les qualifie d’un instrument prometteurs pour passer des revues à libre accès (2021), et l'accord entre UC et Elsevier a reçu un large soutien, y compris de la part de l'Association of Research Libraries (ARL) americaine, qui note que l'accord fait partie d'un changement plus large dans la façon dont les bibliothèques abordent les licences de revues, marquant une époque intéressant dans l'édition savante (Aiwuyor 2021).

D'autres dans la communauté, cependant, hésitent à soutenir des accords transformatifs par crainte qu'ils intègrent les frais de traitement d’articles et perpétuent ainsi les inégalités existantes au sein du système de publication savante. Par exemple, [https://frontiersinblog.files.wordpress.com/2020/03/position-statement-transformative-agreements.pdf un document de position des éditeurs Copernicus, Frontiers, JMIR, MDPI et Ubiquity Press] craint que, sans conditions contraignantes ou délais précis, les accords de transformation ne favorisent pas réellement la transition vers libre accès (Frontiers 2020).

Dans [https://blogs.lse.ac.uk/impactofsocialsciences/2020/02/21/read-and-publish-open-access-deals-are-heightening-global-inequalities-in-access-to-publication/ un article pour le blog LSE], par exemple, Jefferson Pooley soutient que, bien que ces types d'accords mettent effectivement fin à la pratique des éditeurs de double rémunération – faire payer aux institutions et à leurs bibliothèques des fraise de traitement d’articles ainsi que des frais d'abonnement – ces accords sont accessible uniquement aux riches institutions largement occidentales, telles que l'UC. Il note que l'édition savante est déjà stratifiée au nord et au sud, faisant des accords de la lecture et de la publication une insulte à blessure (2020). En outre, non seulement ces accords approuvent l'utilisation des frais de traitement d’articles, mais ils permettent aux grands éditeurs commerciaux de dominer le domaine de l'édition en libre accès.

==Accords transformateurs et science ouverte==
En tant qu'élément important [https://www.coalition-s.org/plan-s-principes-et-mise-en-oeuvre/ des directives de mise en œuvre de Plan S], les accords transformateurs jouent un rôle important dans le passage à la science ouverte en Europe et au Royaume-Uni. L'accord d'UC avec Elsevier indique qu'ils pourraient également devenir une partie de plus en plus importante du paysage nord-américain de l'édition savante.

En juin 2020, UC a annoncé ce qui était alors le plus grand accord de libre accès en Amérique du Nord, un accord de lecture et de publication avec Springer Nature (Brainard 2020). Jeffrey MacKie-Mason, bibliothécaire universitaire de l'UC Berkeley, a noté que le simple fait d'obtenir un engagement de Springer Nature à explorer ce type d'accord était un énorme pas en avant pour libre accès (Brainard 2020).

La décision d'UC de se retirer de la table de négociation avec Elsevier en février 2019 a également été considérée comme un moment important dans le passage à libre accès, en particulier en Amérique du Nord, car UC a la taille et le poids pour créer un précédent pour d'autres négociations de licence (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La rupture entre Elsevier et l'University of California|La rupture entre Elsevier et l'University of California]]&amp;#8239;»]).

==Ouvrages Citées==
*Aiwuyor, Jessica. 2021. «&amp;#8239;ARL Statement on New Transformative Publishing Agreement between the University of California and Elsevier&amp;#8239;». 16 mars 2021. [https://www.arl.org/news/arl-statement-on-new-transformative-publishing-agreement-between-the-university-of-california-and-elsevier/ https://www.arl.org/news/arl-statement-on-new-transformative-publishing-agreement-between-the-university-of-california-and-elsevier/].

*Berghahn Books. 2020. «&amp;#8239;Berghahn Open Anthro&amp;#8239;». [https://www.berghahnjournals.com/page/berghahn-open-anthro https://www.berghahnjournals.com/page/berghahn-open-anthro].

*Brainard, Jeffrey. 2020. «&amp;#8239;Huge Open-Access Journal Deal Inked by University of California and Springer Nature&amp;#8239;». 16 juin 2020. [https://www.sciencemag.org/news/2020/06/huge-open-access-journal-deal-inked-university-california-and-springer-nature https://www.sciencemag.org/news/2020/06/huge-open-access-journal-deal-inked-university-california-and-springer-nature].

*cOAlition S. 2020. «&amp;#8239;Transformative Agreements: Frequently Asked Questions&amp;#8239;». 8 avril 2020. [https://www.coalition-s.org/transformative-journals-faq/ https://www.coalition-s.org/transformative-journals-faq/].

*De Gruyter. 2021. «&amp;#8239;Subscribe to Open&amp;#8239;». [https://www.degruyter.com/cms/pages/subscribe-to-open https://www.degruyter.com/cms/pages/subscribe-to-open].

*EASC. n.d. «&amp;#8239;Transformative Agreements&amp;#8239;». [https://esac-initiative.org/about/transformative-agreements/ https://esac-initiative.org/about/transformative-agreements/].

*EASC. 2020. «&amp;#8239;How Transformative Agreements are Enabling the Open Access Transition&amp;#8239;». 24 mars 2020. [https://esac-initiative.org/transformative-agreements-enable-oa-transition/ https://esac-initiative.org/transformative-agreements-enable-oa-transition/].

*EDP Sciences. 2020. «&amp;#8239;Mathematical Modelling of Natural Phenomena Transitions to Open Access Under the Subscribe to Open Model&amp;#8239;».  5 mars 2020. [https://www.edpsciences.org/en/news-highlights/2002-mathematical-modelling-of-natural-phenomena-transitions-to-open-access-under-the-subscribe-to-open-model https://www.edpsciences.org/en/news-highlights/2002-mathematical-modelling-of-natural-phenomena-transitions-to-open-access-under-the-subscribe-to-open-model].

*EDP Sciences. 2020a. «&amp;#8239;Jisc and EDP Sciences Conclude a ‘Flexible Maths Journals Agreement 2021–2023&amp;#8239;». 10 novembre 2020. [https://www.edpsciences.org/en/news-highlights/2194-jisc-and-edp-sciences-conclude-a-flexible-maths-journals-agreement-2021-2023 https://www.edpsciences.org/en/news-highlights/2194-jisc-and-edp-sciences-conclude-a-flexible-maths-journals-agreement-2021-2023].

*Eve, Martin Paul. 2018. «&amp;#8239;How Learned Societies Could Flip to Open Access, with No Author-Facing Charges, using a Consortial Model&amp;#8239;». 21 janvier 2018. [https://eve.gd/2018/01/21/how-learned-societies-could-flip-to-oa-using-a-consortial-model/ https://eve.gd/2018/01/21/how-learned-societies-could-flip-to-oa-using-a-consortial-model/].

*Frontiers. 2020. «&amp;#8239;Current Transformative Agreements are not Transformative&amp;#8239;». ''Frontiers Science News''. 10 mars 2020. [https://blog.frontiersin.org/2020/03/10/current-transformative-agreements-are-not-transformative/ https://blog.frontiersin.org/2020/03/10/current-transformative-agreements-are-not-transformative/].

*Grove, Jack. 2020. «&amp;#8239;Wiley Strikes ‘Read-and-Publish’ Deal with UK Universities&amp;#8239;». 2 mars 2020. ''Times Higher Ed''. [https://www.timeshighereducation.com/news/wiley-strikes-read-and-publish-deal-uk-universities?utm_source=THE+Website+Users&amp;utm_campaign=e34aa710c9-EMAIL_CAMPAIGN_2020_03_02_01_10&amp;utm_medium=email&amp;utm_term=0_daa7e51487-e34aa710c9-67673409 https://www.timeshighereducation.com/news/wiley-strikes-read-and-publish-deal-uk-universities?utm_source=THE+Website+Users&amp;utm_campaign=e34aa710c9-EMAIL_CAMPAIGN_2020_03_02_01_10&amp;utm_medium=email&amp;utm_term=0_daa7e51487-e34aa710c9-67673409].

*Hinchliffe, Lisa Janicke. 2019. «&amp;#8239;Transformative Agreements: A Primer&amp;#8239;». ''The Scholarly Kitchen''. 2 avril 2019. [https://scholarlykitchen.sspnet.org/2019/04/23/transformative-agreements/ https://scholarlykitchen.sspnet.org/2019/04/23/transformative-agreements/].

*Hinchliffe, Lisa Janicke. 2020. «&amp;#8239;Seeking Sustainability: Publishing Models for an Open Access Age&amp;#8239;». ''The Scholarly Kitchen''. 7 avril 2020. [https://scholarlykitchen.sspnet.org/2020/04/07/seeking-sustainability-publishing-models-for-an-open-access-age/ https://scholarlykitchen.sspnet.org/2020/04/07/seeking-sustainability-publishing-models-for-an-open-access-age/].

*Hinchliffe, Lisa Janicke. 2020a. «&amp;#8239;Subscribe to Open: A Mutual Assurance Approach to Open Access&amp;#8239;». ''The Scholarly Kitchen''. 9 mars 2020. [https://scholarlykitchen.sspnet.org/2020/03/09/subscribetoopen/?informz=1 https://scholarlykitchen.sspnet.org/2020/03/09/subscribetoopen/?informz=1].

*Hinchliffe, Lisa Janicke. 2020b. «&amp;#8239;The ‘Pure Publish’ Agreement&amp;#8239;». ''The Scholarly Kitchen''. 20 février 2020. [https://scholarlykitchen.sspnet.org/2020/02/20/pure-publish/ https://scholarlykitchen.sspnet.org/2020/02/20/pure-publish/].

*Jisc. 2020. «&amp;#8239;Jisc, UK institutions and Wiley Agree Ground-Breaking Deal&amp;#8239;». 2 mars 2020. [https://www.jisc.ac.uk/news/jisc-uk-institutions-and-wiley-agree-ground-breaking-deal-02-feb-2020 https://www.jisc.ac.uk/news/jisc-uk-institutions-and-wiley-agree-ground-breaking-deal-02-feb-2020].

*Michael, Ann. 2019. «&amp;#8239;Subscribe to Open: Annual Reviews’ Take on Open Access&amp;#8239;». ''The Scholarly Kitchen''. 2 avril 2019. [https://scholarlykitchen.sspnet.org/2019/04/02/subscribe-to-open/ https://scholarlykitchen.sspnet.org/2019/04/02/subscribe-to-open/].

*PLOS. 2020. «&amp;#8239;PLOS and the University of California Announce Open Access Publishing Agreement&amp;#8239;». ''PLOS Blogs''. 19 février 2020. [https://theplosblog.plos.org/2020/02/plos-and-the-university-of-california-announce-open-access-publishing-agreement/ https://theplosblog.plos.org/2020/02/plos-and-the-university-of-california-announce-open-access-publishing-agreement/].

*Pooley, Jefferson. 2021. «&amp;#8239;Read-and-Publish Open Access Deals are Heightening Global Inequalities in Access to Publication&amp;#8239;». 21 février 2020. [https://blogs.lse.ac.uk/impactofsocialsciences/2020/02/21/read-and-publish-open-access-deals-are-heightening-global-inequalities-in-access-to-publication/ https://blogs.lse.ac.uk/impactofsocialsciences/2020/02/21/read-and-publish-open-access-deals-are-heightening-global-inequalities-in-access-to-publication/].

*RCDR (Réseau canadien de documentation pour la recherche). 2021. Le Résearu canadien de documentation pour la recherche annonce un accord transformatif avec SAGE&amp;#8239;».  23 février 2021. [https://www.crkn-rcdr.ca/fr/le-reseau-canadien-de-documentation-pour-la-recherche-annonce-un-accord-transformatif-avec-sage https://www.crkn-rcdr.ca/fr/le-reseau-canadien-de-documentation-pour-la-recherche-annonce-un-accord-transformatif-avec-sage].

*RCDR (Réseau canadien de documentation pour la recherche). n.d. ''Principes du programme de licences du RCDR''. [https://www.crkn-rcdr.ca/sites/crkn/files/2021-02/2021_CRKN_Principles_FR_FINAL.pdf https://www.crkn-rcdr.ca/sites/crkn/files/2021-02/2021_CRKN_Principles_FR_FINAL.pdf].

*University of California. 2021. «&amp;#8239;UC Secures Landmark Open Access Deal with World’s Largest Scientific Publisher&amp;#8239;». 16 mars 2021. [https://www.universityofcalifornia.edu/press-room/uc-news-uc-secures-landmark-open-access-deal-world-s-largest-scientific-publisher https://www.universityofcalifornia.edu/press-room/uc-news-uc-secures-landmark-open-access-deal-world-s-largest-scientific-publisher].

*Vernon, Anna. 2020. «&amp;#8239;The UK Wiley Read and Publish Agreement – Nine Months On&amp;#8239;». 25 septembre 2020. [https://www.jisc.ac.uk/blog/the-uk-wiley-read-and-publish-agreement-nine-months-on-25-sep-2020 https://www.jisc.ac.uk/blog/the-uk-wiley-read-and-publish-agreement-nine-months-on-25-sep-2020].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>nvwllbfbv3enw5jobmkdhr5cjzgm01j</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Semaine internationale du libre accès 2021, 25–31 octobre</title>
    <ns>0</ns>
    <id>82281</id>
    <revision>
      <id>745411</id>
      <parentid>745134</parentid>
      <timestamp>2025-06-26T19:08:02Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745411</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="9742" sha1="bhxujucv9fzr2co4xu79mo5ljab2qte" xml:space="preserve">''Cette observation a été rédigée par Caroline Winter (avec des remerciements à Inba Kehoe pour ses retours et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

La 14e Semaine internationale du libre accès se déroule du 25 au 31 octobre 2021 et le thème de cette année est «&amp;#8239;L'importance de notre façon d'ouvrir la connaissance : construisons l'équité structurelle&amp;#8239;». Ce thème a été choisi pour s'aligner sur [https://fr.unesco.org/node/319809 la recommandation de l'UNESCO sur la science ouverte] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|La Recommandation de l'UNESCO sur la science ouverte]]&amp;#8239;»), qui met en avant l'importance de l'équité dans l’avancement d'érudition qui est ouvert par défaut (Fandel 2021).

La Semaine de l'accès ouvert est organisée par [https://sparcopen.org/ SPARC], une organisation mondiale qui milite pour le libre accès, l'éducation ouverte et les données ouvertes. Il a commencé en 2008 comme un événement d'une journée et s'est depuis transformé en une célébration d'une semaine avec une portée mondiale. Les organisateurs soulignent que le plaidoyer en faveur de libre accès se déroule toute l'année, tout comme l'avancement de la diversité, de l'équité et de l'inclusion (Fandel).

Les tweets sur la Semaine internationale du libre accès peuvent être trouvés sur #OAWeek.

==La Semaine du libre accès 2021 et le partenariat INKE==
SPARC organise la Semaine du libre accès en consultation avec un conseil international qui comprend les membres du partenariat INKE Lise Brin, agente de programme avec [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC)], et Juan Pablo Alperin, directeur associé de la recherche avec [https://pkp.sfu.ca/ le Public Knowledge Project] à Simon Fraser Université (SFU).

[https://www.lib.sfu.ca/help/publish/scholarly-publishing/open-access/open-access-week Les bibliothèques de SFU] offrent un atelier aux étudiants diplômés sur la publication en ligne, et leur portail en ligne comprend des liens vers des documents des célébrations de la Semaine du libre accès des années précédentes, y compris un lien vers le film [https://paywallthemovie.com/paywall ''Paywall: the Business of Scholarship''] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Film Paywall : The Business of Scholarship|Le film ''Paywall : The Business of Scholarship'']]&amp;#8239;»]), une présentation par Jessie Loyer de 2019 intitulée [https://www.kpu.ca/library/Open_Access Can we Decolonize Open?], et une table ronde de 2018 intitulée [https://circuit.bcit.ca/repository/islandora/object/repository%3A1406 Open But Not Free: Invisible Labour in Open Scholarship].

L'ABRC organise une série de webinaires sur sa collaboration avec OpenAIRE, une initiative européenne d'infrastructure pour l’érudition ouverte, qui se concentre sur l'intégration et l'identification du contenu canadien. Le premier webinaire, qui aura lieu le 26 octobre, est [https://www.carl-abrc.ca/fr/mini-site-page/webinaire-oct2021-collaboration-abrc-openaire/ À la recherche d'une aiguille dans une botte de foin : Accroître la visibilité internationale de la recherche canadienne grâce à la collaboration entre l’ABRC et OpenAIRE].

La bibliothèque Leddy de l'Université de Windsor organise l'événement en ligne le 26 octobre avec INKE Partners [https://www.erudit.org/fr/ Érudit] et le PKP: [http://openaccessweek.org/events/open-access-publishing-and-coalition-publica-perspectives-from Open Access Publishing and Coalition Publica: Perspectives from Érudit, the Library, and a Journal Editor].

L'Electronic Textual Cultures Lab (ETCL) et les bibliothèques de l'Université de Victoria organisent une présentation en ligne par Nastasia Herold, wikipédienne résidente honoraire de l'UVic en 2021–2022, avec Thérèse Ottawa, [https://etcl.uvic.ca/2021/10/07/public-talk-ethics-and-responsibilities-of-open-access-and-its-realization-in-the-atikamekw-first-nations-wikipedia/ «&amp;#8239;Ethics and Responsibilities of Open Access and its Realization in the Atikamekw First Nation’s Wikipedia.&amp;#8239;»] La conférence aura lieu le mercredi 27 octobre et est gratuite et ouverte à tous.

En Australie, [https://oaaustralasia.org/ Open Access Australasia], l'un des partenaires d'INKE dans [https://inke.ca/canadian-australian-partnership-for-open-scholarship/ le Canadian–Australian Partnership for Open Scholarship (CAPOS)], organise une série d'événements en ligne pour célébrer la Semaine de libre accès :

* [http://openaccessweek.org/events/open-access-australasia-monday-session-a-1 Growing the Value of Research by Nurturing the Open Knowledge Ecosystem], 25 octobre
* [http://openaccessweek.org/events/open-access-australasia-tuesday-session-a Shaking up the Culture of Research Assessment], 26 octobre
* [http://openaccessweek.org/events/open-access-australasia-wednesday-session-a Open Across the Research Spectrum: What Different Disciplines can Learn from Each Other], 27 octobre
* [http://openaccessweek.org/events/open-access-australasia-wednesday-session-b How to Address Global Challenges with Open Science], 27 octobre
* [http://openaccessweek.org/events/open-access-australasia-thursday-session-a Indigenous Voices: Research Principles and Practice through a First Nations Lens], 28 octobre
* [http://openaccessweek.org/events/open-access-australasia-friday-session-a Another Kind of Open: Exploring the Benefits and Barriers to the Creation and Use of Open Education Resources], 29 octobre
* [http://openaccessweek.org/events/open-access-australasia-friday-session-b Making Research Truly Accessible: Insight Unshared is Thwarted Potential], 29 octobre

==Événements de l’intérêt pour La Semaine du libre accès en Canada et internationale==
En Canada, la bibliothèque de l’Université British Columbia (UBC) présente une série d’événements pour La Semaine de libre accès :
* [https://libcal.library.ubc.ca/event/3623290 Indigenous Knowledges and Open Education Symposium], 22 octobre
* [https://libcal.library.ubc.ca/event/3623293 Open and Equitable Publishing: Get to Know ICER Press!], 26 octobre
* [https://libcal.library.ubc.ca/event/3634105 Open 101 Workshop], 26 octobre
* [https://libcal.library.ubc.ca/event/3623299 OA Myth Busting Workshop], 27 octobre
* [https://libcal.library.ubc.ca/event/3623288 UBCO OER Grant Project Showcase], 28 octobre
* [https://libcal.library.ubc.ca/event/3619619 Creative Commons and Open Licensing in Practice], 29 octobre

La bibliothèque de l’UBC organise également plusieurs événements en novembre dans le cadre de sa série Open Scholarship in Practice :
* [https://libcal.library.ubc.ca/event/3615478 Creating Digital Exhibits: A Survey of Tools], 2 novembre
* [https://libcal.library.ubc.ca/event/3637545 Publishing in the Open: A Discussion on Open Access in Canada], 2 novembre
* [https://libcal.library.ubc.ca/event/3618806 Creative Commons and Copyleft Trolls], 3 novembre
* [https://libcal.library.ubc.ca/event/3615473 Open Scholarship in Practice – Faculty Lightning Talks], 3 novembre
* [https://libcal.library.ubc.ca/event/3637979 An Introduction to OSF], 3 novembre
* [https://libcal.library.ubc.ca/event/3641573 Past, Present, and Future: A Conversation on Open Access with Leslie Chan], 4 novembre
* [https://libcal.library.ubc.ca/event/3637415 Preparing and Preserving Your Research Outputs: Basics and Beyond], 4 novembre

En Royaume-Uni, la British Library organise une conférence en ligne en Open and Engaged le 25 octobre pour La Semaine du libre accès, [http://openaccessweek.org/events/open-and-engaged-2021-understanding-the-impact-of-open-in-the Understanding the Impact of Open in the Arts and Humanities Beyond the University].

[https://unfccc.int/fr/processus-et-reunions/les-conferences/conference-sur-les-changements-climatiques-a-glasgow La Conférence des Nations Unies sur les changements climatiques (COP 26)], que s’est tenue à Glasgow, accueillir une [http://openaccessweek.org/events/cop26-open-access-virtual-book-showcase Open Access Virtual Book Showcase] avec plus de 150 livres liés à la durabilité et au changement climatique, disponible du 28 octobre vers 22 novembre.

==La Semaine du libre accès et la science ouverte==
Libre acces est une élément important de la science ouverte et it fait partie de l’Open Agenda du SPARC, qui comprend également les données ouverte et l’éducation ouverte. Comme une évenement internationale qui faire prendre conscience de libre accès et le mouvement Libre plus largement, et une occasion de célebrér ses succès, La Semaine internationale du libre accès est une étape importante annuelle pour la science ouverte.

==Ouvrages citées==
*Fandel, Lese. 2021. «&amp;#8239;2021 Open Access Week Theme to be ‘It Matters How We Open Knowledge: Building Structural Equity’&amp;#8239;». ''International Open Access Week'', 12 aout 2021, [http://www.openaccessweek.org/profiles/blogs/2021-theme-announcement-english http://www.openaccessweek.org/profiles/blogs/2021-theme-announcement-french].

*Shockey, Nick. «&amp;#8239;Open Access Week Advisory Committee&amp;#8239;». ''International Open Access Week'', 25 mai 2018, [http://www.openaccessweek.org/profiles/blogs/advisory-committee http://www.openaccessweek.org/profiles/blogs/advisory-committee].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>bhxujucv9fzr2co4xu79mo5ljab2qte</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/État actuel de la gestion des données de recherche au Canada : un rapport par l’Alliance de recherche numérique du Canada</title>
    <ns>0</ns>
    <id>82353</id>
    <revision>
      <id>745412</id>
      <parentid>745136</parentid>
      <timestamp>2025-06-26T19:15:35Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>/* Éléments du soutien GDR au niveau national */</comment>
      <origin>745412</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="17244" sha1="t0b43xmclixpeox3ge9qhhphxveugjf" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec des remerciements á Shahira Khair pour ses commentaires et contributions) pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En septembre 2021, [https://engagedri.ca/fr/ l’Alliance de recherche numérique du Canada] (récemment renommer de NOIRN, la Nouvelle organisation d'infrastructure de recherche numérique) a publié un rapport intitulé [https://engagedri.ca/assets/documents/NDRIO_GDR_E%CC%81xpose%CC%81deprincipe-1.pdf ''État actuel de la gestion des données de recherche au Canada : Mise à jour de l’éxposé de principe du CLIRN sur la gestion des données''] (2020). Il a été rédigé par le groupe de travail sur la gestion des données de la NOIRN : Shahira Khair, Rozita Dara, Susan Haigh, Mark Leggott, Ian Milligan, Jeff Moon, Karen Payne, Elodie Portales-Casamar, Ghilaine Roquet et Lee Wilson. 

Le rapport présente et contextualise la gestion des données de recherche (GDR) dans le cadre de la science ouverte et offre un résumé de l'état actuel du paysage de la GDR au Canada. Il examine également les supports GDR actuellement disponibles, analyse le paysage GDR national et évalue les capacités dans les domaines du stockage et du calcul, de l'interopérabilité, des services de données et de la gouvernance. Le rapport se termine en décrivant les principaux défis et opportunités et en exposant les prochaines étapes. 

L'objectif global du rapport est de positionner l'Alliance pour «&amp;#8239;lui permettre de miser sur les initiatives précédentes et actuelles, et de tracer une voie à suivre qui fera progresser la GDR en coordination avec d'autres éléments de l’IRN en vue de favoriser l'excellence nationale en recherche&amp;#8239;» (p. 8), en s'appuyant sur le [https://wiki.queensu.ca/download/attachments/135497883/DM%20ISED%20Report%20-%20Final.pdf?version=2&amp;modificationDate=1505740867000&amp;api=v2 ''Data Management Position Paper''] (2017) et [https://doi.org/10.5281/zenodo.3574712 ''La gestion des données de recherche au Canada : état des lieux''] (2019). 

Le rapport identifie les principaux avantages de la GDR, y compris le partage et la réutilisation des données, comme 
* accélérer la recherche et la rendre plus efficace, par exemple lorsque les données peuvent être partagées et réutilisées plutôt que générées à nouveau 
* permettre et encourager la collaboration entre les chercheurs, en particulier lorsque les données sont interopérables, et par le partage d'outils et d'autres ressources ainsi que des données 
* augmenter l'impact de la recherche, notamment en rendant les données plus découvrables et accessibles 
* permettre la reproductibilité de la recherche, et ainsi accroître sa fiabilité, y compris auprès du public (p. 12–14) 

Le rapport souligne également que l'accent mis sur l'ouverture et le respect [https://www.go-fair.org/fair-principles/ des principes FAIR] doit être équilibré avec le respect de la souveraineté des données autochtones, qui «&amp;#8239;reconnaît les droits inhérents des communautés autochtones à gouverner la collecte, l’appropriation et l'utilisation de leurs propres données&amp;#8239;» (p. 17). En plus des [https://www.gida-global.org/care CARE Principles for Indigenous Data Governance], qui traitent des valeurs bénéfice Collectif, Autorité de contrôle, Responsabilité et Éthique et complètent les Principes FAIR (GIDA s.d.), d'autres principes de gouvernance des données autochtones ont été affirmés (p. 17). [https://fnigc.ca/fr/les-principes-de-pcap-des-premieres-nations/ Les principes de PCAP®] traitent « de propriété, de contrôle, d’accès et de possession » et ont été élaborés par les communautés des Premières Nations (CGIPN 2021). La Manitoba Métis Federation souscrit aux principes de l'OCAS, qui comprennent la propriété, le contrôle, l'accès et l’intendance (University of Manitoba s.d.). Le Qaujimajatuqangit inuit (QI) comprend six concepts qui s'appliquent aux données inuites et comprennent les concepts de service, de prise de décision par consensus, d'acquisition de compétences et de connaissances, de collaboration, de gérance de l'environnement et d'ingéniosité dans la résolution de problèmes (Tagalik s.d.). Le respect de la souveraineté des données autochtones et ces ensembles de principes sont des préoccupations clés pour les meilleures pratiques de GDR, pour la science ouverte en général et pour soutenir la réconciliation au Canada. 

==Le paysage actuel de la GDR au Canada==
En interrogeant les organisations soutenant la GDR au Canada qui constituent la base des services nationaux de GDR de l'Alliance, le rapport met en évidence le travail essentiel qui continue d'être effectué par [https://www.rdc-drc.ca/fr/ Données de recherche Canada (DRC)], notamment en soutenant la collaboration «&amp;#8239;entre les organismes de financement de la GDR et de l’IRN&amp;#8239;» et «&amp;#8239;entre les initiatives canadiennes et mondiales de science ouverte&amp;#8239;» (p. 23). Il met également en évidence le réseau Portage et ses initiatives, y compris [https://assistant.portagenetwork.ca/ l'Assistant PGD] (plans de gestion des données), dirigé par Réseau Portage, [https://www.frdr-dfdr.ca/repo/?locale=fr le Dépôt fédéré de données de recherche (DFDR)], l'instance du [https://dataverse.scholarsportal.info/fr/ Scholars Portal Dataverse] et [https://www.crkn-rcdr.ca/fr/consortium-datacite-canada le consortium DataCite Canada] (pp. 23–24). 

De plus, le rapport reconnaît que de nombreux acteurs du «&amp;#8239;paysage décentralisé&amp;#8239;» (p. 22) actuel offrent des services et soutiens permettant la GDR, que l'Alliance doit prendre en considération. Le rapport donne un aperçu du paysage de la GDR au Canada, reconnaissant qu'il est trop complexe pour fournir une image complète. Cet instantané comprend sept secteurs : 
* l'enseignement supérieur 
* organismes de recherche (souvent hébergés par des universités et des instituts de recherche) 
* organismes de financement de la recherche 
* éditeurs savants 
* organisations adjacentes au milieu universitaire (par exemple, les centres de recherche gouvernementaux, les autorités sanitaires, l'industrie, et les galeries, bibliothèques, archives et musées, ou « GLAM ») 
* prestataires de services tiers 
* organisations internationales (par exemple, organisations gouvernementales nationales, associations internationales) 

Dans le secteur de l'enseignement supérieur, par exemple, le paysage GDR comprend des chercheurs (dont beaucoup utilisent la recherche des centres de recherche gouvernementaux, des institutions GLAM et d'autres organisations adjacentes aux universités) et les départements et facultés au sein desquels ils travaillent, les systèmes et les départements informatiques qui fournissent l'infrastructure (qui est parfois complétée par des prestataires de services tiers), les bureaux de recherche qui établissent des politiques institutionnelles et aident les chercheurs à se conformer aux politiques des organismes de financement de la recherche (par exemple, [https://www.science.gc.ca/eic/site/063.nsf/fra/h_97610.html la Politique des trois organismes sur la gestion des données de recherche]), et les bibliothèques et archives institutionnelles qui sont de plus en plus offrant un support et une infrastructure GDR, tels que des dépôts institutionnels. Dans le secteur de l'enseignement supérieur se trouvent également des organisations qui fournissent des infrastructures et des services pour soutenir ou activer la GDR, notamment [https://www.computecanada.ca/?lang=fr Calcul Canada] et [https://www.canarie.ca/fr/rnre/ le Réseau national de la recherche et de l’éducation (RNRE)], et des consortiums de bibliothèques régionaux tels que [https://coppul.ca/ le Council of Prairie and Pacific University Libraries (COPPUL)]. Le secteur des maisons d’édition savante aide à diffuser et à promouvoir les résultats des chercheurs, et les éditeurs développent de plus en plus leurs propres politiques et services GDR, en lien avec le mouvement plus large vers le libre accès. Toutes ces activités se déroulent au Canada au sein d'un écosystème mondial de recherche et d'érudition. 

Le rapport note qu'une meilleure compréhension du paysage des organismes de recherche et de leurs relations entre ses secteurs et ses parties prenantes est nécessaire, tout comme une meilleure compréhension du domaine émergent des services et des politiques de GDR des éditeurs. 

==Éléments du soutien GDR au niveau national==
En plus de présenter un instantané du paysage GDR, le rapport classe également les éléments clés requis pour le support GDR au niveau national : stockage et calcul, interopérabilité, services de données et gouvernance. 

L'éléments de stockage et de calcul prend en charge GDR tout au long du cycle de vie des données. Les dépôts institutionnels et thématiques jouent un rôle important dans le stockage et l'accès aux données de recherche, y compris les dépôts fédérés tels que Scholars Portal Dataverse et le DFDR. Le manque de financement stable rend la durabilité à long terme et l'archivage un défi particulier, cependant, en particulier pour les dépôts spécifiques à un domaine ou à un groupe de recherche plus petits. 

L'élément d'interopérabilité de l'écosystème RDM dépend de normes, de schémas, de politiques et de protocoles communs pour travailler avec les données, y compris les principes FAIR. Il s'étend également aux éléments d'infrastructure tels que les normes et les certifications, ainsi qu'à l'identification et à l'accès, qui incluent les identifiants permanents (IP) tels que [https://orcid.org/ ORCID] et [https://datacite.org/ DataCite] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/ORCID : Connecter la recherche et les chercheurs|ORCID : Connecter la recherche et les chercheurs]]&amp;#8239;», «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche|Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Persistent Identifier (PID) Consortium de Royaume-Uni|Le «&amp;#8239;Persistent Identifier (PID) Consortium&amp;#8239;» de Royaume-Uni]]&amp;#8239;»). 

Les services de données se sont développés en réponse aux besoins des chercheurs et sont fournis par des institutions, des associations et des fournisseurs commerciaux pour traiter la GDR à toutes les étapes du cycle de vie de la recherche. Les exemples incluent l'assistant PGD, les dépôts pour la conservation des données pris en charge par les services informatiques et les bibliothécaires de données, la préservation des données grâce à des modèles de support développés par des consortiums de bibliothèques et des outils de découverte et d'exploration tels que le DFDR. La nature de plus en plus axée sur les données de la recherche a révélé un écart de formation aux compétences numériques, un écart que les institutions, les bibliothèques universitaires et les associations de recherche peuvent tous contribuer à combler. 

En termes de gouvernance, le rapport note que l'environnement politique concernant la GDR et les questions connexes devient de plus en plus complexe. Cet écosystème comprend des politiques nationales telles que la politique des trois organismes sur la GDR, les politiques institutionnelles et les politiques des éditeurs, et d'autres (voir «&amp;#8239;[[Extension : Observatoire des politiques sur les savoirs ouverts, 2021-2024/Mise à jour : Gestion des données de recherche au Canada|Mise à jour : Gestion des données de recherche au Canada]]&amp;#8239;]). Des outils et des ressources ont été développés par des organismes de recherche nationaux en réponse aux besoins des membres, mais les ressources et les pratiques varient considérablement selon les régions et les domaines de recherche, tout comme les politiques liées à la GDR.

==Défis et prochaines étapes==
Le rapport identifie trois défis et opportunités clés auxquels l'Alliance est confrontée pour soutenir la GDR au niveau national : la coordination, la représentation et l'inclusion, et la durabilité. La coordination comprend la poursuite du travail d'intégration d'éléments dans le paysage existant, y compris les membres de la communauté GDR, à travers les distances géographiques et disciplinaires. La représentation et l'inclusion comprennent la sensibilisation et l'adoption de la GDR et de ses meilleures pratiques dans l'ensemble de la communauté des chercheurs, en accordant une attention aux communautés sous-représentées. La durabilité implique la construction de partenariats et de collaborations solides ainsi que les systèmes techniques nécessaires à la préservation des données. Sa structure de financement stable permettra à l'Alliance de résoudre certains des problèmes de durabilité soulevés par les scénarios de financement ad hoc et à court terme existants afin d'optimiser l'écosystème GDR existant. 

==Le rapport et le Partenariat INKE==
Le rapport note que le paysage de la GDR au Canada s'est développé en grande partie grâce au travail d'organisations nationales, notamment [https://www.canarie.ca/fr/ CANARIE], DRC, Portage et [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC)], un partenaire d'INKE. Il souligne le succès de Portage dans la coordination du développement d'outils, de plateformes et de services de sa communauté pour soutenir la GDR. En avril 2021, Portage s'est pleinement intégrée à l'Alliance. 

Le rapport met également en évidence les rôles des autres partenaires INKE dans le paysage canadien de la GDR. Dans sa discussion sur la contribution des organismes de recherche, il met l'accent sur [https://www.coalition-publi.ca/le-projet Coalition Publica], une infrastructure de publication en libre accès développée par les partenaires d'INKE [https://www.erudit.org/fr/ Érudit] et [https://pkp.sfu.ca/ le Public Knowledge Project]. Il met aussi en lumière le projet [https://co-shs.ca/fr/ CO.SHS] d'Érudit, une infrastructure ouverte pour la production, la découverte et l'exploration de la recherche en sciences humaines et sociales. 

==Le rapport et la science ouverte==
Le rapport note que le GDR est « ancrés dans le mouvement de science ouverte qui présente une vision de découvertes et de progrès scientifiques accélérés, facilités par de nouvelles technologies d’information qui permettront le partage ouvert et accessible des publications, des résultats et des données de recherche dans le cadre d’un nouveau contrat social pour la science&amp;#8239;» (p. 16), notant que «&amp;#8239;science&amp;#8239;» désigne ici l'érudition dans son ensemble, y compris les sciences humaines et sociales. En particulier, les pratiques de GDR fondées sur les principes FAIR permettent la découverte et l'accessibilité essentielles à la science ouverte. 

==Ouvrages cités==
*CGIPN (Le Centre de gouvernance de l’information des Premières Nations). 2021. ''Les principes de PCAP® des Premières Nations''. [https://fnigc.ca/fr/les-principes-de-pcap-des-premieres-nations/ https://fnigc.ca/fr/les-principes-de-pcap-des-premieres-nations/]. 

*GIDA (Global Indigenous Data Alliance). s.d. ''CARE Principles for Indigenous Data Governance''. [https://www.gida-global.org/care https://www.gida-global.org/care]. 

*Khair, Shahira, Rozita Dara, Susan Haigh, Mark Leggott, Ian Milligan, Jeff Moon, Karen Payne, Elodie Portales-Casamar, Ghilaine Roquet et Lee Wilson. 2020, Novembre. ''État actuel de la gestion des données de recherche au Canada : Mise à jour de l’exposé de principe du CLIRN sur la gestion des données''. [https://engagedri.ca/assets/documents/NDRIO_GDR_E%CC%81xpose%CC%81deprincipe-1.pdf https://engagedri.ca/assets/documents/NDRIO_GDR_E%CC%81xpose%CC%81deprincipe-1.pdf]. 

*Tagalik, Shirley. s.d. Inuit Qaujimajatuqangit: ''The Role of Indigenous Knowledge in Supporting Wellness in Inuit Communities in Nunavut''. National Collaborating Centre for Aboriginal Health. [https://www.ccnsa-nccah.ca/docs/health/FS-InuitQaujimajatuqangitWellnessNunavut-Tagalik-EN.pdf https://www.ccnsa-nccah.ca/docs/health/FS-InuitQaujimajatuqangitWellnessNunavut-Tagalik-EN.pdf]. 

*University of Manitoba Faculty of Health Sciences. s.d. ''Framework for Research Engagement with First Nation, Metis, and Inuit Peoples''. [https://umanitoba.ca/faculties/health_sciences/medicine/media/UofM_Framework_Report_web.pdf https://umanitoba.ca/faculties/health_sciences/medicine/media/UofM_Framework_Report_web.pdf].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>t0b43xmclixpeox3ge9qhhphxveugjf</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les Fonds de recherche du Québec rejoignent la cOAlition S</title>
    <ns>0</ns>
    <id>82354</id>
    <revision>
      <id>745413</id>
      <parentid>745138</parentid>
      <timestamp>2025-06-26T19:16:19Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745413</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="9730" sha1="bv36noeacdtvep9qklf9uag624jy01f" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec remerciements à Tanja Niemann et Simon Van Bellen pour ses commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En juin 2021, [https://frq.gouv.qc.ca/ les Fonds de recherche du Québec (FRQ)] ont annoncé qu’ils se joignent a la [https://www.coalition-s.org/about/ cOAlition S] et mettaient en oeuvre les principes du [https://www.coalition-s.org/why-plan-s/ Plan S], y compris libre accès complets et immédiat à tous la recherche qu’ils financent.

Les FRQ sont le premier organisme de financement canadien et le premier organisme de financement public en Amérique du Nord à se joindre à cOAlition S, qui a été fondée en 2018 en tant que groupe de 11 organismes de financement européens engagés à faire progresser libre accès, soutenu par le Conseil européen de la recherche et la Commission européenne (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;»). Il s'est depuis élargi pour inclure des membres d'Afrique, du Moyen-Orient et des États-Unis (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche|Mise à jour du Plan S : l'élargissement de l'adhésion de la cOAlition S]]&amp;#8239;»).

Les FRQ comprendre les trois organismes subventionnaires de la recherche au Québec : [https://frq.gouv.qc.ca/nature-et-technologies/ Nature et technologies (FRQNT)], [https://frq.gouv.qc.ca/sante/ Santé (FRQS)] et [https://frq.gouv.qc.ca/societe-et-culture/ Société et culture (FRQSC)]. Représentant près du quart de la communauté de recherche au Canada, les FRQ ont administré 253 millions de dollars en financement de recherche en 2019-2020 à des chercheurs basés au Québec (Fondation européenne de la science, 2021). Les FRQ offrent également un Programme de soutien aux revues scientifiques, qui soutient la publication de recherches savantes en français, avec une priorité à la publication numérique et en libre accès (FRQ 2021). Leur [https://frq.gouv.qc.ca/app/uploads/2021/04/politique-libre-acces_avril19.pdf politique de libre accès existante], en place depuis 2019, exige que les publications soient en libre accès dans les 12 mois suivant la publication ; afin d'aligner cette politique sur le Plan S, à compter de mars 2023, cette période d'embargo sera supprimée (Gouvernement du Québec, 2021).

==Réponse de la communauté INKE==
Plan S et cOAlition S intéressent la communauté INKE depuis leur lancement, en reconnaissance de la nature mondiale de la science ouverte. Dans son rapport de 2020 ''Advancing Open: points de vue des spécialistes de la communication savante'', le groupe de travail sur les dépôts ouverts de l'Association des bibliothèques de recherche du Canada (ABRC), un partenaire d'INKE, exprime ses inquiétudes quant à la volonté du Canada d'adopter un «&amp;#8239;modèle transformateur de science ouverte&amp;#8239;» tel que le Plan S (MacCallum et al. 8). Le délai prolongé des FRQ pour lever leur période d'embargo – près de deux ans plutôt que la période habituelle – semble toutefois répondre à cette préoccupation. Comme le note le communiqué des FRQ, «&amp;#8239;Conscients des impacts que ce changement pourrait engendrer dans la communauté scientifique et étudiante, les FRQ déploieront graduellement les dix principes du Plan S et planifieront des mesures pour les accompagner&amp;#8239;» (Fondation européenne de la science 2021 ; Gouvernement du Québec 2021).

[https://www.erudit.org/fr/ Érudit], un partenaire d'INKE, collabore avec le FRQSC depuis 2006. Conformément à la politique du FRQ en libre accès, toutes les revues financées par le FRQSC sont en libre accès via Érudit (Érudit 2021).

==Les FRQ, la cOAlition S et la science ouverte==
En tant que premier organisme de financement canadien à se joindre à la cOAlition S, les FRQ ouvrent la voie à d'autres bailleurs de fonds publics canadiens et nord-américains pour se joindre au Plan S, qui est devenu une initiative mondiale.

Bien que la recherche financée par les FRQ ne soit pas nécessairement publiée en français, son adhésion au Plan S s'inscrit dans le cadre d'autres initiatives menées par le scientifique en chef du Québec, dont le lancement d'un [https://www.scientifique-en-chef.gouv.qc.ca/dossiers/conseil-scientifique-aux-gouvernements/reseau-francophone-en-conseil-scientifique/ réseau francophone] sur les avis scientifiques pour les politiques publiques, annoncé en septembre 2021. Le rapport accompagnant le lancement de ce réseau note que la recherche en langue française doit être accessible en libre accès à tous les chercheurs francophones (Scientifique en chef 2021, 48).[https://frq.gouv.qc.ca/app/uploads/2021/04/politique-libre-acces_avril19.pdf  La politique libre accès des FRQ] soutient également la recherche en français comme l'un de ses principes fondamentaux (FRQ 2019).

La nouvelle des FRQ rejoignant la cOAlition a été [https://quebec.consulfrance.org/Engagement-du-Quebec-en-faveur-de-la-science-ouverte partagée sur le site Web du Consulat général de France à Québec], soulignant le fait que la politique française de libre accès est un autre contexte important pour la décision des FRQ. Lui-même adopté dans le contexte de cadres européens plus larges, dont Horizon Europe, [https://www.ouvrirlascience.fr/deuxieme-plan-national-pour-la-science-ouverte/ ''le Deuxième Plan national pour la science ouverte : généraliser la science ouverte en France 2021-2024''] étend le premier plan de 2018 pour inclure le code ouvert, l'infrastructure pour soutenir le partage de données, et un accent mis sur la généralisation plus large du libre accès, notamment par la traduction de publications françaises pour améliorer leur accessibilité. Comme indiqué dans un article du [https://www.timeshighereducation.com/news/france-back-not-profit-diamond-journals ''Times Higher Ed''], cet Deuxième Plan est l'une des nouvelles politiques nationales visant à mettre l'accent sur le soutien à libre accès diamant, dans laquelle les revues ne facturent pas de frais de traitement d'article ni de frais d'abonnement (Matthews 2021). [https://anr.fr/fr/ L'Agence nationale de la recherche (ANR)], l'organisme national de financement de la recherche en France, est membre de la cOAlition S depuis sa création, et de nombreux chercheurs français publient probablement dans les revues francophones du Québec.

==Ouvrages citées==
*Érudit. 2021. ''Annual Report 2020–2021: Érudit Consortium''. [https://www.erudit.org/public/documents/AnnualReport_20-21.pdf https://www.erudit.org/public/documents/AnnualReport_20-21.pdf].

*Fondation européenne de la science. 2021. «&amp;#8239;cOAlition S Expands its Global Footprint as the Québec Research Funds adopt Plan S&amp;#8239;». ''Plan S: Making Full &amp; Immediate Open Access a Reality''. [https://www.coalition-s.org/coalition-s-expands-its-global-footprint-as-the-quebec-research-funds-adopt-plan-s/ https://www.coalition-s.org/coalition-s-expands-its-global-footprint-as-the-quebec-research-funds-adopt-plan-s/].

*FRQ (Fonds de recherche du Québec). 2019. ''Politique de diffusion en libre accès des Fonds de recherche du Québec''. Gouvernement du Québec, 15 avril 2019. [https://frq.gouv.qc.ca/app/uploads/2021/05/politique-libre-acces_en_avril19.pdf https://frq.gouv.qc.ca/app/uploads/2021/04/politique-libre-acces_avril19.pdf].

*FRQ (Fonds de recherche du Québec). 2021. ''Scientific Journal Support Program''. Gouvernement du Québec, mai 2021. [https://frq.gouv.qc.ca/app/uploads/2021/07/scientific-journal-support-program-frqsc.pdf https://frq.gouv.qc.ca/app/uploads/2021/07/scientific-journal-support-program-frqsc.pdf].

*Gouvernement du Québec. 2021. «&amp;#8239;Les Fonds de recherche du Québec appuient la science ouverte en joignant la cOAlition S&amp;#8239;». ''Québec'', 21 juin 2021. [https://www.scientifique-en-chef.gouv.qc.ca/nouvelles/les-fonds-de-recherche-du-quebec-appuient-la-science-ouverte-en-joignant-la-coalition-s/ https://www.scientifique-en-chef.gouv.qc.ca/nouvelles/les-fonds-de-recherche-du-quebec-appuient-la-science-ouverte-en-joignant-la-coalition-s/].

*MacCallum, Lindsey, Ann Barrett, Leah Vanderjagt et Amy Buckland. 2020. ''Advancing Open: points de vue de spécialistes de la communication savante''. Association des bibliothèques de recherche du Canada (ABRC), avril 2020, [https://www.carl-abrc.ca/wp-content/uploads/2020/04/GTDO_rapport3_Advancing_open_FR.pdf https://www.carl-abrc.ca/wp-content/uploads/2020/04/GTDO_rapport3_Advancing_open_FR.pdf].

*Matthews, David. 2021. «&amp;#8239;France to Back Not-for Profit Diamond Journals&amp;#8239;». ''Times Higher Ed'', 13 juillet 2021. [https://www.timeshighereducation.com/news/france-back-not-profit-diamond-journals https://www.timeshighereducation.com/news/france-back-not-profit-diamond-journals].

*Scientifique en chef du Québec. 2021. ''Vers un résearu francophone pour l’utilisation des science en soutien aux politiques publiques: Document pour consultation''. Gouvernement du Québec, septembre 2021. [https://www.scientifique-en-chef.gouv.qc.ca/wp-content/uploads/ConseilSci_Francophonie_version_Sept2021.pdf https://www.scientifique-en-chef.gouv.qc.ca/wp-content/uploads/ConseilSci_Francophonie_version_Sept2021.pdf].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>bv36noeacdtvep9qklf9uag624jy01f</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Renforcement des capacités de GDR au Canada et la série de rapports Insights de Portage</title>
    <ns>0</ns>
    <id>82355</id>
    <revision>
      <id>745414</id>
      <parentid>745139</parentid>
      <timestamp>2025-06-26T19:25:31Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745414</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22399" sha1="1cpf9u59hfo3977tps1esfe5g6c49tw" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec remerciements à Shahira Khair pour ses commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En mai 2018, les trois organismes du Canada ont publié une ébauche d’un Politique de gestion des données de recherche (GDR) aux fins de consultation, l'une des nombreuses politiques liées à la gestion des données, y compris la [https://www.science.gc.ca/eic/site/063.nsf/fra/h_F6765465.html Politique des trois organismes sur le libre accès aux publications] (2015) et la [https://www.science.gc.ca/eic/site/063.nsf/fra/h_83F7624E.html Déclaration de principes des trois organismes sur la gestion des données numériques] (2016) (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le politique des trois organismes sur la gestion des données de recherche|Le Politique des trois organismes sur la gestion des données de recherche]]&amp;#8239;»). La version finale de la [https://www.science.gc.ca/eic/site/063.nsf/fra/h_97610.html Politique des trois organismes sur la GDR] a été publiée en mars 2021 (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Mise à jour : Gestion des données de recherche au Canada|Mise à jour : Gestion des données de recherche au Canada]]&amp;#8239;»).

En vertu de la politique, les établissements de recherche qui administrent les fonds des trois organismes sont tenus d'élaborer des stratégies de GDR d'ici le 1er mars 2023 (Gouvernement du Canada 2021). Alors que les établissements commençaient à élaborer leurs politiques de GDR en réponse à l'ébauche de politique des trois organismes, le Groupe d'experts sur la recherche et l’intelligence (GERI) du réseau Portage a mené deux sondages pour déterminer dans quelle mesure les établissements étaient prêts à mettre en œuvre la Politique de GDR et quels services Portage et d'autres intervenants pourraient offrir en soutien.

==Sondage sur la stratégie institutionnelle de GDR==
Le [https://doi.org/10.5281/zenodo.3962885 sondage sur la stratégie institutionnelle de GDR de Portage] (Portage 2019) a été mené en juin 2019 et a reçu 88 réponses de 63 établissements. Il a révélé que la plupart des établissements répondants avaient entamé le processus d'élaboration d'une stratégie institutionnelle de GDR, même si bon nombre d'entre eux en étaient au stade de la planification. Parmi ceux-ci, beaucoup ont noté que le développement a l’arrêt, en attendant la publication de la politique finale de GDR des trois organismes. Sur la base des réponses à l'enquête, le GERI a suggéré des mesures à prendre pour aider les établissements à développer leurs stratégies, notamment en partageant les stratégies finales pour servir d'exemples, en facilitant les communautés de pratique pour aider les groupes de travail institutionnels à apprendre les uns des autres et en fournissant des conseils explicites sur la manière dont stratégies peuvent répondre aux exigences de la politique des trois organismes.

==L'enquête sur la capacité des services GDR institutionnels et les rapports d'analyse==
À l'automne 2019, le GERI a mené le ''Sondage sur la capacité des services institutionnels de gestion des données'' afin d'établir une référence pour la capacité des établissements de recherche au Canada à soutenir les activités de GDR décrites dans l'ébauche de la politique de GDR des trois organismes (Cooper et al. 2020). Il a reçu 85 réponses de 77 établissements, dont des universités, des collèges, des CEGEPs, des centres et établissements de recherche et des organismes gouvernementaux (2). Un résumé analytique a été publié en janvier 2020 (Cooper et al. 2020).

[https://doi.org/10.5281/zenodo.3906470 Le premier rapport Insights], publié en juin 2020, s'est concentré sur la capacité au sein des organisations, avec des conclusions clés liées à la politique, aux structures organisationnelles, aux budgets et aux collaborations internes et externes (Abel et al., 3). S'appuyant sur les résultats discutés dans le rapport initial, il a noté que les bibliothèques et les unités administratives de la recherche dirigeaient le plus souvent l'élaboration de stratégies et de politiques de GDR dans les universités et les collèges (4). En ce qui concerne les structures de travail, environ la moitié des établissements (principalement des universités) avaient des groupes de travail institutionnels formels sur la GDR, la plupart dirigés par des bibliothèques ou des groupes d'administration de la recherche (8).

En termes de structure de personnel, environ le tiers (33,8 %) des établissements, principalement des universités, avaient créé de nouveaux postes pour assumer des responsabilités de GDR et un peu moins du tiers (28,6 %) avaient réaffecté du personnel existant pour les assumer, mais un peu plus du tiers (37,7 %) n'avaient pas de personnel responsable de la GDR (9). Bien que le financement soit crucial pour le développement des capacités, une seule institution a fait état d'un budget institutionnel dédié à la GDR ; la forme de financement la plus courante consistait à utiliser les budgets opérationnels (27,3 %) et de nombreux établissements (37,7 %) ont déclaré ne pas avoir de budget dédié à la GDR (15–16). La plupart des établissements ont participé à des initiatives collaboratives nationales (65,6 %) ou régionales (72,1 %) de GDR (13).

[https://doi.org/10.5281/zenodo.4559991 Le deuxième rapport Insights], publié en février 2021, se concentre sur le personnel hautement qualifié (PHQ), l'infrastructure et les services (Cooper et al. 2021a). Il a examiné l'expertise en GDR dans 12 catégories de compétences (par exemple, la connaissance des politiques nationales, le développement de logiciels, la gestion des données, la création de métadonnées), organisées en étapes du cycle de vie des données, comme décrit dans [https://doi.org/10.5281/zenodo.4015589 ''L'introduction à gestion des données de recherche de Portage'']. Il a constaté que les universités avaient tendance à faire état d'une plus grande capacité que les collèges dans plusieurs catégories et que les établissements exprimaient le besoin d'un soutien plus qualifié dans toutes les catégories, avec un besoin particulier «&amp;#8239;en gestion des données sensibles, en curation de données, en développement de logiciels de recherche, en préservation des données, en gestion des données par les chercheurs et au regard des aspects techniques des infrastructures électroniques&amp;#8239;» (4). En termes d'infrastructure GDR, par rapport aux collèges, les universités ont signalé une plus grande connaissance et un soutien institutionnel pour le transfert de données (50 % ; 19 %), les données sensibles (40,4 % ; 33,3 %), le calcul haute performance (50 % ; 14,3 %) , logiciels commerciaux qualitatifs (55,8 % ; 28,6 %), logiciels quantitatifs (75 % ; 38,1 %) et outils de collaboration (26,9 % ; 9,5 %) (12–14). Dans de nombreux cas, cependant, les répondants ne savaient pas quels soutiens étaient disponibles.

En ce qui concerne les services de GDR, alors que plus de la moitié des répondants offrent une gamme complète de soutiens de GDR, l'étendue et le niveau de développement de ces services varient considérablement (16). Ces services sont généralement proposés au niveau institutionnel et dirigés par des bibliothèques, des départements informatiques ou des efforts conjoints (17–19). Les institutions avec des postes dédiés à la GDR et un soutien budgétaire dédié ont tendance à offrir davantage de soutiens institutionnels, tandis que celles dans lesquelles le soutien à la GDR est affecté à des postes existants ont tendance à faire appel à des ressources externes (20–21).

[https://doi.org/10.5281/zenodo.4892718 Le troisième rapport Insights], publié en février 2021 (Cooper et al. 2021b), examine quelles ressources GDR sont disponibles, comment elles sont allouées et comment elles pourraient mieux servir la communauté. Lorsqu'on leur a demandé de classer les ressources à privilégier pour soutenir la GDR, les répondants ont cité le plus souvent les ressources humaines (37,7 %), suivies des conseils sue les questions de politiques (22,1 %) et des ressources financières (16,9 %) et techniques (14,3 %) (5). En termes d'investissement, près de la moitié (46,8 %) des établissements n'avaient pas l'intention ou ne connaissaient pas de l'intention d'investir davantage dans les supports technologiques de GDR, et seulement 7,8 % prévoyaient de créer de nouveaux postes de GDR (6). Environ le quart des universités ont déclaré offrir du perfectionnement professionnel en GDR aux chercheurs (19,6 %) et au personnel (23,5 %), comparativement à seulement 5,3 % des collèges, qui ont déclaré offrir une formation aux chercheurs seulement (9). Interrogés sur les obstacles au soutien de la GDR, les répondants ont le plus souvent cité le manque de sensibilisation ou la résistance au partage des données, le manque de temps et le manque de financement et d’incitatifs (11). Lorsqu'on leur a demandé quels facteurs accéléreraient le plus efficacement le développement de la GDR, les répondants ont mentionné le plus souvent le financement, suivi des politiques, de la formation et de la collaboration (15).

Le troisième rapport Insights se termine par une liste de recommandations, certaines nouvelles et d'autres déjà mises en œuvre. De façon générale, cela comprend le développement de ressources pour soutenir la capacité de GDR, comme celles que Portage a créées pour soutenir le développement de [https://portagenetwork.ca/fr/outils-et-ressources/strategies-institutionnelles/ stratégies institutionnelles de GDR]. Ils comprennent également une collaboration accrue entre les organisations existantes, en particulier par l'intermédiaire de [https://alliancecan.ca/fr/ l'Alliance de recherche numérique du Canada] (l'Alliance, anciennement NOIRN), et la mise en relation des chercheurs avec les ressources existantes. Le rapport note également que l'Alliance continuera de fournir un soutien à la GDR au niveau national, permettant aux établissements de concentrer leur financement et d'autres ressources sur les besoins locaux (Cooper et al. 2021b, 21).

Pris ensemble, ces trois rapports montrent que les services et soutiens de GDR –– y compris la stratégie institutionnelle et, dans une moindre mesure, la politique ––sont en développement dans de nombreuses institutions canadiennes, souvent dirigées par des bibliothèques. Les établissements s'engagent dans des réseaux et des collaborations régionaux et nationaux, mais les soutiens à la GDR sont disponibles de manière inégale, les universités déclarant plus de ressources que les collèges. Certaines des priorités pour le renforcement des capacités de GDR comprennent le PHQ et les ressources humaines, le financement, l'infrastructure technologique et la connaissance des politiques (Cooper et al 2021b, 19).

==Renforcement des capacités de GDR et le Partenariat INKE==
La GDR est une question d'intérêt pour de nombreux membres du Partenariat INKE, dont beaucoup sont depuis longtemps impliqués dans le développement des capacités de GDR. Avant de se joindre à l'Alliance, Portage était à l'origine une initiative de [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC)] et, sous le nom de l'ABRC Portage, elle a développé [https://assistant.portagenetwork.ca/ l'Assistant PGD (plans de gestion des données)], un outil bilingue en ligne pour la planification de la gestion des données hébergé par l'Université d’Alberta. Il a également travaillé avec [https://www.canarie.ca/fr/ CANARIE] pour soutenir une extension nationale du service [https://dataverse.scholarsportal.info/fr/ Scholars Portal Dataverse], un dépôt de données de recherche soutenu par [https://ocul.on.ca/ l’Ontario Council of University Libraries (OCUL)] et hébergé par [https://onesearch.library.utoronto.ca/ les bibliothèques de l'Université de Toronto]. L'ABRC Portage et [https://www.computecanada.ca/?lang=fr Calcul Canada] se sont également associés à l'Alliance pour développer le [https://www.frdr-dfdr.ca/repo/?locale=fr Dépôt fédéré de données de recherche (DFDR)], un dépôt pour les grands ensembles de données (&gt; 1 To) et une plateforme de découverte qui fédère les données entre les dépôts canadiens.

Portage et un autre partenaire INKE, [https://www.crkn-rcdr.ca/fr le Réseau canadien de documentation pour la recherche (RCDR)], gèrent également [https://www.crkn-rcdr.ca/fr/consortium-datacite-canada le Consortium DataCite Canada], qui permet aux institutions canadiennes de créer et d'intégrer des DOI pour soutenir la GDR et améliorer la découvrabilité, l'accessibilité et la citabilité de la recherche.

En juin 2021, les bibliothèques de l'UVic ont organisé un événement virtuel intitulé [https://osf.io/6vepj/wiki/home/ Research Data Management for Digitally-Curious Humanists] qui a exploré le concept de données de recherche dans les sciences humaines et les stratégies de renforcement des capacités en GDR. [https://ospolicyobservatory.uvic.ca/draft-report-rdm/ Un projet de rapport basé sur les discussions lors de l'événement] a été partagé sur l'Open Scholarship Policy Observatory pour commentaires en novembre 2021.

==Renforcement des capacités de GDR et communauté universitaire élargie==
La série de rapports de la coopérative internationale de bibliothèques [https://www.oclc.org/fr/home.html OCLC], intitulée [https://www.oclc.org/research/publications/2017/oclcresearch-rdm-part-one-service-space-tour.html ''The Realities of Research Data Management''], présente des études de cas d'universités du Royaume-Uni, des États-Unis, d'Australie et des Pays-Bas. Les auteurs notent que l'augmentation exponentielle de l'échelle des données de recherche est un facteur important qui motive le besoin d'une plus grande capacité de GDR. L'avènement du Big Data et les techniques de recherche computationnelle dans les sciences humaines et sociales a changé le visage des données dans la recherche d’aujourd’hui, et les processus d'assemblage, de gestion et la conservation des données également (Bryant et al. 2017). Les données de recherche, en plus des publications qui en découlent, sont devenues une partie importante du dossier scientifique et un atout précieux, en particulier lorsqu'elles sont optimisées pour être réutilisées.

Au Canada, la politique de GDR des trois organismes à laquelle répondent le sondage et les rapports Insights de Portage fait partie des développements continus dans les écosystèmes nationaux de politiques et d'infrastructures qui visent à renforcer la capacité de GDR. Un article paru dans [https://www.affairesuniversitaires.ca/actualites/actualites-article/des-organismes-subventionnaires-priorisent-la-gestion-des-donnees-de-recherche/?_ga=2.122700619.1789151288.1643143466-1326693258.1641858361 ''Affaires universitaires''] note que bien que la GDR soit de plus en plus importante dans toutes les disciplines à mesure que la recherche devient plus intensive en données, ce n'est pas toujours une priorité pour les chercheurs, de sorte que le changement culturel est un facteur important pour faire progresser la capacité de GDR. Comme le note Jeff Moon, directeur de Portage, «&amp;#8239;Nous devons changer cette culture afin que des données, métadonnées et codes bien documentés soient jugés aussi précieux qu'un bon article publié dans une revue scientifique&amp;#8239;» (Voinigescu 2021). L'article pointe vers [https://portagenetwork.ca/fr/outils-et-ressources/ les ressources offertes par Portage] comme supports utiles pour les individus et les institutions.

Les efforts du Canada pour renforcer la capacité de GDR font partie de sa stratégie globale d'infrastructure de recherche numérique (IRN). L'Alliance a été créée dans le cadre de cette stratégie : une organisation nationale à but non lucratif pour soutenir le calcul informatique de recherche avancée et les logiciels de recherche en plus de la GDR et les intégrer dans un système national d'IRN (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/NOIRN et la stratégie canadienne d’infrastructure de recherche numérique|NOIRN et la stratégie canadienne d'infrastructure de recherche numérique]]&amp;#8239;»).

L'Alliance a publié [https://alliancecan.ca/assets/uploads/documents/NDRIO_GDR_E%CC%81xpose%CC%81deprincipe-1.pdf un rapport connexe] en septembre 2021, sondant l'environnement de la GDR au Canada (Khair et al. 2020; voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/État actuel de la gestion des données de recherche au Canada : un rapport par l’Alliance de recherche numérique du Canada|État actuel de la gestion des données de recherche au Canada : un rapport par l’Alliance de recherche numérique du Canada]]&amp;#8239;»). En décembre 2021, [https://alliancecan.ca/fr/dernier/new-research-data-management-resources-institutional-rdm-strategies-and-data-management-plans l'Alliance a annoncé de nouvelles ressources GDR] pour soutenir les établissements :
* [https://zenodo.org/record/5745923#.YfQtt_XMLm8 Modèle pour l’élaboration de stratégie institutionnelle de GDR]
* [https://zenodo.org/record/5745894#.YfQt0fXMLm8 Modèle d'évaluation de la maturité de la GDR au Canada (MAMIC)]
* [https://www.youtube.com/watch?v=epsYxaNlS40 Vidéo d'introduction] aux plans de gestion des données (PGD) et l’Assistant PGD

==Renforcement des capacités GDR et la science ouverte==
Bien que la politique de GDR des trois organismes indique explicitement qu'il «&amp;#8239;n’est pas une politique sur les données ouvertes&amp;#8239;» (Gouvernement du Canada 2021), et que toutes les données de recherche ne peuvent ou ne doivent pas être ouvertes, les pratiques et la capacité de GDR sont fondamentales pour les données ouvertes et la science ouverte. Les chercheurs peuvent utiliser des infrastructures GDR telles que DFDR, par exemple, pour améliorer la découvrabilité et la réutilisation de leurs données de recherche, par exemple (Voinigescu 2021). S'appuyer sur les soutiens GDR existants identifiés dans les rapports Insights de Portage améliorera également la capacité de l'écosystème de recherche canadien en matière de la science ouverte.

==Ouvrages citées==
*Abel, Jennifer, Alexandra Cooper, Dylanne Dearborn, Carol Perry, Andrea Szwajcer, et Minglu Wang. 2020. ''Sondage sur la capacité des services institutionnels de gestion des données de recherche, rapport INSIGHTS #1 Soutien à la GDR au sein des organisations: budget, structure et stratégies''. Juin 2020, Réseau Portage, Association des bibliothèques de recherche du Canada. [https://doi.org/10.5281/zenodo.3906470 https://doi.org/10.5281/zenodo.3906470].

*Bryant, Rebecca, Brian Lavoie, et Constance Malpas. 2017. ''The Realities of Research Data Management, Part One: A Tour of the Research Data Management (RDM) Service Space''. OCLC. [https://doi.org/10.25333/C3PG8J https://doi.org/10.25333/C3PG8J].

*Cooper, Alexandra, Carol Perry, Andrea Szwajecer, Minglu Wang, et Shahira Khair. 2020. ''Sondage sur la capacité des services institutionnels de gestion des données de recherche: Sommaire. ''Réseau Portage, Association des bibliothèque de recherche du Canada. [https://dx.doi.org/10.14288/1.0388723 https://dx.doi.org/10.14288/1.0388723].

*Cooper, Alexandra, Lucia Costanzo, Dylanne Dearborn, Shahira Khair, Carol Perry, Andrea Szwajcer, et Minglu Wang. 2021a. ''Sondage sur la capacité des services institutionnels de gestion des données de recherche, rapport INSIGHTS no2 '': ''Capacité des établissements au chapiter du personnel hautement qualifié, de l’infrastructure et des services''. [https://doi.org/10.5281/zenodo.4559991 https://doi.org/10.5281/zenodo.4559991].

*Cooper, Alexandra, Lucia Costanzo, Dylanne Dearborn, Shahira Khair, Carol Perry, Andrea Szwajcer, et Minglu Wang. 2021b. ''Sondage sur la capacité des services institutionnels de gestion de données de recherche, rapports INSIGHTS no3 : Avenir de soutien à la GDR pour les établissements : ressources priorisées, investissements, défis et accélérateurs''. [https://doi.org/10.5281/zenodo.4892718 https://doi.org/10.5281/zenodo.4892718].

*Gouvernement du Canada. 2021. ''Politique des trois organismes sur la gestion des données de recherche''. [https://www.science.gc.ca/eic/site/063.nsf/fra/h_97610.html https://www.science.gc.ca/eic/site/063.nsf/fra/h_97610.html].

*Groupe d’experts sur la recherche et l’intelligence du reseau Portage. 2019.'' Sondage sur la stratégie institutionelle de gestion des données de recherche (GDR) – Sommaire des résultats''. Novembre 2019. [https://doi.org/10.5281/zenodo.3962885 https://doi.org/10.5281/zenodo.3962885].

*Khair, Shahira, Rozita Dara, Susan Haigh, Mark Leggott, Ian Milligan, Jeff Moon, Karen Payne, Elodie Portales-Casamar, Ghilaine Roquet, et Lee Wilson. 2020. ''État actual de la gestion des données de recherche au Canada : Mise à jour de l’exposé de principe du CLIRN sur la gestion des données''. Novembre 2020. [https://alliancecan.ca/assets/uploads/documents/NDRIO_GDR_E%CC%81xpose%CC%81deprincipe-1.pdf https://alliancecan.ca/assets/uploads/documents/NDRIO_GDR_E%CC%81xpose%CC%81deprincipe-1.pdf].

*Voinigescu, Eva. 2021. «&amp;#8239;Des organismes subventionnaires priorisent la gestion des données de recherche&amp;#8239;». ''Affairs universitaires'', 15 juin 2021, [https://www.affairesuniversitaires.ca/actualites/actualites-article/des-organismes-subventionnaires-priorisent-la-gestion-des-donnees-de-recherche/ https://www.affairesuniversitaires.ca/actualites/actualites-article/des-organismes-subventionnaires-priorisent-la-gestion-des-donnees-de-recherche/].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>1cpf9u59hfo3977tps1esfe5g6c49tw</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Stratégie canadienne de numérisation du patrimoine documentaire</title>
    <ns>0</ns>
    <id>82356</id>
    <revision>
      <id>745415</id>
      <parentid>745140</parentid>
      <timestamp>2025-06-26T19:30:03Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745415</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="27548" sha1="seyq2l8cjbyhhfx2fhz38d9gvv0aj36" xml:space="preserve">''Cette observation a été écrit par Caroline Winter et JT Kern (avec remerciements à Jonathan Bengtson pour ses commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

[https://snpd.ca/ La Stratégie canadienne de numérisation du patrimoine documentaire (SNPD)] fait partie d'une longue histoire de numérisation des matériaux du patrimoine culturel qui est en cours dans les communautés savantes et patrimoniales canadiennes depuis au moins les années 1960, évoluant au rythme des développements des technologies numériques, y compris le World Wide Web. Cette histoire comprend les stratégies de numérisation élaborées par l'Institut canadien de microreproductions historiques (ICMH) et [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC)] à partir des années 1970, l'initiative des bibliothèques numériques des années 1990, [https://www.crkn-rcdr.ca/fr le Réseau canadien de documentation pour la recherche (RCDR)] et [https://www.canadiana.ca/?usrlang=fr Canadiana] dans les années 2000.

[https://archive.org/details/toronto Internet Archive Canada] donne accès libre au matériel numérisé des institutions canadiennes depuis 2004, lorsqu'un centre de numérisation a été établi dans le cadre d'un projet pilote à l'Université de Toronto (Calamai 2007). Le centre a été agrandi en 2006 et a numérisé près de 350 000 textes en quelques années seulement, avec le soutien financier de l'Université de Toronto, d'Internet Archive, de Microsoft et du CRKN (Casey 2011). Le centre de numérisation a été considérablement réduit en 2011, mais à ce jour, Internet Archive Canada a collaboré avec plus de 250 institutions (Internet Archive s.d.).

En 2014, [https://rsc-src.ca/fr/node/3439 la Société royale du Canada (SRC)] a appelé à un programme national de numérisation pour faire entrer le patrimoine culturel et scientifique du Canada dans nouveau l'ère numérique (Beaudry 2014, p. 12). Un [https://www.rapports-cac.ca/reports/a-la-fine-pointe-du-monde-numerique-possibilites-pour-les-institutions-de-la-memoire-collective-au-canada/ rapport de 2015 du Conseil des académies canadiennes (CAC)] sur l'avenir numérique auquel sont confrontées les institutions de mémoire du Canada a noté que «&amp;#8239;le Canada prend du retard, et d’énormes quantités d'information produites sous forme numérique risquent d'être perdues parce que bien des outils traditionnels ne sont plus adéquats&amp;#8239;» (CCA 2015).

==Le SNPD==
En 2016, Guy Berthiaume, alors bibliothécaire et archiviste du Canada, a annoncé le lancement d'une Stratégie de numérisation du patrimoine documentaire (SNPD), éclairée par les rapports de la SRC et du CAC ainsi que par des consultations avec [http://www.cdncouncilarchives.ca/f-intro.html le Conseil canadien des archives] (BAC 2016b). La SNPD a établi ses objectifs pour ses 10 premières années, notamment la numérisation de
* la quasi-totalité (90 %) des documents patrimoniaux publiés avant 1917
* la moitié de toutes les monographies publiées avant 1940
* toutes les revues savantes publiées par les universités canadiennes avant 2000
* toutes les thèses des universités canadiennes avant 2000
* tous les microfilms et microfiches des institutions de mémoire canadiennes
* une sélection de documents audio et audiovisuels de grande valeur
* toutes les cartes historiques disponibles
* toutes les ressources généalogiques d'archives (BAC 2016a).

La SNPD était initialement dirigée par un comité directeur et un secrétariat à [https://www.bac-lac.gc.ca/fra/Pages/accueil.aspx Bibliothèque et Archives Canada (BAC)]. En novembre 2020, il a été annoncé que le secrétariat de la SNPD avait été transféré au [https://www.crkn-rcdr.ca/fr Réseau canadien de documentation pour la recherche (RCDR)] (SNPD 2020). À cette époque, le comité directeur de la SNPD a également été repensé en tant que [https://snpd.ca/le-comite-consultatif-de-la-snpd/ Comité consultatif] relevant d'un nouveau [https://snpd.ca/le-comite-de-direction-de-la-snpd/ Comité de direction] (SNPD 2021b).

==Les activités de la SNPD==
En 2017, la SNPD a mené un projet pilote appelé Digitizing Newspapers, avec le financement de la Salamander Foundation (SNPD s.d.-b). Avec le soutien des éditeurs et des rédacteurs en chef des journaux, les numéros de trois journaux autochtones datant de 1976 à 2017 ont été numérisés et mis en ligne.

En 2018, la SNPD a partagé sa [https://scnpd.files.wordpress.com/2018/03/snpd-strategie-de-contenu-ebauche.pdf Stratégie relative au contenu] et a lancé l'appel de financement pour [https://snpd.ca/2018/04/17/demande-de-financement-dans-le-cadre-de-la-snpd-pour-numeriser-vos-collections/ Numérisation des collections canadiennes], qui offrait jusqu'à 100 000 $ aux des archives, bibliothèques, musées, universités et collèges et autres des organismes du patrimoine culturel pour soutenir leurs projets de numérisation (SNPD 2018a). Il a reçu plus de 200 demandes de financement, totalisant 10 millions de dollars, une réponse qui «&amp;#8239;ont démontré qu’il y a un intérêt pour le programme de numérisation national&amp;#8239;» et a financé 21 projets (SNPD 2018b; 2018c).

Aussi en octobre 2018, la SNPD a co-organisé [https://www.crkn-rcdr.ca/fr/atelier-conjoint-sur-le-patrimoine-documentaire-de-la-snpd-et-du-rcdr l'Atelier conjoint sur le patrimoine documentaire de la SNPD et du RCDR]. Lors de [https://www.crkn-rcdr.ca/fr/2019-conference-du-rcdr-sur-lacces-au-savoir la Conférence du RCDR sur l'accès au savoir en 2019], le RCDR et le SNPD ont tenu des sessions conjointes sur [https://vimeo.com/373462141?embedded=true&amp;source=video_title&amp;owner=91739283 les stratégies de numérisation au Canada], le droit d'auteur, le droit d'auteur et [https://vimeo.com/375434364?embedded=true&amp;source=video_title&amp;owner=91739283 les déclarations des droits]. Des sessions de mise à jour de la stratégie du SNPD ont été offertes lors des conférences virtuelles [https://vimeo.com/485986493 2020] et [https://vimeo.com/648768588 2021] du RCDR.

La SNPD a également développé plusieurs [https://snpd.ca/ressources/ ressources], dont beaucoup en collaboration avec ses membres, notamment [https://scnpd.files.wordpress.com/2020/07/nhds-rightsstatements-report-2020.pdf un rapport sur le groupe de travail sur les déclarations des droits internationaux], [https://www.canada.ca/fr/reseau-information-patrimoine/services/preservation-numerique/recommandations-formats-fichier-preservation-numerique.html des recommandations sur les formats de fichiers pour la préservation numérique] de divers supports et [https://scnpd.files.wordpress.com/2019/05/snpd-pratiques-exemplaires-et-recommandations-2019.pdf un ensemble de meilleures pratiques pour la numérisation].

Le comité exécutif de la SNPD mène actuellement [https://snpd.ca/processus-de-planification-strategique-de-la-snpd/ un processus de planification stratégique] en cinq étapes. L'étape 1 impliquait une consultation, y compris un sondage communautaire et une série d'appels avec communautaires et des parties prenantes. À l'étape 2, actuellement en cours, le Comité de direction et le Comité consultatif et un groupe de travail technique s'appuieront sur le rapport des consultations pour identifier les objectifs, les priorités, les activités et les initiatives à inclure dans le nouveau plan stratégique. À l'étape 3, le Comité de direction élaborera un ébauche de plan stratégique qui, à l'étape 4, sera partagé avec la communauté pour consultation, rétroaction et révision. À l'étape 5, prévue pour 2022, le plan finalisé sera partagé (SNPD s.d.-c.).

==La SNPD dans la presse==
De nombreuses activités de la SNPD ont été couvertes dans la presse académique et populaire. Par exemple, [https://winnipeg.ctvnews.ca/province-digitizing-centuries-old-trading-post-records-to-mark-manitoba-150-1.4317365 un article de CTV News] met en lumière la numérisation [https://www.gov.mb.ca/chc/archives/hbca/index.fr.html des Archives de la Compagnie de la Baie d'Hudson], qui sont maintenant librement accessibles dans le cadre des Archives du Manitoba (Charron 2019). Un article de [https://www.cbc.ca/news/entertainment/digitization-culture-pandemic-1.6015861 CBC News] sur la façon dont la pandémie a conduit à une numérisation accrue des documents du patrimoine culturel mondial note que le gouvernement canadien soutient des initiatives de numérisation depuis des années, y compris la SNPD, et que le budget fédéral du Canada pour 2021 comprend un financement pour la numérisation des documents du patrimoine culturel (Panetta 2021).

Plusieurs projets financés par l'appel de financement Numérisation des collections canadiennes de la SNPD ont également été couverts dans la presse. Un article dans [https://www.affairesuniversitaires.ca/articles-de-fond/article/les-archives-a-lere-de-la-numerisation-et-de-la-decolonisation/?_ga=2.99724830.1629680361.1644268837-1326693258.1641858361 ''Affaires universitaires''] souligne des sérieux efforts des institutions canadiennes, y compris BAC et le SNPD, pour numériser les documents du patrimoine culturel, y compris le projet financé par le SNPD Healing and Education Through Digital Access (Thorkelson 2019). Il s'agit d'un partenariat entre [http://shingwauk.org/srsc/ le Shingwauk Residential Schools Centre] et [https://library.algomau.ca/ la bibliothèque de l'Université Algoma] qui a numérisé [http://archives.algomau.ca/main/?q=node%2F30854 les dossiers du Shingwauk Residential School], un bâtiment qui abrite maintenant l'Université Algoma. Soulignant le rôle important que les institutions de mémoire et les professionnels des bibliothèques et des archives doivent jouer dans la décolonisation, l'article note que rendre ce matériel librement disponible nous permet de demander des autres types de questions comme une communauté de professionnels de l’information sur ce que signifie partager ces éléments en contexte de l'histoire de la violence coloniale et l'utilisation abusive et le vol de matériel aux peuples autochtones (Thorkelson 2019).

Ce projet a également été couvert dans ''SooToday'', un site Web de nouvelles local de Sault Ste. Marie, et sur le blog de [https://www.feathersofhope.ca/digital-archives-project-results-released-national-heritage-digitization-strategy-provides-funding-to-shingwauk-residential-schools-centre/ Feathers of Hope], une initiative de soutien et d'autonomisation des jeunes des Premières Nations en Ontario, soulignant l'importance de ce projet de numérisation pour les communautés concernées.

Un article de [https://www.cbc.ca/news/canada/british-columbia/after-decades-in-boxes-vancouver-s-lgbtq-archive-now-has-a-home-1.5345714 CBC News] traite de la numérisation des [https://searcharchives.vancouver.ca/bc-gay-and-lesbian-archives BC Gay and Lesbian Archives], également financée dans le cadre de l'appel de financement Numérisation des collections canadiennes de la SNPD. Cette collection de milliers de photos, d'œuvres multimédias, d'affiches et d'autres matériaux recueillis par Ron Dutton pendant près de quatre décennies et donnés aux archives de la ville de Vancouver en 2013 (Ghoussoub 2019).

[https://www.cbc.ca/news/canada/prince-edward-island/pei-newspaper-archive-1.4874414 CBC News] a également mis en lumière le projet de numérisation des journaux de l'Université de l'Île-du-Prince-Édouard, financé dans le cadre du même appel. Grâce à ce projet, deux journaux du XIXe siècle, dont le premier journal français de l'Île-du-Prince-Édouard, ont été numérisés et ajoutés à [https://islandnewspapers.ca/nhds IslandNewspapers.ca] (Yarr 2019).

==SNPD et le partenariat INKE==
Le transfert du secrétariat de la SNPD au RCDR, un partenaire d'INKE, a été l'aboutissement d'un partenariat de longue date entre les deux organisations. Clare Appavoo, directrice générale du RCDR, siège aux comités directeurs de la SNPD depuis sa création, et la numérisation et la préservation du patrimoine documentaire canadien sont au cœur des travaux du RCDR, comme le montre de sa fusion avec Canadiana en 2018 (Bengtson et Shepstone 2020 ; voir également «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan Stratégique 2019–2024 du CRKN–RCDR|Plan stratégique 2019-2024 du CRKN–RCDR]]&amp;#8239;» et «&amp;#8239;[https://ospolicyobservatory.uvic.ca/reponse-des-partenaires-au-plan-strategique-2019-2024-du-crkn-rcdr/ Réponse des partenaires au plan stratégique 2019-2024 du CRKN–RCDR]&amp;#8239;»).

[https://www.carl-abrc.ca/fr/ L'ABRC] est un autre partenaire INKE qui entretient des liens étroits avec la SNPD. Parmi ses [https://www.carl-abrc.ca/wp-content/uploads/2016/03/CARL_Budget_2018_brief-final_fr.pdf recommandations pour le budget fédéral de 2018], le gouvernement «&amp;#8239;investir 30 M$ au cours des cinq prochaines années (2018-2022) afin d’appuyer une initiative nationale coordonnée de numérisation du riche patrimoine documentaire du Canada, et de concevoir l'infrastructure numérique requise pour rendre ce matériel accessible à tous les Canadiens&amp;#8239;» (ABRC 2017, 1). L'ABRC est actuellement représentée au SNPD par Jonathan Bengtson (Bibliothèques de l'Université de Victoria), qui est président de son comité exécutif (ABRC s.d.).

Bengtson a présenté une conférence intitulée «&amp;#8239;Five Years Makes All the Difference: Towards a Canadian National Heritage Digitalization Strategy&amp;#8239;» lors d'un panel présenté lors de [https://inke.ca/putting-open-social-scholarship-into-practice/abstracts/ Putting Open Social Scholarship into Practice], le rassemblement annuel du Partenariat INKE, en décembre 2021.

==Le SNPD et la communauté universitaire élargie==
Les stratégies de numérisation du Canada sont également un sujet d'intérêt pour l'ensemble de la communauté universitaire. En 2016, Michael Geist a fait valoir que l'incapacité du Canada à adopter une stratégie nationale de numérisation cohérente a été une source de frustration, donnant l’impression que le pays prend du retard. Il reproche au SNPD de ne pas en faire assez, comparant sa vision à une bibliothèque abandonnée avec des étagères vides de tout sauf de vieux livres. En comparant le SNPD à d'autres stratégies nationales de numérisation, Geist soutient que les obstacles juridiques et financiers qui sont souvent cités ne sont pas aussi insurmontables qu'ils le paraissent, et qu'une initiative dirigée par le gouvernement qui rassemble des ressources publiques et privées c’est le bonne voie à suivre (Geist 2016).

[https://allanamayer.tumblr.com/post/149368526957/the-national-heritage-defeatist-strategy Allana Mayer] a répondu aux critiques de Geist en soulignant que les risques financiers pour les bibliothèques et les archives liés à la numérisation et à la distribution d'œuvres potentiellement protégées par le droit d'auteur sont prohibitifs (voir également «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La prolongation de la période de protection du droit d’auteur en Canada en vertu de l’Accord Canada–États-Unis–Mexique (ACEUM)|La prolongation de la période de protection du droit d’auteur en Canada en vertu de l’Accord Canada–États-Unis–Mexique (ACEUM)]]&amp;#8239;»), et que le partenariat avec le secteur privé comporte ses propres risques, tels que le «&amp;#8239;paywalling&amp;#8239;» des matériaux du patrimoine culturel public (2016). Mayer note que le budget fédéral de 2016 n'offrait aucune augmentation du financement de BAC, qui a été réduit de 10 millions de dollars de 2012 à 2015 (2016). En effet, les revenus du SNPD ne comprennent que les dons, et son travail est effectué par des membres bénévoles (SNPD s.d.-a).

L’article «&amp;#8239;[https://journals.lib.unb.ca/index.php/scl/article/view/26269/1882519038 Survival: Canadian Scholarship in a Digital Age]&amp;#8239;» de Susan Brown appelle également à un soutien national solide pour la numérisation et la préservation des documents du patrimoine canadien. Elle note que, bien que la situation au Québec soit moins désastreuse, en Canada anglais l'ABRC, le RCDR et BAC luttent pour coordonner une programme fédéral sans l'appui du gouvernement. Sans archives nationales dynamiques et bien soutenues, elle argumente, les archives de la culture canadienne seront dispersés et inégales (2018).

==Le SNPD et la science ouverte==
Les valeurs directrices du SNPD s'alignent bien sur le mouvement Science ouverte. Sa vision est «&amp;#8239;un avenir dans lequel l'accès Web au riche patrimoine documentaire numérique du Canada est complet et répandu tout en ayant des répercussions importantes sur la culture, l'éducation, la recherche et l'innovation canadiennes&amp;#8239;» et les principes comprennent l'accès, l'ouverture, la collaboration, la durabilité et la liberté intellectuelle (SNPD s.d-a, p. 2–3).

Le 15 octobre, lors de la session de mise à jour de la SNPD de la Conférence virtuelle 2021 du RCDR, Bengtson et Carole Urbain ont fait rapport sur les résultats de la consultation entreprise dans le cadre du processus de planification stratégique. Ils ont noté que l'accès était la plus grande priorité identifiée par la communauté et que les plus petites institutions et les sociétés historiques étaient particulièrement intéressées par les infrastructures et les meilleures pratiques (RCDR 2021). Bengtson a noté que d'autres thèmes découlant de la consultation communautaire sont également directement liés à la science ouverte, notamment la préservation, le partage des ressources et la coordination du travail, la création de normes, le financement et le renforcement de la diversité. Dans l'ensemble, Bengtson et Urbain ont mis l'accent sur l'élimination des obstacles à l'engagement avec la communauté au sens large comme un thème important pour guider les activités futures de la SNPD.

==Ouvrages Citées==
*ABRC (Association des bibliothèques de recherche du Canada). 2017. ''Budget fédéral de 2018 – Mémoire de l’ABRC au Comité permanent des finances de la Chambre des communes''. 4 août 2017. [https://www.carl-abrc.ca/wp-content/uploads/2016/03/CARL_Budget_2018_brief-final_fr.pdf https://www.carl-abrc.ca/wp-content/uploads/2016/03/CARL_Budget_2018_brief-final_fr.pdf].

*ABRC (Association des bibliothèques de recherche du Canada). n.d. «&amp;#8239;Partenaires et relations&amp;#8239;». [https://www.carl-abrc.ca/fr/a-propos-de-labrc/partenaires-et-relations/ https://www.carl-abrc.ca/fr/a-propos-de-labrc/partenaires-et-relations/].

*BAC (Bibliothèque et Archives Canada). 2016a. «&amp;#8239;Stratégie canadienne de numérisation du patrimoine documentaire&amp;#8239;». [https://www.bac-lac.gc.ca/fra/a-notre-sujet/Pages/strategie-canadienne-numerisation.aspx https://www.bac-lac.gc.ca/fra/a-notre-sujet/Pages/strategie-canadienne-numerisation.aspx].

*BAC (Bibliothèque et Archives Canada). 2016b. «&amp;#8239;Le bibliothècaire et archiviste du Canada annonce la création de la Stratégie nationale de numérisation du patrimoine documentaire&amp;#8239;». 4 juin 2016. ''Internet Archive''. [https://web.archive.org/web/20170224195940/http:/nouvelles.gc.ca/web/article-fr.do?nid=1079789 https://web.archive.org/web/20170224195940/http://nouvelles.gc.ca/web/article-fr.do?nid=1079789].

*Beaudry, Guylaine, et al. 2014. ''The Future Now: Canada’s Libraries, Archives, and Public Memory''. La Société royale du Canada. [https://rsc-src.ca/sites/default/files/L%26A_Report_EN_FINAL_Web.pdf https://rsc-src.ca/sites/default/files/L%26A_Report_EN_FINAL_Web.pdf].

*Bengtson, Jonathan, et Carol Shepstone. 2020. «&amp;#8239;‘Tourner en commun’: La fusion de Canadiana.org avec le Réseau canadien de documentation pour la recherche/Canadian Research Knowledge Network&amp;#8239;». ''Partnership'' 15, no. 1. [https://doi.org/10.21083/partnership.v15i1.6110 https://doi.org/10.21083/partnership.v15i1.6110].

*Brown, Susan. 2018. «&amp;#8239;Survival: Canadian Cultural Scholarship in a Digital Age&amp;#8239;». ''Studies in Canadian Literature / Études en littérature canadienne''. [https://journals.lib.unb.ca/index.php/SCL/article/view/26269/1882519038 https://journals.lib.unb.ca/index.php/SCL/article/view/26269/1882519038].

*CAC (Conseil des académies canadiennes). 2015. ''À la fine pointe du monde numérique : possibilités pour les institutions de la mémoire collective au Canada''. 4 février 2015. [https://www.rapports-cac.ca/reports/a-la-fine-pointe-du-monde-numerique-possibilites-pour-les-institutions-de-la-memoire-collective-au-canada/ https://www.rapports-cac.ca/reports/a-la-fine-pointe-du-monde-numerique-possibilites-pour-les-institutions-de-la-memoire-collective-au-canada/].

*Calamai, Peter. 2007. «&amp;#8239;Archivists Embrace Digital Page&amp;#8239;». ''Toronto Star'', 16 april 2007, [https://www.thestar.com/news/2007/04/16/archivists_embrace_digital_page.html https://www.thestar.com/news/2007/04/16/archivists_embrace_digital_page.html].

*Casey, Liam. 2011. «&amp;#8239;Toronto Online Book Archive Forced to Fire 75% of Staff&amp;#8239;». ''Toronto Star'', 8 juillet 2011. [https://www.thestar.com/news/gta/2011/07/08/toronto_online_book_archive_forced_to_fire_75_of_staff.html https://www.thestar.com/news/gta/2011/07/08/toronto_online_book_archive_forced_to_fire_75_of_staff.html].

*Charron, Jeremie. 2019. «&amp;#8239;Province Digitizing Centuries-old Trading Post Records to Mark Manitoba 150&amp;#8239;». ''CTV News'', 28 février 2019. [https://winnipeg.ctvnews.ca/province-digitizing-centuries-old-trading-post-records-to-mark-manitoba-150-1.4317365 https://winnipeg.ctvnews.ca/province-digitizing-centuries-old-trading-post-records-to-mark-manitoba-150-1.4317365].

*Geist, Michael. 2016. «&amp;#8239;Why Canada’s E-Library is Barren&amp;#8239;». ''The Tyee'', 26 juillet 2021. [https://thetyee.ca/Mediacheck/2016/07/26/Canadas-E-Library-Is-Barren/ https://thetyee.ca/Mediacheck/2016/07/26/Canadas-E-Library-Is-Barren/].

*Ghoussoub, Michelle. 2012. «&amp;#8239;After Decades in Boxes, Vancouver’s LGBTQ Archive Now has a Home&amp;#8239;». ''CBC News''. 3 novembre 2021. [https://www.cbc.ca/news/canada/british-columbia/after-decades-in-boxes-vancouver-s-lgbtq-archive-now-has-a-home-1.5345714 https://www.cbc.ca/news/canada/british-columbia/after-decades-in-boxes-vancouver-s-lgbtq-archive-now-has-a-home-1.5345714.]

*Mayer, Allana. 2016. «&amp;#8239;The National Heritage Defeatist Strategy&amp;#8239;». 23 août 2016. [https://allanamayer.tumblr.com/post/149368526957/the-national-heritage-defeatist-strategy https://allanamayer.tumblr.com/post/149368526957/the-national-heritage-defeatist-strategy].

*Panetta, Alexander. 2021. «&amp;#8239;A World of Art at our Fingertips: How COVID-19 Accelerated the Digitization of Culture&amp;#8239;». ''CBC News''. 8 mai 2021. [https://www.cbc.ca/news/entertainment/digitization-culture-pandemic-1.6015861 https://www.cbc.ca/news/entertainment/digitization-culture-pandemic-1.6015861].

*RCDR (Réseau candien de documentation pour la recherche). 2021. «&amp;#8239;2021 CRKN Virtual Conference – 15 October 2021 – National Heritage Digitization Strategy (NHDS) Update&amp;#8239;». Vidéo, 29:53. 15 octobre 2021. [https://vimeo.com/648768588 https://vimeo.com/648768588].

*SNPD (Stratégie de numérisation du patrimoine documentaire). n.d.-a. ''Plan d’activités 2018–2019''. [https://scnpd.files.wordpress.com/2018/09/snpd-plan-dactivitc3a9s-2018-19.pdf https://scnpd.files.wordpress.com/2018/09/snpd-plan-dactivitc3a9s-2018-19.pdf].

*SNPD (Stratégie de numérisation du patrimoine documentaire). n.d.-b. «&amp;#8239;Numérisation de journaux dans le cadre de la SNPD&amp;#8239;». [https://snpd.ca/plan-daction/numerisation-de-certains-journaux-dans-le-cadre-du-projet-pilote-de-la-snpd/ https://snpd.ca/plan-daction/numerisation-de-certains-journaux-dans-le-cadre-du-projet-pilote-de-la-snpd/].

*SNPD (Stratégie de numérisation du patrimoine documentaire). n.d.-c. «&amp;#8239;Processus de planification stratégique de la SNPD&amp;#8239;». [https://snpd.ca/processus-de-planification-strategique-de-la-snpd/ https://snpd.ca/processus-de-planification-strategique-de-la-snpd/].

*SNPD (Stratégie de numérisation du patrimoine documentaire). 2018a. «&amp;#8239;Demande de financement dans le cadre de la SNPD pour numériser vos collections&amp;#8239;». 17 april 2018. [https://snpd.ca/2018/04/17/demande-de-financement-dans-le-cadre-de-la-snpd-pour-numeriser-vos-collections/ https://snpd.ca/2018/04/17/demande-de-financement-dans-le-cadre-de-la-snpd-pour-numeriser-vos-collections/].

*SNPD (Stratégie de numérisation du patrimoine documentaire). 2018b. «&amp;#8239;Mise à jour d’automne de la Stratégie de numérisation du patrimoine documentaire&amp;#8239;». 21 septembre 2018. [https://snpd.ca/2018/09/21/mise-a-jour-dautomne-de-la-strategie-de-numerisation-du-patrimoine-documentaire/ https://snpd.ca/2018/09/21/mise-a-jour-dautomne-de-la-strategie-de-numerisation-du-patrimoine-documentaire/].

*SNPD (Stratégie de numérisation du patrimoine documentaire). 2018c. «&amp;#8239;Stratégie de numérisation du patrimoine documentaire : 21 demandes de financement approuvées dans l’ensemble du Canada&amp;#8239;». 16 octobre 2018. [https://snpd.ca/2018/10/16/strategie-de-numerisation-du-patrimoine-documentaire-21-demandes-de-financement-approuvees-dans-lensemble-du-canada/ https://snpd.ca/2018/10/16/strategie-de-numerisation-du-patrimoine-documentaire-21-demandes-de-financement-approuvees-dans-lensemble-du-canada/].

*SNPD (Stratégie de numérisation du patrimoine documentaire). 2020. «&amp;#8239;Transfert du secrétariat de la SNPD au RCDR&amp;#8239;». 4 novembre 2020. [https://snpd.ca/2020/11/04/transfert-du-secretariat-de-la-snpd-au-rcdr/ https://snpd.ca/2020/11/04/transfert-du-secretariat-de-la-snpd-au-rcdr/].

*SNPD (Stratégie de numérisation du patrimoine documentaire). 2021b. «&amp;#8239;Prochaines étapes de la SNPD : mise à jour sur la gouvernance et la planification stratégique&amp;#8239;». 7 juin 2021. [https://snpd.ca/2021/06/07/prochaines-etapes-de-la-snpd-mise-a-jour-sur-la-gouvernance-et-la-planification-strategique/ https://snpd.ca/2021/06/07/prochaines-etapes-de-la-snpd-mise-a-jour-sur-la-gouvernance-et-la-planification-strategique/].

*Thorkelson, Erika. 2019. «&amp;#8239;Les archives a l’ère de la numérisation et de la décolonisation&amp;#8239;». ''Affaires universitaires.'' 18 septembre 2019. [https://www.affairesuniversitaires.ca/articles-de-fond/article/les-archives-a-lere-de-la-numerisation-et-de-la-decolonisation/?_ga=2.2862896.1629680361.1644268837-1326693258.1641858361 https://www.affairesuniversitaires.ca/articles-de-fond/article/les-archives-a-lere-de-la-numerisation-et-de-la-decolonisation/?_ga=2.2862896.1629680361.1644268837-1326693258.1641858361].

*Yarr, Kevin. 2018. «&amp;#8239;From Confederation to the Great War: P.E.I. Digital Newspaper Collection Expanding&amp;#8239;». 23 octobre 2018. [https://www.cbc.ca/news/canada/prince-edward-island/pei-newspaper-archive-1.4874414 https://www.cbc.ca/news/canada/prince-edward-island/pei-newspaper-archive-1.4874414].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>seyq2l8cjbyhhfx2fhz38d9gvv0aj36</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Collaboration entre l’ABRC et OpenAIRE</title>
    <ns>0</ns>
    <id>82357</id>
    <revision>
      <id>745417</id>
      <parentid>745141</parentid>
      <timestamp>2025-06-26T22:36:17Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745417</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="16760" sha1="7cyzh67j2khgqwkx0dcbf23aocbnbsc" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec remerciements à Kathleen Shearer et Martha Whitehead pour ses commentaires et contribution), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En janvier 2018, [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC)] a entamé une [https://www.carl-abrc.ca/fr/faire-avancer-la-recherche/depots-institutionnels/groupe-de-travail-depots-ouverts/collaboration-avec-openaire/ collaboration] avec [https://www.openaire.eu/ OpenAIRE], une organisation européenne d'infrastructure de science ouverte, dans le but d'améliorer la visibilité de la recherche canadienne. L'un des résultats de cette collaboration est [https://canada.explore.openaire.eu/ Canada Explore], un portail de recherche dans les dépôts institutionnels canadiens.

Cette collaboration et le portail qui en résulte contribuent aux efforts de l'ABRC pour rendre les résultats de recherche disparates du Canada disponibles via une interface unique, dans le cadre d'une infrastructure de communication savante distribuée et en réseau mondial. La collaboration augmentera la découvrabilité de la recherche canadienne, avec un accent initial sur les travaux financés par les trois organismes du Canada, comprenant [https://cihr-irsc.gc.ca/f/193.html les Instituts de recherche en santé du Canada (IRSC)], [https://www.nserc-crsng.gc.ca/index_fra.asp le Conseil de recherches en sciences naturelles et en génie du Canada (CRSNG)] et [https://www.sshrc-crsh.gc.ca/home-accueil-fra.aspx le Conseil de recherche en sciences humaines (CRSH)]. L'un de ses principaux objectifs est de saisir les relations avec les subventionnaires afin de permettre le suivi de la conformité à [https://www.ic.gc.ca/eic/site/063.nsf/fra/h_F6765465.html la Politique des trois organismes sur le libre accès aux publications] (ABRC s.d-b ; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Politique des trois organismes sur le libre accès aux publications|Politique des trois organismes sur le libre accès aux publications]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Conformité à la politique de libre accès au Canada|Conformité à la politique de libre accès au Canada]]&amp;#8239;»). Cela permettra également d'avoir une vision plus claire du paysage du libre accès au Canada.

La collaboration entre ABRC et OpenAIRE, coordonnée par le [https://www.coar-repositories.org/ Confederation of Open Access Repositories (COAR)], a été lancée dans le cadre du projet [https://www.openaire.eu/advance/ Advance] d'OpenAIRE, un projet financé par la Commission européenne qui vise à promouvoir l'érudition ouverte dans un contexte mondial grâce à des collaborations avec des parties prenantes en Afrique, Canada, Japon, Amérique latine et des États-Unis (OpenAIRE 2018).

==OpenAIRE==
OpenAIRE (Open Access Infrastructure for Research in Europe) a été fondée en 2008 par la Commission européenne pour promouvoir et soutenir la mise en œuvre des directives du [https://erc.europa.eu/sites/default/files/document/file/ERC_Open_Access_Guidelines-revised_Dec_2021.pdf European Research Council’s Open Access Guidelines] de la recherche pour le libre accès et du [https://ec.europa.eu/commission/presscorner/detail/fr/MEMO_08_548 septième programme-cadre de recherche (FP7)] de la Commission européenne, qui exigeait que tous les résultats de la recherche financée doivent être librement accessibles soit par l'intermédiaire d'une revue, soit par l'intermédiaire d'un dépôt.

OpenAIRE, devenue une entité juridique, fournit un certain nombre de services, dont [http://catalogue.openaire.eu/service/openaire.usage_statistics le service de métriques OpenAIRE] et des tableaux de bord institutionnels, communautaires et subventionnaires. Il fournit également [https://www.openaire.eu/noad-activities?highlight=WyJub2FkIl0= des bureaux nationaux de libre accès], qui sont des services d'assistance aux politiques qui offrent une formation et un soutien aux chercheurs et aux institutions pour le partager de leurs travaux dans des dépôts. En outre, il offre une infrastructure de recherche numérique sous la forme de [https://zenodo.org/ Zenodo], un dépôt ouvert pour toutes les disciplines développé avec le [https://home.cern/fr CERN], ainsi que des normes de liaison des données, grâce à l'adoption d'identifiants persistants qui aident à lever l'ambiguïté des organisations de recherche (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/ORCID : Connecter la recherche et les chercheurs|ORCID : Connecter la recherche et des chercheurs]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Persistent Identifier (PID) Consortium de Royaume-Uni|Le «&amp;#8239Persistent Identifier (PID) Consortium&amp;#8239;» de Royaume-Uni]]&amp;#8239;»).

[https://graph.openaire.eu/ Le plate-forme OpenAIRE] agrège les métadonnées de milliers de fournisseurs de contenu (par exemple, Zenodo, arXiv, les revues en libre accès) ainsi que des registres d'entités (par exemple, ORCID, CrossRef) pour créer le base de données, au-dessus duquel les services d'OpenAIRE sont construits. Grâce à [https://explore.openaire.eu/ OpenAIRE Explore], les utilisateurs peuvent rechercher et trouver des publications, des projets de recherche, des données de recherche, des organismes de recherche, des dépôts et d'autres fournisseurs de contenu (OpenAIRE s.d.).

==Le portail Explore Canada==
[https://canada.explore.openaire.eu/ Canada Explore] est un portail personnalisé pour la recherche canadienne qui affiche un sous-ensemble du base de données d'OpenAIRE (OpenAIRE 2021). Il fournit une vue de tous les enregistrements dans le base de données avec une affiliation avec des auteurs, des institutions ou des subventionnaires au Canada. Le portail utilise les capacités d'exploration de données d'OpenAIRE pour capturer les relations avec les subventionnaires et d'autres points de données à partir du texte intégral des publications qui ne sont pas capturées dans les métadonnées. Par exemple, en octobre 2021, le portail affichait 55 595 résultats financés par l’IRSC, dont 37 671 ont été découverts grâce à l'exploration de texte (ABRC 2021, 24:05).

Afin de soutenir l'inclusion des collections de dépôts canadiens dans le base de données d’OpenAIRE, [https://www.carl-abrc.ca/fr/faire-avancer-la-recherche/depots-institutionnels/groupe-de-travail-depots-ouverts/ le Groupe de travail sur les dépôts ouverts] de l'ABRC travaille avec les institutions canadiennes pour s'assurer que leurs dépôts peuvent être récoltés par OpenAIRE. Cela nécessite que les dépôts soient conformes aux [https://guidelines.openaire.eu/en/latest/ directives OpenAIRE 4.0], qui dictent un certain format pour les métadonnées. Les dépôts de littérature qui ne sont pas en mesure de devenir conformes à OpenAIRE peuvent s'assurer que leurs métadonnées sont récoltées indirectement par l'intermédiaire du [https://canadaresearch.mcmaster.ca/handle/123456789/1?locale=fr Canada Research Aggregator], développé par les bibliothèques de l'Université McMaster. Les dépôts de données canadiens sont mis à la disposition d'OpenAIRE par l'intermédiaire du service de découverte du [https://www.frdr-dfdr.ca/repo/?locale=fr Dépôt fédéré de données de recherche (DFDR)] (CARL s.d.-a).

Pour soutenir une plus grande participation à OpenAIRE, le Groupe de travail sur les dépôts ouverts développe des documents pour aider les gestionnaires de dépôts, et l'ABRC a proposé une série de webinaires liés à la collaboration ABRC-OpenAIRE :
* [https://www.youtube.com/watch?v=i5pmEfn9G4U À la recherche d’une aiguille dans une botte de foin : Accroître la visibilité international de la recherche Canadienne grâce à la collaboration entre l’ABRC et OpenAIRE] (26 octobre 2021)
* [https://www.youtube.com/watch?v=8uG13dMzc7A La collaboration ABRC-OpenAIRE : Que faut-il faire dans nos établissements pour y participer?] (26 novembre 2021)
* [https://www.youtube.com/watch?v=H-MrsuYU8WE&amp;t=5s Webinaire pour les responables de dépôt : Mise a jour sur la collaboration entre l’ABRC et OpenAIRE] (2 décembre 2020)

==La collaboration CARL–OpenAIRE et la communauté INKE==
En plus de l'ABRC, la collaboration implique le CRSH, un partisan de l'INKE et membre des trois organismes. Matthew Lucas, directeur exécutif, Stratégie et rendement organisationnels au CRSH, note que la collaboration CARL-OpenAIRE est essentielle pour rendre la recherche canadienne plus ouverte et plus utilisable et pour améliorer la conformité à la politique des trois organismes sur le libre accès (CARL 2021). En plus de faciliter le suivi de la conformité à la politique, ces données peuvent également aider les trois organismes à déterminer quels obstacles à la conformité existent, comment ils peuvent être surmontés et comment mieux surveiller la conformité.

==La collaboration CARL-OpenAIRE et la communauté universitaire élargie==
En plus des avantages qu'elle apporte à la communauté canadienne, la collaboration CARL-OpenAIRE contribue également à la communauté plus large. Par exemple, dans le cadre du projet, le Groupe de travail sur les dépôts ouverts de l'ABRC a lancé le développement d'un plugin pour [https://duraspace.org/dspace/ DSpace] 5 et 6, des plates-formes de dépôt largement utilisées, pour permettre la conformité aux directives OpenAIRE. Cette extension a été dirigée et financée par la bibliothèque de l'Université Queen's avec un financement supplémentaire de l'Université de la Colombie-Britannique, de l'Université Laval, de l'Université de Montréal, de l'Université de la Saskatchewan, de l'Université de l'île de Vancouver et de l'Université York. Ce plugin est disponible pour tous les dépôts DSpace et permettra aux dépôts du monde entier de se conformer plus facilement aux directives OpenAIRE, qui sont également [https://www.coalition-s.org/plan-s-practical-advice/ recommandées pour les dépôts faisant partie du Plan S] (CARL 2019 ; CARL 2020 ; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;»).

==La collaboration CARL-OpenAIRE et la science ouverte==
La collaboration entre l'ABRC et OpenAIRE met en évidence le rôle de l'infrastructure dans l'avancement de la science ouverte. Une infrastructure ouverte et dirigée par la communauté telle qu'OpenAIRE offre une plus grande transparence autour de la fourniture de services, ainsi qu'une couche importante de gouvernance communautaire. Vivian Lewis, présidente de l'ABRC, note que l'infrastructure ouverte et dirigée par la communauté est une partie importante de la vision décrite dans [https://www.carl-abrc.ca/wp-content/uploads/2018/03/CARL_ScholComm_Roadmap_FR.pdf ''la Feuille de route de l’ABRC sur la communication savante''] et [https://unesdoc.unesco.org/ark:/48223/pf0000379949.locale=fr ''la Recommendation de l'UNESCO sur une science ouverte''] (ABRC 2021 ; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Feuille de route sur la communication savante de l'ABRC|Feuille de route sur la communication savante de l'ABRC]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|La Recommandation de l'UNESCO sur la science ouverte]]&amp;#8239;»).

Le développement et l'optimisation de cette infrastructure nécessitent l'adoption généralisée de normes de métadonnées, de vocabulaires et d'identificateurs persistants, et ceux-ci sont destinés au portail Canada Explore et à l'ouverture de la recherche plus largement.

Ce projet met en évidence la nature mondiale de la science ouverte. Comme indiqué dans un article [https://www.affairesuniversitaires.ca/actualites/actualites-article/des-organismes-subventionnaires-priorisent-la-gestion-des-donnees-de-recherche/?_ga=2.135693940.45428248.1645808203-1326693258.1641858361 d’''Affaires universitaires''] sur [https://science.gc.ca/eic/site/063.nsf/fra/h_97610.html ''la Politique des trois organismes sur la gestion des données de recherche''], par exemple, la collecte de [https://portagenetwork.ca/fr/nouvelles/metadonnees-du-dfdr-moissonnees-par-openaire/ métadonnées DFDR] dans le base de données d'OpenAIRE a rendu la recherche canadienne visible et accessible à la communauté internationale (Voinigescu 2021). Natalia Manola, PDG d'OpenAIRE, note que  la recherche est mondiale : la recherche qui trouve son origine en Europe ou en Canada n’y reste pas. Ce qu'il faut, c'est une infrastructure mondiale ouverte avec des nœuds décentralisés, avec des responsabilités, ressources et gouvernance partagée (CARL 2021, 19:50). À titre d'exemple, en améliorant la découvrabilité et l'interopérabilité des résultats de la recherche canadienne, le portail accroît sa visibilité dans le paysage mondial de la recherche.

==Ouvrages citées==
*ABRC (Association des bibliothèques de recherche du Canada). 2019. «&amp;#8239;Collaboration pour une plus grande visibilité et pour améliorer la découvrabilité de l’érudition ouverte – l’extension de DSpace 5 et 6 permettra bientôt de supporter les nouvelles lignes directrices liées à OpenAIRE&amp;#8239;». 2 décembre 2019. CARL. [https://www.carl-abrc.ca/fr/nouvelles/extension-dspace-5-6-conformite-openaire/ https://www.carl-abrc.ca/fr/nouvelles/extension-dspace-5-6-conformite-openaire/].

*ABRC (Association des bibliothèques de recherche du Canada). 2020. «&amp;#8239;Collaboration pour une plus grande visibilité et pour améliorer la découvrabilité de la science ouverte – l’extension de DSpace 5 et 6 est maintenant disponible pour supporter les nouvelles lignes directrices liées à ORCID et à OpenAIRE&amp;#8239;». 20 mai 2020. [https://www.carl-abrc.ca/fr/nouvelles/sortie-extension-dspace-openaire/ https://www.carl-abrc.ca/fr/nouvelles/sortie-extension-dspace-openaire/].

*ABRC (Association des bibliothèques de recherche du Canada). «&amp;#8239;CARL–OpenAIRE Collaboration Webinar (Oct. 26 2021)&amp;#8239;». YouTube, 1 novembre 2021. [https://www.youtube.com/watch?v=i5pmEfn9G4U https://www.youtube.com/watch?v=i5pmEfn9G4U].

*ABRC (Association des bibliothèques de recherche du Canada). s.d.-a. «&amp;#8239;Comment pouvez-vous participer ?&amp;#8239;» [https://www.carl-abrc.ca/fr/faire-avancer-la-recherche/depots-institutionnels/groupe-de-travail-depots-ouverts/collaboration-avec-openaire/comment-pouvez-vous-participer/ https://www.carl-abrc.ca/fr/faire-avancer-la-recherche/depots-institutionnels/groupe-de-travail-depots-ouverts/collaboration-avec-openaire/comment-pouvez-vous-participer/].

*ABRC (Association des bibliothèques de recherche du Canada). s.d.-b. «&amp;#8239;En quoi ce projet est-il important ?&amp;#8239;» [https://www.carl-abrc.ca/fr/faire-avancer-la-recherche/depots-institutionnels/groupe-de-travail-depots-ouverts/collaboration-avec-openaire/importance/ https://www.carl-abrc.ca/fr/faire-avancer-la-recherche/depots-institutionnels/groupe-de-travail-depots-ouverts/collaboration-avec-openaire/importance/].

*OpenAIRE. 2018. «&amp;#8239;OpenAIRE Advance&amp;#8239;». 20 avril 2018. [https://www.openaire.eu/openaire-advance-project https://www.openaire.eu/openaire-advance-project].

*OpenAIRE. 2021. «&amp;#8239;CANADA.EXPLORE: Discovering Canadian Research Outputs&amp;#8239;». 13 décembre 2021. [https://www.openaire.eu/identifying-canadian-research-outputs https://www.openaire.eu/identifying-canadian-research-outputs].

*OpenAIRE. s.d. «&amp;#8239;About&amp;#8239;». [https://graph.openaire.eu/about https://graph.openaire.eu/about].

*Voinigescu, Eva. 2021. «&amp;#8239;Des organismes subventionnaires priorisent la gestion des données de recherche&amp;#8239;». ''Affaires universitaires''. 15 juin 2021. [https://www.affairesuniversitaires.ca/actualites/actualites-article/des-organismes-subventionnaires-priorisent-la-gestion-des-donnees-de-recherche/?_ga=2.90745823.45428248.1645808203-1326693258.1641858361 https://www.affairesuniversitaires.ca/actualites/actualites-article/des-organismes-subventionnaires-priorisent-la-gestion-des-donnees-de-recherche.]

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>7cyzh67j2khgqwkx0dcbf23aocbnbsc</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le Rapport sur l’infrastructure ouverte du projet Future of Open Scholarship</title>
    <ns>0</ns>
    <id>82358</id>
    <revision>
      <id>745418</id>
      <parentid>745142</parentid>
      <timestamp>2025-06-26T22:43:01Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745418</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="15972" sha1="j4hh2fb4nvkiv3again3uom4i0022fa" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec remerciements à Janneke Adema et Virginia Barbour pour ses commentaires et contribution), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

[https://investinopen.org/ Invest in Open Infrastructure (IOI)] est une organisation internationale qui recherche et défend une infrastructure de recherche ouverte et dirigée par la communauté et travaille à des modèles de financement coordonnés et durables. En août 2021, IOI a publié le rapport final du projet «&amp;#8239;[https://investinopen.org/research/future-of-open-scholarship/ Future of Open Scholarship (FOS)]&amp;#8239;». Ce projet de recherche vise à développer un modèle ouvert et durable pour l'infrastructure de recherche, que IOI définit sur son site Web comme l'ensemble de services, de normes, de protocoles et de logiciels dont l'écosystème universitaire a besoin pour remplir ses fonctions tout au long du cycle de vie de la recherche. IOI définit l'infrastructure ouverte comme les ensembles plus étroite de services, de normes, de protocoles et de logiciels qui permettre communautés de construire collectivement les infrastructures et les systèmes qui offrent des avantages collectifs sans restrictions, et pour un système d'infrastructure mondiale robuste (IOI sd, «&amp;#8239;About&amp;#8239;»).

Le projet FOS aborde les risques et les défis de longue date auxquels sont confrontées les infrastructures de recherche qui ont été exacerbés par la pandémie de COVID-19, y compris un besoin en augmentant de ressources ouvertes et en ligne, des budgets de bibliothèque surchargés et des pénuries de personnel (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Science Ouverte et COVID-19|Science Ouverte et COVID-19]]&amp;#8239;»).

==Le rapport==
Le rapport final du FOS, [https://zenodo.org/record/5218968#.Yh_1FRPMKWA ''Designing a Preparedness Model for the Future of Open Scholarship''], s'appuie sur les cadres de modélisation de la préparation aux situations d'urgence et aux catastrophes utilisés pour se préparer aux crises de santé publique ou aux catastrophes environnementales. Ces cadres traitent des risques immédiats et urgents ainsi que de la durabilité à plus long terme. En demandant comment les infrastructures de recherche peuvent être développées et financées pour assurer la réactivité à la crise et la durabilité à l'avenir, le projet a adopté une approche communautaire de sa recherche en menant des entretiens, en organisant les appels de la communauté et en animant des ateliers avec des parties prenantes travaillant dans des bibliothèques universitaires, des bibliothèques et services d'archives, universités, organismes de recherche et d'innovation, édition et autres organismes de recherche. Les ateliers ont abordé les thèmes du rôle des principes et des valeurs dans le processus de prise de décision collective et les modèles et mécanismes de financement en matière d'infrastructures de recherche.

Le rapport indique que pour que la science ouverte prospère, nous devons assurer que les outils, les logiciels et les systèmes qui permettent la production et la diffusion des connaissances sont également entretenus et alignés sur les valeurs de la communauté, avec le soutien, la surveillance et des ressources adéquats.

Le rapport soutient qu'une infrastructure ouverte, détenue et exploitée par la communauté est nécessaire pour s'assurer que les valeurs et les besoins de la communauté universitaire sont prioritaires et pris en compte&amp;#8239;», puisque les infrastructures actuelles dominées par les produits commerciaux ne sont pas bien alignées sur les besoins et les valeurs de cette communauté. communauté (6). Il identifie certains défis auxquels sont confrontés les systèmes d'infrastructure ouverts, notamment «l'individualisme institutionnel», le temps nécessaire pour développer et mettre en œuvre des solutions open source par rapport aux solutions commerciales, la maintenance, l'alignement et la dotation en personnel. L'interopérabilité est devenue une préoccupation plus urgente étant donné le risque que certains systèmes d'infrastructure s'arrêtent en raison d'un manque de ressources, ce qui signifie que garantir que le contenu peut être migré est une priorité.

Le rapport identifie également la résilience - la capacité d'un système à se remettre d'une crise - comme un facteur clé de succès. S'appuyant sur l'efficacité de l'action collective pour faire progresser le mouvement du libre accès (Joseph 2013), le rapport appelle à une approche similaire pour faire progresser l'infrastructure ouverte, notant que les consortiums de bibliothèques jouent un rôle important, notamment dans l'élaboration d'un programme de changement partagé.

Le rapport recommande la création d'un «&amp;#8239;Open infrastructure technology oversight committee&amp;#8239;» comprenant des parties prenantes clés et souligne que les modèles de financement sont un élément clé pour une infrastructure de recherche ouverte durable. Enfin, le rapport présente cinq interventions recommandées, avec des mises à jour sur ce qui a été réalisé jusqu'à présent et des échéanciers futurs possibles. Ces recommandations sont, à court terme (&lt;1 an), de
* explorer des modèles permettant une plus grande interopérabilité entre les systèmes de partage d'informations
* créer un comité de surveillance des technologies d'infrastructure ouverte.

A moyen terme (1–2 ans+), pour
* identifier les opportunités de services collectifs et de modèles de soutien pour maximiser les avantages collectifs et améliorer la résilience.

Et à long terme, (3 ans+) pour
* piloter un fonds de réponse rapide pour soutenir la maintenance du projet, en s'appuyant sur le projet pilote précédent
* élaborer un cadre de modèle de financement pour évaluer la faisabilité d'un modèle de financement collectif, en coordonnant les efforts actuellement en cours (28–29).

En plus de son rapport final, le projet FOS comprend [https://docs.google.com/spreadsheets/d/1VkxmIOFCMYHFlrY4xm05PAsklA_SXbnaTyoHI20dQfg/edit#gid=311894591 un outil de modélisation financière interactif] et [https://zenodo.org/record/5153496#.Yh_r8RPMKWA un rapport] d'accompagnement qui modélise les coûts et les avantages de l'investissement collectif dans les infrastructures ouvertes.

==Le rapport FOS et le partenariat INKE==
Les membres de l'INKE sont impliqués dans plusieurs des initiatives d'infrastructure ouverte référencées dans le rapport FOS. [https://www.coalition-publi.ca/ Coalition Publica], un exemple de partenariat novateur cité dans le rapport, est une collaboration entre les partenaires INKE [https://www.erudit.org/fr/ Érudit] et [https://pkp.sfu.ca/ le Public Knowledge Project (PKP)] pour créer une infrastructure ouverte pour l'édition de revues au Canada. Cette infrastructure comprend [https://pkp.sfu.ca/ojs/ Open Journal Systems], une application de publication de revues open source développée par le PKP que le rapport cite comme un exemple d'infrastructure ouverte réussie. Les membres de l'INKE [https://www.canarie.ca/fr/rnre/ CANARIE], [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC)] et [https://portagenetwork.ca/fr/ Portage] ont apporté leur soutien à [https://dataverse.scholarsportal.info/fr/ Scholars Portal Dataverse] et à la plate-forme de dépôt de données ouvertes qui est également mentionnée comme un exemple clé d'infrastructure ouverte nécessitant un financement plus durable.

Les membres de l'INKE ont également été impliqués dans diverses initiatives visant à faire progresser l'infrastructure ouverte et à améliorer sa durabilité. En mars 2019, l'ABRC et [https://www.crkn-rcdr.ca/fr le Réseau canadien de documentation pour la recherche (RCDR)] se sont joints au SCOSS, une organisation qui facilite le financement collectif d'initiatives de la science ouverte ; deux initiatives précédemment financées sont [https://v2.sherpa.ac.uk/romeo/ Sherpa/RoMEO] et [https://doaj.org/ le Directory of Open Access Journals (DOAJ)] (CARL 2019). L'adhésion au SCOSS signifie que les membres de l'ABRC et du RCDR peuvent participer à un cadre de partage des coûts coordonné (SPARC Europe 2019, 1).

En juin 2021, l'ABRC et le RCDR ont co-présenté un webinaire avec SPARC intitulé [https://www.youtube.com/watch?v=GDWr6zVoA-g Perspectives des établissements par rapport aux investissements en infrastructures ouvertes], réunissant des bibliothécaires universitaires du Canada et des États-Unis pour discuter de stratégies d'investissement dans l'infrastructure ouverte.

L'ABRC a également collaboré avec [https://www.openaire.eu/ OpenAIRE], une organisation européenne de la science ouverte, pour développer [https://www.openaire.eu/identifying-canadian-research-outputs Canada Explore], un portail pour la recherche canadienne basé sur le OpenAIRE plate-forme (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Collaboration entre l’ABRC et OpenAIRE|La Collaboration entre l'ABRC et OpenAIRE]]&amp;#8239;»).

==Le rapport FOS et la communauté universitaire élargie==
Comme le reconnaît le rapport FOS, de nombreux groupes et organisations au sein de la communauté universitaire travaillent déjà à la construction d'infrastructures ouvertes. En plus de ceux mentionnés dans le rapport, d'autres groupes développent et mettent en œuvre des infrastructures, telles que l'organisation d'identificateurs persistants [https://orcid.org/ ORCID], [https://www.copim.ac.uk/ COPIM (Community-led Open Publication Infrastructures for Monographs)] et [https://www.coar-repositories.org/ COAR (Confederation of Open Access Repositories)] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/ORCID : Connecter la recherche et les chercheurs|ORCID : Connecter la recherche et les chercheurs]]&amp;#8239;» ; «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/ORCID : Connecter la recherche et les chercheurs|Les monographies en libre accès]]&amp;#8239;»).

Faisant écho aux évaluations du rapport sur l'importance de la construction d'infrastructures ouvertes durables, [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre la Recommandation de l'UNESCO sur une science ouverte] reconnaît qu'en plus de ses avantages économiques, investir dans des infrastructures ouvertes permet la collaboration, améliore la réutilisation des données de recherche (et donc la réplicabilité et la reproductibilité des recherche), et promeut une plus grande égalité au sein de la communauté mondiale de la recherche (2021). La Recommandation de l'UNESCO indique également «&amp;#8239;Investir dans les infrastructures et les services de la science ouverte&amp;#8239;» comme l'un de ses objectifs clés (6) et appelle les infrastructures ouvertes l'un des «&amp;#8239;piliers essentiels&amp;#8239;» de la science ouverte (7).

==Le rapport FOS et la science ouverte==
L'infrastructure ouverte est un élément clé de la science ouverte et de l'écosystème de la communication savante. Comme le note le rapport FOS, l'effondrement des infrastructures pourrait entraîner un manque de diversité dans l'écosystème si les petites presses sont contraintes de fermer, les services et outils ouverts ne peuvent plus être pris en charge et les sociétés savantes ne peuvent plus générer de revenus grâce à des événements en personne. (Thaney 2020).

En plus du projet FOS, IOI développe un catalogue de services d'infrastructure ouverte qui décrit et évalue l'infrastructure ouverte, présentant des informations sur chacun sous une forme standardisée pour faciliter la sélection et la prise de décision.

De plus, la pandémie de COVID-19 est un contexte important pour le projet FOS, une crise en cours qui a rendu visibles à la fois les vulnérabilités de l'écosystème scientifique, y compris ses infrastructures, et son importance vitale, en particulier l'importance vitale du libre accès et la science ouverte (Barbour et Borchert 2020; Tavernier 2020). Dans un article pour le blog LSE, Kaitlin Thaney, directrice exécutive de l'IOI, note que les institutions ont réagi à la pandémie de l'une des deux manières suivantes : en continuer avec le nombre de fournisseurs de services afin d’assurer la continuité de la recherche à le coût de la flexibilité et de la capacité de changement, ou en voyant cela comme un moment pour s'adapter et renforcer la résilience en coordonnant dans le cadre d'une stratégie à long terme (2020). La collaboration et les efforts collectifs sont essentiels à la vision du rapport FOS d'un avenir durable pour la science ouverte.

==Ouvrages citées==
*ABRC (Association des bibliothèques de recherche du Canada). 2019. «&amp;#8239;L’ABRC et le RCDR se joignent à la SCOSS, la Global Sustainability Coalition for Open Science Services&amp;#8239;». 18 mars 2019. [https://www.carl-abrc.ca/fr/nouvelles/labrc-et-le-rcdr-se-joignent-au-scoss/ https://www.carl-abrc.ca/fr/nouvelles/labrc-et-le-rcdr-se-joignent-au-scoss/].

*ABRC (Association des bibliothèques de recherche du Canada). 2021. «&amp;#8239;Webinar: Institutional Perspectives on Investments in Open Infrastructure (June 17, 2021)&amp;#8239;». 23 juin 2021. [https://www.youtube.com/watch?v=GDWr6zVoA-g https://www.youtube.com/watch?v=GDWr6zVoA-g].

*Barbour, Virginia, et Martin Borchert. 2020. «&amp;#8239;Open Science: After the COVID-19 Pandemic There can be No Return to Closed Working&amp;#8239;». Australian Academy of Science. [https://www.science.org.au/curious/policy-features/open-science-after-covid-19-pandemic-there-can-be-no-return-closed-working https://www.science.org.au/curious/policy-features/open-science-after-covid-19-pandemic-there-can-be-no-return-closed-working].

*Goudarzi, Saman, Katrina Pugh, Vanessa Rhinesmith, Heather Staines, et Kaitlin Thaney. 2021. ''Designing a Preparedness Model for the Future of Open Scholarship. Invest in Open Infrastructure''. Juillet 2021. [http://doi.org/10.5281/zenodo.5218968 doi.org/10.5281/zenodo.5218968].

*IOI (Invest in Open Infrastructure). s.d. «&amp;#8239;About IOI&amp;#8239;». [https://investinopen.org/about/ https://investinopen.org/about/].

*Joseph, Heather. 2013. «&amp;#8239;The Open Access Movement Grows Up: Taking Stock of a Revolution&amp;#8239;». ''PLOS Biology'' 11, no. 10: e1001686. [https://doi.org/10.1371/journal.pbio.1001686 https://doi.org/10.1371/journal.pbio.1001686].

*SPARC Europe. 2019. ''A Global Sustainability Committee for Open Science Services: The Case''. [https://sparceurope.org/download/2859/ https://sparceurope.org/download/2859/].

*Tavernier, Willa. 2020. «&amp;#8239;COVID-19 Demonstrates the Value of Open Access&amp;#8239;». ''S&amp;RL News'', mai 2020, [https://crln.acrl.org/index.php/crlnews/article/viewFile/24414/32235 https://crln.acrl.org/index.php/crlnews/article/viewFile/24414/32235].

*Thaney, Kaitlin. 2020. «&amp;#8239;The Open Scholarship Ecosystem Faces a Collapse; It’s Also our Best Hope for a More Resilient Future&amp;#8239;». ''LSE Blog'', 19 juin 2020. [https://blogs.lse.ac.uk/impactofsocialsciences/2020/06/19/the-open-scholarship-ecosystem-faces-collapse-its-also-our-best-hope-for-a-more-resilient-future/ https://blogs.lse.ac.uk/impactofsocialsciences/2020/06/19/the-open-scholarship-ecosystem-faces-collapse-its-also-our-best-hope-for-a-more-resilient-future/].

*UNESCO. 2021. ''Recommendation de l’UNESCO sur une science ouverte''. [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>j4hh2fb4nvkiv3again3uom4i0022fa</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Politique de libre accès du l’UKRI 2021</title>
    <ns>0</ns>
    <id>82359</id>
    <revision>
      <id>745419</id>
      <parentid>745143</parentid>
      <timestamp>2025-06-26T22:48:51Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745419</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="25250" sha1="mtr0d85vh352l2twtlofwthvgh5zm4i" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec remerciements à Matthew Greenhall et Samuel Moore pour ses commentaires et contribution), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En août 2021, [https://www.ukri.org/ UK Research and Innovation (UKRI)] a publié [https://www.ukri.org/news/ukri-announces-new-open-access-policy/ une politique organisationnelle de libre accès] qui s'applique aux publications financées par l'un de [https://www.ukri.org/councils/ ses sept conseils de recherche, Research England et Innovate UK]. Cette nouvelle politique est le résultat d'un processus de consultation qui a débuté en 2018, avec une version de politique pour consultation publié en février 2020 (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Examen et consultation de la politique de L’UKRI sur libre accès|Examen et consultation de la politique de l’UKRI sur libre accès]]&amp;#8239;»). Il s'appuie sur près de deux décennies d'élaboration de politiques de libre accès au Royaume-Uni, notamment le rapport Finch de 2012, la politique et les orientations du Research Excellence Framework (REF) 2021 sur libre accès et les politiques d'accès ouvert existants des conseils de recherche.

Dans le cadre de la nouvelle politique de libre accès, les articles de recherche soumis pour publication à compter du 1er avril 2022 doivent être publiés en libre accès immédiat via l'une des deux voies : dorée ou verte. Dans la voie 1 – libre accès dorée - l'article est publié dans une revue ou une plateforme libre accès (y compris des revues hybrides transformatifs) qui répond à un ensemble de normes techniques pour s'aligner sur [https://www.go-fair.org/fair-principles/ les principes FAIR (Findability, Accessibility, Interoperability, Reusability)]. Ces normes incluent l'utilisation d'identificateurs permanents, des normes de métadonnées, un programme de conservation à long terme et l'inclusion de la politique d'auto-archivage dans [https://v2.sherpa.ac.uk/romeo/ SHERPA/RoMEO] (UKRI 2021c ; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Persistent Identifier (PID) Consortium de Royaume-Uni|Le «&amp;#8239;Persistent Identifier (PID) Consortium&amp;#8239;» de Royaume-Uni]]&amp;#8239;»).

Dans la voie 2 – libre accès verte - l'article est publié dans une revue payante et le manuscrit accepté de l'auteur ou la version de l’éditeur est déposé dans un dépôt institutionnel ou thématique. Une licence [https://creativecommons.org/about/cclicenses/ Creative Commons] doit également être appliquée, soit Attribution (CC BY) ou Attribution–No Derivatives (CC BY ND) 4.0 International. (UKRI 2021a). Le dépôt doit répondre à des normes techniques similaires à celles de la revue libre accès et doit être enregistré dans [https://v2.sherpa.ac.uk/opendoar/ le Directory of Open Access Repositories (OpenDOAR)]. Tous les articles biomédicaux doivent également être déposés dans [https://europepmc.org/ Europe PubMed Central] (politique UKRI 2021b).

Il s'agit de la première politique de libre accès de l’UKRI qui s'applique aux monographies ainsi qu'aux articles (voir  «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les monographies en libre accès|Les monographies en libre accès]]&amp;#8239;»). En vertu de la politique, les publications de forme longue - monographies, collections éditées et chapitres de livre - doivent être en libre accès dans les 12 mois suivant la publication, à compter du 1er janvier 2024, soit par publication sur une plate-forme en libre accès (similaire à la voie 1 ci-dessus ou en libre accès dorées) ou par dépôt du manuscrit accepté de l’auteur dans un dépot (similaire à la voie 2 ou à libre accès verte). Comme pour les articles, une licence CC doit être appliquée, soit CC BY (préféré), CC BY ND, ou Attribution–NonCommercial (CC BY NC) (UKRI 2021a). La politique reconnaît que certaines exceptions rares peuvent être faites lorsque la publication en libre accès n'est pas possible et encourage mais n'exige pas le respect des normes de métadonnées et l'utilisation des identificateurs permanents (UKRI 2021b).

La politique note que ses exigences en matière de licence ne s'appliquent à aucun matériel protégé par le droit d'auteur par une tierce partie, tel que des images ou des cartes, inclus dans des articles ou des publications de longue durée (Royaume-Uni 2021b). Et, bien que la politique ne s'applique pas aux prépublications, elle soutient leur utilisation et leur diffusion, en particulier dans les situations d'urgence (UKRI 2021b).

Pour soutenir la mise en œuvre de la nouvelle politique libre accès, l'UKRI a engagé jusqu'à 47,7 £ millions par an, dont 3,5 £ millions réservés aux monographies libre accès, mais les fonds de soutien ne peuvent être utilisés que pour publier des articles dans des revues hybrides qui ont un accord transformateur en place avec [https://www.jisc.ac.uk/content/open-access/our-role#requirements JISC] (UKRI 2021b ; URKI 2021c). Il s'efforcera de s'assurer que toutes les exigences libre accès futures du Research Excellence Framework (REF) sont conformes à celui-ci et fournira plus de détails sur la mise en œuvre et le financement, en particulier en ce qui concerne les publications de longue durée, plus tard en 2022 (UKRI 2021a ; UKRI 2021b). De plus amples détails sur la mise en œuvre seront disponibles sur le site [https://www.ukri.org/what-we-offer/supporting-healthy-research-and-innovation-culture/open-research/open-access-policies-review/ Shaping Our Open Access Policy] de l'UKRI dès qu'ils seront disponibles.

==Réactions de la communauté INKE==
[https://oaaustralasia.org/2021/08/12/new-ukri-open-access-policy/ Open Access Australasia], membre du partenariat INKE par le biais du [https://inke.ca/canadian-australian-partnership-for-open-scholarship/ Canadian–Australian Partnership for Open Scholarship (CAPOS)], a fait une déclaration en faveur de la nouvelle politique, notant qu'elle offre un exemple utile qui pourrait éclairer [https://oa2020.org/wp-content/uploads/POSTER_12_OpenAccessForAustralia_poster_DrCathyFoley.pdf la stratégie nationale australienne de libre accès], actuellement en cours de consultation.

==La nouvelle politique libre accès de l’UKRI dans la presse==
L'annonce de la politique a été couverte par la presse universitaire, notamment dans [https://physicsworld.com/a/researchers-and-publishers-respond-to-new-uk-open-access-policy/ ''Physics World''], [https://sciencebusiness.net/news/ukri-funded-research-be-published-open-access-journals ''Science Business''] et [https://universitybusiness.co.uk/research/ukri-publishes-new-open-access-policy-for-publicly-funded-research/ ''University Business'']. Comme le montre sa couverture médiatique, la politique de libre accès de l'UKRI bénéficie en principe d'un large soutien de la part de la communauté universitaire, mais les opinions divergent sur la manière dont elle devrait être mise en œuvre (Duncan 2021).

Dans un article au [https://www.timeshighereducation.com/blog/ukris-new-open-access-policy-will-hinder-open-science ''Times Higher Ed''], Carrie Webster (de Springer Nature) affirme que la nouvelle politique de libre accès de l'UKRI fait bien les choses, y compris ses engagements de financement et son exigence que le financement soit utilisé pour soutenir des accords transformatifs. Elle exprime cependant des inquiétudes quant au fait que la politique traite libre accès verte (voie 2) sur un pied d’égalité avec libre accès dorée (voie 1), car cela a le potentiel de saper les objectifs ultimes de la politique en enracinant plutôt qu'en s'éloignant d'un modèle basé sur l'abonnement (Webster 2021).

Un article au [https://www.nature.com/articles/d41586-021-02148-8 ''Nature''] de Richard Van Noorden est moins favorable à la politique, le décrivent  comme strict et le processus de l'UKRI pour déterminer quelles revues hybrides sont éligibles au soutien des frais de publication comme l’indécision (2021). Comme Webster, sa critique se concentre sur le soutien à libre accès vert, mais il fait part de l'inquiétude de la communauté de l'édition britannique que le soutien à libre accès vert féra souffrir des éditeurs en permettant aux auteurs de se conformer sans payer des frais de publication.

==Réaction de la communauté élargie==
L'UKRI a reçu une forte réponse de la communauté au sens large à son projet de politique pour consultation et a partagé [https://www.ukri.org/wp-content/uploads/2021/08/UKRI-060821-UKRIOpenAccessReviewConsultationAnalysis-FINAL.pdf une analyse des 350 réponses qu'elle a reçues].

[https://www.rluk.ac.uk/rluk-welcomes-publication-of-ukris-new-open-access-policy/ Research Libraries UK (RLUK)] a partagé une déclaration de soutien ferme à la nouvelle politique, tout comme [https://www.coalition-s.org/coalition-s-welcomes-the-plan-s-aligned-open-access-policy-from-ukri/ la cOAlition S] et [https://blog.frontiersin.org/2021/08/09/statement-in-support-of-ukris-new-open-access-policy/ Frontiers], ainsi que d'autres parties prenantes ont exprimé leur soutien à la politique avec des inquiétudes quant à sa mise en œuvre.

Bon nombre de ces préoccupations concernent l'élimination de tout embargo sur les articles déposés dans les dépôts. Par exemple, [https://www.publishers.org.uk/publications/the-practical-implications-of-ukris-proposed-open-access-policy-for-the-uks-research-sector/ le Publishers Association] déclare que mettre le libre accès verte sur un pied d'égalité avec dorée - plutôt que comme une option de secours lorsque le libre accès dorée n'est pas disponible - sapera à la fois l'industrie de l'édition et le mouvement libre accès (2021). Des préoccupations similaires ont été exprimées par [https://www.alpsp.org/news/ukri-policy-alpsp-response-aug21 le Copyright Committee de l'Association of Learned and Professional Society Publishers (ALPSP)], [https://www.stm-assoc.org/2021_08_09_STM_response_to_UKRI_Open_Access_Policy.pdf STM] (une organisation industrielle pour les éditeurs universitaires), [https://physicsworld.com/a/researchers-and-publishers-respond-to-new-uk-open-access-policy/ l'Institute of Physics (IOP) Publishing], [https://newsroom.taylorandfrancisgroup.com/taylor-francis-response-to-the-ukri-policy-announcement/ Taylor &amp; Francis] et [https://www.thebookseller.com/news/ukri-announces-new-open-access-policy-1274942 ''The Bookseller''] (un magazine spécialisé dans l'édition). [https://openaccess.ox.ac.uk/wp-content/uploads/sites/2/2021/08/Oxford-UKRI-OA-policy-response-09-08-21-1.pdf L'Université d'Oxford] a publié une déclaration en réponse à l'annonce de la politique exprimant sa préoccupation que les questions soulevées en réponse au projet n'aient pas été entièrement traitées. Il indique que le délai du 1er avril pour les articles est trop court, que les révisions de la politique n'ont pas pris en compte le nombre croissant d'accords transformateurs au Royaume-Uni et que les détails nécessaires sur le financement ne sont pas encore disponibles. En outre, il soutient que l'embargo de 12 mois sur les monographies mettra en péril l'avenir des presses savantes (Oxford 2021).

Jusqu'au 1er avril, date à laquelle la nouvelle politique devait prise effet, ''Nature'' et les autres revues publiées par Springer Nature n'étaient pas incluses dans [https://v2.sherpa.ac.uk/romeo/tjlists.html la liste des revues transformatifs approuvées par Jisc]. Cela a soulevé des inquiétudes quant au fait que le financement de l'UKRI ne pouvait pas être utilisé pour payer les frais de publication pour ces revues, empêchant ainsi les chercheurs et chercheuses de publier dans ces lieux prestigieux. Un accord temporaire de dernière minute entre Jisc et Springer Nature annoncé le 1er avril, en vigueur jusqu'à la fin de 2022, a temporairement résolu ces préoccupations, et Springer Nature devrait avoir un accord transformateur en place pour 2023 et au-delà. Cet accord reste cependant controversé en raison des frais de publication élevés facturés par ''Nature'' de 8290 £ ou 9500 € (Grove 2022).

D'autres intervenants ont exprimé des inquiétudes quant au traitement des monographies par la politique. [https://copim.ac.uk/about-us/ COPIM (Community-led Publication Infrastructures for Monographs)] a publié une réponse à l'appui de la politique, en particulier ses exigences pour les publications savantes de longue durée. Notant que d'autres organisations développent déjà les infrastructures nécessaires à la publication de monographies en libre accès, le COPIM s'oppose à l'exemption de l'éditeur approprié de la politique et aux possibilités d'embargos incluses dans le prochain REF (2021). [https://blog.royalhistsoc.org/2021/08/11/ukri-open-access-protocols-august-2021/ Le Royal Historical Society] du Royaume-Uni soutient généralement la politique et son traitement des publications de longue durée, mais exprime des préoccupations similaires au COPIM, que des détails importants sur le financement et la mise en œuvre restent indéfinis, et comment cette politique affectera la prochaine REF est encore inconnue (Finn et al. 2021 ; COPIM 2021).

Faisant écho aux préoccupations concernant les effets du soutien à libre accès hybride basé sur les frais de publication, la réponse du COPIM avertit que l'établissement d'un système similaire de financement des frais de publication des livres ne peut qu'enraciner davantage l'édition hybride et aggraver les inégalités existantes (COPIM 2021). [https://www.samuelmoore.org/2021/08/09/what-does-the-ukri-policy-mean-for-open-access-book-publishing/ Samuel Moore] exprime des préoccupations similaires, faisant valoir que la politique pourrait faire des frais de publication de monographie le principal modèle commercial pour les monographies libre accès plutôt que de soutenir des modèles d'édition plus innovants et dirigés par la communauté (Moore 2021). Dans le même ordre d'idées, [https://blogs.lse.ac.uk/impactofsocialsciences/2021/09/14/genuine-open-access-to-academic-books-requires-collective-solutions/#comments Lucy Barnes d'Open Book Publishers] soutient en réponse à la nouvelle politique que les modèles de financement collectifs sont le meilleur moyen de financer l'édition longue en libre accès sans compter sur les frais de publication de livres (2021).

==La nouvelle politique libre accès de l’UKRI et la science ouverte==
Les débats sur les effets potentiels de la politique sur l'industrie de l'édition et sur l'économie du Royaume-Uni dans son ensemble mettent en évidence le rôle de la science ouverte dans l'économie mondiale. La nouvelle politique de libre accès de l’UKRI fait partie de la stratégie globale [https://www.gov.uk/government/publications/build-back-better-our-plan-for-growth Build Back Better] du Royaume-Uni, une réponse à la pandémie de COVID-19 qui comprend des investissements importants dans la recherche et développement pour soutenir la croissance économique (Ficarra et Johnson 2021 ; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Science Ouverte et COVID-19|Science ouverte et COVID-19]]&amp;#8239;») .

Cependant, [https://www.publishers.org.uk/wp-content/uploads/2021/02/FTI-Report-for-Publishers-Association-1.pdf un rapport sur les effets économiques potentiels de la nouvelle politique de libre accès] de FTI Consulting, commandé par le Publishers Association, conclut que la politique affectera négativement l'économie britannique (2021). Plus précisément, il constate que la suppression de la période d'embargo pour les articles publiés via le libre accès verte faire souffrir la capacité des éditeurs à récupérer leurs investissements dans les publications de recherche, avec des répercussions sur l'économie du Royaume-Uni dans son ensemble (9-10, 40). En réponse à ce rapport, [https://theplosblog.plos.org/2021/03/open-response-to-fti-consulting-report/ PLOS] fait valoir qu'en limitant son analyse aux effets économiques du libre accès sur l'industrie de l'édition - et sur les modèles d'édition traditionnels - le rapport ne tient pas compte des avantages généralisés du libre accès dans la science ouverte et au-delà (2021).

L'UKRI est un membre fondateur de la cOAlition S, et l'appel de la politique pour un libre accès immédiat et sans embargo s'aligne sur le Plan S et d'autres politiques de financement internationales (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;» et «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Mise à jour du Plan S : L’élargissement de l’adhésion de la cOAlition S|Mise à jour du Plan S: L’élargissement de l’adhésion de la cOAlition S]]&amp;#8239;») (O'Grady 2021 ; UKRI 2021a). L'exigence d'une licence Creative Commons met également la politique de l'UKRI en conformité avec la stratégie de conservation des droits du Plan S, qui a soulevé des inquiétudes quant aux impacts sur la science ouverte dans son ensemble, y compris la possibilité de rejets généralisés de manuscrits lorsque la politique de la revue exige le transfert du droit d'auteur et la l'effondrement des revues hybrides qui choisissent de ne passer pas à libre accès, mais Stephen Eglen soutient que bon nombre de ces préoccupations sont exagérées (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Mise à jour du Plan S : L’élargissement de l’adhésion de la cOAlition S|Mise à jour du Plan S: La Stratégie de conservation des droits]]&amp;#8239;» ; Eglen 2021).

La déclaration du Jisc en réponse à la politique souligne son importance au sein de l'écosystème des communications savantes et de la communauté au sens large, déclarant que la politique aidera la transition durable vers le libre accès complet et immédiat (2021). Étant donné que le Royaume-Uni est un leader mondial de l’édition en libre accès, la nouvelle politique de l’UKRI est une contribution significative à l'avancement de la science ouverte dans le monde entier.

==Ouvrages citées==
*Barnes, Lucy. «&amp;#8239;Genuine Open Access to Academic Books Requires Collective Solutions&amp;#8239;». ''LSE Blog''. 14 septembre 2021. [https://blogs.lse.ac.uk/impactofsocialsciences/2021/09/14/genuine-open-access-to-academic-books-requires-collective-solutions/#comments https://blogs.lse.ac.uk/impactofsocialsciences/2021/09/14/genuine-open-access-to-academic-books-requires-collective-solutions/#comments].

*COPIM (Community-led Publication Infrastructures for Monographs). 2021. «&amp;#8239;COPIM Response to new UKRI Open Access Policy&amp;#8239;». 11 août 2021. [https://copim.pubpub.org/pub/copim-response-to-new-ukri-open-access-policy/release/2 https://copim.pubpub.org/pub/copim-response-to-new-ukri-open-access-policy/release/2].

*Duncan, Bruce. «&amp;#8239;URKI Open Access Policy: A Revolution in Scholarly Communication?&amp;#8239;» ''Times Higher Ed''. 19 août 2021. [https://www.timeshighereducation.com/news/ukri-open-access-policy-revolution-scholarly-communication https://www.timeshighereducation.com/news/ukri-open-access-policy-revolution-scholarly-communication].

*Eglen Stephen J. 2021. «&amp;#8239;How will the Rights Retention Strategy affect Scholarly Publishing?&amp;#8239;» ''LSE Blog'', 10 septembre 2021. [https://blogs.lse.ac.uk/impactofsocialsciences/2021/09/10/how-will-the-rights-retention-strategy-affect-scholarly-publishing/ https://blogs.lse.ac.uk/impactofsocialsciences/2021/09/10/how-will-the-rights-retention-strategy-affect-scholarly-publishing/].

*Ficarra, Victoria, et Rob Johnson. 2021. «&amp;#8239;Guest Post – Five Things you Need to Know about UKRI’s New Open Access Policy&amp;#8239;». ''The Scholarly Kitchen''. 3 novembre 2021. [https://scholarlykitchen.sspnet.org/2021/11/03/guest-post-five-things-you-need-to-know-about-ukris-new-open-access-policy/ https://scholarlykitchen.sspnet.org/2021/11/03/guest-post-five-things-you-need-to-know-about-ukris-new-open-access-policy/].

*Finch, Janet et le Working Group on Expanding Access to Published Research Findings. 2012. ''Accessibility, Sustainability, Excellence: How to Expand Access to Research Publications''. Research Information Network. Grande Bretagne. [https://apo.org.au/node/29938 https://apo.org.au/node/29938].

*Finn, Margot, Richard Fisher, Emma Griffin et Peter Mandler. 2021. «&amp;#8239;UKRI Open Access Protocols: August 2021&amp;#8239;». ''Historical Transactions'', Royal Historical Society. [https://blog.royalhistsoc.org/2021/08/11/ukri-open-access-protocols-august-2021/ https://blog.royalhistsoc.org/2021/08/11/ukri-open-access-protocols-august-2021/].

*FTI Consulting. 2021. ''Economic Assessment of the Impact of the New Open Access Policy Developed by UK Research and Innovation''. [https://www.publishers.org.uk/wp-content/uploads/2021/02/FTI-Report-for-Publishers-Association-1.pdf https://www.publishers.org.uk/wp-content/uploads/2021/02/FTI-Report-for-Publishers-Association-1.pdf].

*Grove, Jack. 2022. «&amp;#8239;Late Reprieve Allows Scientists with UK Grants to Publish in Nature&amp;#8239;». ''Times Higher Education (THE)'', 14 avril 2022. [https://advance.lexis.com. https://advance.lexis.com.]

*Jisc. 2021. «&amp;#8239;New UKRI Policy is a ‘Significant Driver’ Towards Open Access Research&amp;#8239;». ''Jisc Blog''. 6 août 2021. [https://www.jisc.ac.uk/blog/new-ukri-policy-is-a-significant-driver-towards-open-access-research-06-aug-2021 https://www.jisc.ac.uk/blog/new-ukri-policy-is-a-significant-driver-towards-open-access-research-06-aug-2021].

*Moore, Samuel. 2021. «&amp;#8239;What Does the UKRI Policy Mean for Open Access Book Publishing?&amp;#8239;» 9 août 2021. [https://www.samuelmoore.org/2021/08/09/what-does-the-ukri-policy-mean-for-open-access-book-publishing/ https://www.samuelmoore.org/2021/08/09/what-does-the-ukri-policy-mean-for-open-access-book-publishing/].

*O’Grady, Cathleen. 2021. «&amp;#8239;Major U.K. Science Funder to Require Grantees to Make Papers Immediately Free to All&amp;#8239;». ''Science''. 6 août 2021. [https://www.science.org/content/article/major-uk-science-funder-require-grantees-make-papers-immediately-free-all https://www.science.org/content/article/major-uk-science-funder-require-grantees-make-papers-immediately-free-all].

*Oxford University. 2021. «&amp;#8239;Oxford UKRI OA Policy Response&amp;#8239;». 9 août 2021. [http://openaccess.ox.ac.uk/wp-content/uploads/sites/2/2021/08/Oxford-UKRI-OA-policy-response-09-08-21-1.pdf http://openaccess.ox.ac.uk/wp-content/uploads/sites/2/2021/08/Oxford-UKRI-OA-policy-response-09-08-21-1.pdf].

*PLOS. «&amp;#8239;Open Response to ‘Economic Impact of UKRI Open Access Policy’ Report&amp;#8239;». ''The Official PLOS Blog''. 17 mars 2021. [https://theplosblog.plos.org/2021/03/open-response-to-fti-consulting-report/ https://theplosblog.plos.org/2021/03/open-response-to-fti-consulting-report/].

*Publishers Association. 2021. ''The Practical Implications of UKRI’s Proposed Open Access Policy for the UK’s Research Sector''. 23 juin 2021. [https://www.publishers.org.uk/publications/the-practical-implications-of-ukris-proposed-open-access-policy-for-the-uks-research-sector/ https://www.publishers.org.uk/publications/the-practical-implications-of-ukris-proposed-open-access-policy-for-the-uks-research-sector/].

*UKRI. 2021a. «&amp;#8239;UKRI Announces New Open Access Policy&amp;#8239;». UK Research and Innovation [https://www.ukri.org/news/ukri-announces-new-open-access-policy/ https://www.ukri.org/news/ukri-announces-new-open-access-policy/].

*UKRI. 2021b. ''UKRI Open Access Policy''. UK Research and Innovation, [https://www.ukri.org/publications/ukri-open-access-policy/ https://www.ukri.org/publications/ukri-open-access-policy/].

*UKRI. 2021c. «&amp;#8239;UKRI Open Access Policy – Explanation of Policy Changes&amp;#8239;». 6 août 2021. [https://www.ukri.org/wp-content/uploads/2021/08/UKRI-180821-UKRIOpenAccessPolicyExplanationOfChanges-2.pdf https://www.ukri.org/wp-content/uploads/2021/08/UKRI-180821-UKRIOpenAccessPolicyExplanationOfChanges-2.pdf]

*Van Noorden, Richard. «&amp;#8239;Major UK Science Funder Unveils Strict Open-Access Policy&amp;#8239;». ''Nature''. 6 août 2021. [https://doi.org/10.1038/d41586-021-02148-8 https://doi.org/10.1038/d41586-021-02148-8].

*Webster, Carrie. 2021. «&amp;#8239;UKRI’s New Open Access Policy will Hinder Open Science&amp;#8239;». ''Times Higher Ed''. 3 septembre 2021. [https://www.timeshighereducation.com/blog/ukris-new-open-access-policy-will-hinder-open-science https://www.timeshighereducation.com/blog/ukris-new-open-access-policy-will-hinder-open-science].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>mtr0d85vh352l2twtlofwthvgh5zm4i</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le rapport The state of open data 2021</title>
    <ns>0</ns>
    <id>82360</id>
    <revision>
      <id>745420</id>
      <parentid>745144</parentid>
      <timestamp>2025-06-26T22:54:31Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745420</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="10308" sha1="8usrdnm4d1bgswn2ixa47o0pu2obubm" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec remerciements à Ian Duncan et John Simpson pour ses commentaires et contribution), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

Le rapport [https://digitalscience.figshare.com/articles/report/The_State_of_Open_Data_2021/17061347/1 ''The state of open data 2021''] (en anglais seulement) a été publié en novembre 2021. Il est le sixième rapport de la série publiée par [https://www.springernature.com/gp Springer Nature], [https://www.digital-science.com/ Digital Science] et [https://figshare.com/ Figshare] et présente les résultats d'une enquête longitudinale de six ans qui a recueilli des données sur les perceptions et comportements des chercheurs et chercheures concernant des données ouvertes si même que leurs motivations et défis (Digital Science, 2021, 5). L'enquête a reçu plus de 21 000 réponses individuelles de 192 pays, et l[https://figshare.com/articles/dataset/State_of_Open_Data_Survey_2021_additional_resources/17081231/1 'enquête et les données de réponse] sont librement accessibles en ligne.

Le rapport est structuré comme une série d’analyses courtes par des auteurs travaillant dans des bibliothèques, des maison d’édition et des organismes de recherche et d'information, le tout encadré par un avant-propos et une introduction.

L'avant-propos de Natasha Simons de l'Australian Research Data Commons (ADRC) (4–8) contextualise les conclusions du rapport dans le cadre de la réponse mondiale collaborative à la pandémie de COVID-19, nous appelant d’imaginer ce que nous pourrions faire de plus si les données de recherche étaient ouvertes et partagées. Simons souligne l’importance d'une infrastructure de recherche solide et l’expertise pour la faire fonctionner, comme des dépôts de données et des installations informatiques de recherche avancées (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le Rapport sur l’infrastructure ouverte du projet Future of Open Scholarship|Le rapport sur l’infrastructure ouverte du projet ‹&amp;#8239;Future of Open Scholarship&amp;#8239;›]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/NOIRN et la stratégie canadienne d’infrastructure de recherche numérique|NOIRN et le stratégie canadienne d’infrastructure de recherche numérique]]&amp;#8239;»). Elle souligne également la [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre ''Recommandation de l'UNESCO sur une science ouverte''] comme un politique repère pour soutenir et promouvoir la science ouverte dans ses 193 États membres (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|La Recommandation de l'UNESCO sur la science ouverte]]&amp;#8239;»).

L'introduction de Greg Goodey de Springer Nature et Megan Hardeman de Figshare (9-11) met en évidence les trois conclusions principales de l'enquête :
* Bien que les chercheurs et chercheures souhaitent accroître la visibilité et l'impact de leur travail, le considérant comme un bien public, ils craignent que leurs données ne soient utilisées à mauvais escient, qu'ils ne reçoivent pas le crédit approprié pour leur travail et que des problèmes de droit d'auteur et de licence ne leur soient attribués.
* Les réponses indique plus familiers avec [https://www.nature.com/articles/sdata201618 les principes de données FAIR (Findable, Accessible, Interoperable, Reusable)] et le réutiliser des données que par le passé.
* Le soutien des bibliothèques institutionnelles, des dépôts et des éditeurs et éditrices, en particulier en ce qui concerne le droit d'auteur et les licences, la recherche de dépôts appropriés et la gestion des données sont impératif.

Les analyses qui suivent contextualisent et discutent les données de l'enquête sous divers angles. Plusieurs sont regroupés avec un objectif commun sur la conservation des données, examinant les rôles des communautés du conservation et d’édition, l'importance de la collaboration et l'importance de l'infrastructure consolidée de gestion des données de recherche (GDR) (12-23). D'autres articles se concentrent sur les principaux résultats de l'enquête pour les sciences de la vie (24-25), le développement d'une plateforme de données ouvertes au Japon (26-28), des conseils pour engager les chercheurs et chercheures dans les pratiques de données ouvertes, d'un point de vue sud-africain (29-32), et l'importance des données ouvertes pour renforcer la confiance du public dans la recherche en général (33-35).

Deux thèmes se dégagent de ce rapport. La première est que nous avons besoin de données ouvertes pour relever des défis complexes à l'échelle mondiale tels que la pandémie de COVID-19 (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Science Ouverte et COVID-19|Science ouverte et COVID-19]]&amp;#8239;»). Une autre est que l'ouverture des données n'est pas un processus passif : les experts et expertes en conservation des données travaillent activement avec les chercheurs et chercheures pour s'assurer que leurs données sont conformes aux principes FAIR, et les infrastructures, y compris les infrastructures techniques et les infrastructures d'information telles que les normes de métadonnées, doivent être développées et maintenues avec soin, souvent par le biais de collaborations entre chercheurs et chercheures, bibliothécaires, les maisons d’édition et autres parties prenantes. La formation à toutes les étapes est essentielle.

==Le rapport et la communauté INKE==
Le rapport présente une analyse de Ginny Barbour [https://oaaustralasia.org/ d’Open Access Australasia], membre de l'INKE par le biais du [https://inke.ca/canadian-australian-partnership-for-open-scholarship/ Canadia-Australian Partnership for Open Scholarship (CAPOS)] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Canadian–Australian Partnership for Open Scholarship (CAPOS)|Le Canadian-Australian Partnership for Open Scholarship (CAPOS)]]&amp;#8239;»).

Barbour note que les problèmes liés aux données ouvertes abordés dans le rapport se rapportent à un contexte plus large d'ouverture, de systèmes d'incitations universitaires et de qualité et de confiance dans la recherche. Elle soutient que l'édition savante doit se concentrer davantage sur la reproductibilité et renforcer la confiance du public dans la recherche, qui sont toutes deux soutenues par des données ouvertes (33-35).

==Le rapport et la communauté élargie==
Le rapport a été [https://figshare.altmetric.com/details/117861518 largement consulté], avec plus de 9600 vues et 2200 téléchargements. Il a également été partagé entre les communautés de l'édition, des bibliothèques et de la recherche sur Twitter et d'autres voies, notamment [https://apo.org.au/node/315373 l’Analysis &amp; Policy Observatory] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/L'Analysis &amp; Policy Observatory|l’Analysis &amp; Policy Observatory]]&amp;#8239;», [https://www.charleston-hub.com/2021/11/the-state-of-open-data-2021-global-attitudes-towards-open-data-published-today-plus-more-atg-news-announcements-for-12-1-21/ Charleston Hub], [https://www.cni.org/news/catching-up-on-several-recent-reports la Coalition of Networked Information], l[https://www.infodocket.com/2021/11/30/the-state-of-open-data-2021-global-attitudes-towards-open-data-published-today/ 'InfoDocket du ''Library Journal''] et [https://www.researchinformation.info/news/state-open-data-2021-survey-results Research Information].

==Le rapport et la science ouverte==
Les données ouvertes sont une branche du mouvement plus large de la science ouverte, avec le libre accès, l'éducation ouverte et d'autres pratiques savante ouvertes. Les infrastructures ouvertes telles que les dépôts institutionnels et de données et les pratiques telles que la GDR sont fondamentales pour les données ouvertes et pour ouvrir la science plus largement (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Les principes TRUST pour les dépôts numériques|Les principes TRUST pour les dépôts numériques]]&amp;#8239;» et «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Renforcement des capacités de GDR au Canada et la série de rapports Insights de Portage|Renforcement des capacités de GDR au Canada et la série de rapports Insights de Portage]]&amp;#8239;»).

La prise de conscience croissante des données ouvertes que décrit le rapport est alignée sur l'élan du mouvement des données ouvertes ces dernières années, alors que la recherche dans toutes les disciplines et tous les domaines devient de plus en plus axée sur les données. En 2020, neuf groupes représentant plus de 160 instituts de recherche à travers le monde ont signé [https://www.leru.org/files/Sorbonne-declaration.pdf la Déclaration de la Sorbonne sur les droits relatifs aux données de recherche], qui appelle à l'élaboration de cadres juridiques et institutionnels pour un partage responsable des données, conformément aux principes FAIR (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La déclaration de la Sorbonne sur les droits relatifs aux données de recherche|La Déclaration de la Sorbonne sur les droits relatifs aux données de recherche]]&amp;#8239;»). Le rapport ''State of Open Data 2021'' met en évidence les problèmes qu'il est important de prendre en compte à mesure que le mouvement progresse.

==Ouvrage cité==
*Digital Science, Natasha Simons, Greg Goodey, Megan Hardeman, Connie Clare, Sara Gonzales et al. 2021. ''The State of Open Data 2021''. Digital Science. [https://doi.org/10.6084/m9.figshare.17061347.v1 https://doi.org/10.6084/m9.figshare.17061347.v1].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>8usrdnm4d1bgswn2ixa47o0pu2obubm</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les mesures alternatives pour l’évaluation de la recherche</title>
    <ns>0</ns>
    <id>82361</id>
    <revision>
      <id>745421</id>
      <parentid>745145</parentid>
      <timestamp>2025-06-26T22:57:27Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745421</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="27158" sha1="sh1xiknv5x9v9sumtca1criyikvgmrc" xml:space="preserve">''Ce observation a été écrit par Caroline Winter (avec remerciements à Mike Taylor pour ses commentaires et contribution), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

Ces dernières années, de nombreux appels ont été lancés pour modifier les politiques d'évaluation de la recherche afin de moins se compter sur les mesures de citation au niveau des revues telles que le Journal Impact Factor (JIF), y compris deux initiatives internationales clés. [https://sfdora.org/read/ Le San Francisco Declaration on Research Assessment (DORA)], élaborée lors de la réunion annuelle de l'American Society for Cell Biology en 2012, appelle à l'utilisation de mesures au niveau de l'article, à une plus grande transparence dans les politiques et procédures d'évaluation de la recherche et à la prise en compte de tous les types des résultats de la recherche, pas seulement des articles de revues.

[https://www.nature.com/articles/520429a Le Leiden Manifesto], rédigé par Diana Hicks, Paul Wouters, Ludo Waltman, Sarah de Rijcke et Ismael Rafols et publié dans ''Nature'' en 2015, attire l'attention sur le problème de l'évaluation de la recherche – au niveau de l'individu, de la revue et du institution – repose de plus en plus sur des mesures qui sont souvent appliquées et interprétées de manière inappropriée. Il présente dix principes pour guider la politique d'évaluation de la recherche à tous les niveaux, soulignant que les mesures quantitatives et les mesures qualitatives doivent être utilisées en combinaison pour produire une évaluation de la recherche bien informée et pleinement contextualisée.

De nombreux membres de la communauté universitaire ont proposé l'utilisation de mesures alternatives ou «&amp;#8239;altmetrics&amp;#8239;» parallèlement aux mesures de citation pour quantifier l'impact de la recherche de manière plus nuancée. Dans leur [https://er.educause.edu/articles/2016/3/the-use-of-altmetrics-in-promotion-and-tenure étude sur l'utilisation des mesures dans l'examen du rendement, la promotion et la titularisation], par exemple, Stacy Konkiel, Cassidy Sugimoto et Sierra Williams (2016) notent que les mesures alternatives peuvent fournir une image plus complète de la façon dont la recherche est utilisée par des groupes extérieurs à l'académie, tels que les décideurs politiques et le public, y compris les résultats de recherche autres que les articles de revues, tels que le code, les rapports, les jeux de données et les logiciels. Ils notent, faisant écho aux préoccupations de la communauté universitaire au sens large, que les mesures quantitatives ne peuvent à elles seules donner une image complète de l'impact de la recherche.

==À propos des mesures alternatives==
Contrairement aux mesures de citation qui retracent les citations de publications savantes formelles – principalement des articles de revues – dans d'autres publications savantes formelles, les données des mesures alternatives retracent diverses formes d'engagement avec de nombreux types de productions savants, non seulement des articles et des monographies, mais aussi des jeux de données, du code et des ressources pédagogiques.

Comme le soulignent Jason Priem, Dario Taraborelli, Paul Groth et Cameron Neylon dans [http://altmetrics.org/manifesto/ ''Altmetrics : A Manifesto''] (2010), étant donné qu'une grande partie du discours universitaire et public se déroule désormais en ligne, il est possible de recueillir des données sur les formes d'engagement dans la recherche universitaire qui ne pouvaient pas être capturés ou mesurés auparavant. Ce manifeste note que, contrairement aux des comptes de citations qui évoluent lentement, sont relativement étroits et manquent souvent de transparence, les mesures alternatives évoluent rapidement et reflètent la diversité de l'écosystème de la communication savante en examinant les résultats au-delà des publications savantes formelles.

«&amp;#8239;Des mesures alternatives&amp;#8239;» ou «&amp;#8239;altmetrics&amp;#8239;» est un terme générique qui fait référence à une variété de mesures mesurant de nombreux types d'engagement, en s'appuyant sur les domaines de la bibliométrie, de la scientométrie et de la webométrie (Taylor 2020). Ces types d'engagement sont souvent classés comme suit :
* Utilisation : téléchargements, vues
* Enregistrement : signets, sauvegardes, partages
* Mentions : dans les blogs, articles de presse, [https://fr.wikipedia.org/ Wikipédia]
* Médias sociaux : partages et likes sur [https://www.facebook.com/ Facebook], [https://www.instagram.com/' Instagram], [https://ca.linkedin.com/ LinkedIn], [https://www.pinterest.ca/ Pinterest], [https://twitter.com/home Twitter]
* Citations : dans des ressources scientifiques, des bases de données, ainsi que des rapports, des brevets, des politiques et d'autres formes de littérature grise (King et Thuna 2013 ; Tananbaum 2013)

Les données des mesures alternatives sont générées à l'aide d'interfaces de programmes d'applications (API), qui collectent des données sur l'utilisation, les captures, les mentions, etc., à partir de diverses sources :
* Outils de gestion des citations : [https://www.mendeley.com/ Mendeley], [https://www.zotero.org/ Zotero]
* Bases de données et plateformes similaires : bases de données de citations, bases de données savantes, [https://opensyllabus.org/ Open Syllabus], [https://publons.com/about/home/ Publons]
* Dépôts de données, de sujets et institutionnels
* Sites de partage multimédia : [https://www.slideshare.net/ SlideShare], [https://www.youtube.com/ YouTube], [https://github.com/ GitHub]
* Sites de partage de signets social : [https://www.bibsonomy.org/ BibSonomy], [https://facultyopinions.com/ Faculty Opinions], [https://www.goodreads.com/ Goodreads]
* Forums communautaires : [https://www.reddit.com/ Reddit], [https://stackoverflow.com/questions Stack Overflow Questions]
* Réseaux sociaux : [https://www.academia.edu/ Academia], [http://www.facebook.com/ Facebook], [https://www.instagram.com/ Instagram], [https://www.pinterest.ca/ Pinterest], [https://twitter.com/home Twitter], [https://www.researchgate.net/ ResearchGate]
* Wikis et blogs : [http://www.researchblogging.org/ ResearchBlogging], [http://www.scienceseeker.org/ ScienceSeeker], [https://fr.wikipedia.org/ Wikipédia], blogs sur [https://wordpress.com/ WordPress]

Les données peuvent être collectées pour la recherche seulement avec un identifiant pérenne (PID), tel qu'un DOI, et seulement lorsque ce PID est utilisé (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Persistent Identifier (PID) Consortium de Royaume-Uni|Le ‹&amp;#8239;Persistent Identifier (PID) Consortium&amp;#8239;› de Royaume-Uni]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche|Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche]]&amp;#8239;»). Cela signifie que les informations pour les livres, chapitres de livres et autres ressources qui n'ont pas de DOI ou d'autres PID ne peuvent pas être collectées (voir Taylor 2020).

Alors que les mesures alternatives ont gagné en popularité au cours de la dernière décennie, de nombreux outils et services ont été développés pour collecter, analyser et partager les données. Bien que le paysage évolue rapidement, au moment de la rédaction de cet observation, certains des outils des mesures alternatives dédiés et des services les plus largement utilisés sont les suivants :
* [https://www.altmetric.com/explorer/login Altmetric Explorer] et l’[https://www.altmetric.com/about-our-data/the-donut-and-score/ Altmetric Attention Score]
* [https://www.programmableweb.com/api/citedin CitedIn]
* [https://www.crossref.org/services/event-data/ Crossref Event Data]
* [https://scholar.google.com/intl/en/scholar/metrics.html Google Scholar Metrics]
* [https://profiles.impactstory.org/ Impactstory]
* [https://info.growkudos.com/research-stories Kudos]
* [https://www.lagotto.io/ Lagotto]
* [https://www.mendeley.com/?interaction_required=true Mendeley Readership metric]
* [https://plos.org/publish/metrics/ PLOS Article Level Metrics]
* [https://plumanalytics.com/ PlumX] et le [https://plumanalytics.com/visualizing-impact-the-plum-print/ Plum Analytics Plum Print]
* [https://explore.researchgate.net/display/support/RG+Score ResearchGate RG Score]
* [https://www.ssrn.com/index.cfm/en/ Social Science Research Network (SSRN)]

==Altmetrics et politique==
[https://www.at2oa.at/at2oa2_home.html L'Austrian Transition to Open Access 2 (AT2OA2)], une initiative nationale visant à transformer les publications de recherche en libre accès, s'associe à Altmetric pour étudier l'effet du libre accès sur la visibilité des publications utilisant des mesures alternatives. Cela semble être la première instance des mesures alternatives utilisée dans un programme national d'évaluation de la recherche (Jour 2021).

En plus de leur pertinence pour les changements dans la politique d'évaluation de la recherche, les mesures alternatives rendent également visible l'impact de la recherche sur l'élaboration des politiques. [https://www.altmetric.com/ Altmetric], par exemple, collecte des données à partir de documents politiques, et son fondateur, Euan Adie, a fondé la base de données politiques [https://www.overton.io/ Overton] en 2019 qui permet de retracer les références aux publications savantes dans divers types de documents politiques, à différents niveaux de granularité, y compris par discipline et domaine. Une analyse a révélé, par exemple, que le plus grand nombre de citations de recherche dans le corpus d'Overton concernait la recherche en sciences sociales et humaines (Szomszor et Adie 2022).

==Des mesures alternatives pour l'évaluation de la recherche dans la presse==
Dans un article publié dans ''Science'', [https://www.science.org/content/article/twitter-transformed-science-communication-pandemic-will-last Jeffrey Brainard] (2022) explore l'utilisation de Twitter par les chercheurs et les chercheuses pour partager des recherches sur le COVID-19 (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Science Ouverte et COVID-19|Science Ouverte et COVID-19]]&amp;#8239;»]). Il note que, bien que les preuves soient encore mitigées reliant les données des mesures alternatives aux pratiques de citation, cela démontre l'intérêt et l'engagement du public dans la recherche.

Un article dans ''Forbes'' par [https://www.forbes.com/sites/alexzhavoronkov/2022/03/17/measuring-attention-in-science-and-technology/ Alex Zhavoronkov] (2022) se concentre sur l'attention plutôt que sur l'impact de la recherche, s'appuyant sur une discussion de scientifiques célèbres. Il comprend une déclaration de Kathy Christian d'Altmetric selon laquelle les chercheurs et les chercheuses devraient viser à atteindre les publics qui seraient les plus intéressés par leur travail plutôt que d'essayer d'augmenter leur score Altmetric pour son propre bien.

Les mesures alternatives et l'évaluation de la recherche ont également été couverts dans la presse universitaire, comme dans le ''Chronicle'' : [https://www.chronicle.com/article/rise-of-altmetrics-revives-questions-about-how-to-measure-impact-of-research/ un article de 2013] décrit les expériences d'un chercheur visant à inclure ces données dans son dossier de titularisation, et [https://www.chronicle.com/article/someday-altmetrics-will-no-longer-need-alt/ un entretien avec Jason Priem] de 2016 explique comment le paysage des mesures alternatives a changé depuis leur introduction. Un article de 2017 dans [https://www.researchinformation.info/feature/rise-and-rise-altmetrics ''Research Information''] exprime un optimisme prudent quant aux possibilités offertes par les métriques alternatives et souligne que, ayant appris comment les métriques peuvent être utilisées à mauvais escient, les fournisseurs de métriques alternatives, les bibliothécaires et d'autres membres de la communauté de la recherche reconnaissent l'importance de l'éducation et de la formation sur la signification des métriques et comment elles doivent être interprétées.

==Réponses de la communauté INKE==
Les mesures d’impact alternatives est depuis longtemps un sujet d'intérêt pour les membres de la communauté INKE. En 2013, [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC)] a publié [https://www.carl-abrc.ca/doc/CARL2013-altmetrics-FR-FA2.pdf ''Les mesures d’impact alternatives : mise en contexte''], une introduction destinée aux chercheurs et chercheuses décrivant les principes de base de ces mesures et certains outils et services pertinents (King et Thuna).

En 2019, [https://pkp.sfu.ca/ le Public Knowledge Project (PKP)] a annoncé le lancement de [https://pkp.sfu.ca/2019/04/30/announcing-the-ojs-paperbuzz-plugin/ Paperbuzz], un plugin ouvert pour [https://pkp.sfu.ca/ojs/ Open Journal Systems (OJS)] qui utilise les données de l'organisation à but non lucratif Crossref, construite en partenariat avec Impactstory. [https://profiles.impactstory.org/ Impactstory] est un outil des mesures d’impact alternatives source ouvert développé par [https://ourresearch.org/about OurResearch], l'organisation à but non lucratif qui a créé [http://unpaywall.org/ Unpaywall].

[https://journals.publishing.umich.edu/jep/article/id/788/ Une étude de Paul Arthur et Lydia Hearn (2021)] met en évidence les relations entre des mesures alternatives et politique, notant que ces mesures permettent d'évaluer les types d'impacts mis en avant dans des politiques telles que le Research Evaluation Framework au Royaume-Uni et le Crowdsourcing and Citizen Science Act (2016) aux États-Unis. Arthur et Hearn notent que l'environnement politique se dirige vers développer des moyens plus ouverts et congruents pour les universités de remodeler leur évaluation de l’impact de la recherche, mais des obstacles subsistent. Certains de ces obstacles incluent le manque de données de qualité (données dynamiques agrégées à partir de sources complexes et hétérogènes) ainsi que la dépendance à l'égard d'outils commerciaux et de sources de données. L'incomplétude des ensembles de données disponibles est une autre préoccupation, car seuls les résultats de recherche qui ont des PID peuvent être suivis, et les données ne sont collectées qu'à partir de certaines plateformes en ligne. Arthur et Hearn soulignent également que les mesures alternatives ne mesurent que le flux d'informations dans la sphère en ligne ; ils ne saisissent pas le flux d'informations dans les deux sens qui constitue un véritable engagement communautaire.

[https://co-shs.ca/fr/recherche/decouvrir/social-media-engine/ Le Social Media Engine], dirigé par Luis Meneses avec [https://co-shs.ca/fr/ CO.SHS], fournit un cas d'utilisation pour optimiser des données de mesures d’impact alternatives pour un plus grand impact de la recherche. Il génère une liste de sujets à partir du corpus de publications d'[https://www.erudit.org/fr/ Érudit] en sciences humaines et sociales, tweete des liens vers des publications en libre accès liées à des sujets abordés sur les médias sociaux et surveille les données d'Altmetric pour identifier les publications tendances (Meneses et al. 2019).

==Réponses de la communauté universitaire élargie==
En 2013, [https://sparcopen.org/ SPARC] a publié [https://sparcopen.org/wp-content/uploads/2016/01/SPARC-ALM-Primer.pdf une introduction sur les mesures au niveau de l'article] qui clarifie en quoi elles se distinguent des mesures alternatives et discute de leurs possibilités et limites.

Les mesures d’impact alternatives et l'évaluation de la recherche sont également une question d'intérêt pour [https://ec.europa.eu/info/index_fr la Commission européenne], qui a créé un groupe d'experts sur l'Altmetrics en 2016. Son rapport [https://op.europa.eu/fr/publication-detail/-/publication/b858d952-0a19-11e7-8a35-01aa75ed71a1 ''Next Generation Metrics: Responsible Metrics and Evaluation for Open Science''] (2017) souligne que les métriques auront un rôle clé dans faire progresser l'érudition ouverte, mais que les mesures nouvelles et existantes doivent être utilisées de manière responsable et transparente. Il fait référence à des initiatives récentes visant à explorer les défis associés à l'utilisation de métriques, notamment DORA et le Leiden Manifesto. Il fait également référence au mouvement néerlandais [https://scienceintransition.nl/en Science in Transition], fondé en 2013, qui se concentre sur l'amélioration de la reproductibilité et de la qualité globale de la recherche scientifique, et à [https://responsiblemetrics.org/the-metric-tide-report-now-published/ ''The Metric Tide''], un rapport de 2015 sur le rôle des mesures dans l'évaluation de la recherche au Royaume-Uni.

[https://www.scholcommlab.ca/ Le ScholCommLab] a un courant de recherche dédié au [https://www.scholcommlab.ca/research/altmetrics-and-societal-impact/ mesures alternatives et à l'impact sociétal], et ses nombreuses publications connexes traitent de questions telles que les mesures des médias sociaux, les mesures alternatives et les modèles de citations, ainsi que le rôle des mesures dans les politiques d'examen, de promotion et de titularisation.

==Mesures pour l'évaluation de la recherche et la science ouvertes==
Les mesures d’impact alternatives a un rôle clé à jouer dans l'avancement de la science ouverte dans le cadre de l'infrastructure numérique sur laquelle la science ouverte est construite. Par exemple, ces mesures peut améliorer la compréhension des avantages de la publication libre accès : Michael Taylor a trouvé que les articles, livres et chapitres de livres en libre accès ont tendance à recevoir davantage d'attention en ligne que les altmetrics captent (2020).

Dans son exposé sur les services de bibliothèque et les mesures alternatives pour la science ouverte, [https://www.youtube.com/watch?v=BNkGlWUCUiU David Walters] (2015) affirme qu’ils ont une relation réciproque : les liens sont plus susceptibles d'être partagés lorsqu'ils mènent à un contenu ouvert plutôt qu'à des murs payants, par exemple, et les recherches partagées sur les réseaux sociaux ont tendance à être citées plus souvent. Il note que les bibliothèques sont des moteurs clés du changement culturel nécessaire pour faire progresser la science ouverte, notamment grâce à leur adoption d'innovations telles que les mesures alternatives.

Les mesures alternatives offre des incitations à faire la science ouverte. Dans un contexte institutionnel, leur inclusion dans les politiques et processus d'examen, de promotion et de titularisation permettrait de mieux reconnaître les diverses formes de résultats de recherche produits par les chercheurs et les chercheuses, et leur impact au-delà de la communauté universitaire (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Projet Review, Promotion, and Tenure à ScholCommLab|Le Projet ‹&amp;#8239;Review, Promotion, and Tenure&amp;#8239;› à ScholCommLab]]&amp;#8239;»]). Cela contribuerait également à susciter un changement culturel vers la valorisation de ces formes de résultats et d'impacts (voir Miedema et al. 2018).

L'un des points soulevés dans [https://ec.europa.eu/research-and-innovation/en/statistics/policy-support-facility/mle-open-science-altmetrics-and-rewards#:~:text=Altmetrics%20have%20the%20opportunity%20to,quality%2C%20not%20quantity%20of%20research le Mutual Learning Exercise (MLE) on Open Science – Altmetrics and Rewards] européen était que l'élan conduisant à l’adoption des mesures alternatives indique le changement en cours dans la façon dont l'impact de la recherche est évalué, s'éloignant d'une compréhension plus insulaire de l'impact au sein du communauté de recherche à une qui met en avant l'impact sociétal dans un contexte politique international (Miedema et al. 2018).

En plus du danger que les mesures alternatives soient mal utilisés comme mesures de citations, la dépendance de la communauté universitaire à l'égard des éditeurs commerciaux pour les données et l'analyse ces données a été citée comme un obstacle à la science ouverte (Haustein; Konkiel et al. 2014). Les mesures ouvertes et transparentes sont une composante essentielle de l'écosystème de la science ouverte, comme le souligne le rapport [http://www.hefce.ac.uk/pubs/rereports/Year/2015/metrictide/ ''Metric Tide''] (Wilsdon et al. 2015).

Le rapport MLE de Frank Miedema et al. souligne aussi qu’il est trés difficile pour les chercheurs et les chercheuses d'adopter les pratiques de la science ouverte sans une changement institutionnel profonde des structures qui régissent leurs travaux, s’inclus des structures d’évaluation. Alors que le paysage des mesures de recherche continue de se développer, les discussions sur les mesures alternatives et leur rôle dans l'évaluation de la recherche et d'autres politiques connexes ouvrent des questions plus larges sur la façon de définir et de mesurer l'impact de la recherche, quels types d'impact sont plus valorisés, et même le rôle de la recherche dans société.

==Ouvrages citées==
*Arthur, Paul Longley, et Lydia Hearn. 2021. «&amp;#8239;Reshaping How Universities Can Evaluate the Research Impact of Open Humanities for Societal Benefit&amp;#8239;». ''The Journal of Electronic Publishing'' 24 (1). [https://doi.org/10.3998/jep.788 https://doi.org/10.3998/jep.788].

*Brainard, Jeffrey. 2022. «&amp;#8239;Riding the Twitter Wave&amp;#8239;». ''Science'', 24 mars 2022. [https://www.science.org/content/article/twitter-transformed-science-communication-pandemic-will-last https://www.science.org/content/article/twitter-transformed-science-communication-pandemic-will-last].

*Direction générale de la recherche et de l’innovation (Commission européenne), James Wilsdon, Judit Bar-Ilan, Robert Frodeman, Elisabeth Lex, Isabella Peters, et Pauls Wouters. 2017. ''Next-Generation Metrics: Responsible Metrics and Evaluation for Open Science''. L’Office des publications de l’Union européenne. [https://data.europa.eu/doi/10.2777/337729 https://data.europa.eu/doi/10.2777/337729].

*Day, Laura. 2021. «&amp;#8239;Altmetric Partners with Austria’s National Open Access Transformation Initiative&amp;#8239;». ''Altmetric News'' (blog). 22 novembre 2021. [https://www.altmetric.com/news/altmetric-partners-with-austrias-national-open-access-transformation-initiative/ https://www.altmetric.com/news/altmetric-partners-with-austrias-national-open-access-transformation-initiative/].

*DORA (San Francisco Declaration on Research Assessment). s.d. «&amp;#8239;Read the Declaration&amp;#8239;». [https://sfdora.org/read/ https://sfdora.org/read/].

*Haustein, Stefanie. 2016. «&amp;#8239;Grand Challenges in Altmetrics: Heterogeneity, Data Quality and Dependencies&amp;#8239;». ''Scientometrics'' 108 (1): 413–23. [https://doi.org/10.1007/s11192-016-1910-9 https://doi.org/10.1007/s11192-016-1910-9].

*Hicks, Diana, Paul Wouters, Ludo Waltman, Sarah de Rijcke, et Ismael Rafols. 2015. «&amp;#8239;Bibliometrics: The Leiden Manifesto for Research Metrics&amp;#8239;». ''Nature'' 520 (7548): 429–31. [https://doi.org/www.doi.org/10.1038/520429a https://doi.org/www.doi.org/10.1038/520429a].

*King, Pam, et Mindy Thuna. 2013. ''Les mesure d’impact alternatives : mise en contexte''. Association des bibliothèques de recherche du Canada. [https://www.carl-abrc.ca/doc/CARL2013-altmetrics-EN-FA.pdf https://www.carl-abrc.ca/doc/CARL2013-altmetrics-EN-FA.pdf].

*Konkiel, Stacy, Cassidy Sugimoto, et Sierra Williams. 2016. «&amp;#8239;The Use of Altmetrics in Promotion and Tenure&amp;#8239;». ''Educause Review''. [https://er.educause.edu/articles/2016/3/the-use-of-altmetrics-in-promotion-and-tenure https://er.educause.edu/articles/2016/3/the-use-of-altmetrics-in-promotion-and-tenure].

*Meneses, Luis, Alyssa Arbuckle, Hector Lopez, Belaid Moa, Ray Siemens, et Richard Furuta. 2019. «&amp;#8239;Social Media Engine: Extending Our Methodology into Other Objects of Scholarship&amp;#8239;». ''Pop! Public. Open. Participatory'', no. 1 (octobre). [https://popjournal.ca/issue01/meneses https://popjournal.ca/issue01/meneses].

*Miedema, Frank, Katja Mayer, Kim Holmberg, et Sabina Leonelli. 2018. «&amp;#8239;Mutual Learning Exercise: Open Science: Altmetrics and Rewards&amp;#8239;». Commision européenne. [https://ec.europa.eu/research-and-innovation/sites/default/files/rio/report/MLE%2520OS_Final%2520Report_0.pdf https://ec.europa.eu/research-and-innovation/sites/default/files/rio/report/MLE%2520OS_Final%2520Report_0.pdf].

*Priem, Jason, Dario Taraborelli, Paul Groth, et Cameron Neylon. 2010. ''Altmetrics: A Manifesto''. 2010. [http://altmetrics.org/manifesto/ http://altmetrics.org/manifesto/].

*Szomszor, Martin, et Euan Adie. 2022. «&amp;#8239;Overton -- A Bibliometric Database of Policy Document Citations&amp;#8239;». ''arXiv''. [https://doi.org/10.48550/arXiv.2201.07643 https://doi.org/10.48550/arXiv.2201.07643].

*Tananbaum, Greg. 2013. ''Article-Level Metrics: A SPARC Primer''. SPARC. [https://sparcopen.org/wp-content/uploads/2016/01/SPARC-ALM-Primer.pdf https://sparcopen.org/wp-content/uploads/2016/01/SPARC-ALM-Primer.pdf].

*Taylor, M. (2020). «&amp;#8239;An altmetric attention advantage for open access books in the humanities and social sciences&amp;#8239;». ''Scientometrics'', ''125''(3), 2523–2543. [https://doi.org/10.1007/s11192-020-03735-8 https://doi.org/10.1007/s11192-020-03735-8].

*Walters, David. 2015. «&amp;#8239;Institutional Services and Altmetrics as Drivers for a Cultural Transition to Open Scholarship&amp;#8239;». Altmetric 2:am Conference. [https://www.youtube.com/watch?v=BNkGlWUCUiU https://www.youtube.com/watch?v=BNkGlWUCUiU].

*Wilsdon, James, Liz Allen, Eleonora Belfiore, Philip Campbell, Stephen Curry, Steven Hill, Richard Jones, et al. 2015. ''The Metric Tide: Report of the Independent Review of the Role of Metrics in Research Assessment and Management''. Higher Education Funding Council for England. [http://www.hefce.ac.uk/pubs/rereports/Year/2015/metrictide/ http://www.hefce.ac.uk/pubs/rereports/Year/2015/metrictide/].

*Zhavoronkov, Alex. 2022. «&amp;#8239;Measuring Attention In Science And Technology&amp;#8239;». ''Forbes'', 17 mars 2022. [https://www.forbes.com/sites/alexzhavoronkov/2022/03/17/measuring-attention-in-science-and-technology/ https://www.forbes.com/sites/alexzhavoronkov/2022/03/17/measuring-attention-in-science-and-technology/].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>sh1xiknv5x9v9sumtca1criyikvgmrc</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le partenariat renouvelé entre PKP et SciELO</title>
    <ns>0</ns>
    <id>82362</id>
    <revision>
      <id>745422</id>
      <parentid>745146</parentid>
      <timestamp>2025-06-26T23:02:35Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745422</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="14571" sha1="2az0q80xpdc74mafu7dlys20o1i4quq" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec remerciements à Juan Pablo Alperin et Bernardo Bueno pour ses commentaires et contribution), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En décembre 2021, [https://pkp.sfu.ca/ le Public Knowledge Project (PKP)] a [https://pkp.sfu.ca/2021/12/21/1459967/ annoncé] son nouveau partenaire de développement : [https://scielo.org/ Scientific Electronic Library Online (SciELO)]. En renouvelant cette relation de collaboration entre les deux organismes qui date de 2007, SciELO se joint aux les [https://pkp.sfu.ca/development-partners/ autres partenaires de développement] du PKP.

Le PKP est une initiative de recherche et de développement de logiciels libres fondée en 1998 par John Willinsky de l'Université de la Colombie-Britannique et actuellement basée à l'Université Simon Fraser. Son logiciel comprend [https://pkp.sfu.ca/ojs/ Open Journal Systems (OJS)], [https://pkp.sfu.ca/omp/ Open Monograph Press (OMP)] et [https://pkp.sfu.ca/ops/ Open Preprint Systems (OPS)]. SciELO est le premier membre du comité consultatif de PKP basé en dehors de l'Europe et de l'Amérique du Nord.

==SciELO==
SciELO est une base de données internationale et une bibliothèque numérique de revues en libre accès en Amérique latine, au Portugal et en Espagne. Il a été fondé au Brésil en 1998 pour répondre aux besoins des chercheurs et chercheuses des pays en développement, notamment d'Amérique latine et des Caraïbes. Il suit trois principes : considérer la recherche comme un bien public et adopter la voie dorée du libre accès, utiliser un modèle de réseau décentralisé pour créer des économies d'échelle et maximiser la visibilité de ses recherches, et se tenir au courant des innovations techniques et autres dans le domaine de la communication savante (SciELO 2021).

SciELO agit comme un «&amp;#8239;méta-éditeur&amp;#8239;», fournissant une infrastructure de publication ainsi que des objectifs, technologies, processus, règles et principes communs aux revues qu'il publie, ce qui se traduit par une augmentation globale de la qualité de la recherche en libre accès produite (Packer 2009).

Le réseau de revues SciELO comprend maintenant 15 collections régionales (avec deux autres en développement), chacune gérée par un organisme de recherche national, ainsi que deux collections thématiques. Il comprend également [https://books.scielo.org/ SciELO Books], une collection de près de 1000 livres savants en libre accès qui a célébré [https://books10.scielo.org/en/ son dixième anniversaire] en mars 2022. Dans un précurseur du partenariat de développement, en 2018, SciELO et PKP ont [https://blog.scielo.org/en/2018/09/21/pkp-and-scielo-announce-development-of-open-source-preprint-server-system/#.YlSyldPMJFw annoncé qu'ils collaboraient] pour développer SciELO Preprints, qui a été [https://blog.scielo.org/en/2020/04/07/scielo-preprints-begins-operations/#.YlSzGdPMJFw lancé] en 2020. [https://mailchi.mp/scielo/scielo-data-en SciELO Data] a également été lancé en 2020, un dépôt de données de recherche de les revues et prépublications du SciELO.

Le réseau de SciELO suit [https://open-access.network/en/information/open-access-primers/green-and-gold la voie dorée vers libre accès], mais en mettant l'accent sur la couverture des coûts de publication uniquement et en les minimisant grâce à des économies d'échelle (Packer 2009). Il reçoit des subventions du [https://fapesp.br/en São Paulo Research Foundation (FAPESP)], mais chaque partenaire national finance les frais de publication de ses propres collections.

En augmentant la visibilité, l'accès et la qualité, SciELO améliore également l'impact de la recherche. Les revues SciELO sont indexées dans diverses bases de données bibliographiques, ce qui augmente leur facilité de recherche, et toutes sont en libre accès et sous licence [https://creativecommons.org/ Creative Commons]. Il utilise des identifiants pérenne, y compris des DOI pour les articles et des ORCID Id pour les auteurs (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Persistent Identifier (PID) Consortium de Royaume-Uni|Le ‹&amp;#8239;Persistent Identifier (PID) Consortium&amp;#8239;› de Royaume-Uni]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/ORCID : Connecter la recherche et les chercheurs|ORCID : connecter la recherche et les chercheurs et chercheuses]]&amp;#8239;»), et dispose d'un [https://analytics.scielo.org/ tableau de bord d’analyse] en version bêta et effectue des analyses périodiques des données des mesures alternatives (SciELO 2021 ; voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les mesures alternatives pour l’évaluation de la recherche|Les mesures alternatives pour l’évaluation de la recherche]]&amp;#8239;»).

==SciELO et le partenariat INKE==
SciELO a des liens avec la communauté INKE grâce à ce partenariat renouvelé avec PKP. Il rejoint également un autre partenaire INKE, [https://www.erudit.org/fr/ Érudit], dans [https://en.unesco.org/news/launch-global-alliance-open-access-scholarly-communication-platforms-democratize-knowledge le Global Alliance of Open Access Scholarly Communication Platforms (GLOALL)], une initiative de l'UNESCO lancée en 2019 pour reconnaître l'importance de la science ouverte pour atteindre [https://sdgs.un.org/fr/goals les objectifs de développement durable des Nations Unies]. GLOALL comprend également [https://www.ajol.info/index.php/ajol African Journals Online (AJOL)], [https://amelica.org/ AmeliCA], [https://www.jstage.jst.go.jp/browse/-char/en J-Stage] et [https://www.openedition.org/ OpenEdition].

==Réponses de la communauté élargie==
SciELO est largement considéré comme un chef de file du mouvement science ouverte et un modèle de libre accès et de publication collaborative durable et à but non lucratif. Tennant et al. écrivent, par exemple, que SciELO a été couronée de succès sans équivoque et qu’il offre un exemple de la diversité géographique, l'une des forces du mouvement science ouverte (2019).

De même, l'Open Scholarship Initiative (OSI) répertorie SciELO aux côtés du Budapest Open Access Initiative, OA2020, SPARC et d'autres initiatives et organisations internationales influentes comme chef de file du mouvement science ouverte («&amp;#8239;OSI&amp;#8239;» 2018). L'OSI souligne également l'importance du SciELO dans ses recommandations sur la feuille de route pour la science ouverte à l'UNESCO, notant qu’il est antérieures au mouvement ouvert, mais reste toujours à sa pointe (Hampson et al 2020).

==Partenariat de SciELO avec PKP et la science ouverte==
L'Amérique latine est un chef mondial de la recherche en libre accès (Alperin 2019; Colodrón 2018). Une étude examinant les performances de libre accès au niveau institutionnel, par exemple, décrit la très bonne performance de nombreuses universités latino-américaines, africaines et indonésiennes et attribue ce succès au leadership institutionnel et aux infrastructures – y compris SciELO – qui soutiennent le publication libre accès (Huang et al. 2020 ; voir Ross 2020).

[https://wp.scielo.org/wp-content/uploads/priority-lines-action-2019-2023.pdf Le plan stratégique de SciELO] se concentre fortement sur la science ouverte et comprend l'augmentation de sa capacité de dépôt de prépublications, de publication continue, de gestion des références (conformément aux [https://www.cos.io/initiatives/top-guidelines Transparency and Openness Promotion Guidelines] du Center for Open Science) et d'un critique des pairs ouvert et transparent (SciELO 2021). Il fournit un modèle pour comprendre la communication savante en tant que bien public (Bulock 2019).

Parce que les réseaux SciELO publient des recherches en portugais, afrikaner, français, anglais, néerlandais, catalan, espagnol, russe, galego, etc., ils jouent un rôle important dans la promotion du multilinguisme dans la communication savante et la bibliodiversité (voir Shearer et al. 2020). SciELO soutient la recherche avec une orientation locale et régionale, conformément à son mandat de soutenir et de permettre libre accès dans les pays en développement, conformément aux principes de [http://www.icml9.org/channel.php?lang=en&amp;channel=91&amp;content=439 la Salvador Declaration] (Packer 2009). L'annonce de la collaboration entre PKP et SciELO souligne que ces organisations partagent une vision d'une collaboration dédiée à l’expansion de la capacité de l'Amérique latine à publier en espagnol, portugais et anglais. Cette multilinguisme est un aspect essentiel de leurs efforts pour soutenir et promouvoir la communication savante à l’échelle mondiale (PKP 2021).

Dans un [https://www.scholcommlab.ca/2019/12/19/osun-keynote/ discours liminaire] pour le [https://research.un.org/conferences/OpenScienceUN United Nations Open Science Conference en 2019] dans laquelle il relie la science ouverte aux [https://www.undp.org/sustainable-development-goals objectifs de développement durable d’ONU], Juan Pablo Alperin du PKP souligne le fait que l'innovation en libre accès désavantage les chercheurs et chercheuses latino-américains dans un contexte mondial parce que de nombreuses politiques de libre accès existantes, telles que [https://www.coalition-s.org/ le Plan S], soutiennent ou facilitent les routes de dorées qui dépendent des frais de publications (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;»). Alperin explique que les universités et les gouvernements latino-américains couvrent les coûts lorsqu'un chercheur latino-américain publie ses recherches dans une revue latino-américaine et également lorsqu'il publie dans une revue du Nord (2019).

Alperin souligne un défi généralisé pour la science ouverte : s'assurer que les stratégies visant à rendre la recherche plus ouverte fonctionnent comme prévu, en augmentant plutôt qu'en diminuant l'inclusivité et l'accessibilité (voir Kowaltowski et al., 2022).

Le partenariat renouvelé entre PKP et SciELO reconnaît la nécessité d'une politique de la science ouverte à prendre en compte dans le contexte de l'écosystème mondial des communications savantes.

==Ouvrages citées==
*Alperin, Juan Pablo. 2019. «&amp;#8239;Policies and Incentives for Open Scholarly Communication&amp;#8239;». ScholCommLab, 19 decembre 2019. [https://www.scholcommlab.ca/2019/12/19/osun-keynote/ https://www.scholcommlab.ca/2019/12/19/osun-keynote/].

*Bulock, Chris. 2019. «&amp;#8239;Open Dialog: SciELO’s Approach to Open Access Publishing&amp;#8239;». ''Serials Review'' 45 (4): 245–47. [https://doi.org/10.1080/00987913.2019.1690931 https://doi.org/10.1080/00987913.2019.1690931].

*Colodrón, Victoriano. 2018. «&amp;#8239;Why Open Access Publishing Is Growing in Latin America&amp;#8239;». ''Times Higher Education'' (THE) (blog), 19 juin 2018. [https://www.timeshighereducation.com/blog/why-open-access-publishing-growing-latin-america https://www.timeshighereducation.com/blog/why-open-access-publishing-growing-latin-america].

*Hampson, Glenn, Mel DeSart, Jason Steinhauer, Elizabeth Gadd, Lisa Janicke Hinchliffe, Michael Vandegrift, Chris Erdmann et Rob Johnson. 2020. «&amp;#8239;Open Science Roadmap&amp;#8239;». OSI Policy Perspectives. Open Scholarship Initiative. [https://journals.gmu.edu/index.php/osi/article/view/2735 https://journals.gmu.edu/index.php/osi/article/view/2735].

*Huang, Chun-Kai (Karl), Cameron Neylon, Richard Hosking, Lucy Montgomery, Katie S Wilson, Alkim Ozaygen et Chloe Brookes-Kenworthy. 2020. «&amp;#8239;Evaluating the Impact of Open Access Policies on Research Institutions&amp;#8239;». ''ELife'' 9 (septembre): e57067. [https://doi.org/10.7554/eLife.57067 https://doi.org/10.7554/eLife.57067].

*Kowaltowski, Alicia, Michel Naslavsky et Mayana Zatz. 2022. «&amp;#8239;Open Access Is Closed to Middle-Income Countries&amp;#8239;». ''Times Higher Education (THE)'', 14 avril 2022. [https://www.timeshighereducation.com/opinion/open-access-closed-middle-income-countries https://www.timeshighereducation.com/opinion/open-access-closed-middle-income-countries].

*«&amp;#8239;OSI Brief: What Do We Mean by ‘Open’?&amp;#8239;» 2018. ''OSI Global'' (blog), 15 novembre 2018. [https://osiglobal.org/2018/11/15/osi-brief-what-do-we-mean-by-open/ https://osiglobal.org/2018/11/15/osi-brief-what-do-we-mean-by-open/].

*Packer, Abel L. 2009. «&amp;#8239;The SciELO Open Access: A Gold Way from the South&amp;#8239;». ''Canadian Journal of Higher Education / Revue Canadienne d’enseignement Supérieur'' 39 (3): 111–26. [https://doi.org/10.47678/cjhe.v39i3.479 https://doi.org/10.47678/cjhe.v39i3.479].

*PKP (Public Knowledge Project). 2021. «&amp;#8239;PKP and SciELO Announce Renewed Partnership&amp;#8239;». ''Public Knowledge Project'' (blog), 21 decembre 2021. [https://pkp.sfu.ca/2021/12/21/1459967/ https://pkp.sfu.ca/2021/12/21/1459967/].

*Ross, John. 2020. «&amp;#8239;Open Access ‘Top Performers’ in Africa and Latin America&amp;#8239;». ''Times Higher Education'', 24 octobre 2020. [https://www.timeshighereducation.com/news/open-access-top-performers-africa-and-latin-america https://www.timeshighereducation.com/news/open-access-top-performers-africa-and-latin-america].

*SciELO. 2021. «&amp;#8239;SciELO – Priority Lines of Action 2019–2023.&amp;#8239;» [https://wp.scielo.org/wp-content/uploads/priority-lines-action-2019-2023.pdf https://wp.scielo.org/wp-content/uploads/priority-lines-action-2019-2023.pdf].

*Shearer, Kathleen, Leslie Chan, Iryna Kuchma et Pierre Mounier. 2020. ''Fostering Bibliodiversity in Scholarly Communications: A Call for Action''. Zenodo. [https://doi.org/10.5281/zenodo.3752923 https://doi.org/10.5281/zenodo.3752923].

*Tennant, Jon. 2019. «&amp;#8239;‘Transformative’ Open Access Publishing Deals Are Only Entrenching Commercial Power&amp;#8239;». ''Times Higher Ed'', 15 août 2019. [https://www.timeshighereducation.com/opinion/transformative-open-access-publishing-deals-are-only-entrenching-commercial-power https://www.timeshighereducation.com/opinion/transformative-open-access-publishing-deals-are-only-entrenching-commercial-power].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>2az0q80xpdc74mafu7dlys20o1i4quq</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le projet de la décolonisation des métadonnées de Canadiana du RCDR</title>
    <ns>0</ns>
    <id>82363</id>
    <revision>
      <id>745423</id>
      <parentid>745147</parentid>
      <timestamp>2025-06-26T23:05:47Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>/* Réponses du partenariat INKE */</comment>
      <origin>745423</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="20123" sha1="h2degrgwmq5gjocvi9afva0ee82kyyq" xml:space="preserve">''Cette observation a été écrit par Caroline Winter et JT Kern (avec remerciements à Julia Bullard, Caitlin Horrall, Natalie MacDonald, Rebecca Ross et Annie Wolfe pour ses commentaires et contribution), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En janvier 2022, [https://www.crkn-rcdr.ca/fr le Réseau canadien de documentation pour la recherche (RCDR)] a annoncé que la première phase de ses efforts pour décoloniser les métadonnées des collections Canadiana était achevée. Ce projet en trois phases a été initialement défini dans le cadre du [https://www.crkn-rcdr.ca/fr/plan-strategique-2019-2024 plan stratégique 2019-2024 du RCDR] et relève de son premier objectif stratégique, «&amp;#8239;transformer les communications savantes&amp;#8239;». Plus précisément, le RCDR vise à «&amp;#8239;Donnera l'exemple en augmentant l'accessibilité et la découvrabilité décolonisée des dynamiques collections de Canadiana, afin de garantir que ces contenus uniques sont disponibles pour la recherche et l'utilisation personnelle, dès maintenant et pour les générations à venir&amp;#8239;» (RCDR 2019, 3).

Les collections Canadiana, qui comprennent la collection [https://www.canadiana.ca/?usrlang=fr Canadiana] et la collection [https://heritage.canadiana.ca/ Héritage], ont été confiées au RCDR en 2018, dans le cadre de [https://www.crkn-rcdr.ca/fr/le-rcdr-et-canadianaorg-fusionnent-pour-devenir-une-organisation-commune la fusion entre le RCDR et Canadiana.org] (voir Bengtson et Shepstone 2020). La collection Canadiana comprend plus de 96 000 titres ou 19 millions de pages de documents historiques numérisés, la plupart publiés avant 1921. La collection Héritage est développée en partenariat avec [https://www.bac-lac.gc.ca/fra/Pages/accueil.aspx Bibliothèque et Archives Canada (BAC)] et comprend environ 40 millions de pages de documents de source primaire datant des années 1600 au milieu des années 1900 (RCDR 2022a). Les efforts actuels pour décoloniser les métadonnées s'appliquent à la collection Canadiana, mais les efforts futurs incluront également Héritage. Dans son annonce, le RCDR explique que,

Le contenu de ces collections a été créé au cours de cinq siècles. Il racont une histoire incomplète, souvent déformée et parfois néfaste du Canada. De plus, les descriptions de contenu, des métadonées et des ressources des collections Canadiana contiennent un langage qui reflète les préjugés, les normes et les perspectives de l'époque à laquelle ils ont été créés. (RCDR, 2022b)

L'objectif de la mise à jour des métadonnées de la collection Canadiana est de remplacer les métadonnées inappropriées et néfaste et, comme l'indique Natalie MacDonald, d'assurer une représentation juste et équitable dans les documents en veillant à que les descriptions correspondent à la façon dont les groupes de personnes veulent être représentés (CRKN RCDR 2019). Ces descriptions révisées seront intégrées aux notices MARC («&amp;#8239;Machine-readable cataloguing&amp;#8239;») pour les collections Canadiana et partagées avec les institutions qui ingèrent ces notices.

La phase I, achevée en 2021, visait à remplacer «&amp;#8239;Indians of North America&amp;#8239;» par «&amp;#8239;Indigenous peoples&amp;#8239;» et «&amp;#8239;Indiens d'Amérique—Amérique du Nord&amp;#8239;» par «&amp;#8239;Autochtones&amp;#8239;». «&amp;#8239;Amérique du Nord&amp;#8239;» a été remplacé par des termes plus spécifiques, le cas échéant (RCDR 2022b). Le projet est guidé par le Comité de préservation et d'accès (CPA) du RCDR, qui examine et formule des recommandations concernant le développement et la gestion des collections Canadiana et de la plateforme du Dépôt numérique fiable (DNF) et les services et capacités associés (RCDR 2021).

En préparation de la deuxième phase du projet, le RCDR a élaboré [https://docs.google.com/spreadsheets/d/1uPI55rpGEQT7OP3uJWVm2KWZ0RpaznaW/edit#gid=584739606 une feuille de calcul de vedettes-matières provisoires] qui s'appuie sur le travail de diverses organisations autochtones et «&amp;#8239;GLAM&amp;#8239;» (galeries, bibliothèques, archives et musées), y compris [https://www.nikla-ancla.com/post/national-indigenous-knowledge-and-language-alliance-nikla-alliance-nationale-des-connaissances-et l'Alliance nationale des connaissances et langues autochtones], [http://cfla-fcab.ca/fr/home-page-fr/ la Fédération canadienne des associations de bibliothèques], [https://gvpl.ent.sirsidynix.net/client/fr_CA/default/? la Greater Victoria Public Library], [https://main.lib.umanitoba.ca/ le Manitoba Archival Information Network], [https://xwi7xwa.library.ubc.ca/about/ la X̱wi7x̱wa Library] de l'Université de la Colombie-Britannique et les sites Web des organisations communautaires autochtones. Il s'agit d'un document évolutif, et le RCDR invite les contributions et les commentaires.

La phase II de la décolonisation des métadonnées de Canadiana est en cours et comprend la suppression du terme «&amp;#8239;Indien&amp;#8239;» des vedettes-matière indiquant les communautés individuelles et la mise à jour des noms et de la terminologie autochtones en utilisant les conseils des communautés autochtones et les travaux préexistants des organisations GLAM (RCDR 2022b). Les phases futures comprendront la révision des vocabulaires non contrôlés, comme dans les champs de notes des enregistrements de métadonnées (CRKN RCDR 2019).

Les efforts du RCDR pour décoloniser les métadonnées des collections Canadiana s'inscrivent dans le contexte des efforts de décolonisation plus larges de la communauté GLAM internationale, y compris les travaux entrepris par BAC. Dans [https://ehprnh2mwo3.exactdn.com/wp-content/uploads/2021/04/4-Appels_a_l-Action_French.pdf les appels à l'action du Commission de vérité et réconciliation du Canada (CVR) de 2015], par exemple, l'appel no. 69 demande à BAC «&amp;#8239;d’adopter et de mettre en œuvre&amp;#8239;» [http://www.un.org/development/desa/indigenouspeoples/wp-content/uploads/sites/19/2018/11/UNDRIP_F_web.pdf la Déclaration des Nations Unies sur les droits des peuples autochtones] (10), qui stipule que «&amp;#8239;Les peuples autochtones ont le droit […] de choisir et de conserver leurs propres noms pour les communautés, les lieux et les personnes&amp;#8239;» (Nations Unies 2007, 13). Étant donné que l'initiative de décolonisation des métadonnées de BAC est actuellement en cours - comme décrit dans son [https://www.bac-lac.gc.ca/fra/decouvrez/patrimoine-autochtone/initiatives/Pages/plan-action.aspx Plan d'action pour le patrimoine autochtone] (BAC 2019) - la feuille de calcul des vedettes-matières du RCDR a été développée comme une mesure provisoire (RCDR 2022b).

Ces mesures s'appuient sur les efforts antérieurs visant à améliorer la représentation des peuples autochtones dans les systèmes de classification. Dans les années 1970, Alex Brian Deer a créé [https://en.wikipedia.org/wiki/Brian_Deer_Classification_System le Système de classification Brian Deer] comme alternative aux systèmes de classification [https://fr.wikipedia.org/wiki/Classification_d%C3%A9cimale_de_Dewey Dewey Decimal] et [https://www.loc.gov/aba/cataloging/classification/ Library of Congress], qui perpétuent une fausse compréhension des peuples autochtones en tant qu'artefacts historiques en les répertoriant par ordre alphabétique sous Histoire (Szeto 2020). Le Système de classification Brian Deer a été adopté par diverses communautés autochtones, notamment la [https://xwi7xwa.library.ubc.ca/collections/indigenous-knowledge-organization/ X̱wi7x̱wa Library], les archives du [http://carriersekani.ca/cstc-services/archives/history-and-collections/ conseil tribal Carrier Sekani] et [https://creeculturalinstitute.ca/fr/home-page-fr/ l'Institut culturel cri Aanischaaukamikw].

==Décoloniser les métadonnées dans la presse==
Les efforts connexes pour décoloniser les métadonnées au Canada ont été couverts dans la presse. En septembre 2020, [https://www.cbc.ca/news/canada/british-columbia/cstc-library-dewey-brian-deer-1.5726732 CBC] a interviewé l'archiviste du Carrier Sekani Tribal Council, Kat Louro, qui utilise le Système de classification Brian Deer car, contrairement à la Library of Congress, il permet d'organiser les collections liées aux communautés autochtones par lieu (Szeto 2020).

En 2018, [https://www.ctvnews.ca/canada/canadian-universities-colleges-working-to-indigenize-programs-campus-life-1.4070645 CTV News] s'est entretenu avec un certain nombre d'universités canadiennes qui s'efforcent de supprimer la langue coloniale de leurs catalogues et archives, notamment l'Université de la Saskatchewan, l'Université de l'Alberta et l'Université métropolitaine de Toronto (alors l'Université Ryerson) (Rizza 2018).

==Réponses du partenariat INKE==
Comme le RCDR, d'autres partenaires et membres de l'INKE prennent des mesures vers la vérité et la réconciliation au Canada, notamment en décolonisant les infrastructures numériques telles que les métadonnées. Dans l'article «&amp;#8239;Knowledge Organization for Open Scholarship&amp;#8239;» (2019), par exemple, Julia Bullard, membre du partenariat INKE, affirme qu’INKE est prêt à entamer une conversation sur la façon dont l'infrastructure ouverte peut soutenir des systèmes d'organisation des connaissances réfléchissants, transparents et réactifs et demande, que signifierait créer des systèmes d'accès aux matières alignés avec l’ouverture, le multiculturalisme, et la décolonisation?

En 2019, les Bibliothèques de l'Université de Victoria (un partenaire INKE) ont nommé [https://www.uvic.ca/news/topics/2020+indigenous-libraries-rymoran+news Ry Moran] comme Bibliothèque universitaire associée - réconciliation. Les Bibliothèques note que cette nomination aidera à établir des liens plus solides au sein et au-delà de l'université pour travailler à la réconciliation (Abram 2020).

En 2019, l'Université Simon Fraser a accueilli [https://ocs.lib.sfu.ca/index.php/dcid/dcid2019 Sorting Libraries Out: Decolonizing Classification and Indigenizing Description]. L'événement, parrainé par les Bibliothèques SFU (un partenaire INKE), la Bibliothèque de l'Université de la Colombie-Britannique, les Bibliothèques de l'Université de l'Alberta et le Council of Prairie and Pacific University Libraries (COPPUL), a réuni des professionnels et professionnelles du patrimoine culturel autochtones et non autochtones, des universitaires, des professionnels et professionnelles de l'information et des chercheurs et chercheuses pour discuter et travailler à la décolonisation et à l'indigénisation des bibliothèques, y compris les métadonnées.

La Stratégie de numérisation du patrimoine documentaire du Canada (SNPD) met au premier plan son engagement envers la décolonisation dans son processus de planification stratégique en cours, y compris un engagement envers les appels à l'action de la CVR (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Stratégie canadienne de numérisation du patrimoine documentaire|La stratégie canadienne de numérisation du patrimoine]]&amp;#8239;»). Après le transfert de son secrétariat au RCDR en 2020, le SNPD a entamé une vaste consultation communautaire sur son plan stratégique dans le but de «&amp;#8239;favoriser un paysage patrimonial axé sur l'inclusion, la vérité et la décolonisation&amp;#8239;» ([https://snpd.ca/a-propos-de-la-snpd/la-strategie/ SNPD s.d.]). Les activités précédentes de la SNPD comprennant financer des efforts de numérisation décoloniale tels que le projet [https://archivists.ca/Blog/8650726 Shingwauk Residential Schools Centre's Healing and Education Through Digital Access] et un [https://snpd.ca/plan-daction/numerisation-de-certains-journaux-dans-le-cadre-du-projet-pilote-de-la-snpd/ projet pilote] de numérisation du contenu de quatre journaux autochtones publiés depuis plus de 80 ans.

==Réponses de la communauté élargie==
Considérant le projet de la décolonisation des métadonnées de Canadiana du point de vue des bibliothèques de droit, Michel-Adrien Sheppard souligne qu'il s'agit de l'un des nombreux projets des bibliothèques et des archives mondial pour décoloniser le catalogue de bibliothèque (2022). Pour Sheppard, l'importance de ce projet réside dans son lien avec les [https://www.marc21.ca/CSH/index-f.html Canadian Subject Headings], un vocabulaire contrôlé pour décrire les documents sur le Canada maintenu par BAC et sur lequel les bibliothèques et associations de droit canadiennes fondent leurs vedettes-matières.

La communauté universitaire sur Twitter a répondu à [https://twitter.com/CRKN_RCDR/status/1486086776598843394 l'annonce du RCDR] avec enthousiasme.

==Décoloniser les métadonnées Canadiana et la science ouverte==
Comme Dean Seeman et Heather Dean en discutent, les métadonnées des bibliothèques et des archives sont hautement collaboratives avec une forte tradition de collaboration, contribution et réutilisation par des experts et expertes en catalogage et en création de métadonnées (2019). Bien que ces pratiques de réutilisation signifient que d'autres institutions peuvent intégrer les notices MARC des collections Canadiana révisées dans leurs propres systèmes, cela signifie également que les notices ont généralement créées et partagées de manière centralisée plutôt que locale.

Ce défi a été souligné lors du panel «&amp;#8239;Decolonizing Metadata&amp;#8239;» de [https://www.crkn-rcdr.ca/fr/2019-conference-du-rcdr-sur-lacces-au-savoir la Conférence du RCDR sur l'accès au savoir] 2019 (CRKN RCDR 2019), qui comprenait des conférenciers de BAC, de l'Université de la Saskatchewan et du RCDR. Annie Wolfe de BAC et Natalie MacDonald du RCDR ont expliqué que, bien que BAC soit en train de créer ses propres recommandations pour décoloniser les Canadian Subject Headings, les bibliothèques et les archives canadiennes utilisent également les Library of Congress Subject Headings, qui conservent un langage colonial inexact et préjudiciable concernant aux peuples autochtones du Canada. Deborah Lee, panéliste de l'Université de la Saskatchewan, a appelé tous les dirigeants et consortiums de bibliothèques canadiennes à plaider en faveur du maintien des changements locaux dans les vedettes-matières, car aucun chercheur ou chercheuse ne devrait utiliser ou être exposé à la terminologie offensante pour son peuple.

Comme le souligne Bullard, parce que les infrastructures d'organisation des connaissances telles que les métadonnées sont des constructions sociales, elles incarnent les croyances - et les préjugés - de leurs créateurs et créatrices (2019). Ils sont également le fondement de l'érudition, y compris l'érudition ouverte, et pour cette raison, l'élaboration de vedettes-matière inclusives et précises est une étape essentielle pour faire progresser la science ouverte au Canada.

==Ouvrages citées==
*Abram, Lisa. 2020. «&amp;#8239;Truth and Reconciliation Leader to Advance Decolonization Work at UVic&amp;#8239;». UVic News. [https://www.uvic.ca/news/topics/2020+indigenous-libraries-rymoran+news https://www.uvic.ca/news/topics/2020+indigenous-libraries-rymoran+news].

*BAC (Bibliothèque et archives Canada). 2019. ''Plan d’action pour le patrioine autochtone''. [https://www.bac-lac.gc.ca/fra/decouvrez/patrimoine-autochtone/initiatives/Pages/plan-action.aspx https://www.bac-lac.gc.ca/fra/decouvrez/patrimoine-autochtone/initiatives/Pages/plan-action.aspx].

*Bengtson, Jonathan, et Carol Shepstone. 2020. «&amp;#8239;‹&amp;#8239;Tourner en commun&amp;#8239;› : La fusion de Canadiana.org avec le Réseau canadien de documentation pour la recherche/Canadian Research Knowledge Network&amp;#8239;». ''Partnership: The Canadian Journal of Library and Information Practice and Research'' 15 (1). [https://doi.org/10.21083/partnership.v15i1.6110 https://doi.org/10.21083/partnership.v15i1.6110].

*Bullard, Julia. 2019. «&amp;#8239;Knowledge Organization For Open Scholarship&amp;#8239;». ''Pop! Public. Open. Participatory'', no. 1 (octobre). [https://doi.org/10.21810/pop.2019.005 https://doi.org/10.21810/pop.2019.005].

*Commission de vérité et réconciliation du Canada : appels à l’action. 2015.'' Commission de vérité et réconciliation du Canada : appels à l’action''. Publications du gouvernement du Canada. [https://publications.gc.ca/collections/collection_2015/trc/IR4-8-2015-fra.pdf https://publications.gc.ca/collections/collection_2015/trc/IR4-8-2015-fra.pdf].

*CRKN RCDR. 2019. «&amp;#8239;CRKN Conference: Decolonizing Metadata – 18Oct – EN&amp;#8239;» (enregistrement d'une séance de conférence). la Conférence du RCDR sur l'accès au savoir. Vimeo, 1:24:19. [https://vimeo.com/373462736 https://vimeo.com/373462736].

*Nations unies. 2007. ''Déclaration des Nations unies sur les droits des peuples autochtones''. [https://www.un.org/development/desa/indigenouspeoples/wp-content/uploads/sites/19/2018/11/UNDRIP_F_web.pdf https://www.un.org/development/desa/indigenouspeoples/wp-content/uploads/sites/19/2018/11/UNDRIP_F_web.pdf].

*RCDR (Réseau canadien de documentation pour la recherche). 2019. ''Plan stratégique 2019-2024''. CRKN–RCDR. [https://www.crkn-rcdr.ca/fr/plan-strategique-2019-2024 https://www.crkn-rcdr.ca/fr/plan-strategique-2019-2024].

*RCDR (Réseau canadien de documentation pour la recherche). 2021. «&amp;#8239;Comitzee de préservation et d’accès (CPA)&amp;#8239;». CRKN–RCDR. [https://www.crkn-rcdr.ca/fr/comite-de-preservation-et-dacces https://www.crkn-rcdr.ca/fr/comite-de-preservation-et-dacces].

*RCDR (Réseau canadien de documentation pour la recherche). 2022a. «&amp;#8239;Collections de Canadiana&amp;#8239;». CRKN–RCDR. [https://www.crkn-rcdr.ca/fr/collections-de-canadiana https://www.crkn-rcdr.ca/fr/collections-de-canadiana].

*RCDR (Réseau canadien de documentation pour la recherche). 2022b. «&amp;#8239;Décolonisation des métadonnées de Canadiana : un étape attendue depuis longtemps pour la suppression des vedettes-matières nuisibles&amp;#8239;». CRKN–RCDR. [https://www.crkn-rcdr.ca/fr/decolonisation-des-metadonnees-de-canadiana-une-etape-attendue-depuis-longtemps-pour-la-suppression https://www.crkn-rcdr.ca/fr/decolonisation-des-metadonnees-de-canadiana-une-etape-attendue-depuis-longtemps-pour-la-suppression].

*Rizza, Alanna. 2018. «&amp;#8239;Canadian Universities, Colleges Working to Indigenize Programs, Campus Life&amp;#8239;». ''CTV News''. [https://www.ctvnews.ca/canada/canadian-universities-colleges-working-to-indigenize-programs-campus-life-1.4070645 https://www.ctvnews.ca/canada/canadian-universities-colleges-working-to-indigenize-programs-campus-life-1.4070645].

*Seeman, Dean, et Heather Dean. 2019. «&amp;#8239;Open Social Knowledge Creation and Library and Archival Metadata&amp;#8239;». ''KULA: Knowledge Creation, Dissemination, and Preservation Studies'' 3 (février): 13–13. [https://doi.org/10.5334/kula.51 https://doi.org/10.5334/kula.51].

*Sheppard, Michel-Adrien. 2022. «&amp;#8239;Updating Canadian Metadata for Indigenous Materials&amp;#8239;». ''Slaw: Canada’s Online Legal Magazine'', 28 janvier 2022. [https://www.slaw.ca/2022/01/27/updating-canadian-metadata-for-indigenous-materials/ https://www.slaw.ca/2022/01/27/updating-canadian-metadata-for-indigenous-materials/].

*SNPD (Stratégie de numérisation du patrimoine documentaire). s.d. «&amp;#8239;La stratégie&amp;#8239;». [https://snpd.ca/a-propos-de-la-snpd/la-strategie/ https://snpd.ca/a-propos-de-la-snpd/la-strategie/].

*Szeto, W. 2020. «&amp;#8239;B.C. First Nations Council is Moving to Indigenous-developed Library System&amp;#8239;». ''CBC News''. [https://www.cbc.ca/news/canada/british-columbia/cstc-library-dewey-brian-deer-1.5726732 https://www.cbc.ca/news/canada/british-columbia/cstc-library-dewey-brian-deer-1.5726732].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>h2degrgwmq5gjocvi9afva0ee82kyyq</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Une mise à jour sur les monographies en libre accès</title>
    <ns>0</ns>
    <id>82364</id>
    <revision>
      <id>745424</id>
      <parentid>745148</parentid>
      <timestamp>2025-06-26T23:07:21Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745424</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="17082" sha1="n4gp6f7om8jpsx2nb7fh4zgqmbs0r26" xml:space="preserve">''Cette observation a été écrit par Caroline Winter (avec remerciements à John Maxwell, Émilie Paquin, et Kevin Stranack pour ses commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

Comme indiqué dans l'observation «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les monographies en libre accès|Les monographies en libre accès]]&amp;#8239;», publiée en mars 2021, une attention croissante a été accordée ces dernières années aux stratégies pour publier avec succès des monographies en libre accès et d'autres publications de versions longues que des chapitres de livre. Martin Eve et Anthony Cond ont décrit 2021 comme l'année du pistolet de départ pour les livres en libre accès, avec la publication des directives du Plan S pour les monographies, la nouvelle politique de libre accès de l'UK Research and Innovation (UKRI) qui s'applique pour la première fois aux monographies, et le compte à rebours pour la prochain Research Excellence Framework (REF) du Royaume-Uni (2021). Cette observation résume certains développements liés à la publication de monographies en libre accès au cours de l'année écoulée.

En juin 2021, Cambridge University Press au Royaume-Uni a lancé le projet pilote [https://www.cambridge.org/core/services/open-research/open-access/oa-book-pilot-flip-it-open Flip it Open], une initiative libre accès basée sur la demande. Lorsque 25 monographies sélectionnées des éditeurs participants atteindront un objectif de revenus spécifié, elles passeront en libre accès et une version brochée sera disponible à l'achat. Ce modèle de publication vise à rendre les livres les plus demandés librement accessibles, et les institutions qui achètent le livre bénéficieront d'un accès plus précoce et seront reconnues dans les versions imprimées et numériques du livre libre accès pour leur rôle dans le retournement. À partir de septembre 2022, cinq livres ont été transformer dans le cadre du programme (Cambridge University Press 2022). Étant donné que la transformation à libre accès est soutenu par les ventes plutôt que par les frais d'édition de livres, le programme vise à être plus inclusif pour les auteurs exclus de la publication de leurs livres en libre accès en raison de frais élevés (Tivnan 2021).

Aussi en juin, [https://www.operas-eu.org/ OPERAS (Open Scholarly Collaboration in the European Research Area for Social Sciences and Humanities)] et [https://oaspa.org/ OASPA (Open Access Scholarly Publishing Association)] ont publié [https://doi.org/10.5281/zenodo.5017705 ''The Future of Scholarly Communication''], un rapport traitant sur les défis et les solutions potentielles pour la communication savante en sciences sociales et humaines en Europe, y compris ceux liés aux monographies en libre accès.

En août, [https://www.ukri.org/ UKRI] a publié [https://www.ukri.org/news/ukri-announces-new-open-access-policy/ une nouvelle politique de libre accès] qui s'applique à toutes les publications soutenues par un financement de l'un de ses conseils de recherche (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Politique de libre accès du l’UKRI 2021|La politique de libre accès du l’UKRI’s 2021]]&amp;#8239;»). Cette version inclut pour la première fois une exigence selon laquelle les publications savantes de versions longues - monographies, volumes édités, chapitres de livre - doivent être en libre accès dès leur publication.

En septembre, cOAlition S a publié [https://www.coalition-s.org/coalition-s-statement-on-open-access-for-academic-books/ un ensemble de recommandations pour les livres savantes] en libre accès, qu'ils définissent comme des publications de versions longues comprenant des monographies, des volumes édités et des chapitres de livres individuels, ainsi que des éditions critiques. Ce sont des recommandations plutôt qu'une partie de la politique officielle du Plan S et n'ont pas de calendrier de mise en œuvre en reconnaissance de la nature complexe et diversifiée de l'édition de livres savantes. Étant donné que la cOAlition S est un consortium international en pleine croissance, ces recommandations auront potentiellement des effets étendus sur la publication de monographies en libre accès (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les Fonds de recherche du Québec rejoignent la cOAlition S|Les Fonds de Recherche du Québec rejoignent la cOAlition S]]&amp;#8239;» et «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Mise à jour du Plan S : L’élargissement de l’adhésion de la cOAlition S|Mise à jour du Plan S : l'élargissement de l’adhésion de la cOAlition S]]&amp;#8239;»).

Au cours du même mois, [https://www.crkn-rcdr.ca/fr le Réseau canadien de documentation pour la recherche (RCDR)] a [https://www.crkn-rcdr.ca/fr/le-rcdr-gerera-la-facturation-et-les-licences-centralisees-du-programme-direct-open-de-mit-press annoncé un partenariat] avec MIT Press Direct to Open (D2O) : le RCDR s'occupera des paiements et des licences pour ses membres qui souhaitent faire partie de cette initiative, réduisant ainsi les obstacles à la participation.

En novembre, [https://mitpress.mit.edu/blog/direct-to-open-enables-the-mit-press-to-publish-its-full-list-of-spring-2022-monographs-and-edited-collections-open-access/ MIT Press], basé aux États-Unis, a annoncé qu'il avait atteint son objectif de financement pour l'initiative D2O et qu'il publierait en libre accès sa liste complète du printemps 2022 des livres savants.

En décembre, MIT Press a publié [https://direct.mit.edu/books/pages/direct-to-open-report «&amp;#8239;The MIT Press Open Monograph Model: Direct to Open&amp;#8239;»], un livre blanc décrivant le modèle et sa mise en œuvre dans le cadre du projet pilote.

En avril 2022, le projet [https://copim.pubpub.org/ COPIM (Community-led Open Publication Infrastructures for Monographs)] basé au Royaume-Uni a lancé [https://copim.pubpub.org/pub/introducing-the-open-book-collective/release/1 l'Open Book Collective], une plateforme réunissant des bibliothèques, des instituts de recherche, des éditeurs en libre accès et des fournisseurs de services d'édition pour faciliter les initiatives de financement basées sur l'adhésion.

En mai, l'Université de Californie a signé le programme [https://www.openingthefuture.net/model/ Opening the Future], développé par [https://copim.pubpub.org/pub/cdl-signs-up-to-opening-the-future/release/1 COPIM]. Il s'agit d'un modèle d'abonnement collectif dans lequel les bibliothèques s'abonnent à les publications précédentes d'un éditeur, et l'éditeur oriente une partie de ces fonds vers le soutien de nouveaux livres en libre accès. Opening the Future a été lancé en 2020 mais élargi en juin 2021. Bien que l'adhésion de l'Université de Californie à l'initiative soit un point de repère en raison de la taille et de l'influence de ce système universitaire, de nombreux [https://ceup.openingthefuture.net/supporters/ partisans] sont inscrits.

En juin, [https://educopia.org/ l'Educopia Institute], basé aux États-Unis, a annoncé le projet [https://educopia.org/educopia-partnering-curtin-university-and-oapen/ Book Analytics Dashboard] (2022-2025), développé en partenariat avec [https://oapen.org/ OAPEN] et le [https://ccat.curtin.edu.au/programs/innovation-knowledge-communication/curtin-open-knowledge-initiative-coki/ Open Knowledge Initiative de l'Université Curtin], avec un financement de [https://mellon.org/ la Fondation Mellon]. Le projet mettra à la disposition des petits et moyens éditeurs des analyses solides sur l'utilisation des livres en libre accès via une infrastructure numérique partagée, leur permettant de prendre des décisions stratégiques axées sur les données et de concurrencer les grands éditeurs sur un pied d'égalité.

En juillet, [https://mitpress.mit.edu/blog/mit-press-opens-full-list-2022-monographs-direct-open/ MIT Press a annoncé] qu'il publierait sa liste complète de 2022 de 80 livres savants en libre accès.

Le même mois, [https://www.openmonographs.org/ Toward an Open Monograph Ecosystem (TOME)] a ​​publié le rapport préliminaire [https://doi.org/10.17613/pvek-7g97 ''The Cost to Publish TOME Monographs''] (Maron et Schmelzinger 2022). TOME est un programme pilote de cinq ans (2017-2022) pour la publication coopérative de monographies en libre accès aux États-Unis par le biais duquel les établissements accordent une subvention d'au moins 15 000 $ pour financer la publication en libre accès des monographies par membres du corps professoraux. Le rapport est une première évaluation visant à déterminer si cette subvention couvre de manière adéquate les coûts de publication, compte tenu de l'évolution du paysage de la publication de monographies en libre accès.

En août, [https://www.thebritishacademy.ac.uk/news/readership-boost-for-monographs-after-british-academy-switches-to-open-access/ la British Academy] a publié le premier livre en libre accès de sa série British Academy Monograph et a [https://www.researchprofessionalnews.com/rr-news-uk-open-access-2022-8-all-british-academy-monographs-to-be-published-open-access/ annoncé] son intention de publier tous les livres suivants de la série en tant que libre accès.

Les tendances de l'année écoulée ont donc inclus politique qui rend obligatoire le libre accès pour les monographies ainsi que les projets pilotes et les rapports de recherche qui étudient la meilleure façon d'accomplir cette transition vers libre accès, compte tenu de la nature diversifiée et complexe de la publication de monographies savantes.

==Monographies en libre accès dans la presse==
La publication de monographies en libre accès est un sujet d'intérêt pour les presses des bibliothèques et de l'industrie du livre ainsi que pour la presse universitaire. L'InfoDocket du ''Library Journal'' a couvert le lancement de [https://www.infodocket.com/2022/04/27/say-hello-to-the-open-book-collective/ l'Open Book Collective du COPIM] et le lancement du projet [https://www.infodocket.com/2022/06/30/educopia-partnering-with-curtin-university-and-oapen-to-create-a-community-governed-oa-book-analytics-service-for-publishers/ Book Analysis Dashboard], et ''The Bookseller'' a couvert l'initiative [https://www.thebookseller.com/news/cup-launches-revolutionary-open-access-monograph-pilot-1266449 Flip it Open] du Cambridge University Press.

==Monographies en libre accès et la communauté INKE==
Comme indiqué dans notre article précédent, «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les monographies en libre accès|Les monographies en libre accès]]&amp;#8239;», les monographies en libre accès sont depuis longtemps un sujet d'intérêt pour la communauté INKE. En plus des activités énumérées dans cette observation, le [https://pkp.sfu.ca/ Public Knowledge Project (PKP)] a lancé [https://pkp.sfu.ca/omp/ Open Monograph Press], une plate-forme open source pour la gestion des flux de travail de publication de livres savants, en 2012. PKP a récemment annoncé que son nouveau partenaire de développement est la Scientific Electronic Library Online (SciELO); SciELO Books a près de 1000 livres savants libre accès dans sa collection (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le partenariat renouvelé entre PKP et SciELO|Le partenariat renouvelé entre PKP et SciELO]]&amp;#8239;»).

De plus, [https://canada.explore.openaire.eu/ le Portail des résultats de recherche canadienne], résultat d'un partenariat entre [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC], un partenaire de l'INKE) et [https://www.openaire.eu/ OpenAIRE], agrégats des métadonnées sur les résultats de recherche canadiens, y compris monographies. Les recherches peuvent être limitées aux monographies en libre accès, ce qui facilite la collecte de données (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le partenariat renouvelé entre PKP et SciELO|La collaboration entre l’ABRC et OpenAIRE]]&amp;#8239;»).

==Monographies en libre accès et la communauté élargie==
Judith Fathallah a publié [http://www.doi.org/10.53377/lq.11068 un article] sur la nouvelle politique de libre accès de l'UKRI en janvier 2022, répondant à certaines des préoccupations de la communauté à ce sujet. Fathallah présente également certaines initiatives existantes pour faire progresser la publication de monographies en libre accès, notamment [https://www.infodocket.com/2022/04/27/say-hello-to-the-open-book-collective/ l’Open Book Collective du COPIM].

==Monographies en libre accès et la science ouverte==
Faire progresser les monographies en libre accès nécessite d'adapter les infrastructures existantes et d'en développer de nouvelles innovantes, des plate-formes de publication numérique aux modèles de financement.

Charles Watkinson et Melissa Pitts soutiennent que les presses universitaires doivent être reconnues comme des éléments cruciaux dans les infrastructures de monographies en libre accès, car non seulement elles publient des monographies et d'autres études approfondies, mais elles développent également des plateformes de publication open source et des modèles de financement innovants. Ils écrivent que les presses universitaires fonctionnent comme un réseau de laboratoires pour les universitaires qui jouent un rôle particulièrement important dans la croissance des disciplines et de l'érudition interdisciplinaire. Ils aident aussi à avancer des collaborations entre des établissements et la création des plateformes innovatifs.

Eve et Cond soutiennent de la même manière que faire progresser la publication de monographies en libre accès est crucial pour les sciences humaines en particulier : sans investissement dans les modèles de publication innovatif, nous sommes confrontés d’une situation dans laquelles la recherche scientifique est publié en libre accès, mais la recherche des sciences humaines aura un coût prohibitif, disponible seulement pour ceux qui peuvent payer (2021).

Les innovations développées pour faire progresser la publication de monographies en libre accès feront partie de l'écosystème plus large de l'édition savante ouverte, contribuant ainsi à l'avancement de libre accès et de la recherche ouverte plus largement.

==Ouvrages citées==
*Cambridge University Press. 2022. «&amp;#8239;Open Access Book Pilot - Flip It Open&amp;#8239;». Cambridge Core. 2022. [https://www.cambridge.org/core/services/open-research/open-access/oa-book-pilot-flip-it-open https://www.cambridge.org/core/services/open-research/open-access/oa-book-pilot-flip-it-open].

*Eve, Martin, et Anthony Cond. 2021. «&amp;#8239;‘Crucial Time’ for OA Monographs&amp;#8239;». ''Research Information''. 21 octobre 2021. [https://www.researchinformation.info/analysis-opinion/crucial-time-oa-monographs https://www.researchinformation.info/analysis-opinion/crucial-time-oa-monographs].

*Fathallah, Judith. 2022. «&amp;#8239;Open Access Monographs: Myths, Truths and Implications in the Wake of UKRI Open Access Policy&amp;#8239;». ''LIBER Quarterly: The Journal of the Association of European Research Libraries'' 32 (1). [https://doi.org/doi.org/10.53377/lq.11068 https://doi.org/doi.org/10.53377/lq.11068].

*Maron, Nancy, et Kimberly Schmelzinger. 2022. «&amp;#8239;The Cost to Publish TOME Monographs: A Preliminary Report&amp;#8239;». [https://hcommons.org/deposits/item/hc:47235/ https://hcommons.org/deposits/item/hc:47235/].

*Smalley, Suzanne. 2021. «&amp;#8239;MIT Press to Release Many Spring Titles Open Access&amp;#8239;». ''Inside Higher Ed'', 14 decembre 2021. [https://www.insidehighered.com/news/2021/12/14/mit-press-plans-release-much-spring-slate-open-access https://www.insidehighered.com/news/2021/12/14/mit-press-plans-release-much-spring-slate-open-access].

*Tivnan, Tom. 2021. «&amp;#8239;CUP Launches ‘revolutionary’ Open Access Monograph Pilot&amp;#8239;». ''The Bookseller''. 28 juin 2021. [https://www.thebookseller.com/news/cup-launches-revolutionary-open-access-monograph-pilot-1266449 https://www.thebookseller.com/news/cup-launches-revolutionary-open-access-monograph-pilot-1266449].

*Watkinson, Charles, et Melissa Pitts. 2021. «&amp;#8239;Re-Envisioning Humanities Infrastructure&amp;#8239;». ''Inside Higher Ed'', 22 février 2021. [https://www.insidehighered.com/views/2021/02/22/institutions-and-funders-must-recognize-contributions-university-presses-humanities https://www.insidehighered.com/views/2021/02/22/institutions-and-funders-must-recognize-contributions-university-presses-humanities].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>n4gp6f7om8jpsx2nb7fh4zgqmbs0r26</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le mémo Nelson : Une politique d’accès public mis à jour aux États-Unis</title>
    <ns>0</ns>
    <id>82365</id>
    <revision>
      <id>745425</id>
      <parentid>745149</parentid>
      <timestamp>2025-06-26T23:12:22Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745425</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="39461" sha1="lmb1u2pw27b8kf1xmam1sd6tn36a7k4" xml:space="preserve">''Cette observation a été écrite par Caroline Winter (avec ses remerciements à Leslie Chan et Kate Shuttleworth pour leurs commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

Le 25 août 2022, l'Office of Science and Technology Policy (OSTP) des États-Unis a publié un mémo intitulé [https://ospolicyobservatory.uvic.ca/wp-content/uploads/sites/7744/2025/05/08-2022-OSTP-Public-Access-Memo.pdf ''Ensuring free, immediate, and equitable access to federally funded research''] et un [https://ospolicyobservatory.uvic.ca/wp-content/uploads/sites/7744/2025/05/Nelson-Memo-media-release.pdf communiqué de presse] l’accompagnant. Ce mémo, appelé le mémo Nelson parce qu’il a été écrit par Alondra Nelson, en ce temps-là directrice par intérim de l’OSTP, présente les orientations politiques en matière d’accès public (libre accès) pour les agences fédérales américaines qui financent la recherche et le développement. Le rapport de l’OSTP [https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-Access-Congressional-Report.pdf ''Economic Landscape of Federal Public Access Policy''], aussi publié en août 2022, examine les effets économiques potentiels du libre accès immédiat à la recherche financée par le gouvernement fédéral.

La politique mise à jour a suscité un débat animé au sein de la communauté de la communication savante et au-delà. Cette observation offre un bref résumé des points clés du mémo et un aperçu des premières réponses.

Le mémo Nelson s’appuie sur la politique fédérale américaine de libre accès publiée en 2013 par John Holdren, en ce temps-là directeur de l’OSTP, le [https://obamawhitehouse.archives.gov/sites/default/files/microsites/ostp/ostp_public_access_memo_2013.pdf ''Memorandum on Increasing Access to the Results of Federally Funded Research''], appelé le mémo Holdren. Ce mémo de 2013 demandait que les agences fédérales qui fournissaient plus de 100 millions de dollars par an en financement pour la recherche et le développement créent des plans pour rendre les publications et les données de recherche plus accessibles au public, avec un embargo autorisé de 12 mois.

Deux des changements importants apportés à cette politique mise à jour sont suivants :
* la politique s’applique à tous les organismes de financement fédéraux ;
* les publications doivent être en libre accès dès leur publication, sans embargo.
Le mémo Nelson spécifie que les organismes de financement fédéraux devraient
* Mettre à jour leurs politiques de libre accès pour rendre les publications et les données de la recherche financée accessibles au public dès leur publication ;
* Adopter des procédures transparentes garantissant l’intégrité scientifique de ces politiques ;
* Collaborer avec l’OSTP pour s’assurer que les résultats de la recherche financée, y compris les données, sont diffusés équitablement.

Les agences qui ont élaboré des politiques de libre accès conformément aux directives de 2013 doivent compléter leurs plans mis à jour dans les six mois suivant la publication du mémo Nelson, et d’autres ont un peu moins d’un an pour le faire. Toutes les politiques doivent être publiées au plus tard le 31 décembre 2024 et entrer en vigueur au plus tard le 31 décembre 2025.

Le mémo comprend les dispositions pour les publications examinées par les pairs et pour les données de recherche. Les publications financées par le gouvernement fédéral doivent être en libre accès dès leur publication par défaut, dans un dépôt désigné par des agences, bien que le mémo ne précise pas quelle version de la publication doit être disponible (c’est-à-dire le manuscrit accepté par l’auteur ou la version de l’éditeur). Cette disposition s’applique à tous les articles et peut inclure d’autres publications évaluées par les pairs tels que des actes de colloques, des éditoriaux et des chapitres de livre. Notamment, les plans des agences doivent envisager comment maximiser la diffusion équitable, non seulement par la publication en libre accès, mais aussi par la lisibilité automatique, l’accessibilité et les licences ouvertes.

Les plans d’accès public aux données de recherche doivent inclure des politiques pour la gestion et le partage des données, et les données de recherche associées aux publications doivent être librement et publiquement accessibles par défaut au moment de la publication, soumis aux conditions légales, éthiques, de confidentialité, et autres restrictions similaires. Les coûts associés à la gestion, la conservation et la publication des données peuvent être inclus dans les budgets de recherche.

Le mémo souligne l’importance de l’accès public et ouvert pour le soutien de l’intégrité scientifique et de la recherche et pour le renforcement de la confiance du public dans la recherche financée par le gouvernement fédéral. Il demande aux agences fédérales d’élaborer une politique pour collecter et partager les métadonnées sur les publications et les données de recherche, y compris des identifiants pérenne pour les résultats de la recherche, les chercheurs et les chercheuses, et les subventions fédérales, conformément aux directives afin de réaliser «&amp;#8239;[https://www.whitehouse.gov/wp-content/uploads/2022/01/010422-NSPM-33-Implementation-Guidance.pdf National Security Presidential Memorandum 33 (NSPM-33)]&amp;#8239;», publié par le National Science and Technology Council en janvier 2022. Cette mise à jour de la politique doit être achevée au plus tard le 31 décembre 2026 et entrer en vigueur au plus tard le 31 décembre 2027.

Le mémo aborde également la nécessité de coordonner les plans d’accès public entre les agences fédérales. Il décrit le rôle du National Science and Technology Council’s Subcommittee on Open Science, qui a été créé pour faciliter la coordination des plans et fournir des orientations supplémentaires sur la mise en œuvre des exigences du mémo.

==La politique dans la presse==
La mise à jour de la politique a été un sujet d’intérêt dans la presse universitaire. Un article de [https://www.science.org/content/article/white-house-requires-immediate-public-access-all-u-s--funded-research-papers-2025 ''Science''] note que, bien que la politique utilise le terme d’accès public, il s’agit essentiellement d’une politique du libre accès, le résultat de décennies de discussions sur la nécessité de rendre accessible au public la recherche financée par le secteur public (Brainard et Kaiser 2022). Un article pour [https://www.insidehighered.com/news/2022/09/12/wholl-pay-public-access-federally-funded-research ''Inside Higher Ed''] note également que cette mise à jour de la politique était en développement depuis près d’une décennie sous les administrations de Barack Obama et de Donald Trump, mais elle a en même temps rencontré l’opposition de la communauté des éditeurs, en particulier à l’élimination de l’embargo (D’Agostino et Lederman 2022).

Un article dans [https://www.chronicle.com/article/a-historic-moment-new-guidance-requires-federally-funded-research-to-be-open-access ''The Chronicle''] offre un aperçu des réponses à la mise à jour de la politique des avocats du libre accès, qui y sont généralement fortement favorables, et de l’industrie de l’édition, qui a exprimé des réserves sur la manière dont la politique sera mise en œuvre (Zahneis 2022). ''The Scholarly Kitchen'' a également publié plusieurs articles sur ce sujet dans les semaines qui ont suivi la publication du mémo, y compris les réponses de leur équipe ([https://scholarlykitchen.sspnet.org/2022/08/30/ask-the-chefs-ostp-policy-i/ partie 1] et [https://scholarlykitchen.sspnet.org/2022/08/31/ask-the-chefs-ostp-policy-ii/ partie 2]), un article [https://scholarlykitchen.sspnet.org/2022/09/13/guest-post-quantifying-the-impact-of-the-ostp-policy/ quantifiant l’impact de la politique], un [https://scholarlykitchen.sspnet.org/2022/10/03/the-new-ostp-memo-a-roundup-of-reactions-and-an-interview-preview/?informz=1&amp;nbd=e7acf065-7b8f-4940-9c2f-ebcb1b99d33d&amp;nbd_source=informz résumé de nombreuses réponses et réactions] au mémo, une [https://scholarlykitchen.sspnet.org/2022/10/11/new-light-on-the-new-ostp-memo-an-interview-with-dr-alondra-nelson/ entrevue avec Nelson], et quelques [https://scholarlykitchen.sspnet.org/2022/10/13/thoughts-and-observations-on-the-ostp-responses-to-our-interview-questions/ réflexions sur cette entrevue]. ''Library Journal'' ''InfoDocket'' a également publié un [https://www.infodocket.com/2022/08/25/white-house-office-of-science-and-technology-policy-ostp-issues-new-guidance-to-ensure-free-immediate-and-equitable-access-to-federally-funded-research/ résumé des réponses communautaire] à la fin du mois d’août.

La publication de la politique a également été couverte par le[https://www.goodnewsnetwork.org/white-house-bans-paywalls-on-taxpayer-funded-research/  ''Good News Network''], le[https://www.natlawreview.com/article/all-federal-research-agencies-to-update-public-access-policies  ''National Law Review''], le[https://www.nytimes.com/2022/08/25/us/white-house-federally-funded-research-access.html  ''New York Times''],[https://www.publishersweekly.com/pw/by-topic/international/Frankfurt-Book-Fair/article/90593-frankfurt-spotlight-u-s-to-require-open-access-by-2025.html  ''Publishers Weekly''], le[https://www.theregister.com/2022/08/25/science_research_release/  ''Register''] et[https://www.researchinformation.info/news/new-ostp-policy-federally-funded-research '' Research Information''], et le podcast[https://www.sciencefriday.com/segments/public-access-science-biden/  ''Science Friday''], entre autres.

==Réponses du partenariat INKE==
Un [https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access/ostp-nelson-memo-open-access article de blog] de la Bibliothèque de l’Université Simon Fraser, un des partenaires d’INKE, place la politique mise à jour à côté de [https://www.lib.sfu.ca/help/publish/scholarly-publishing/open-access/open-access-policy la politique libre accès de l’université], qui exige le dépôt du texte finalisé de toutes les publications par l’auteur de l’université dans son entrepôt institutionnel, et d’autres politiques nationales et internationales du libre accès (Liuta 2022). Il s’agit notamment du Plan S et de [https://science.gc.ca/site/science/fr/financement-interorganismes-recherche/politiques-lignes-directrices/libre-acces/politique-trois-organismes-libre-acces-aux-publications?OpenDocument= la Politique des trois organismes sur le libre accès aux publications] du Canada de 2015, qui exige que des articles de revues financés par [https://cihr-irsc.gc.ca/f/193.html les Instituts de recherche en santé du Canada (IRSC)], [https://www.nserc-crsng.gc.ca/index_fra.asp le Conseil de recherches en sciences naturelles et en génie du Canada (CRSNG)] et [https://www.sshrc-crsh.gc.ca/home-accueil-fra.aspx le Conseil de recherches en sciences humaines (CRSH)] soient librement accessible dans les 12 mois suivant la publication (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Politique des trois organismes sur le libre accès aux publications|Politique des trois organismes sur le libre accès aux publications]]&amp;#8239;»]).

Le [https://pkp.sfu.ca/2022/08/29/embargo-no-more/ Public Knowledge Project (PKP)], un des partenaires d’INKE, a exprimé son soutien à la mise à jour de la politique et à ses effets sur l’accès et la qualité de la recherche. En particulier, il salue l’accent mis par la politique sur la transparence et l’importance de la confiance du public (Racy 2022), notant qu’elle s’aligne sur le projet [https://docs.google.com/document/d/1AvIElSv6JYfdsOIiy15Cyvzdg3ENgOwCtkQIB39RCHY/edit Publication Facts Label] du PKP, actuellement en cours.

[https://oaaustralasia.org/2022/08/31/open-access-australasia-comment-on-us-white-house-ostp-public-access-guidance/ Open Access Australasia], un des partenaires d’INKE via le [https://inke.ca/canadian-australian-partnership-for-open-scholarship/ Canada–Australia Partnership for Open Scholarship (CAPOS)], a également exprimé son soutien à la mise à jour de la politique, déclarant que la politique est un facteur crucial dans le passage au libre accès et soulignant les changements provoqués par les politiques RCUK et cOAlition S ( 2022 ; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Examen et consultation de la politique de L’UKRI sur libre accès|Examen et consultation de la politique de l’UKRI sur libre accès]]&amp;#8239;» et «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Politique de libre accès du l’UKRI 2021|La politique de libre accès du l’UKRI 2021]]&amp;#8239;»). Cette déclaration exprime également l’espoir que la politique conduira à une plus grande diversité de modèles et d’approches du libre accès qui reflètent mieux la diversité de la communauté de la recherche.

==Réponses de la communauté élargie==
La communauté élargie a exprimé un appui solide pour le mémo Nelson ainsi que plusieurs préoccupations, mais elle semble unie en pensant que la politique est un tournant pour le libre accès. [https://www.aip.org/fyi/2022/white-house-moves-make-federally-funded-research-free-upon-publication L'American Institute of Physics], par exemple, affirme qu’elle marque un changement tectonique dans le domaine de l’édition scientifique (2022), et [https://www.arl.org/news/arl-celebrates-biden-harris-administrations-historic-policy-to-make-federally-funded-research-immediately-available/ l’Association of Research Libraries] la décrit comme un moment historique pour les communications scientifiques (2022).

SPARC a exprimé son appui fort pour la politique dans son [https://sparcopen.org/news/2022/taxpayers-to-get-immediate-access-to-publicly-funded-research/ communiqué de presse] ainsi que dans une [https://sparcopen.org/our-work/2022-updated-ostp-policy-guidance/fact-sheet-white-house-ostp-memo-on-ensuring-free-immediate-and-equitable-access-to-federally-funded-research/ fiche d’information]. Les déclarations des [https://www.nih.gov/about-nih/who-we-are/nih-director/statements/statement-nih-plans-speed-access-federally-funded-research-results National Institutes of Health] et de la [https://www.nlm.nih.gov/news/Expediting_Access_To_Results_Of_Federally_Funded_Research.html National Library of Medicine] expriment leur empressement de mettre en œuvre la politique, mais certaines parties prenantes, en particulier, [https://www.aaas.org/news/aaas-statement-ostp-federally-funded-research-guidance l’'American Association for the Advancement of Science (AAAS)], [https://www.aip.org/fyi/2022/white-house-moves-make-federally-funded-research-free-upon-publication l’'American Institute of Physics] et [https://www.aau.edu/newsroom/press-releases/aau-statement-ostp-decision-make-federally-funded-research-publicly l'Association of American Universities], ont exprimé l’incertitude quant à la question du comment cela serait fait. .

Les parties prenantes ont également exprimé plusieurs préoccupations concernant la politique et ses effets potentiels. Certaines de ces préoccupations ont été liées au manque apparent de consultation des parties prenantes, ce qui a été souligné, entre autres,  par [https://publishers.org/news/statement-from-shelley-husband-senior-vice-president-government-affairs-association-of-american-publishers-on-decision-by-white-house-office-of-science-and-technology-policy-to-make-private-se/ l'Association of American Publishers] (Husband 2022 ; Michael, Vines et al. 2022). Bien qu’un bon nombre des éditeurs universitaires principaux n’aient pas publié de déclarations sur la politique, [https://newsroom.taylorandfrancisgroup.com/ostp-memorandum/ Taylor &amp; Francis] a exprimé son appui tout en reconnaissant les défis de la mise en œuvre.

Une autre préoccupation est le fait que le mémo présente des recommandations plutôt que des directives, et il n’est pas clair quelles seront les conséquences en cas de non-conformité (Anderson 2022 ; Anderson et Wulf 2022).

Les préoccupations principales sont liées à sa mise en œuvre, y compris plusieurs concernant le financement. Bien que certains éditeurs en libre accès, tels que [https://theplosblog.plos.org/2022/09/plos-cheers-the-ostp-memorandum/ PLOS] et [https://blog.frontiersin.org/2022/08/29/white-house-announces-new-policy-to-drop-paywalls-around-publicly-funded-research/ Frontiers], aient exprimé leur appui pour la politique mise à jour, d’autres membres du milieu de l’édition ont exprimé des préoccupations au sujet de l’impact de l’élimination de l’embargo sur leur viabilité financière.

Le mémo ne décrit pas de modèle d’entreprise particulier, permettant aux agences de décider des meilleurs modèles pour leurs communautés. Cependant, les modèles d’entreprise d’abonnement seront probablement intenables pour la plupart des éditeurs sans embargo. La rapidité de ce changement dépendra en partie des décisions politiques des agences, telles que la version d’une publication dont elles ont besoin pour être en libre accès lors de la publication et la restriction à laquelle une licence doit être appliquée (Clark et Esposito).

Le mémo ne promet pas de financement supplémentaire pour le soutien de la politique mise à jour, bien qu’il mentionne que les coûts associés peuvent être inclus dans les budgets de recherche. On ne sait pas quels seront les coûts de mise en œuvre de la politique, comment ils seront payés et par qui. Ceci est vrai pour les publications et pour les données de recherche, qui nécessiteront beaucoup d’infrastructures et un soutien financier important à long terme (voir Clark et Esposito ; Michael, Carpenter et al. 2022). La réponse du [https://datacurationnetwork.org/2022/09/06/dcn-is-ready-to-support-policies-resulting-from-ostp-public-access-memo%25EF%25BF%25BC/ Data Curation Network] à la mise à jour de la politique met en évidence le rôle clé que les dépôts institutionnels joueront dans la fourniture de l’infrastructure nécessaire à sa mise en œuvre. Une déclaration de [https://www.asbmb.org/advocacy/position-statements/asbmb-statement-on-ostp-memo l’American Society for Biochemistry and Molecular Biology] souligne que le financement de la recherche n’a pas suivi le rythme du coût croissant de la recherche et de la publication et appelle l’OSTP et les décideurs politiques à relever ce défi. Certains ont également remis en cause l’exhaustivité et la validité du rapport économique qui a éclairé cette politique (par exemple, D’Agostino 2022 ; Michael, Vines et al. 2022 ; White 2022).

Certaines parties prenantes s’inquiètent des effets potentiels de la politique sur l’équité dans le domaine de l’édition savante. Bien que la politique ne promette pas de financement supplémentaire et n’impose pas d’approche ou de modèle spécifique pour libre accès, elle stipule que les agences fédérales devraient permettre l’inclusion des coûts de publication raisonnables dans les budgets de recherches, en consultation avec l’Office of Mangaement and Budget. Les parties prenantes sont concernées donc que le libre accès sera financé principalement par les frais de publication des articles et que les coûts de gestion des données soient également répercutés sur les auteurs (Clark et Esposito 2022 ; Pooley 2022). Notant qu’une dépendance croissante aux frais de publication est probable, Jefferson Pooley souligne que libre accès soutenu financièrement de cette manière est déjà la norme aux États-Unis, surtout la publication dans les revues hybrides et les accords de lecture et de publication et d’autres accords transformatifs (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les accords de libre accès|Les accords de libre accès]]&amp;#8239;»). Il demande des mesures pour atténuer les effets qui en résultent, comme le soutien à des modèles alternatifs et des plafonds sur les frais de publication. Une déclaration de [https://subscribetoopencommunity.org/ la communauté de pratique Subscribe to Open] soutient la politique et demande une multiplicité d’approches pour atteindre ses objectifs (2022).

Les bibliothèques de l’University of California décrivent la politique comme soutenant ses efforts afin de faire progresser le libre accès, suggérant que la politique pourrait inciter les éditeurs à abandonner le modèle d’abonnement payant et à développer des modèles d’entreprise entièrement différents conçus pour le libre accès (2022 ; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La rupture entre Elsevier et l'University of California|La rupture entre Elsevier et l’University of California]]&amp;#8239;»). Il est également noté que toute augmentation des coûts pour les grands instituts de recherche en raison de l’élargissement de la lecture et de la publication ou de modèles similaires pourrait être compensée par les contributions des chercheurs et des chercheuses incluses dans les propositions de financement (2022). [https://scholarlykitchen.sspnet.org/2022/09/27/academia-zero-embargo/ Roger Schonfeld] note que certains éditeurs miseront sur la valeur qu’ils offrent en fournissant une version de record, citant en exemple [https://www.science.org/journal/science ''Science''], publié par l’AAAS, qui a annoncé [https://www.science.org/doi/10.1126/science.ade8028 une politique de libre accès verte] en réponse au mémo Nelson et en opposition à l’exclusion des tendances du libre accès basées sur les frais de publication.

Si le modèle «&amp;#8239;payer pour publier&amp;#8239;» devient plus établi, cependant, une conséquence serait de rendre la publication moins accessible aux chercheurs et chercheuses sans financement ou avec un financement insuffisant, y compris ceux et celles qui sont en début de leur carrière, qui viennent des plus petites institutions et qui font partie des disciplines avec moins de financement, y compris les sciences humaines. Une lettre ouverte à l’OSTP coordonnée par [https://neuromatch.io/ Neuromatch] avec plus de 1300 signatures souligne cette préoccupation, indiquant que la politique peut améliorer l’accès équitable mais rendre la participation à la recherche moins équitable, avec des conséquences graves pour le progrès de la recherche.

[https://www.arl.org/news/arl-celebrates-biden-harris-administrations-historic-policy-to-make-federally-funded-research-immediately-available/ L’Association of Research Libraries], cependant, fait l’éloge de la politique comme de celle qui fait progresser l’équité pour les personnes issues des milieux défavorisés et pour les chercheurs et chercheuses en début de leur carrière ainsi que comme de celle qui garantit que les résultats sont accessibles aux personnes handicapées (Aiwuyor 2022). Il souligne aussi l’accent mis par la politique sur l’harmonisation des politiques entre les agences afin de réduire la pression sur des bibliothèques de recherche. Un article du [https://www.libraryjournal.com/story/technology/white-house-make-public-access-to-research-immediate ''Library Journal''] souligne de la même manière l’objectif de la politique d’améliorer l’équité (Peet 2022).

==Le mémo Nelson et la science ouverte==
Le mémo Nelson contextualise ses mises à jour de politique dans le cadre de la transition généralisée vers libre accès pour la recherche sur le COVID-19 (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Science Ouverte et COVID-19|Science ouverte et COVID-19]]&amp;#8239;»). Il note qu’à la suite de cette crise de santé publique, le gouvernement, l’industrie et les chercheurs et chercheuses ont travaillé ensemble volontairement pour adopter une politique d’accès public immédiat, ce qui a donné des conséquences formidables. Ces conséquences sont les suivantes : la recherche et les données ont circulé efficacement et des résultats accessibles ont accéléré la vitesse de la découverte et de la mise en pratique. Il indique également que le libre accès est aligné sur les valeurs américaines fondamentales d’égalité des chances et que rendre la science publique aidera les États-Unis à devenir un leader mondial de la science ouverte. Bien qu’une mise à jour de la politique de 2013 ait été rédigée en 2018, l’élan du mouvement libre accès à cause du COVID-19 a contribué au timing de la publication du mémo Nelson; l’émergence du virus monkeypox et l’intérêt personnel du président américain Biden pour l’accès publique peuvent également être des facteurs contributifs (Najokaitytė et Hudson 2022 ; Nelson 2022). L’accent mis par le mémo sur l’équité et la nécessité d’augmenter la confiance du public dans la science reflètent également les valeurs professionnelles de Nelson. Nelson est professeure de sociologie à l’Université de Columbia et présidente du [https://www.ssrc.org/staff/nelson-alondra/ Social Science Research Council], et ses recherches examinent les intersections entre les inégalités sociales et la science et la technologie.

Comme l’ont noté [https://sparcopen.org/news/2022/taxpayers-to-get-immediate-access-to-publicly-funded-research/ SPARC], [https://www.coalition-s.org/coalition-s-welcomes-the-updated-open-access-policy-guidance-from-the-white-house-office-of-science-technology-and-policy/ la cOAlition S] et [https://creativecommons.org/2022/08/26/a-big-win-for-open-access/ Creative Commons], la disposition de la politique qui élimine l’embargo s’aligne dans une certaine mesure sur les politiques internationales de libre accès telles que [https://www.coalition-s.org/ le Plan S] et la [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre Recommandation de l’UNESCO sur une science ouverte] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;», «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour du Plan S : La Stratégie de conservation des droits|Mise à jour du Plan S : La stratégie de conservation des droits]]&amp;#8239;», «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Mise à jour du Plan S : L’élargissement de l’adhésion de la cOAlition S|Mise à jour du Plan S : L’élargissement de l’adhésion de la cOAlition S]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|La recommandation de l’UNESCO sur la science ouverte]]&amp;#8239;»). Cependant, contrairement au Plan S, le mémo Nelson n’exclut pas les revues hybrides ni ne demande que le droit d’auteur reste aux auteurs (Clark et Esposito 2022). La déclaration de [https://creativecommons.org/2022/08/26/a-big-win-for-open-access/ Creative Commons] célèbre la politique mais appelle à un soutien supplémentaire pour les licences ouvertes et les infrastructures ouvertes dirigées par la communauté (Green 2022).

La politique mise à jour s’applique à toutes les recherches financées par le gouvernement fédéral, y compris les organismes de financement des sciences humaines et sociales qui ont été exclus de la politique de 2013, tels que [https://www.arts.gov/ le National Endowment for the Arts] et [https://www.neh.gov/ le National Endowment for the Humanities]. Le mémo Nelson, cependant, ne fait pas référence aux sciences humaines spécifiquement, contrairement au Plan S et à la Recommandation de l’UNESCO (cOAlition S, s.d. ; UNESCO 2020). Malgré cela, Karin Wulf note que la politique mise à jour renforcera la science ouverte en sciences humaines, ce qui, selon elle, est désespérément nécessaire à notre époque historique actuelle (Michael, Carpenter et al. 2022).

L’OSTP a estimé que le financement fédéral américain a soutenu 195 000 à 263 000 articles en 2020, ce qui représente environ 7 à 9 % des articles publiés dans le monde (Brainard et Kaiser 2022). La façon dont les agences mettront en œuvre la politique mise à jour déterminera dans une large mesure son effet sur les auteurs, les éditeurs et l’écosystème de l’édition dans son ensemble. Bien que le mémo Nelson présente une politique nationale de libre accès aux États-Unis, la taille pure de l’effort d’édition savante aux États-Unis signifie que les effets du mémo Nelson seront sûrement répandus, notamment en contribuant à l’élan du mouvement libre accès dans le monde entier.

==Ouvrages cités==
*Aiwuyor, Jessica. s.d. «&amp;#8239;ARL Celebrates Biden-Harris Administration’s Historic Policy to Make Federally Funded Research Immediately Available&amp;#8239;». Association of Research Libraries. Le 20 octobre 2022. [https://www.arl.org/news/arl-celebrates-biden-harris-administrations-historic-policy-to-make-federally-funded-research-immediately-available/ https://www.arl.org/news/arl-celebrates-biden-harris-administrations-historic-policy-to-make-federally-funded-research-immediately-available/].

*American Institute of Physics. 2022. «&amp;#8239;White House Moves to Make Federally Funded Research Free Upon Publication&amp;#8239;». American Institute of Physics. Le 30 août 2022. [https://www.aip.org/fyi/2022/white-house-moves-make-federally-funded-research-free-upon-publication https://www.aip.org/fyi/2022/white-house-moves-make-federally-funded-research-free-upon-publication].

*Anderson, Rick. 2022. «&amp;#8239;A New OSTP Memo: Some Initial Observations and Questions&amp;#8239;». ''The Scholarly Kitchen''. Le 29 août 2022. [https://scholarlykitchen.sspnet.org/2022/08/29/a-new-ostp-memo-some-initial-observations-and-questions/ https://scholarlykitchen.sspnet.org/2022/08/29/a-new-ostp-memo-some-initial-observations-and-questions/].

*Anderson, Rick, et Karin Wulf. 2022. «&amp;#8239;Thoughts and Observations on the OSTP Responses to Our Interview Questions&amp;#8239;». ''The Scholarly Kitchen''. Le 13 octobre 2022. [https://scholarlykitchen.sspnet.org/2022/10/13/thoughts-and-observations-on-the-ostp-responses-to-our-interview-questions/ https://scholarlykitchen.sspnet.org/2022/10/13/thoughts-and-observations-on-the-ostp-responses-to-our-interview-questions/].

*Brainard, Jeffrey, et Jocelyn Kaiser. «&amp;#8239;White House Requires Immediate Public Access to All U.S.-Funded Research Papers by 2025&amp;#8239;». ''Science'', le 26 août 2022. [https://www.science.org/content/article/white-house-requires-immediate-public-access-all-u-s--funded-research-papers-2025 https://www.science.org/content/article/white-house-requires-immediate-public-access-all-u-s--funded-research-papers-2025].

*Clark and Esposito. «&amp;#8239;Zero Embargo&amp;#8239;». ''The Brief'', le 29 août 2022. [https://www.ce-strategy.com/the-brief/zero-embargo/ https://www.ce-strategy.com/the-brief/zero-embargo/].

*cOAlition S. s.d. «&amp;#8239;Why Plan S&amp;#8239;». Consulté le 20 octobre 2022. [https://www.coalition-s.org/why-plan-s/ https://www.coalition-s.org/why-plan-s/].

*D’Agostino, Susan. 2022. «&amp;#8239;Who’ll Pay for Public Access to Federally Funded Research?&amp;#8239;» ''Inside Higher Ed''. Le 12 septembre 2022. [https://www.insidehighered.com/news/2022/09/12/wholl-pay-public-access-federally-funded-research https://www.insidehighered.com/news/2022/09/12/wholl-pay-public-access-federally-funded-research].

*D’Agostino, Susan, et Doug Lederman. «&amp;#8239;No Paywall for Taxpayer-Funded Research, U.S. Declares&amp;#8239;». ''Inside Higher Ed'', le 26 août 2022. [https://www.insidehighered.com/news/2022/08/26/us-mandates-immediate-public-access-taxpayer-funded-research https://www.insidehighered.com/news/2022/08/26/us-mandates-immediate-public-access-taxpayer-funded-research].

*Green, Cable. 2022. «&amp;#8239;A Big Win for Open Access: United States Mandates All Publicly Funded Research Be Freely Available with No Embargo&amp;#8239;». ''Creative Commons''. Le 26 août 2022. [https://creativecommons.org/2022/08/26/a-big-win-for-open-access/ https://creativecommons.org/2022/08/26/a-big-win-for-open-access/].

*Holdren, John P. 2013. «&amp;#8239;Increasing Access to the Results of Federally Funded Scientific Research&amp;#8239;». Office of Science and Technology Policy. [https://obamawhitehouse.archives.gov/sites/default/files/microsites/ostp/ostp_public_access_memo_2013.pdf https://obamawhitehouse.archives.gov/sites/default/files/microsites/ostp/ostp_public_access_memo_2013.pdf].

*Husband, Shelley. 2022. «&amp;#8239;Statement from Shelley Husband, Senior Vice President, Government Affairs, AAP, on Decision by The White House Office of Science and Technology Policy to Make Private Sector Publications Freely Available&amp;#8239;». ''Association of American Publishers''. Le 25 août 2022. [https://publishers.org/news/statement-from-shelley-husband-senior-vice-president-government-affairs-association-of-american-publishers-on-decision-by-white-house-office-of-science-and-technology-policy-to-make-private-se/ https://publishers.org/news/statement-from-shelley-husband-senior-vice-president-government-affairs-association-of-american-publishers-on-decision-by-white-house-office-of-science-and-technology-policy-to-make-private-se/].

*Liuta, Ioana. 2022. «&amp;#8239;Important Milestone in the Open Access Movement: Immediate Open Access by 2026, in the US&amp;#8239;». ''Radical Access''. Le 28 octobre 2022. [https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access/ostp-nelson-memo-open-access https://www.lib.sfu.ca/help/publish/scholarly-publishing/radical-access/ostp-nelson-memo-open-access].

*Michael, Ann, et al. «&amp;#8239;Ask The Chefs: OSTP Policy Part I&amp;#8239;». ''The Scholarly Kitchen'', le 30 août 2022. [https://scholarlykitchen.sspnet.org/2022/08/30/ask-the-chefs-ostp-policy-i/ https://scholarlykitchen.sspnet.org/2022/08/30/ask-the-chefs-ostp-policy-i/].

*Michael, Ann, et al. 2022. «&amp;#8239;Ask The Chefs: OSTP Policy Part II&amp;#8239;». ''The Scholarly Kitchen''. Le 31 août 2022. [https://scholarlykitchen.sspnet.org/2022/08/31/ask-the-chefs-ostp-policy-ii/ https://scholarlykitchen.sspnet.org/2022/08/31/ask-the-chefs-ostp-policy-ii/].

*Naujokaitytė, Goda, et Richard L. Hudson. s.d. «&amp;#8239;Washington Gives a Big Boost to Drive for Open-Access Scientific Publishing&amp;#8239;». ''Science|Business''. Le 13 octobre 2022. [https://sciencebusiness.net/news/washington-gives-big-boost-drive-open-access-scientific-publishing https://sciencebusiness.net/news/washington-gives-big-boost-drive-open-access-scientific-publishing].

*Nelson, Alondra. 2022. «&amp;#8239;Ensuring Free, Immediate, and Equitable Access to Federally Funded Research&amp;#8239;». Office of Science and Technology Policy. [https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-Access-Memo.pdf https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-Access-Memo.pdf].

*Open Access Australasia. «&amp;#8239;Open Access Australasia Comment on US White House OSTP Public Access Guidance&amp;#8239;». Open Access Australasia, le 31 août 2022. [https://oaaustralasia.org/2022/08/31/open-access-australasia-comment-on-us-white-house-ostp-public-access-guidance https://oaaustralasia.org/2022/08/31/open-access-australasia-comment-on-us-white-house-ostp-public-access-guidance].

*«&amp;#8239;Open Letter to the WHOSTP and Subcommittee on Open Science&amp;#8239;». s.d. Consulté le 18 octobre 2022. [https://ostp-letter.github.io https://ostp-letter.github.io].

*Peet, Lisa. 2022. «&amp;#8239;White House: Make Public Access to Research Immediate&amp;#8239;». ''Library Journal'', le 26 septembre 2022. [https://www.libraryjournal.com/story/technology/white-house-make-public-access-to-research-immediate https://www.libraryjournal.com/story/technology/white-house-make-public-access-to-research-immediate].

*Pooley, Jefferson. «&amp;#8239;The APC Question Mark Hovering over the OSTP Announcement&amp;#8239;». ''LSE Blog'', le 2 septembre 2022. [https://blogs.lse.ac.uk/impactofsocialsciences/2022/09/02/the-apc-question-mark-hovering-over-the-ostp-announcement/ https://blogs.lse.ac.uk/impactofsocialsciences/2022/09/02/the-apc-question-mark-hovering-over-the-ostp-announcement/].

*Racy, Famira. «&amp;#8239;Embargo No More!&amp;#8239;» Public Knowledge Project, le 29 août 2022. [https://pkp.sfu.ca/2022/08/29/embargo-no-more/ https://pkp.sfu.ca/2022/08/29/embargo-no-more/].

*Schonfeld, Roger C. 2022. «&amp;#8239;How Will Academia Handle the Zero Embargo?&amp;#8239;» ''The Scholarly Kitchen''. Le 27 septembre 2022. [https://scholarlykitchen.sspnet.org/2022/09/27/academia-zero-embargo/ https://scholarlykitchen.sspnet.org/2022/09/27/academia-zero-embargo/].

*Subscribe to Open Community of Practice. «&amp;#8239;Subscribe-to-Open Community of Practice Statement on the OSTP ‘Nelson Memo’&amp;#8239;». SPARC, le 16 septembre 2022. [https://sparcopen.org/news/2022/subscribe-to-open-community-of-practice-statement-on-the-ostp-nelson-memo/ https://sparcopen.org/news/2022/subscribe-to-open-community-of-practice-statement-on-the-ostp-nelson-memo/].

*UNESCO. 2020. «&amp;#8239;Recommandation de l’UNESCO sur une science ouverte&amp;#8239;». [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre.]

*University of California, Office of Scholarly Communication. 2022. «&amp;#8239;‘Wind in Our Sails’: University of California Hails White House Guidance Accelerating Public Access to Federally Funded Research&amp;#8239;». ''University of California, Office of Scholarly Communication''. Le 26 août 2022. [https://osc.universityofcalifornia.edu/2022/08/wind-in-our-sails-university-of-california-hails-white-house-ostp-guidance/ https://osc.universityofcalifornia.edu/2022/08/wind-in-our-sails-university-of-california-hails-white-house-ostp-guidance/].

*White, Meg. «&amp;#8239;The Nelson Memo: More Questions than Answers&amp;#8239;». ''Charleston Hub'', le 6 septembre 2022.[https://www.charleston-hub.com/2022/09/the-nelson-memo-more-questions-than-answers/  https://www.charleston-hub.com/2022/09/the-nelson-memo-more-questions-than-answers/].

*Zahneis, Megan. «&amp;#8239;‘A Historic Moment’: New Guidance Requires Federally Funded Research to Be Open Access&amp;#8239;». ''The Chronicle of Higher Education'', le 25 août 2022. [https://www.chronicle.com/article/a-historic-moment-new-guidance-requires-federally-funded-research-to-be-open-access https://www.chronicle.com/article/a-historic-moment-new-guidance-requires-federally-funded-research-to-be-open-access].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>lmb1u2pw27b8kf1xmam1sd6tn36a7k4</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Un plan d’action pour faire avancer le libre accès diamant</title>
    <ns>0</ns>
    <id>82366</id>
    <revision>
      <id>745427</id>
      <parentid>745150</parentid>
      <timestamp>2025-06-26T23:14:50Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745427</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="24324" sha1="jckw2w1liyh9uz27tvnbwg7pd5vmxxo" xml:space="preserve">''Cette observation a été écrite par Caroline Winter (avec ses remerciements à Iryna Kuchma et Vincent Larivière pour leurs commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

En mars 2022, [https://www.scienceeurope.org/ Science Europe], [https://www.coalition-s.org/ cOAlition S], [https://operas-eu.org/ Open Scholarly Communication in the European Research Area for Social Sciences and Humanities (OPERAS)] et [https://anr.fr/fr/ l'Agence nationale de la recherche] ont annoncé la publication du document [https://doi.org/10.5281/zenodo.6282403 ''Action Plan for Diamond Open Access''] (Ancion et al. 2022). Ce plan d'action comprend des recommandations pour soutenir et étendre le modèle du libre accès diamant. Alors que le libre accès doré fait référence aux publications rendues librement disponibles pour lire sur les sites Web des revues (souvent, mais pas nécessairement, subventionnées par des frais de publication d'articles) et que le libre accès vert fait référence aux publications rendues librement disponibles pour un dépôt, le libre accès diamant fait référence à des publications gratuites pour les lecteurs et pour les auteurs (voir [https://oaaustralasia.org/2021/05/25/what-are-the-different-types-of-open-access/ “What are the Different Types of Open Access”] d’Open Access Australasia).

Les recommandations du plan d'action ont été aviséess par l’[https://doi.org/10.5281/zenodo.4558704 ''Open Access Diamond Journals Study''] (Bosman et al. 2021), ce qui a été soutenu par cOAlition S et Science Europe et réalisé par un consortium de 10 organisations.

L'étude a révélé que le libre accès diamant est utilisé par entre 17 000 et 19 000 revues dans le monde, ce qui représente environ de 8 à 9 % des articles au total (Bosman et al. p. 47–48). Le libre accès diamant est particulièrement populaire en Europe de l'Est et en Amérique latine, et en termes de domaine d’étude, plus de la moitié de toutes les revues en libre accès diamant sont dans les sciences humaines et sociales (p. 48).

Les revues en libre accès diamant ont tendance à être de petite échelle (publiant moins de 25 articles chaque année), nationales en termes d'auteurs mais internationales en termes de lectorat, et plus multilingues que les revues en libre accès financées par des frais de publication (p. 41–44).

Près de la moitié (42 %) des revues en libre accès diamant sont possédées par des presses universitaires et par d'autres presses appartenant à des universités, 14 % appartiennent à des sociétés savantes et 8 % à d'autres organismes de recherche (p. 79). Comme indiqué par le plan d'action, ces revues incarnent le concept de bibliodiversité parce qu’ils desservent une variété de communautés savantes multilingues, multiculturelles et à petite échelle (Ancion et al. p. 3).

Cet accent mis sur la propriété communautaire présente plusieurs avantages, notamment l'autonomie, la continuité des traditions (par exemple, le modèle du club), la liberté d'innover et la gouvernance communautaire (Bosman et al. p. 83). Cependant, la propriété communautaire contribue également aux défis opérationnels et techniques auxquels de nombreuses revues en libre accès diamant sont confrontées.

L'étude a également révélé qu'en termes de défis opérationnels, bon nombre de ces revues manquent de documentation juridique sur leur statut. D'autres défis incluent l'analyse et le rapport des métriques, la gestion de l'examen par les pairs, l'indexation et la découvrabilité. Bien que le libre accès diamant soit bien aligné sur les principes de la science ouverte et, plus précisément, sur les principes du Plan S, de nombreuses revues en libre accès diamant ne répondent pas aux spécifications techniques que le plan décrit, notamment l'utilisation de licences ouvertes, de DOI et de XML ou HTML et la mise en place des politiques de préservation (voir « [[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et cOAlition S]]&amp;#8239;»). De plus, de nombreuses revues en libre accès diamant de haute qualité ne sont pas indexées dans [https://doaj.org/ le Directory of Open Access Journals (DOAJ)] pour des raisons techniques ou à cause des limites de capacité (Bosman et al. p. 87).

De nombreuses revues en libre accès diamant comptent sur le travail impayé, et bien qu'il existe certaines infrastructures pour reconnaître ce travail, telles que la [https://www.kent.ac.uk/guides/credit-contributor-roles-taxonomy Contributor Roles Taxonomy (CRediT)] et la [https://tadirah.info/ Taxonomy of Digital Research Activities in the Humanities (TaDiRAH)], elles ne sont pas largement utilisées. La mémoire institutionnelle est un défi connexe, puisque de nombreuses revues s'appuient sur le travail de quelques personnes dévouées dont les connaissances sont perdues lorsqu'elles déménagent ou prennent leur retraite (Bosman et al., p. 90). Les revues dirigées par la communauté manquent également des ressources de grands éditeurs, notamment des budgets de marketing, d’une visibilité plus faible et d’un pouvoir de négociation réduit (p. 35).

En termes de durabilité, bien que les revues en libre accès diamants rapportent des dépenses opérationnelles relativement faibles, elles ont tendance à dépendre du financement par subventions, des dons et d'autres sources de financement contingentes. De nombreuses revues n'ont pas d’idée claire de leur situation financière, et la plupart équilibrent leur budget (40 %) ou rapportent des pertes financières (25 %) au cours d'une année donnée (p. 8). Bien que la diversité des revues en libre accès diamants soit de multiples façons un avantage, cela signifie également qu'il est difficile de trouver des gains d'efficacité et des économies d'échelle dans ces revues. En termes de durabilité, le nombre d'articles publiés dans des revues en libre accès diamant a augmenté lentement entre 2014 et 2018, puis a commencé à décliner, contrairement à la croissance plus forte observée dans les revues basées sur les frais de publication au cours de la même période (p. 31).

Avec le but général d'augmenter la capacité des revues en libre accès diamant, le plan d'action présente des recommandations liées à l'efficacité, aux normes de qualité, au renforcement des capacités et à la durabilité, résumées ici :
* Efficacité : aligner et partager les infrastructures, les systèmes opérationnels et d'autres ressources tout en respectant les différences entre les disciplines et les communautés de recherche
* Normes de qualité : aligner les normes existantes pour développer un cadre de publication international libre accès diamant ainsi qu'un outil d'auto-évaluation pour les revues
* Renforcement des capacités : impliquer et soutenir les parties prenantes en développant une suite d'outils pour la publication des revues en libre accès diamant et en fondant un Capacity Centre for Diamond Publishing à but non lucratif
* Durabilité : développer des cadres pour assurer la reconnaissance et la protection de la propriété et de la gouvernance des revues ainsi que la transparence financière ; assurer que les coûts de publication en libre accès diamant soient répartis et prôner pour un soutien financier plus robuste

==Le plan d'action dans la presse==
Bien que le plan d'action n'ait pas été largement couvert par la presse universitaire ou populaire, un article à ce sujet dans ''Research Professional News'' note que le modèle du libre accès diamant est considéré par les défenseurs et défenseuses comme un moyen pour la communauté universitaire de garder ou de reprendre un plus grand contrôle sur l'édition savante, car de nombreuses plateformes du libre accès diamant sont entretenues par des communautés universitaires ou des sociétés savantes utilisant des bénévoles et des ressources institutionnelles (Bisson 2022).

==Le plan d'action et le partenariat INKE==
En réponse à l'étude de 2021 intitulée [https://pkp.sfu.ca/2022/01/27/pkp-enables-diamond-open-access/ ''PKP Enables Diamond Open Access''], John Willinsky et Juan Pablo Alperin distillent des conclusions de cette étude correspondant au Public Knowledge Project (PKP) et à son logiciel [https://pkp.sfu.ca/software/ojs/ Open Journal Systems (OJS)]. Trois de ses points clés sont les suivants :
* Etant donné le fait que 60 % des revues utilisent OJS, le PKP a clairement contribué à faire des revues en libre accès diamant une réalité
* Aucune autre plateforme ou outil, à l'exception du courriel, n'est aussi largement utilisé que l'OJS par des revues en libre accès diamant pour leurs opérations, surtout parce qu’elles s’élargissent.
* Aucun autre système n'a autant contribué à soutenir la diversité linguistique ou géographique de l'édition savante qu'OJS (2021).

La réponse souligne également que l'OJS permet la conformité au Plan S, notamment en permettant la conservation des droits d'auteur et des licences lisibles par machine par défaut (voir « [[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour du Plan S : La Stratégie de conservation des droits|Mise à jour du Plan S : la stratégie de conservation des droits]]&amp;#8239;»). OJS a également des capacités techniques nécessaires pour attribuer des DOI et publier dans plusieurs formats, et il fournit [https://docs.pkp.sfu.ca/plan-s/en/ un guide répondant] [https://docs.pkp.sfu.ca/plan-s/en/ aux][https://docs.pkp.sfu.ca/plan-s/en/  exigences du Plan S]. En termes de préservation, [https://pkp.sfu.ca/pkp-pn/ le PKP Preservation Network] fournit l'archivage des revues utilisant des versions compatibles d'OJS, et PKP s'associe à [https://clockss.org/ CLOCKSS], [https://doaj.org/ DOAJ], [https://keepers.issn.org/ Keepers Registry] et [https://archive.org/ Internet Archive] pour aider les revues utilisant d'autres versions à préserver leur contenu. OJS agit également comme une plateforme commune pour aider à rationaliser des opérations et des coûts, et ses revues peuvent être indexées et prélevées.

Alperin note également dans un article de [https://doi.org/10.1038/d41586-022-03201-w ''Nature''] que, bien que le modèle libre accès diamant soit populaire et réussi en Amérique latine et dans le Sud global depuis des décennies, la popularité des modèles de publication soutenus par les frais de publication met ce modèle en danger. Notant que les chercheurs et chercheuses d’Amérique latine se sentent pressés de publier dans des revues prestigieuses, souvent soutenues par les frais de publication et basées dans le Nord global, Alperin déclare que des frais de publication engendrent plus de frais de publication. Plus il y a de fonds disponibles pour les payer, et plus il y a de chercheurs et chercheuses qui ont la capacité de les payer, plus des revues se sentiront obligées de les imposer (2022). Il déclare que détourner les fonds alloués aux frais de publication vers des investissements dans l'infrastructure pour soutenir les revues en libre accès diamant conduirait à un contenu de meilleure qualité, à des coûts d'exploitation inférieurs et au prestige plus élevé pour ces revues.

[https://www.coalition-publi.ca/le-projet Coalition Publica], un partenariat entre des partenaires d'INKE [https://www.erudit.org/fr/ Érudit] et le PKP a publié [https://www.coalition-publi.ca/news-nouvelles/2022/3/1/plan-daction-pour-le-libre-acces une déclaration] à l'appui du plan d'action en mars 2022. Notant que les revues en libre accès diamant ont reçu des ressources limitées au cours des 20 dernières années, Coalition Publica lance un appel à des organismes de financement et à d'autres organisations à travers le monde, pas seulement en Europe, pour explorer des solutions aux défis auxquels ces revues sont confrontées. Coalition Publica souligne également que ces solutions doivent respecter divers contextes dans lesquels ces revues opèrent, considérant que les actions qui ne soutiennent pas directement la large variété de contextes institutionnels, nationaux et culturels dans lesquels les revues en libre accès diamant opèrent, peuvent par inadvertance diminuer cette forme d'édition savante la plus diversifiée et la plus inclusive (2022). Coalition Publica, Érudit et PKP ont tous endossé ce plan d'action.

Le plan d'action a également été approuvé par [https://oaaustralasia.org/ Open Access Australasia], un partenaire INKE par le biais du [https://inke.ca/canadian-australian-partnership-for-open-scholarship/ Canadian–Australian Partnership for Open Access (CAPOS)].

==Le plan d'action et la communauté universitaire élargie==
En automne 2022, le plan d'action a été approuvé par plus de 130 institutions de recherche, revues, bibliothèques et associations de bibliothèques, universités, conseils de recherche, organismes de financement et individus du monde entier.

Plusieurs organisations ont publié des déclarations à l'appui du plan d'action, notamment
* l’[https://www.aka.fi/en/about-us/whats-new/press-releases/2022/academy-of-finland-signs-action-plan-for-diamond-open-access/ Academy of Finland]
* [https://www.cesaer.org/news/advancing-open-science-through-institutional-strategies-open-access-to-conference-proceedings-and-an-action-plan-on-diamond-open-access-1173/ CESAER]
* [https://geographie-cites.cnrs.fr/en/open-access-scientific-publishing-cybergeo-co-signs-the-european-diamond-action-plan/ Cybergeo]
* le [https://www.dfg.de/en/research_funding/announcements_proposals/2022/info_wissenschaft_22_26/index.html Deutsche Forschungsgemeinschaft (German Research Foundation)]
* [https://www.eifl.net/news/eifl-endorses-action-plan-diamond-oa Electronic Information for Libraries (EIFL)]
* [https://eua.eu/news/845:eua-signs-action-plan-for-diamond-open-access.html l’European University Association (EUA)]
* [https://blog.doaj.org/2022/03/02/action-plan-for-diamond-access/ DOAJ]
* [https://library.harvard.edu/about/news/2022-03-14/harvard-library-endorses-new-action-plan-diamond-open-access Harvard Library]
* le [https://www.the-guild.eu/news/2022/diversity-sustainability-and-quality-must-be-the-h.html Guild of European Research-Intensive Universities]
* [https://os.helmholtz.de/en/newsroom/news/article/helmholtz-supports-action-plan-for-diamond-open-access/ Helmholtz Open Science]
* le [https://www.leru.org/news/leru-supports-the-action-plan-for-diamond-open-access League of European Research Universities (LERU)]
* le [https://blogs.tib.eu/wp/tib/2022/08/17/endorses-action-plan/ Leibniz-Informationszentrum Technik und Naturwissenschaften Universitätsbibliothek (TIB)]
* [https://oep.hypotheses.org/2811 OpenEdition]
* [https://ulakbim.tubitak.gov.tr/en/haber/tubitak-ulakbim-has-signed-action-plan-diamond-open-access ULAKBIM (Turkish Academic Network and Information Centre)]
* l’[https://www.uc.pt/en/openscience/news/action-plan-for-diamond-open-access-is-released/ Universidade d Coimbra]
* le [https://yerun.eu/2022/03/yerun-endorses-action-plan-for-diamond-open-access/ Young European Research Universities Network (YERUN)].

En septembre 2022, Science Europe a organisé la [https://www.scienceeurope.org/events/diamond-oa-conference/ Diamond Open Access Conference] à Zadar, en Croatie, un événement qui a rassemblé des organisations et des individus qui ont approuvé le plan d'action pour discuter des meilleures pratiques et de leur mise en œuvre et pour s’introduire dans le projet [https://diamasproject.eu/ Developing Institutional Open Access Publishing Models to Advance Scholarly Communication (DIAMAS)]. Le projet DIAMAS est dirigé par l’Université d’Aix-Marseille et a été lancé en septembre 2022, avec la participation de cOAlition S et Science Europe. Ce projet de 3 millions d'euros planifié d’être achevé ende trois ans implique 23 organisations européennes et dirigera certaines des initiatives décrites dans le plan d'action. [https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/how-to-participate/org-details/999999999/project/101094397/program/43108390/details Creating a Robust Accessible Federated Technology for Open Access (CRAFT-OA)], financé par Horizon Europe, est un projet fraternel dirigé par la Public Law Foundation de l'Université de Göttingen, avec l’objectif de consolider les infrastructures qui rendent possible la publication en libre accès diamant en Europe.

[https://educopia.org/scaling-diamond-oa/ Kristen Ratan] du projet [https://educopia.org/next-generation-library-publishing/ Next Generation Library Publishing] de l'Educopia note que, bien qu'il y ait une vitalité particulièrement forte derrière le mouvement de libre accès en ce moment, à la suite du 20e anniversaire de [https://www.budapestopenaccessinitiative.org/boai20/ Budapest Open Access Initiative] et des recommandations qui l'accompagnent, [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre la Recommandation de l'UNESCO sur une science ouverte], et [https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-Access-Memo.pdf le Nelson Memo] récent des États-Unis, le développement d'infrastructures ouvertes robustes et durables est nécessaire pour faire progresser le libre accès, et ce développement prendra du temps (voir « [[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|La recommandation de l'UNESCO sur la science ouverte]]&amp;#8239;» et « [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le mémo Nelson : Une politique d’accès public mis à jour aux États-Unis|Le mémo Nelson : Une politique d’accès public mis à jour aux États-Unis]]&amp;#8239;»). Ratan déclare que les universités et les organisations à but non lucratif jouent un rôle clé dans le développement des infrastructures ouvertes et dirigées par la communauté demandées dans le plan d'action, et que les consortiums seront importants pour les développer et les déployer à grande échelle. [https://www.researchinformation.info/viewpoint/diamond-mission May Copsey] discute du rôle des sociétés savantes dans le soutien du libre accès diamant de la même manière dans un article réfléchissant à l'étude de Bosman et al. en relation avec la revue ''Chemical Science'' de la Royal Society of Chemistry, qui a est transformée au libre accès diamant en 2015.

[https://redalyc.org/home.oa Redalyc] et [http://amelica.org/index.php/en/home/ AmeliCA], des initiatives de l'University of the State of Mexico financées par [https://www.arcadiafund.org.uk/ Arcadia], développent et promeuvent une infrastructure ouverte, collaborative et communautaire pour la publication et l'indexation des revues en libre accès diamant en Amérique latine. L’objectif de ces projets est d’améliorer la durabilité et la bibliodiversité de l'édition savante.

Dans un article pour le blog cOAlition S, [https://www.coalition-s.org/blog/diamond-mining/ Martin Paul Eve] souligne la question de la préservation soulignée dans le rapport et dans le plan d'action comme une préoccupation majeure pour les revues en libre accès diamant, mais note que le problème pourrait être résolu relativement facilement et à peu de frais grâce à l'établissement d'un réseau de préservation numérique développé en collaboration entre quelques organismes de financement (« Diamond Mining&amp;#8239;»).

==Le plan d'action et la science ouverte==
Il y a un fort consensus sur le fait que le libre accès diamant est un composant important de l'écosystème de l'édition savante. L'étude de Bosman et al. déclare, par exemple, qu'il est un composant du monde de la diffusion savante qui est aussi ancienne que la science elle-même : la communauté scientifique évaluant la qualité scientifique et gérant seule la communication savante. Bien qu'un thème commun des réponses au plan d'action soit que le soutien à la publication en libre accès diamant est important pour faire progresser un écosystème de science ouvert solide, durable et équitable, mais que cela nécessitera des investissements dans les infrastructures technologiques et humaines.

Un autre thème connexe est que l’édition savante est à un point de basculement, ou ce que Martin Paul Eve décrit comme un carrefour. Il déclare que nous allons succomber à des frais de publication et que l'écosystème de communication savante deviendra encore plus stratifié qu'il a été à ce jour ou nous pourrions embrasser une révolution. De plus, il décrit des revues en libre accès diamant comme cette révolution dans le microcosme (2021).

Vu la prévalence des revues libre accès diamant dans l'écosystème de la communication savante et l'importance de leur modèle de publication pour l'ouverture de la science, la mise en œuvre des recommandations du plan d'action pourrait avoir des effets étendus.

==Ouvrages cités==
*Academy of Finland. 2022. « Academy of Finland Signs Action Plan for Diamond Open Access&amp;#8239;». Le 16 mai 2022. [https://www.aka.fi/en/about-us/whats-new/press-releases/2022/academy-of-finland-signs-action-plan-for-diamond-open-access/ https://www.aka.fi/en/about-us/whats-new/press-releases/2022/academy-of-finland-signs-action-plan-for-diamond-open-access/].

*Alperin, Juan Pablo. 2022. « Why I Think Ending Article-Processing Charges Will Save Open Access&amp;#8239;». ''Nature'', le 12 octobre 2022, [https://doi.org/10.1038/d41586-022-03201-w https://doi.org/10.1038/d41586-022-03201-w].

*Ancion, Zoé, Lidia Borrell-Damián, Pierre Mounier, Johan Rooryck et Bregt Saenen. 2022. ''Action Plan for Diamond Open Access''. Édité par Johan Rooryck et Laetitia Martin. Science Europe, cOAlition S, OEPRAS et l’Agence nationale de la recherche. [https://doi.org/10.5281/zenodo.6282403 https://doi.org/10.5281/zenodo.6282403].

*Bisson, Robin. 2022. « Funder Groups Announce Push to Strengthen ‘Diamond’ Open Access&amp;#8239;». ''Research Professional News''. Le 7 février 2022. [https://www.researchprofessionalnews.com/rr-news-europe-infrastructure-2022-2-funder-groups-announce-push-to-strengthen-diamond-open-access/ https://www.researchprofessionalnews.com/rr-news-europe-infrastructure-2022-2-funder-groups-announce-push-to-strengthen-diamond-open-access/].

*Bosman, Jeroen, Jan Erik Frantsvåg, Bianca Kramer, Pierre-Carl Langlais et Vanessa Proudman. 2021. ''OA Diamond Journals Study, Part 1: Findings''. [https://doi.org/10.5281/zenodo.4558704 https://doi.org/10.5281/zenodo.4558704].

*Coalition Publica. 2022. « Réponse de Coalition Publica au Plan d'action pour le libre accès diamant&amp;#8239;». Le 2 mars 2022. [https://www.coalition-publi.ca/news-nouvelles/2022/3/1/plan-daction-pour-le-libre-acces https://www.coalition-publi.ca/news-nouvelles/2022/3/1/plan-daction-pour-le-libre-acces].

*Copsey, May. 2021. « A Diamond Mission&amp;#8239;». ''Research Information'', le 18 mai 2021. [https://www.researchinformation.info/viewpoint/diamond-mission https://www.researchinformation.info/viewpoint/diamond-mission].

*Eve, Martin Paul. 2021. « Diamond Mining&amp;#8239;». ''Plan S: Making Full and Immediate Open Access a Reality''. Le 31 mars 2021. [https://www.coalition-s.org/blog/diamond-mining/ https://www.coalition-s.org/blog/diamond-mining/].

*Ratan, Kristen. 2022. « Scaling Diamond OA: Universities as Centers of Open Publishing Excellence&amp;#8239;». ''Educopia Institute: Community Cultivators''. Le 8 septembre 2022. [https://educopia.org/scaling-diamond-oa/ https://educopia.org/scaling-diamond-oa/].

*Willinsky, John, et Juan Pablo Alperin. 2021. ''PKP Enables Diamond Open Access: The OA Diamond Journals Study''. Public Knowledge Project. [https://pkp.sfu.ca/2022/01/27/pkp-enables-diamond-open-access/ https://pkp.sfu.ca/2022/01/27/pkp-enables-diamond-open-access/].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>jckw2w1liyh9uz27tvnbwg7pd5vmxxo</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Semaine internationale du libre accès 2022, le 24–30 octobre</title>
    <ns>0</ns>
    <id>82367</id>
    <revision>
      <id>745428</id>
      <parentid>745151</parentid>
      <timestamp>2025-06-26T23:15:42Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745428</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="11277" sha1="c4okvqocz2hrecjbog7akkkrtzw2n9k" xml:space="preserve">''Cette observation a été écrite par Caroline Winter (avec remerciements à Virginia Barbour pour ses commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

La 15e [https://www.openaccessweek.org/ Semaine internationale du libre accès] s’est déroulée du 24 au 30 octobre. Le thème de cette année était « Ouvert à la justice climatique », reconnaissant que les effets généralisés du changement climatique sont vécus différemment par différents groupes de personnes. Une des façons dont cette injustice se manifeste est à travers les niveaux inéquitables d’accès aux connaissances et à l’information sur le changement climatique, alors le libre accès « peut créer des voies vers un partage plus équitable des connaissances et servir de moyen de lutte contre les inégalités qui conditionnent les impacts du changement climatique et notre réponse à ces derniers » (« Semaine » 2022).

La Semaine internationale du libre accès est une initiative de [https://sparcopen.org/ SPARC] et du [https://www.openaccessweek.org/about Comité consultatif de la Semaine du libre accès]. C’est l’occasion pour les communautés de recherche et du monde entier d’organiser des événements sous une bannière commune et d’attirer l’attention du public sur le libre accès. Cette année, des événements en personne, virtuels et hybrides, allant des ateliers et des conférences publiques à des projections de films et des cours de formation, ont eu lieu.

==Semaine internationale du libre accès dans la presse==
La Semaine internationale du libre accès n’a pas été largement couverte par la presse. Cependant, le site Web technologique [https://www.hpcwire.com/off-the-wire/cern-to-host-open-access-week-event-oct-24-28/ ''HPCwire''] a mentionné [https://indico.cern.ch/event/1179488/ les événements organisés par le Scientific Information Service du CERN], qui comprenaient une série de discussions en ligne qui a été enregistrée et peut être visionnée en ligne. [https://www.researchinformation.info/interview/us-every-week-open-access-week ''Research Information''] a également publié une entrevue avec le directeur de la publication d’Oxford University Press, Rhodri Jackson, qui s’est concentrée sur ses événements de la Semaine du libre accès et sur les initiatives du libre accès de l’éditeur. En outre, [https://asiapacificreport.nz/2022/10/26/fiji-academic-warns-over-media-climate-injustice-in-open-access-webinar/ ''Asia Pacific Report''] a mentionné un panel de médias sur l’injustice climatique qui faisait partie de l’agenda [https://oaaustralasia.org/events/open-access-week-2022/ d’Open Access Australasia pour la Semaine du libre accès].

==La Semaine internationale du libre accès et le Partenariat INKE==
Plusieurs membres du Partenariat INKE ont organisé des célébrations. La [https://www.lib.sfu.ca/help/publish/scholarly-publishing/open-access/open-access-week bibliothèque de l’Université Simon Fraser] a organisé une série d’ateliers, une exposition des affiches et des tableaux ainsi qu’une collection sur la justice climatique dans son dépôt institutionnel.

Le [https://pkp.sfu.ca/2022/10/20/celebrating-open-access-week-open-for-climate-justice/ Public Knowledge Project] a célébré avec une collection de recherche liée au climat, comprenant des revues ouvertes et des articles publiés avec son logiciel [https://pkp.sfu.ca/ojs/ Open Journal Systems].

[https://oaaustralasia.org/events/open-access-week-2022/ Open Access Australasia,] un partenaire de l’INKE via le [https://inke.ca/canadian-australian-partnership-for-open-scholarship/ Canadian–Australian Partnership for Open Scholarship (CAPOS),] a organisé un programme d’événements comprenant des tables rondes et un « hackathon » collaboratif dont le but était de développer un guide ouvert des ressources sur la justice climatique pour les enseignants. Les enregistrements de tous les webinaires sont disponibles pour visionnement.

Selon Virginia Barbour, directrice d’Open Access Australasia, un des objectifs principaux des événements de la semaine en Australie et en Nouvelle-Zélande était l’inclusion des chercheurs et chercheuses, des journalistes et des militants et militantes du climat de la région Pacifique, où, bien sûr, les effets du changement climatique se font sentir le plus intensément. Les membres de la communauté de recherche du Pacifique ont souligné toutes sortes des inégalités en ce qui concerne la recherche : non seulement le manque d’accès à la recherche, mais aussi les obstacles à la publication de la recherche en raison du coût et, enfin, le manque de la consultation et du partage de la recherche avec les communautés affectées. Les journalistes du Pacifique ont soulevé les risques d’un manque de diversité dans le journalisme, en particulier dans les langues locales.

==La Semaine internationale du libre accès et communauté universitaire élargie==
Voici un aperçu des événements qui ont eu lieu au Canada et dans le monde. Une liste plus complète est disponible sur [https://www.openaccessweek.org/events le site Web de la Semaine internationale du libre accès].

De nombreuses universités canadiennes ont organisé des événements pour célébrer la semaine. [https://library.concordia.ca/research/open-access/open-access-week.php La Bibliothèque de l’Université Concordia] a organisé un salon transdisciplinaire comprenant des conférences, des ateliers et des expositions numériques interactives. [https://libraryguides.mcgill.ca/c.php?g=518294&amp;p=3544275 La Bibliothèque de l’Université McGill] a également organisé des ateliers ainsi qu’une projection du film ''Paywall: The Business of Scholarship''  (voir « [[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Film Paywall : The Business of Scholarship|Le Film ''Paywall: The Business of Scholarship'']] »).] [https://uwaterloo.ca/open-scholarship/news/archive/2022-10 L’Université de Waterloo] a publié une série d’articles dans son ''Daily Bulletin'' sur la justice climatique. [https://utsc.library.utoronto.ca/join-us-open-access-week-2022 L’Université de Toronto Scarborough] a organisé un quiz sur le libre accès sur Twitter et a encouragé sa communauté de recherche à déposer les travaux dans le dépôt institutionnel en l’honneur de la Semaine du libre accès. De même, [https://library.uwinnipeg.ca/news/2022/10/open-access-week-20221.html l’Université de Winnipeg] a partagé un portail de recherche ouverte sur les changements climatiques accueillie dans son dépôt institutionnel.

En Afrique, [https://www.eifl.net/events/open-access-week-2022 Electronic Information for Libraries (EIFL)] a marqué la semaine en mettant en avant son [https://www.eifl.net/programmes/open-access-programme programme], qui plaide en faveur du libre accès et de la recherche ouverte aux niveaux national et international et renforce les capacités de publication de revues ouvertes et de dépôts en libre accès, entre autres activités.

La Semaine du libre accès a été largement célébrée en Europe. [https://scienceeurope.org/news/open-access-week-2022-science-europe/ Science Europe] a souligné la publication récente de son document de la nouvelle orientation [https://scienceeurope.org/our-resources/direction-paper-open-science/ ''Open Science as Part of a Well-Functioning Research System,''] soulignant également ses efforts pour faire progresser le libre accès diamant (voir « [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Un plan d’action pour faire avancer le libre accès diamant|Un plan d’action pour faire progresser le libre accès diamant]] »). L’organisation européenne d’infrastructure de science ouvertes [https://www.openaire.eu/oaweek2022 OpenAIRE] a organisé deux séries de webinaires, avec deux sessions axées sur l’élaboration des politiques: Research Communities &amp; Climate Action et Being Open to Drive Change and Open Data in the Forefront: Driving Policy Decisions for Climate Justice. Le [https://openaccess.dk/oaw2022 Danish Network for Open Access] a organisé une série de webinaires, et de nombreuses autres organisations de recherche européennes ont également célébré avec des événements au cours de la semaine.

Aux États-Unis, [https://acrl.ala.org/acrlinsider/celebrate-open-access-week-2022/ l’Association of College and Research Libraries] de l’American Library Association a célébré en mettant en avant ses livres, revues et bulletins d’information en libre accès ainsi que certains de ses ateliers, podcasts et webinaires ouverts. De nombreuses bibliothèques universitaires ont également organisé des événements pour marquer la semaine, rassemblés dans une liste de [https://www.arl.org/blog/arl-member-libraries-promote-open-access-week-2022/ l'Association of Research Libraries].

Plusieurs éditeurs ont également marqué la Semaine internationale du libre accès. Cambridge University Press a célébré en mettant en avant certaines de ses initiatives en libre accès, telles que son programme [https://www.research4life.org/ Research4Life] pour les institutions des pays à revenu faible et intermédiaire et son programme [https://www.cambridge.org/core/services/open-research/open-access/oa-book-pilot-flip-it-open Flip it Open], grâce auquel les monographies sont inversées pour être ouvertes une fois qu’elles atteignent un certain niveau de vente (voir « [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Une mise à jour sur les monographies en libre accès|Une mise à jour sur les monographies en libre accès]] »). MIT Press a mis en évidence certains de ses articles de revues et livres en libre accès liés à la justice climatique et à ses initiatives de publication en libre accès, y compris son modèle de publication Direct to Open pour les monographies et les collections éditées (voir « [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les accords de libre accès|Les monographies en libre accès]] »). Le blogue Early Career Researchers Community du PLOS a présenté un [https://ecrcommunity.plos.org/2022/10/30/open-access-week-2022-open-for-climate-justice/ article sur la Semaine du libre accès], notant que les chercheurs et chercheuses émergents jouent un rôle important dans l’avancement du libre accès.

==La Semaine internationale du libre accès et la science ouverte==
Le libre accès est une composante importante de la science ouverte, et en attirant l’attention du public et en renforçant la communauté autour du libre accès, la Semaine internationale du libre accès contribue à faire progresser la science ouverte plus largement.

==Ouvrage cité==
*«&amp;#8239;Semaine de l'open access 2022: Ouvert pour la justice climatique&amp;#8239;». 2022. International Open Access Week. [https://www.openaccessweek.org/theme/fr https://www.openaccessweek.org/theme/fr].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>c4okvqocz2hrecjbog7akkkrtzw2n9k</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La consolidation du marché et la communication savante</title>
    <ns>0</ns>
    <id>82369</id>
    <revision>
      <id>745429</id>
      <parentid>745152</parentid>
      <timestamp>2025-06-26T23:18:24Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745429</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="40994" sha1="toalzdh4jjr90e14ncls3jepp5hgpkh" xml:space="preserve">''Cette observation a été écrite par Caroline Winter (avec ses remerciements à Leslie Chan, John Maxwell et Jefferson Pooley pour leurs commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

Au cours de la dernière décennie ou plus, une tendance vers la consolidation du marché a été observée dans l’écosystème des communications savantes, avec moins d’entreprises détenant des parts croissantes du marché. Une étude de Data Think a estimé qu’en 2021, les très grands éditeurs (ceux qui publient plus de 500 revues) ont représenté seulement 0,06% des éditeurs de leur étude, mais ils ont publié près de la moitié – 47% – de tous les articles (Pollock 2022). Cette consolidation croissante du marché a soulevé des préoccupations dans la communauté de la science ouverte et dans la communauté universitaire en général.

Un certain nombre de fusions entre de grands éditeurs et des entreprises associées en 2021 ont incité un commentateur à l’appeler une année de consolidation du marché (Crotty 2021 «&amp;#8239;Market&amp;#8239;»). [https://newsroom.wiley.com/press-releases/press-release-details/2021/Wiley-Announces-the-Acquisition-of-Hindawi/default.aspx Wiley a eu une année particulièrement active] : il a acquis l’éditeur en libre accès [https://newsroom.wiley.com/press-releases/press-release-details/2021/Wiley-Announces-the-Acquisition-of-Hindawi/default.aspx Hindawi], l’entreprise de services d’édition [https://jjeditorial.com/wiley-acquires-jj-editorial-advance-publishing-service-offerings/ J &amp; J Editorial], l’entreprise de logiciels d’édition savante [https://newsroom.wiley.com/press-releases/press-release-details/2021/Wiley-Acquires-eJournalPress/default.aspx eJournalPress] et [https://knowledgeunlatched.org/2021/12/wiley-acquires-oa-innovator-ku/ Knowledge Unlatched], une plateforme et un modèle pour la publication de monographies en libre accès. Toujours en 2021, [https://group.springernature.com/gp/group/media/press-releases/springer-nature-has-aquired-atlantis-press/18946944 Springer Nature a acquis Atlantis Press], un éditeur en libre accès basé à Paris, et [https://clarivate.com/news/clarivate-to-acquire-proquest/ Clarivate a acquis ProQuest].

La consolidation du marché a poursuivi en 2022 : en mai, [https://www.copyright.com/ccc-announces-acquisition-of-ringgold-leading-provider-of-organization-identifiers-in-scholarly-communications/ Copyright Clearance Center a acquis Ringgold], et en juin, [https://www.elsevier.com/ Elsevier] a acquis [https://www.interfolio.com/ Interfolio], une entreprise de technologie universitaire dont le portefeuille comprend la plateforme de recherche d’emploi [https://www.interfolio.com/products/dossier/ universitaire Dossier], la plateforme d’analyse de recherche [https://www.interfolio.com/products/researchfish/ Researchfish] et la plateforme de données administratives [https://www.interfolio.com/faculty-information-system/ Faculty Information System (FIS).]

La question de la consolidation du marché et du rôle de la stratégie et la politique corporative dans la science ouverte est complexe et évolue rapidement. Cette observation offre un aperçu des développements récents et met en évidence certaines questions clés liées à la science ouverte.

==Monopolisation==
En raison de la nature de l’industrie des communications savantes, elle est particulièrement vulnérable à la monopolisation et à d’autres pratiques anticoncurrentielles. En effet, les trois principaux marchés concernés – les revues savantes, les fournisseurs des services de bibliothèque et l’analyse des données de recherche – manquent de transparence en ce qui concerne les prix et les clauses contractuelles (par exemple par le biais des accords de non-divulgation) et sont soumis aux discriminations par les prix au premier degré, où les prix sont déterminés par le montant maximum que chaque client est prêt à payer. De plus, le coût de la commutation entre les produits est très élevé (SPARC 2021 «&amp;#8239;Opposing&amp;#8239;»).

À mesure que les entreprises fusionnent, moins d’entreprises détiennent de plus grandes parts de marché, ce qui conduit à des monopoles et des duopoles. La monopolisation peut avoir des effets négatifs sur les consommateurs – dans ce cas, la communauté savante – car elle peut entraîner une hausse des prix, une réduction du choix des consommateurs et une diminution de l’innovation. Un projet de fusion entre les éditeurs éducatifs [https://www.mheducation.com/news-media/press-releases/cengage-mcgraw-hill-merge.html Cengage et McGraw-Hill Education], par exemple, a été largement contesté par les communautés universitaires et éducatives en raison de ses effets sur le marché des manuels et a été annulé en 2020 en raison de préoccupations antitrust et réglementaires (SPARC 2020).

L’acquisition d’Interfolio par Elsevier a suscité des préoccupations similaires, bien qu’elle ait finalement été couronnée de succès. L’acquisition a concentré la part d’Elsevier sur le marché émergeant des systèmes d’information des facultés («&amp;#8239;faculty information systems&amp;#8239;») à un point juste en dessous du seuil fixé par les régulateurs antitrust. Il est probable que cette part de marché augmentera puisque Elsevier pourra regrouper ses systèmes d’information des facultés avec ses autres produits, tels que les abonnements à des revues (SPARC 2022, «&amp;#8239;Executive&amp;#8239;» et «&amp;#8239;The Interfolio&amp;#8239;»), y compris dans le cadre des accords de lecture et de publication (de Knecht 2020 ; Chen et Chan 2021; voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les accords de libre accès|Accords de libre accès]]&amp;#8239;»). Ce regroupement peut entraîner une réduction de contrôle de budgets pour les bibliothèques, par exemple si l’administration d’une université s’abonne à Interfolio dans le cadre d’un forfait qui comprend des abonnements à des revues. Dans ce cas, les bibliothèques perdraient également la capacité de faire progresser le libre accès par le biais de négociations avec les éditeurs, comme l’University of California l’a fait avec Elsevier (SPARC 2022, «&amp;#8239;Elsevier’s&amp;#8239;» ; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La rupture entre Elsevier et l'University of California|La rupture entre Elsevier et l’University of California]]&amp;#8239;»] et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Négociations de l'édition à libre accès en Europe|Négociations de l’édition à libre accès en Europe]]&amp;#8239;»).

Les monopoles ont évincé de petits éditeurs du marché, ce qui a abouti à une perte de bibliodiversité et d’options de publication pour les auteurs (voir Shearer et al. 2020 et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Appel de Jussieu pour la Science ouverte et la bibliodiversité|Appel de Jussieu pour la Science ouverte et la bibliodiversité]]&amp;#8239;»). Les petites institutions et celles qui ont moins de ressources, y compris celles des pays du Sud, sont également désavantagées.

Une préoccupation connexe est la monopolisation des plateformes, ce qui est le cas lorsque des entreprises individuelles contrôlent les plateformes, les outils et les services qui sous-tendent l’ensemble de l’entreprise de recherche, de la collecte de données à la publication, en passant par l’évaluation et l’examen du rendement, la promotion et la titularisation. Ces systèmes monétisent le cycle de vie complet de la recherche (SPARC 2021 «&amp;#8239;Opposing&amp;#8239;»). Une étude de George Chen, Alejandro Posada et Leslie Chan a révélé des tendances claires vers une telle monopolisation ou intégration verticale dans la recherche et l’enseignement supérieur parmi les principaux éditeurs commerciaux (2019).

L’acquisition d’Interfolio par Elsevier et ses autres acquisitions récentes illustrent ce phénomène. Elsevier est l’un des plus grands éditeurs universitaires au monde et a été critiqué pour ses marges bénéficiaires élevées et ses pratiques d’exploitation. En plus de ses activités de publication, Elsevier a acquis le système de gestion de référence [https://www.elsevier.com/about/press-releases/archive/corporate/elsevier-acquires-mendeley,-an-innovative,-cloud-based-research-management-and-social-collaboration-platform Mendeley] en 2013, les plateformes de dépôt [https://www.elsevier.com/connect/ssrn-the-leading-social-science-and-humanities-repository-and-online-community-joins-elsevier Social Science Research Network (SSRN)] en 2016 et [https://www.elsevier.com/about/press-releases/corporate/elsevier-acquires-bepress,-a-leading-service-provider-used-by-academic-institutions-to-showcase-their-research bepress] en 2017, le fournisseur des mesures d’impact alternatives [https://www.elsevier.com/about/press-releases/archive/corporate/elsevier-acquires-leading-altmetrics-provider-plum-analytics Plum Analytics] en 2017 et le système de gestion de flux de travail [https://www.elsevier.com/about/press-releases/archive/corporate/elsevier-closes-its-acquisition-of-aries-systems Aries Systems] en 2018. Elsevier s’intéresse également aux classements des universités grâce à ses liens avec ''Times Higher Education'', qui produit les ''World University Rankings'' (Chen et Chan 2021). La plateforme de données administratives d’Interfolio est un type émergent de plateforme, qui facilite – et recueille des données sur – les demandes d’emploi et les processus d’embauche ; rapports sur les activités du corps professoral; et les processus d’examen, de promotion et de titularisation. Elsevier est en train de devenir ce que Roger Schonfeld appelle une entreprise de flux de travail (2022), qui profite des services de plateforme qu’elle fournit et des données qu’ils génèrent.

==La confidentialité des données==
La tendance des grands éditeurs universitaires d’acquérir ou de fusionner avec des entreprises de données (par exemple Elsevier et Interfolio ou Clarivate et ProQuest) soulève des préoccupations quant à la façon dont les données recueillies au moyen d’outils et de plateformes de recherche sont utilisées. Les données collectées via des plateformes propriétaires sont soumises aux politiques de confidentialité de l’entreprise et peuvent être vendues à des tierces parties. Par exemple, Elsevier fait partie de l'entreprise RELX, qui vend des données personnelles à l’Immigration and Customs Enforcement (ICE) des États-Unis via LexisNexis (Biddle 2021; Funk 2019; Lamdan 2022), une pratique qui a été dénoncée et contestée par les communautés juridiques et universitaires (SPARC 2022, «&amp;#8239;Possible&amp;#8239;» ; voir, par exemple, [https://notechforice.com/ #NoTechForICE]).

==La commercialisation du libre accès et des infrastructures ouvertes==
Parce que le mandat des éditeurs commerciaux est de générer des profits, beaucoup préfèrent la voie à libre accès des frais de publication des articles, où les coûts de l’ouverture de la recherche sont supportés par les auteurs, souvent par l’intermédiaire des organismes de financement. Ce modèle économique a été critiqué d’être allé à l’encontre des idéaux du mouvement libre accès et d’avoir exacerbé les inégalités existant dans l’édition savante, puisque seuls les auteurs ayant accès au financement peuvent assumer la publication ouverte de leurs recherches. À mesure que de moins en moins d’éditeurs commerciaux acquièrent plus de contrôle sur le marché de l’édition, les frais de publication peuvent également s’enraciner davantage, au détriment des modèles de financement collectif et d’autres qui soutiennent un accès libre plus généralisé.

En plus de cette commercialisation des modèles d’édition en libre accès, des préoccupations ont été soulevées au sujet de la commercialisation des infrastructures de recherche et d’édition, en particulier l’acquisition, la monétisation et la monopolisation des infrastructures ouvertes. Un exemple clé est celui de [https://knowledgeunlatched.org/ Knowledge Unlatched], qui a été fondée en tant qu’organisation à but non lucratif en 2012 mais a été transformée en une entreprise à but lucratif en 2016, une décision qui a été largement critiquée pour son manque de transparence (Gerakopoulou et al. 2021).

Un exemple connexe est l’acquisition de [https://www.ringgold.com/ Ringgold] par le Copyright Clearance Centre (CCC), une entreprise de licences collectives des droits d’auteur. Ringgold fournit et gère des identifiants pérennes et leurs métadonnées associées pour des organisations. Bien qu’il existe des registres ouverts des identifiants pérennes pour des organisations, tels que [https://ror.org/ le Research Organization Registry (ROR)] et [https://isni.org/ l’International Standard Name Identifier (ISNI),] Ringgold a des ressources nécessaires pour développer des métadonnées propriétaires pour une désambiguïsation plus robuste. À mesure que les identifiants pérennes sont de plus en plus intégrés dans les flux de travail de recherche, de publication, d’octroi de permis et de financement (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Le Persistent Identifier (PID) Consortium de Royaume-Uni|Le ‹&amp;#8239;Persistent Identifier (PID) Consortium&amp;#8239;› de Royaume-Uni]]&amp;#8239;» et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche|Mise à jour ORCID : Intégration des identifiants ORCID dans les workflows de financement de la recherche]]&amp;#8239;» des registres ouverts, dirigés et financés par la communauté risquent d’être évincés de l’écosystème au profit des systèmes propriétaires.

==La consolidation du marché des communications savantes dans la presse==
La consolidation du marché est une préoccupation de longue date dans la communauté universitaire, y compris dans la presse universitaire. Un article de 2017 de [https://www.affairesuniversitaires.ca/opinion/a-mon-avis/la-publication-scientifique-un-carrefour/?_ga=2.68265489.1487666577.1677105656-1604337689.1677105656 Marc Couture] dans ''Affaires universitaires'' traite du rôle des frais de publication dans la monétisation de l’accès ouvert. Il note que ces frais sont autrefois considérés comme une menace, mais le libre accès est devenu une opportunité pour les éditeurs commerciaux de resserrer leur emprise sur le marché et leurs sources de revenus. Un article d’opinion publié en 2018 par [https://www.universityaffairs.ca/opinion/in-my-opinion/time-stand-academic-publishing-industry/ Adriane Macdonald et Nicole Eva] dans ''Affaires universitaires ''traite de la consolidation du marché dans le contexte des pratiques prédatrices dans l’édition universitaire et appelle la communauté universitaire à prendre des mesures collectives pour reprendre le contrôle de l’industrie. Un article dans [https://researchprofessionalnews.com/rr-news-europe-views-of-europe-2022-1-how-to-reclaim-ownership-of-scholarly-publishing/ ''Research Professional News''] demande un système d’adjudication ouvert et transparent pour remplacer les négociations secrètes entre les bibliothèques et les éditeurs.

Un article publié en 2019 par [https://www.chronicle.com/article/elseviers-presence-on-campuses-spans-more-than-journals-that-has-some-scholars-worried/ Lindsay Ellis] dans ''The Chronicle'' attire l’attention sur les appels croissants de la communauté universitaire à faire attention à qui détient et contrôle des infrastructures numériques. Un article publié en 2021 par [https://americanlibrariesmagazine.org/blogs/the-scoop/clarivate-to-acquire-proquest/ Marshall Breeding] dans le magazine'' American Libraries'' discute de l’acquisition de ProQuest par Clarivate du point de vue des bibliothèques universitaires, notant que, bien que la fusion offre la possibilité d’une suite complète et intégrée d’outils pour soutenir la recherche, l’expansion de l’entreprise dans les données et l’analyse est une raison de prudence. L’acquisition de Knowledge Unlatched par Wiley a également été couverte dans [https://www.infodocket.com/2021/12/02/open-access-publishing-wiley-acquires-knowledge-unlatched/ l’InfoDocket du][https://www.infodocket.com/2021/12/02/open-access-publishing-wiley-acquires-knowledge-unlatched/ '' Library Journal''].

Le secteur des technologies éducatives a également abordé le sujet : l’acquisition d’Interfolio par Elsevier a été couverte par [https://listedtech.com/blog/elsevier-to-acquire-interfolio/ ListEdTech], un analyste de marché des technologies éducatives,  et l’acquisition de Knowledge Unlatched par Wiley a été couverte par [https://www.edsurge.com/news/2018-11-27-faculty-information-system-developer-interfolio-acquired-for-110m EdSurge] et [https://iblnews.org/wiley-continues-its-acquisition-strategy-with-the-purchase-of-knowledge-unlatched/ IBL News].

==Les réponses du Partenariat INKE==
En 2016, le [https://www.crkn-rcdr.ca/fr Réseau canadien de documentation pour la recherche (RCDR),] un partenaire d’INKE, a lancé [https://www.crkn-rcdr.ca/fr/projet-sur-lutilisation-des-revues le Projet sur l’utilisation des revues], auquel ont participé 28 organismes membres du RCDR partout au Canada dans le cadre d’une étude sur la façon dont la consolidation à travers l’édition savante affecte les bibliothèques. Ce projet s’étend sur les recherches menées par Vincent Larivière, membre d’INKE, sur la consolidation des éditeurs universitaires, qui est décrite dans une étude comme un oligopole, un marché dans lequel quelques très grandes entreprises dominent une industrie (Larivière et al. 2015).

Dans un mémoire de 2018 [https://www.carl-abrc.ca/wp-content/uploads/2018/02/CARL_Brief_Subscription_Costs_fr.pdf pour l’Association des bibliothèques de recherche du Canada (ABRC),] Kathleen Shearer, partenaire d’INKE, identifie la consolidation du marché comme l’une des causes principales des coûts d’abonnement aux revues insoutenables. Elle note que les coûts d’abonnement sont les plus élevés chez les grands éditeurs commerciaux, dont les marges bénéficiaires se situent entre 28 et 40 % environ (Shearer, 2018, 3). Shearer souligne que les négociations consortiales et l’action collective des communautés savantes sont des stratégies pour atténuer ces problèmes, et note qu'«&amp;#8239;Il n’y aura aucun allégement à long terme de hausses de prix tant que nous ne promouvons pas collectivement la transition vers un système de communication savante plus ouvert et que nous n’investissons pas dans une infrastructure et des services plus durables&amp;#8239;» (8).

En outre, de nombreux partenaires d’INKE développent des outils et des infrastructures ouverts et dirigés par la communauté pour la science ouverte. Par exemple, [https://www.coalition-publi.ca/le-projet Coalition Publica], une collaboration entre les partenaires d’INKE [https://www.erudit.org/fr/ Érudit] et le [https://pkp.sfu.ca/ Public Knowledge Project (PKP)], développe une infrastructure nationale non commerciale et open source pour la communication savante numérique qui combine le logiciel [https://pkp.sfu.ca/ojs/ Open Journal Systems] de PKP et la  plateforme de publication ouverte d’Érudit. D’autres membres de la communauté publient des revues en libre accès dirigées par la communauté, telles que [https://popjournal.ca/ ''Pop! Public. Open. Participatory.''], publié par le Canadian Institute for Studies in Publishing de l’Université Simon Fraser et dirigé par John Maxwell, membre  d’INKE, et [https://ideah.pubpub.org/ ''IDEAH: Interdisciplinary Digital Engagement in Arts &amp; Humanities''], fondé par Alyssa Arbuckle, Lindsey Setter et Ray Siemens et publié par [https://c-ski.ca/ le Canadian Social Knowledge Institute] (C-SKI, l’organisme-cadre d’INKE).

==Les réactions de l’ensemble de la communauté universitaire élargie==
La consolidation du marché des communications savantes est un sujet récurrent dans des publications telles que [https://scholarlykitchen.sspnet.org/ ''The Scholarly Kitchen'']. Bon nombre de leurs articles examinent et analysent les acquisitions. Ces articles comprennent les sujets de l’acquisition de [https://scholarlykitchen.sspnet.org/2021/10/04/wiley-acquires-editorial-services-group/ J&amp;J Editorial] et [https://scholarlykitchen.sspnet.org/2021/01/11/wiley-acquires-hindawi-interview/ Hindawi] par Wiley, ainsi que de l’acquisition de [https://scholarlykitchen.sspnet.org/2021/05/18/clarivate-to-acquire-proquest/ ProQuest] par Clarivate et de [https://scholarlykitchen.sspnet.org/2021/05/18/clarivate-to-acquire-proquest/ l’acquisition de ][https://scholarlykitchen.sspnet.org/2022/05/10/is-infrastructure-consolidation-the-next-step-ccc-acquires-ringgold/ Ringgold par Copyright Clearance Center]. Ils comprennent également la discussion sur l’acquisition de [https://scholarlykitchen.sspnet.org/2017/08/02/elsevier-acquires-bepress/ bepress], [https://scholarlykitchen.sspnet.org/2018/08/06/interpreting-elseviers-acquisition-aries-systems/ Aries Systems] et [https://scholarlykitchen.sspnet.org/2022/04/25/elsevier-acquire-interfolio/ Interfolio] par Elsevier.

Les auteurs de'' The Scholarly Kitchen'' ont également analysé [https://scholarlykitchen.sspnet.org/2021/08/03/guest-post-one-publisher-to-rule-them-all-consolidation-trends-in-the-scholarly-communications-and-research-sectors/ les tendances générales] de la consolidation du marché et ses effets potentiels, tels que ses [https://scholarlykitchen.sspnet.org/2021/09/14/when-consolidation-provides-benefits/ avantages globaux] et [https://scholarlykitchen.sspnet.org/2021/12/14/market-consolidation-and-the-demise-of-the-independently-publishing-research-society/ ses effets négatifs potentiels sur l’édition de sociétés savantes]. D’autres articles examinent comment l’industrie de l’édition est en train de changer, en examinant [https://scholarlykitchen.sspnet.org/2022/06/09/revisiting-when-is-a-publisher-not-a-publisher-cobbling-together-the-pieces-to-build-a-workflow-business/ les transformations des éditeurs en «&amp;#8239;entreprises de flux de travail], [https://scholarlykitchen.sspnet.org/2021/12/09/new-clarivate-science/ la consolidation du marché à la suite du libre accès] et la résurgence possible des [https://scholarlykitchen.sspnet.org/2022/06/29/revisiting-return-of-the-big-brands-how-legacy-publishers-will-coopt-open-access/ éditeurs traditionnels].

En réponse à l’acquisition de Knowledge Unlatched par Wiley, [https://copim.pubpub.org/ le Community-led Open Publication Infrastructures for Monographs (COPIM)] a publié [https://copim.pubpub.org/pub/copim-statement-corporate-acquisition-oa-infra/release/1 une déclaration exprimant son inquiétude quant à la consolidation du marché] et, en particulier, aux tentatives croissantes de monétiser et, potentiellement, de monopoliser les infrastructures de diffusion des connaissances ouvertes (COPIM 2021).

Le [https://sparcopen.org/ Scholarly Publishing and Academic Resources Coalition (SPARC)] a été une des voix principales dans la communauté universitaire contre la consolidation du marché. Il a analysé les tendances du marché des communications savantes au cours des quatre dernières années et a développé une [https://infrastructure.sparcopen.org/ ressource sur l’acquisition commerciale d’infrastructures de recherche numériques] en 2018 avec des mises à jour en [https://infrastructure.sparcopen.org/2020-update 2020] et [https://infrastructure.sparcopen.org/media/posts/report-landscape-analysis-2021-update.pdf 2021].

SPARC a également lutté contre la fusion prévue entre Cengage et McGraw-Hill en 2019.  Il a notamment déposé une [https://sparcopen.org/news/2019/sparc-urges-department-of-justice-to-block-merger-between-cengage-and-mcgraw-hill/ lettre] avec le Department of Justice des États-Unis faisant valoir le fait que la fusion proposée violerait les réglementations antitrust.

En réponse au projet d’acquisition de ProQuest par Clarivate, SPARC a soumis un [https://sparcopen.org/wp-content/uploads/2021/10/SPARC-FTC-Letter-in-Opposition-to-the-Clarivate-ProQuest-Merger.pdf dossier antitrust] à la Federal Trade Commission des États-Unis, ainsi qu’une [https://sparcopen.org/news/2021/sparc-statement-on-completion-of-clarivate-proquest-merger/ déclaration] en réponse à la fusion réalisée. L’[https://investinopen.org/blog/take-action-to-stop-the-lock-up-of-research-and-learning/ Invest in Open] s’est également opposé à cette fusion, soulignant la question du capitalisme de surveillance et évoquant l’appel aux infrastructures ouvertes dans [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre la Recommandation de l’UNESCO sur une science ouverte] (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|Recommandation de l’UNESCO sur la science ouverte]]&amp;#8239;»).

==La consolidation du marché et la science ouverte==
Le changement de l’édition savante imprimée à l’édition numérique, qui a permis le libre accès et la science ouverte – et les infrastructures numériques qui les rendent possibles – a également mené à la collection et à la vente de données des chercheurs et chercheuses (Chen et al., 2019; Larivière et al., 2015). Comme le souligne Lamdan, les monopoles de plateforme entraînent des problèmes éthiques pour les bibliothécaires en particulier, qui doivent tenir compte des besoins de recherche et d’accès des utilisateurs et utilisatrices ainsi que des préoccupations en matière de confidentialité des données (2022).

Certains membres de la communauté universitaire voient la tendance aux monopoles de plateforme et à la commercialisation des infrastructures comme une conséquence du mouvement du libre accès, alors que les éditeurs commerciaux s’éloignent des modèles commerciaux basés sur l’abonnement au profit des services de plateforme et de l’analyse (Schonfeld 2022). Les exigences techniques et pragmatiques des politiques de libre accès telles que [https://www.coalition-s.org/ le Plan S] peuvent être considérées comme favorisant les grands éditeurs dotés de ressources suffisantes et poussant les petits éditeurs à s’associer aux plus grands ou à s’exclure complètement (Crotty 2021 «&amp;#8239;More&amp;#8239;»).

La commercialisation des infrastructures numériques qui rendent possible le libre accès est une préoccupation majeure pour l’avenir de la science ouverte (Joy 2019) : comme l’affirment Geoffrey Bilder, Jennifer Lin et Cameron Neylon, tout ce que les mouvements ouverts gagnent en ouvrant du contenu et des données sera menacé si des infrastructures savantes sont fermées (2015).

Cependant, les effets de la consolidation du marché s’étendent au-delà de la science ouverte à l’entreprise de recherche elle-même: dans la déclaration de SPARC sur la réalisation de la fusion entre Elsevier et Interfolio, la directrice exécutive Heather Joseph a averti qu'il devrait être de la plus haute préoccupation que l’entreprise de recherche soit dominée par de moins en moins d’entreprises dotées d’un pouvoir de marché extraordinaire qui contrôlent de grand volume de notre infrastructure numérique (SPARC 2021 «&amp;#8239;Déclaration SPARC&amp;#8239;»).

Les conflits d’intérêts sont l’une de ces préoccupations : de moins en moins d’entreprises contrôlent de plus en plus les plateformes et le contenu qui sous-tendent l’ensemble du processus de recherche. Cela signifie que les entreprises qui publient des revues contrôlent les données et les métriques sur lesquelles ces revues sont évaluées. Certains critiques craignent que la métrique d’une entreprise donnée – calculée à l’aide de méthodes et de données exclusives – ne privilégie les revues de cet éditeur. D’autres, comme Ellen Finnie des MIT Libraries, notent que, même si ce n’est pas le cas, ce type de consolidation du marché crée un conflit d’intérêts intrinsèquement problématique (Straumsheim 2016). De plus, les chercheurs et chercheuses des établissements qui s’abonnent à une plateforme de données administratives peuvent faire des choix en fonction du sentiment d’être surveillés, par exemple s’ils croient que le fait de soumettre leur recherche à une revue appartenant à la société-mère de la plateforme de données administratives aura une incidence plus positive sur leur profil que le fait de la publier ailleurs, ou que le fait de postuler à un poste dans un autre établissement par l’entremise de la plateforme Dossier aura une incidence négative sur leur profil (Chen et coll., 2019; SPARC 2022, «&amp;#8239;Possible&amp;#8239;»).

Ces discussions soulèvent également des questions plus importantes sur les valeurs liées à la communication savante (voir Chen et Chan, 2021). Samuel Moore note que la consolidation du marché et les oligopoles de l’édition continuant signifient que les valeurs et les pratiques des grands éditeurs influencent fortement ce qui sera l’édition (2021). Les données recueillies auprès des plateformes de recherche peuvent également être utilisées pour déterminer quels types de recherche devraient être financés, ce qui déplace le pouvoir de la communauté universitaire, soulève des préoccupations quant à la liberté académique et renforce les inégalités existantes (Aspesi, 2022; Chen et coll., 2019; Lamdan et coll., 2022; Sly et Koivisto, 2023).

La consolidation croissante de l’industrie des communications savantes et l’essor du modèle de publication en tant que données (Sly et Koivisto 2023) soulèvent des questions sur le rôle des éditeurs commerciaux, qui sont, de plus en plus souvent, également des fournisseurs de plateformes et de services, dans l’écosystème ouvert de la recherche dans son ensemble.

==Ouvrages cités==
*Aspesi, Claudio, Knowledge Equity Lab et SPARC. L’automne 2022. «&amp;#8239;The High Cost of Knowledge Monopoly&amp;#8239;». ''Unsettling Knowledge Inequities''. [https://knowledgeequitylab.ca/podcast/s3-ep3/ https://knowledgeequitylab.ca/podcast/s3-ep3/].

*Biddle, Sam. 2021. «&amp;#8239;LexisNexis to Provide Giant Database of Personal Information to ICE&amp;#8239;». ''The Intercept'', le 2 avril 2021. [https://theintercept.com/2021/04/02/ice-database-surveillance-lexisnexis/ https://theintercept.com/2021/04/02/ice-database-surveillance-lexisnexis/].

*Bilder, Geoffrey, Jennifer Lin, et Cameron Neylon. 2015. «&amp;#8239;Principles for Open Scholarly Infrastructures&amp;#8239;». ''Science in the Open''. Le 23 février 2015. [http://dx.doi.org/10.6084/m9.figshare.1314859 http://dx.doi.org/10.6084/m9.figshare.1314859].

*Chen, George, Alejandro Posada, et Leslie Chan. 2019. «&amp;#8239;Vertical Integration in Academic Publishing: Implications for Knowledge Inequality&amp;#8239;». Dans le ''Connecting the Knowledge Commons: From Projects to Sustainable Infrastructure'', sous la direction de Pierre Mounier et Leslie Chan. Laboratoire d’idées. OpenEdition Press. [http://books.openedition.org/oep/9068 http://books.openedition.org/oep/9068].

*Chen, George, et Leslie Chan. 2021. «&amp;#8239;University Rankings and Governance by Metrics and Algorithms&amp;#8239;». Dans le ''Research Handbook on University Rankings: Theory, Methodology, Influence and Impact'', sous la direction de Ellen Hazelkorn et Georgiana Mihut. Edward Elgar. [https://doi.org/10.5281/zenodo.4730593 https://doi.org/10.5281/zenodo.4730593].

*COPIM (Community-led Open Publication Infrastructures for Monographs). 2021. «&amp;#8239;COPIM Statement on the Corporate Acquisition of OA Infrastructure&amp;#8239;». COPIM. Le 15 décembre 2021. [https://copim.pubpub.org/pub/copim-statement-corporate-acquisition-oa-infra/release/1 https://copim.pubpub.org/pub/copim-statement-corporate-acquisition-oa-infra/release/1].

*Couture, Marc. 2017. «&amp;#8239;La publication scientifique à un carrefour&amp;#8239;». ''Affaires universitaires'', le 12 juillet 2017.  [https://www.affairesuniversitaires.ca/opinion/a-mon-avis/la-publication-scientifique-un-carrefour/ https://www.affairesuniversitaires.ca/opinion/a-mon-avis/la-publication-scientifique-un-carrefour/].

*Crotty, David. 2021. «&amp;#8239;Market Consolidation and the Demise of the Independently Publishing Research Society&amp;#8239;». ''The Scholarly Kitchen''. Le 14 décembre 2021. [https://scholarlykitchen.sspnet.org/2021/12/14/market-consolidation-and-the-demise-of-the-independently-publishing-research-society/ https://scholarlykitchen.sspnet.org/2021/12/14/market-consolidation-and-the-demise-of-the-independently-publishing-research-society/].

*Crotty, David. 2021. «&amp;#8239;More Unintended Consequences: How the Plan S Transformative Journal Route Favors Larger Incumbent Publishers&amp;#8239;». ''The Scholarly Kitchen''. Le 22 juillet 2021. [https://scholarlykitchen.sspnet.org/2021/07/22/more-unexpected-consequences-how-the-plan-s-transformative-journal-route-favors-larger-incumbent-publishers/ https://scholarlykitchen.sspnet.org/2021/07/22/more-unexpected-consequences-how-the-plan-s-transformative-journal-route-favors-larger-incumbent-publishers/].

*Funk, McKenzie. 2019. «&amp;#8239;How ICE Picks Its Targets in the Surveillance Age&amp;#8239;». ''The New York Times'', October 2, 2019. [https://www.nytimes.com/2019/10/02/magazine/ice-surveillance-deportation.html https://www.nytimes.com/2019/10/02/magazine/ice-surveillance-deportation.html].

*Gerakopoulou, Elli, Izabella Penier, et Joe Deville. 2021. «&amp;#8239;The Promise of Collaboration: Collective Funding Models and the Integration of Open Access Books into Libraries&amp;#8239;». COPIM. [https://doi.org/10.5281/zenodo.4501512 https://doi.org/10.5281/zenodo.4501512].

*Joy, Eileen. 2019. «&amp;#8239;The Enclosure of Scholarly Infrastructures, Open Access Books &amp; the Necessity of Community&amp;#8239;». ''Punctum Books''. Le 7 juin 2019. [https://punctumbooks.com/blog/the-enclosure-of-scholarly-infrastructures-open-access-books-the-necessity-of-community/ https://punctumbooks.com/blog/the-enclosure-of-scholarly-infrastructures-open-access-books-the-necessity-of-community/].

*de Knecht, Sicco. 2020. «&amp;#8239;Dutch Open Science Deal Primarily Benefits Elsevier&amp;#8239;». ''ScienceGuide''. Le 29 juin 2020. [https://www.scienceguide.nl/2020/06/open-science-deal-benefits-elsevier/ https://www.scienceguide.nl/2020/06/open-science-deal-benefits-elsevier/].

*Lamdan, Sarah, Knowledge Equity Lab et SPARC. L’automne 2022. «&amp;#8239;Data Cartels and Surveillance Publishing&amp;#8239;». ''Unsettling Knowledge Inequities''. [https://knowledgeequitylab.ca/podcast/s3-e2/ https://knowledgeequitylab.ca/podcast/s3-e2/].

*Lamdan, Sarah. 2022. ''Data Cartels: The Companies That Control and Monopolize Our Information''. Stanford University Press. [https://doi.org/10.1515/9781503633728 https://doi.org/10.1515/9781503633728].

*Larivière, Vincent, Stefanie Haustein, et Philippe Mongeon. 2015. «&amp;#8239;The Oligopoly of Academic Publishers in the Digital Era&amp;#8239;». ''PLOS ONE'' 10 (6): e0127502. [https://doi.org/10.1371/journal.pone.0127502 https://doi.org/10.1371/journal.pone.0127502].

*Moore, Samuel. 2021. «&amp;#8239;All Publishers Great and Small&amp;#8239;». ''Samuel Moore''. Le 26 juillet 2021. [https://www.samuelmoore.org/2021/07/26/all-publishers-great-and-small/ https://www.samuelmoore.org/2021/07/26/all-publishers-great-and-small/].

*Pollock, Dan. 2022. «&amp;#8239;News &amp; Views: Publishers and Market Consolidation – Part 1 of 2&amp;#8239;». ''Delta Think''. Le 21 juin 2022. [https://deltathink.com/news-views-publishers-and-market-consolidation-part-1-of-2/ https://deltathink.com/news-views-publishers-and-market-consolidation-part-1-of-2/].

*Schnfeld, Roger C. 2022. «&amp;#8239;Revisiting: When Is a Publisher Not a Publisher?&amp;#8239;» ''The Scholarly Kitchen''. Le 9 juin 2022. [https://scholarlykitchen.sspnet.org/2022/06/09/revisiting-when-is-a-publisher-not-a-publisher-cobbling-together-the-pieces-to-build-a-workflow-business/ https://scholarlykitchen.sspnet.org/2022/06/09/revisiting-when-is-a-publisher-not-a-publisher-cobbling-together-the-pieces-to-build-a-workflow-business/].

*Shearer, Kathleen. 2018. ''Contrer les coûts insoutenables des revues savantes : Un mémoire de l’ABRC''. L’Association des bibliothèques de recherche du Canada. [https://www.carl-abrc.ca/wp-content/uploads/2018/02/CARL_Brief_Subscription_Costs_fr.pdf https://www.carl-abrc.ca/wp-content/uploads/2018/02/CARL_Brief_Subscription_Costs_fr.pdf].

*Shearer, Kathleen, Leslie Chan, Iryna Kuchma, et Pierre Mounier. 2020. «&amp;#8239;Fostering Bibliodiversity in Scholarly Communications: A Call for Action&amp;#8239;». Zenodo. [https://doi.org/10.5281/zenodo.3752923 https://doi.org/10.5281/zenodo.3752923].

*Sly, Jordan, et Joseph Koivisto. 2023. «&amp;#8239;Publication and Data Surveillance in Academia&amp;#8239;». ''Research Information Yearbook 2022–2023'' (janvier). [https://www.researchinformation.info/feature/publication-and-data-surveillance-academia https://www.researchinformation.info/feature/publication-and-data-surveillance-academia].

*SPARC (Scholarly Publishing and Academic Resources Coalition). 2020. «&amp;#8239;Cengage/McGraw-Hill Merger Called Off&amp;#8239;». Le 4 mai 2020. [https://sparcopen.org/news/2020/cengage-mcgraw-hill-merger-called-off/ https://sparcopen.org/news/2020/cengage-mcgraw-hill-merger-called-off/].

*SPARC (Scholarly Publishing and Academic Resources Coalition). 2021. «&amp;#8239;Landscape Analysis and Roadmap for Action: 2021 Update&amp;#8239;». [https://infrastructure.sparcopen.org/media/posts/report-landscape-analysis-2021-update.pdf https://infrastructure.sparcopen.org/media/posts/report-landscape-analysis-2021-update.pdf].

*SPARC (Scholarly Publishing and Academic Resources Coalition). 2021. «&amp;#8239;SPARC Statement on Completion of Clarivate-ProQuest Merger&amp;#8239;». SPARC. Le 2 décembre 2021. [https://sparcopen.org/news/2021/sparc-statement-on-completion-of-clarivate-proquest-merger/ https://sparcopen.org/news/2021/sparc-statement-on-completion-of-clarivate-proquest-merger/].

*SPARC (Scholarly Publishing and Academic Resources Coalition). 2021. «&amp;#8239;Opposing the Merger Between Clarivate PLC and ProQuest LLC&amp;#8239;». Le 22 octobre 2021. [https://sparcopen.org/wp-content/uploads/2021/10/SPARC-FTC-Letter-in-Opposition-to-the-Clarivate-ProQuest-Merger.pdf https://sparcopen.org/wp-content/uploads/2021/10/SPARC-FTC-Letter-in-Opposition-to-the-Clarivate-ProQuest-Merger.pdf].

*SPARC (Scholarly Publishing and Academic Resources Coalition). 2022. «&amp;#8239;The Interfolio Acquisition Highly Concentrates the Nascent Market for Faculty Information Systems&amp;#8239;». Dans l’''Interfolio Acquisition''. Le 29 juin 2022. [https://infrastructure.sparcopen.org/interfolio-acquisition/fis-market-concentration https://infrastructure.sparcopen.org/interfolio-acquisition/fis-market-concentration].

*SPARC (Scholarly Publishing and Academic Resources Coalition). 2022. «&amp;#8239;Executive Summary&amp;#8239;». Dans l’''Interfolio Acquisition''. Le 29 juin 2022. [https://infrastructure.sparcopen.org/interfolio-acquisition/executive-summary https://infrastructure.sparcopen.org/interfolio-acquisition/executive-summary].

*SPARC (Scholarly Publishing and Academic Resources Coalition). 2022. «&amp;#8239;Elsevier’s Dominance in the FIS Market Could Threaten Competition in Related Markets&amp;#8239;». Le 29 juin 2022. [https://infrastructure.sparcopen.org/interfolio-acquisition/related-markets https://infrastructure.sparcopen.org/interfolio-acquisition/related-markets].

*SPARC (Scholarly Publishing and Academic Resources Coalition). 2022. «&amp;#8239;Possible Negative Impacts From Elsevier’s Increased Market Power&amp;#8239;». Dans l’''Interfolio Acquisition''. Le 29 juin 2022. [https://infrastructure.sparcopen.org/interfolio-acquisition/possible-negative-impacts https://infrastructure.sparcopen.org//interfolio-acquisition/possible-negative-impacts].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>toalzdh4jjr90e14ncls3jepp5hgpkh</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les droits de propriété intellectuelle et la science ouverte en Europe</title>
    <ns>0</ns>
    <id>82370</id>
    <revision>
      <id>745430</id>
      <parentid>745153</parentid>
      <timestamp>2025-06-26T23:19:22Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745430</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22120" sha1="eguyxs3fq46pkk806g7zgco1rt5reu2" xml:space="preserve">''Cette observation a été écrite par Caroline Winter, avec ses remerciements à Iryna Kuchma et John Willinsky pour leurs commentaires et contributions.''

L'intersection des droits de propriété intellectuelle (DPI) et de la science ouverte est depuis longtemps une question d'intérêt pour le milieu de la recherche et pour l'industrie. Les politiques et la législation en matière de propriété intellectuelle visent à établir un équilibre entre les droits moraux et économiques des créateurs et créatrices de leurs œuvres et les droits et intérêts du grand public. La nécessité de comprendre comment les DPI et la science ouverte interagissent est devenue plus pressante à mesure que le mouvement de la science ouverte a progressé. Cela est particulièrement vrai dans le contexte de la pandémie de COVID-19, qui a mis en évidence le pouvoir de la recherche ouverte et collaborative de résoudre des défis complexes et mondiaux (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Science Ouverte et COVID-19|Science ouverte et COVID-19]]&amp;#8239;»).

En 2019, les membres de l'UNESCO ont demandé un instrument pour construire un consensus international autour de la science ouverte, et la [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre Recommandation de l'UNESCO sur une science ouverte] a été publiée en novembre 2021 (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|La Recommandation de l'UNESCO sur la science ouverte]]&amp;#8239;»). La tension possible entre la science ouverte et les DPI a été l'une des questions clés identifiées lors des consultations de l'UNESCO.

En avril 2021, l'UNESCO a abordé cette question en organisant une réunion d'experts en ligne [https://www.unesco.org/en/articles/expert-meeting-open-science-and-intellectual-property-rights sur la science ouverte et les DPI], réunissant plus de 500 participants, y compris six experts et expertes invités. Comme il est indiqué dans le [https://en.unesco.org/sites/default/files/report_expert_meeting_ipr_os_23apr.pdf rapport de la Réunion d'experts], les messages clés suivants sont ressortis de la discussion :

# Étant donné qu'il existe des tensions possibles entre les DPI et la science ouverte, des politiques et des approches stratégiques équilibrées sont nécessaires.
# Plutôt que d'être un obstacle à la science ouverte, un cadre de propriété intellectuelle bien défini peut promouvoir l'ouverture et la collaboration : par exemple, les licences ouvertes peuvent aider à garantir que toutes les contributions à la recherche sont reconnues.
# Il est également nécessaire de comprendre les complexités et les diverses formes des DPI et leurs différentes implications pour la science ouverte, y compris la façon dont elles se croisent avec d'autres systèmes réglementaires (UNESCO 2021).

En Europe, les tensions possibles entre les DPI et la science ouverte ont été abordées dans plusieurs études et rapports publiés au cours des dernières années, parallèlement à des politiques appelant à une plus grande ouverture, telles que [https://www.coalition-s.org/ le Plan S] (lancé en 2018) (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Plan S et cOAlition S|Plan S et coAlition S]]&amp;#8239;», «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Mise à jour du Plan S : L’élargissement de l’adhésion de la cOAlition S|Mise à jour du Plan S : l’élargissement de l’adhésion de la cOAlition S]]&amp;#8239;» et «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les Fonds de recherche du Québec rejoignent la cOAlition S|Les Fonds de Recherche du Québec se rejoignent la cOAlition S]]&amp;#8239;»).

En 2017, le [https://commission.europa.eu/about-european-commission/departments-and-executive-agencies/joint-research-centre_en Centre commun de recherche (JRC) de la Commission européenne] et la [https://commission.europa.eu/about-european-commission/departments-and-executive-agencies/research-and-innovation_en Direction générale de la recherche et de l'innovation] ont organisé un atelier sur [https://op.europa.eu/en/publication-detail/-/publication/8294fcb4-8df7-11e7-b92d-01aa75ed71a1/language-en ''IPR, technology transfer &amp; open science'']. Les conclusions de l'atelier comprenaient que l'équilibre était nécessaire, que les DPI était un outil important pour assurer l'attribution en science ouverte, que les stratégies d'équilibre entre les deux devraient être éclairées par les meilleures pratiques existantes, et que le traitement de cette question était particulièrement urgent alors que l[https://eosc-portal.eu/ 'European Open Science Cloud] était en cours de développement (Crouzier 2017).

En 2020, European Association of Research and Technology Associations (EARTO) a publié le livre blanc [https://www.earto.eu/wp-content/uploads/EARTO-Paper-Towards-a-Balanced-Approach-Between-IPRs-and-Open-Science-Policy-Final.pdf ''Towards a Balanced Approach Between IPRs and Open Science Policy'']. Bien qu'il appelle également à l'équilibre, le document suggère des cadres politiques et des approches qui soutiennent la commercialisation et l'innovation ouverte, un modèle de recherche, de développement et d'innovation impliquant la collaboration entre les universités, les entreprises et d'autres parties prenantes.

En avril 2022, la European Federation of Academies of Sciences and Humanities (l’ALLEA) a publié la déclaration [https://allea.org/wp-content/uploads/2022/04/ALLEA-Statement-Aligning-IPR-with-Open-Science.pdf ''Aligning Intellectual Property Rights with Open Science'']. Cette déclaration met l'accent sur la commercialisation des innovations par le biais de brevets et souligne que la science ouverte peut être mise en œuvre dans le cadre des DPI. Par exemple, les brevets accordent aux créateurs et créatrices des droits exclusifs sur les innovations pendant un certain temps, mais lorsque les brevets expirent, ces innovations deviennent des connaissances ouvertes.

L'étude de 2022 de Christina Angelopoulos [https://op.europa.eu/en/publication-detail/-/publication/884062d5-1145-11ed-8fa0-01aa75ed71a1 ''Study on EU Copyright and Related Rights and Access to and Reuse of Scientific Publications, Including Open Access''] analyse le rôle du régime de droits d'auteur de l'UE dans l'accès et la réutilisation des publications savantes. Elle offre des recommandations législatives et non législatives pour faciliter l'accès et demande un examen attentif des effets – intentionnels et non intentionnels – de chacun.

Le rapport [https://op.europa.eu/en/publication-detail/-/publication/42d27e04-b715-11ec-b6f4-01aa75ed71a1/language-en ''Open Science and Intellectual Property Rights: How Can They Better Interact? State of the Art and Reflections''] a également été publié en avril 2022 par la Commission européenne. Ce rapport présente les résultats d'une méta-analyse de la littérature sur la science ouverte et la propriété intellectuelle de la dernière décennie, y compris la recherche publiée et la littérature grise (documents de politique, rapports et livres blancs). Il soutient que, bien qu'il existe une tension entre la science ouverte et la propriété intellectuelle, elles ne sont pas fondamentalement incompatibles. Elles doivent plutôt être équilibrées, c’est-à-dire aussi ouvertes que possible, aussi fermées que nécessaire (p. 2).

Le rapport de la Commission européenne présente quelques conclusions générales ainsi que des recommandations pour des décideurs et décideuses politiques, chercheurs et chercheuses et des praticiens et praticiennes qui font écho à celles des autres rapports décrits ici. Ces constatations et recommandations peuvent être résumées en plusieurs thèmes :
# Il doit y avoir un équilibre entre la protection de la propriété intellectuelle et le partage ouvert des connaissances, avec l'ouverture comme valeur par défaut. Idéalement, un cadre mondial des DPI devrait être mis au point pour la science ouverte qui soit adaptée à l'évolution des technologies et qui protège l'ouverture de la science fondamentale.
# D'autres recherches sur la relation entre les DPI et la science ouverte sont nécessaires, en particulier celles sur l'effet de la réglementation de la propriété intellectuelle sur l'innovation, aux niveaux national et européen. Une meilleure compréhension de la valeur des œuvres et de l'infrastructure du domaine public, y compris l'Internet, est également nécessaire.
# Bien que le financement gouvernemental et les réglementations en matière de propriété intellectuelle aient tendance à encourager les innovations qui peuvent aider à résoudre des défis mondiaux complexes (p. ex. la recherche sur la COVID-19), nous devons considérer de manière holistique la véritable valeur de la science ouverte et collaborative et les coûts réels de la protection des innovations potentiellement vitales en tant que propriété intellectuelle.
# Les choix des chercheurs et chercheuses quant à leur travail doivent être respectés. Ils ne devraient pas être pénalisés pour avoir fait la science ouverte, par exemple en raison de charges administratives ou financières supplémentaires. En même temps, leurs DPI et les modalités de réutilisation des données doivent être respectés.
# Les praticiens et praticiennes doivent être au courant des meilleures pratiques de la communauté des logiciels ouverts, y compris l'utilisation des licences à jour, la diversité des licences, la normalisation des licences et le processus de les rendre lisibles par l’homme et la machine, la création des communautés de pratique et la mentalité «&amp;#8239;release early, release often&amp;#8239;».

Au niveau politique, le rapport appelle à la création d'un Office for Free Intellectual Property Rights and Open Science, qui serait aligné sur [https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:52020DC0760&amp;qid=1689012632159 le Plan d’action en faveur de la propriété intellectuelle] de l'Union européenne et qui pourrait être financé par Horizon Europe. Il appelle également à une révision de la législation européenne en matière de propriété intellectuelle relative aux hyperliens, aux exceptions au droit d'auteur pour l'exploration de textes et de données et aux prélèvements sur le droit d'auteur.

Le rapport se termine par un appel à réviser et à adapter la réglementation en matière de propriété intellectuelle pour l'aligner sur les nouvelles technologies développées au cours des dernières décennies. Il soutient que l'ouverture de recherche et de la science bien que leurs processus devraient entraîner une transformation prometteuse de la science (p. 9). Un nouveau paradigme de propriété intellectuelle est nécessaire pour cette nouvelle ère numérique.

==DPI et la science ouvert dans la presse==
Bien que le rapport de la Commission européenne n'ait pas été largement couvert dans la presse, la propriété intellectuelle et la science ouverte sont des questions d'intérêt pour les communautés universitaires et celles plus larges en Europe et en Amérique du Nord.

Un article paru en 2020 dans [https://www.affairesuniversitaires.ca/articles-de-fond/article/le-neuro-de-montreal-porteur-de-changement-dans-les-sciences-universitaires/?_ga=2.127238605.1924387654.1689180763-1262500445.1689180763 ''University Affairs/Affaires universitaires''], par exemple, souligne la nécessité d'avoir des DPI moins restrictifs en biomédecine à travers l'exemple des chercheurs et chercheuses qui ont accéléré le développement d’un vaccin potentiel contre le SRAS en 2003, ce qui n'a été possible qu'en contournant les DPI (Voinigescu). Un document d'information récent d'Itzel Saldivar pour [https://www.timeshighereducation.com/campus/what-you-dont-know-about-ip-protections-should ''Times Higher Education''] décrit diverses formes de propriété intellectuelle – des brevets, droits d'auteur et marques de commerce – et soutient que les chercheurs et chercheuses devraient comprendre comment les DPI les affectent et affectent leur travail.

Un article de Claire Woodcock dans ''Vice'' explique comment la [https://www.vice.com/en/article/epzyde/librarians-are-finding-thousands-of-books-no-longer-protected-by-copyright-law New York Public Library a découvert ]des milliers d'œuvres créatives publiées avant 1964 qui sont maintenant dans le domaine public parce que leur droit d'auteur n'a pas été renouvelé, une découverte faite à l'aide de XML source ouverte. Dans le cadre de discussions animées sur les promesses et les pièges de l’intelligence artificielle générative, un article du [https://www.wsj.com/articles/ai-chatgpt-dall-e-microsoft-rutkowski-github-artificial-intelligence-11675466857 ''Wall Street Journal''] traite des recours collectifs lancés par les créateurs et créatrices des médias qui affirment que les données utilisées pour former Dall-E 2, Stable Diffusion et des systèmes d’intelligence artificielle génératifs similaires sont de la propriété intellectuelle volée.

==Les réponses du Partenariat INKE==
Plusieurs partenaires de l'INKE s'intéressent à des questions liées aux droits de propriété intellectuelle et à la science ouverte.

Au nom de ses membres, [https://www.carl-abrc.ca/fr/ l'Association des bibliothèques de recherche du Canada (ABRC)] entreprend des initiatives liées à la politique sur le droit d'auteur. Par exemple, elle a contribué à [https://www.carl-abrc.ca/fr/influencer-les-politiques/droit-dauteur/examen-2018/ l'examen législatif de 2018 de la Loi sur le droit d'auteur] et a soumis une [https://www.carl-abrc.ca/wp-content/uploads/2021/04/FCAB-ABRC_Reponse_conjointe_consultation_prolongation_droit_dauteur.pdf réponse conjointe avec la Fédération canadienne des associations de bibliothèques (FCAB) à l'accord Canada-United States-Mexico (CUSMA)] en 2021. En 2020, [https://www.carl-abrc.ca/wp-content/uploads/2020/10/200921-le-droit-dauteur-de-la-Couronne.pdf l'ABRC et le FCAB ont soumis une lettre conjointe ][https://www.carl-abrc.ca/wp-content/uploads/2020/10/200921-le-droit-dauteur-de-la-Couronne.pdf aux ministres fédéraux ][https://www.carl-abrc.ca/wp-content/uploads/2020/10/200921-le-droit-dauteur-de-la-Couronne.pdf au sujet du droit d'auteur de la Couronne], demandant des licences ouvertes pour l'information gouvernementale afin d'améliorer l'accès du public à l'information sur la COVID-19. Il a également publié une [https://www.carl-abrc.ca/wp-content/uploads/docs/CARL_Statement_on_Fair_Dealing_2016_FR-1.pdf déclaration sur l'utilisation équitable et le droit d'auteur] en 2016 et est intervenu dans l'[https://www.carl-abrc.ca/influencing-policy/copyright/ affaire York University v. Access Copyright].

À l'automne 2022, John Willinsky du [https://pkp.sfu.ca/ Public Knowledge Project (PKP)] a fait une [https://pkp.sfu.ca/2022/10/18/the-pkp-amend-copyright-tour/ tournée Amend Copyright] en Europe et en Amérique du Nord pour plaider en faveur de l'inclusion du droit d'auteur dans les intentions du mouvement de libre accès. Sa position sur les licences légales pour les publications de recherche, dans lesquelles les DPI sont placés au service du libre accès, est décrite dans son livre en libre accès [https://doi.org/10.7551/mitpress/14201.001.0001 ''Copyright's Broken Promise: How to Restore the Law's Ability to Promote the Progress of Science ''](Willinsky).

[https://www.crkn-rcdr.ca/fr/projet-sur-les-declarations-de-droits Le Projet sur les déclarations de droits] du [https://www.crkn-rcdr.ca/fr Réseau canadien de documentation pour la recherche (RCDR)] cherche une solution au problème des renseignements manquants et incomplets sur les droits dans [https://www.crkn-rcdr.ca/fr/collections-de-canadiana les collections Canadiana du RCDR]. Le projet est en train d'élaborer un cadre pour déterminer comment les matériaux du patrimoine numérique dans l'ensemble de la collection afin de protéger les droits des créateurs tout en rendant les collections aussi ouvertes et réutilisables que possible.

==Les réactions de l’ensemble de la communauté universitaire élargie==
Dans un article de blog pour [https://www.the-guild.eu/blog/connecting-the-dots-iprs-knowledge-transfer-innova.html ''The Guild''], Alessandra Baccigotti, l'une des experts et expertes invités à la réunion d'experts de l'UNESCO, discute de la réunion au côté de la première [https://eua.eu/partners-news/969-eu-knowledge-valorisation-week-2023.html Semaine européenne de valorisation des connaissances], organisée par la Commission européenne, qui s'est déroulée du 27 au 30 avril 2021. Elle note qu'il y a souvent un scepticisme au sein de la communauté de la science ouverte sur les DPI et la valorisation des connaissances ou la recherche et l'innovation, et tout comme l'UNESCO et d'autres organisations travaillent à l'établissement de connaissances et d'un consensus sur la science ouverte, la même chose doit être faite pour les DPI.

==DPI et la science ouverte==
Il a été largement reconnu au début de la pandémie de COVID-19 que l'ouverture et la collaboration étaient essentielles pour lutter contre la maladie, comme discuté [https://www.oecd.org/coronavirus/policy-responses/why-open-science-is-critical-to-combatting-covid-19-cd6ab2f9/ par l’OECD]. E. Richard Gold note dans un article paru dans [https://www.nature.com/articles/s41587-022-01485-x ''Nature''] que la réponse du milieu de la recherche à la pandémie a remis en question certaines hypothèses sur les DPI, y compris le fait que de solides réglementations en matière de DPI stimulent l'innovation. Au fur et à mesure que la pandémie a mis en évidence des questions plus larges telles que le droit à la santé et le droit à la connaissance, la nécessité d'examiner les DPI et la science ouverte d'une manière holistique est devenue plus claire.

Bien que ces problèmes aient été mis en avant par la pandémie, la réflexion sur les DPI et l'ouverture a changé parallèlement à la transition vers le libre accès. Willinsky note que dans le passé, les éditeurs avaient tendance à considérer le libre accès comme une menace pour leurs DPI, mais à mesure que le libre accès s'enracine, les éditeurs réfléchissent à la façon dont leurs DPI peuvent soutenir le libre accès à l'avenir.

En effet, cet aperçu des récents rapports de politique sur les DPI et la science ouverte en Europe montre que, dans ce contexte politique, les droits de propriété intellectuelle sont de plus en plus compris comme étant au service de la science ouverte plutôt qu'en opposition à celle-ci.

==Ouvrages cités==
*ALLEA (European Federation of Academies of Sciences and Humanities). 2022. «&amp;#8239;Aligning Intellectual Property Rights with Open Science: An ALLEA Statement&amp;#8239;». [https://allea.org/wp-content/uploads/2022/04/ALLEA-Statement-Aligning-IPR-with-Open-Science.pdf https://allea.org/wp-content/uploads/2022/04/ALLEA-Statement-Aligning-IPR-with-Open-Science.pdf].

*Angelopoulos, Christina. 2022. ''Study on EU Copyright and Related Rights and Access to and Reuse of Scientific Publications, Including Open Access: Exceptions and Limitations, Rights Retention Strategies and the Secondary Publication Right''. Office des publications de l’Union européenne. [https://data.europa.eu/doi/10.2777/891665 https://data.europa.eu/doi/10.2777/891665].

*Commission européenne, Direction générale pour Research and Innovation. 2022. ''Open Science and Intellectual Property Rights: How Can They Better Interact? State of the Art and Reflections: Executive Summary''. Office des publications de l’Union européenne. [https://data.europa.eu/doi/10.2777/347305 https://data.europa.eu/doi/10.2777/347305].

*EARTO (European Association of Research and Technology Organizations). 2020. «&amp;#8239;Towards a Balanced Approach between IPRs and Open Science Policy&amp;#8239;». [https://www.earto.eu/wp-content/uploads/EARTO-Paper-Towards-a-Balanced-Approach-Between-IPRs-and-Open-Science-Policy-Final.pdf https://www.earto.eu/wp-content/uploads/EARTO-Paper-Towards-a-Balanced-Approach-Between-IPRs-and-Open-Science-Policy-Final.pdf].

*UNESCO. 2021. «&amp;#8239;Towards a UNESCO Recommendation on Open Science: Online Expert Meeting on Open Science and Intellectual Property Rights&amp;#8239;». [https://en.unesco.org/sites/default/files/report_expert_meeting_ipr_os_23apr.pdf https://en.unesco.org/sites/default/files/report_expert_meeting_ipr_os_23apr.pdf].

*UNESCO. 2022. «&amp;#8239;Expert Meeting on Open Science and Intellectual Property Rights&amp;#8239;». [https://www.unesco.org/en/articles/expert-meeting-open-science-and-intellectual-property-rights https://www.unesco.org/en/articles/expert-meeting-open-science-and-intellectual-property-rights].

*Voinigescu, Eva. 2020. «&amp;#8239;Le Neuro de Montréal : porteur de changement dans les sciences universitaires ?&amp;#8239;» ''University Affairs/Affaires universitaires'', le 24 juin 2020. [https://www.affairesuniversitaires.ca/articles-de-fond/article/le-neuro-de-montreal-porteur-de-changement-dans-les-sciences-universitaires https://www.affairesuniversitaires.ca/articles-de-fond/article/le-neuro-de-montreal-porteur-de-changement-dans-les-sciences-universitaires].

*Willinsky, John. 2022. ''Copyright’s Broken Promise: How to Restore the Law’s Ability to Promote the Progress of Science''. MIT Press. [https://direct.mit.edu/books/book/5507/Copyright-s-Broken-PromiseHow-to-Restore-the-Law-s https://direct.mit.edu/books/book/5507/Copyright-s-Broken-PromiseHow-to-Restore-the-Law-s].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>eguyxs3fq46pkk806g7zgco1rt5reu2</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le 20e anniversaire de l’Initiative de Budapest pour l’accès ouvert</title>
    <ns>0</ns>
    <id>82371</id>
    <revision>
      <id>745432</id>
      <parentid>745154</parentid>
      <timestamp>2025-06-26T23:23:32Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745432</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="15858" sha1="oeocu4d0k8csbch5d0vzaqevuojqfvt" xml:space="preserve">''Cette observation a été écrite par Caroline Winter et JT Kern (avec leurs remerciements à Shawn Martin pour ses commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

Le 15 mars 2022, [https://www.budapestopenaccessinitiative.org/read/french-translation/ l’Initiative de Budapest pour l’accès ouvert (BOAI)] a célébré son 20e anniversaire en publiant [https://www.budapestopenaccessinitiative.org/boai20/boai20-french-translation/ quatre nouvelles recommandations de haut niveau ]- ainsi que des sous-recommandations détaillées et d'autres développements - mettant l'accent sur le libre accès dirigé par les communautés et l'équité mondiale, et en relevant les principaux défis de la prochaine décennie (BOAI 2022). Le BOAI a commencé à Berlin en 2001 avec une réunion de l'Open Society Institute (OSI). Dans un épisode de la baladodiffusion [http://knowledgeequitylab.ca/podcast/s2ep3/ ''Unsettling Knowledge Inequities''], le comité de pilotage penche sur les origines du terme «&amp;#8239;libre accès&amp;#8239;». Peter Suber considère que le groupe a été, peut-être sans le savoir, inspiré par le terme «&amp;#8239;logiciel libre&amp;#8239;», un terme qui avait été inventé quelques années auparavant pour décrire les logiciels qui pouvaient être copiés, partagés et modifiés sans restriction. Voici ce que dit la déclaration originale :

&lt;blockquote&gt;
Par «&amp;#8239;accès libre&amp;#8239;» à cette littérature [scientifique], nous entendons sa mise à disposition gratuite sur l'Internet public, permettant à tout un chacun de lire, télécharger, copier, transmettre, imprimer, chercher ou faire un lien vers le texte intégral de ces articles, les disséquer pour les indexer, s’en servir de données pour un logiciel, ou s’en servir à toute autre fin légale, sans barrière financière, légale ou technique autre que celles indissociables de l'accès et de l’utilisation d’Internet. La seule contrainte sur la reproduction et la distribution, et le seul rôle du copyright dans ce domaine devrait être celuicelui de garantir aux auteurs le contrôle sur l'intégrité de leurs travaux et le droit à être correctement reconnus et cités. (BOAI 2002)
&lt;/blockquote&gt;

La déclaration de 2002 a lancé deux appels à l'action : pour que les organisations lancent de nouvelles revues en libre accès sans frais d'abonnement et pour que les chercheurs et chercheuses auto-archivent leurs travaux dans les archives et les dépôts ouverts. Tout en reconnaissant que les publications en libre accès n'étaient pas produites de manière gratuite, la déclaration suggérait d'autres méthodes de financement, telles que les fonds institutionnels, les dotations, le financement gouvernemental et les contributions individuelles des chercheurs et chercheuses. En 2012, [https://www.budapestopenaccessinitiative.org/boai10/french-translation/ le BOAI a célébré son 10e anniversaire] en réaffirmant et en élaborant sur son engagement envers le libre accès. Les recommandations étaient centrées sur la coordination et le plaidoyer, des licences pour l'accès et la réutilisation, l'élaboration de la documentation et de la politique de libre accès, et l'infrastructure durable. Ces recommandations visaient principalement les éditeurs, les établissements universitaires et le financement gouvernemental, et fournissaient plus de nuance et de spécificité que la déclaration originale. L'accent mis sur les infrastructures durables est réaffirmé dans l'appel des recommandations du 20e anniversaire en faveur de plateformes d'infrastructure ouvertes. Les recommandations de 2022 ont été [https://eifl.net/news/boai-20th-anniversary-questions-oa-community informées par des consultations communautaires] et s'adressent à la fois aux organisations et aux individus. Les recommandations définissent libre accès comme suit :
* rendre la recherche disponible par l'entremise d'infrastructures ouvertes dirigées par la communauté universitaire et des organisations à but non lucratif;
* réformer l'évaluation de la recherche et améliorer les incitations;
* garantir que les auteurs et auteures ne seront pas exclus pour des raisons économiques, comme la publication financée au moyen de frais de publication d'articles.

L'accent mis sur l'open source, les plateformes contrôlées par la communauté et l'infrastructure dirigée par la communauté conforme à la déclaration de 2002 qui, bien qu'elle n'ait pas lancé d'appel explicite pour éviter les plateformes commerciales, a appelé les chercheurs et chercheuses à placer leur travail dans des archives conformes aux normes de contenu Web interopérable de [https://www.openarchives.org/ l’Open Archives Initiative].

==Des réponses de la communauté de Partenariat INKE==
Juan Pablo Alperin du [https://pkp.sfu.ca/ Public Knowledge Project] (PKP, un partenaire d'[https://inke.ca/ INKE]) a dirigé [https://www.youtube.com/watch?v=8TNpTMS1XPs une discussion par webdiffusion] avec les membres du comité de pilotage, dont Heather Joseph, Peter Suber et Dominique Babini, sur les recommandations du 20e anniversaire de la BOAI. En août 2022, [https://onlineacademiccommunity.uvic.ca/scholarlycommunications/tag/boai/ les Bibliothèques de l’Université de Victoria] (un partenaire d’INKE) ont célébré le 20e anniversaire de la BOAI, décrivant l’initiative comme une inspiration continue pour l’Université de Victoria et pour le mouvement libre accès en général (Schmidt 2022). Le libre accès est l'un [https://www.carl-abrc.ca/fr/a-propos-de-labrc/gouvernance/principes/ des principes fondamentaux qui guident le travail de l'Association des bibliothèques de recherche du Canada] (ABRC; un partenaire d’INKE), qui est signataire de la BOAI et de [https://openaccess.mpg.de/68042/BerlinDeclaration_wsis_fr.pdf la Déclaration de Berlin sur le libre accès à la connaissance en sciences exactes, sciences de la vie, sciences humaines et sociales].

==Les réactions de l’ensemble de la communauté universitaire élargie==
[https://www.eui.eu/news-hub?id=eui-endorsement-of-the-20th-anniversary-of-the-budapest-open-access-initiative L’EUI a célébré l'anniversaire du BOAI] en approuvant les nouvelles recommandations, soulignant l'accent mis sur les frais de publication, les accords de lecture et de publication, l'évaluation de la recherche et l'infrastructure ouverte. Le blog [https://acrl.ala.org/acrlinsider/budapest-open-access-initiative-20th-anniversary/ ACRL Insider] a marqué l'anniversaire en partageant une liste de ressources de l'ACRL, y compris leurs livres sur le libre accès, des ateliers et un référentiel de communication savante. En explorant les implications des nouvelles recommandations, l'article de A. J. Boston intitulé «[https://scholarlykitchen.sspnet.org/2022/04/26/guest-post-open-access-and-the-direction-moving-forward/  Open Access and the Direction Moving Forward]&amp;#8239;», publié par ''The Scholarly Kitchen'', décrit ce qu'ils considèrent comme une tendance troublante dans le mouvement du libre accès : les accords de transformation. Ces accords visent à passer du modèle basé sur l'abonnement aux accords de lecture et de publication, qui regroupent le coût de la publication avec le coût des abonnements (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les accords de libre accès|Les accords de libre accès]]&amp;#8239;»). Bien que cela réponde à la pression menée par des organismes de financement pour que les auteurs et auteures publier leur recherche en libre accès, cela exclut ceux et celles dont les institutions n'ont pas le financement pour conclure des accords de lecture et de publication. Boston voit les recommandations du 20e anniversaire comme une correction de cap: un rappel que le libre accès vise à faire progresser l’équité, la qualité, et la durabilité de la recherche (Boston 2022).

==Le 20e anniversaire de l’Initiative de Budapest et la science ouverte==
La déclaration de 2002 était l'une des trois [https://ospolicyobservatory.uvic.ca/bbb/ déclarations  à définir le ] libre accès, avec [https://legacy.earlham.edu/~peters/fos/bethesda.htm le Bethesda Statement on Open Access Publishing] et la [https://openaccess.mpg.de/Berlin-Declaration Déclaration de Berlin], toutes deux publiées en 2003 (voir [https://ospolicyobservatory.uvic.ca/bbb/ «&amp;#8239;Trois déclarations déterminantes sur l’accès libre: Budapest, Bethesda et Berlin]&amp;#8239;»). Les nouvelles recommandations mettent l'accent sur l’action de contrer les inégalités en matière du libre accès, y compris l'exclusion des auteurs dont les institutions ne peuvent pas se permettre les frais de publication et l'effacement du travail; cela souligne l'importance des préoccupations de justice sociale pour le mouvement pour libre accès et d'autres mouvements ouverts plus largement (voir Roh et al, 2020). Cet accent mis sur l’action de contrer les inégalités fait également partie d'un mouvement plus large vers le libre accès diamant, un mode de publication qui ne nécessite pas de frais de la part des auteurs ou auteures ou des lecteurs ou lectrices (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Un plan d’action pour faire avancer le libre accès diamant|Un plan d'action pour faire avancer le libre accès diamant]]&amp;#8239;»). [https://educopia.org/scaling-diamond-oa/ Kristin Ratan] place l'appel des recommandations de 2022 pour des infrastructures ouvertes dans le contexte d'une conversation plus large qui comprend [https://unesdoc.unesco.org/ark:/48223/pf0000379949_fre la Recommandation de l'UNESCO sur une science ouverte] et l'approbation du libre accès diamant par [https://library.harvard.edu/about/news/2022-03-14/harvard-library-endorses-new-action-plan-diamond-open-access Harvard Library] (2022; voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|La Recommandation de l'UNESCO sur la science ouverte]]&amp;#8239;»). Ratan discute également des développements politiques aux États-Unis - en particulier, le [https://www.whitehouse.gov/ostp/news-updates/2022/08/25/breakthroughs-for-alldelivering-equitable-access-to-americas-research/ mémo Nelson ]- notant que cela conduira probablement à un pic large de publications ouvertes (2022; «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le mémo Nelson : Une politique d’accès public mis à jour aux États-Unis|Le mémo Nelson : Une politique d'accès public mis à jour aux États-Unis]]&amp;#8239;»). Lisa Janicke Hinchliffe soutient que, puisque le mémo Nelson appelle à la publication dans les dépôts ouverts par défaut et permet aux chercheurs et chercheuses d'intégrer les frais de publication dans leurs budgets de subventions, le résultat sera probablement l’enracinement accrue de ces frais aux États-Unis par le biais d'une variété d'accords de libre accès (2023). Une force directrice dans ce changement vers le libre accès diamant est le [https://doi.org/10.5281/zenodo.4558704 OA Diamond Journals Study], qui a été soutenu par un certain nombre d'organisations et d'initiatives européennes, y compris [https://sparceurope.org/ SPARC Europe], le [https://doaj.org/ Directory of OA Journals (DOAJ)] et l’[https://enresshcost.eu/ European Network for Research Evaluation in the Social Sciences and the Humanities] (Bosman et al. 2021). La déclaration de BOAI de 2002 envisageait «&amp;#8239;un futur dans lequel recherche et éducation soient beaucoup plus libres de s’épanouir dans toutes les parties du monde&amp;#8239;». Bien qu’elles soient sensibles au besoin potentiel de changement et d'expérimentation, les recommandations de 2022 restent engagées à cet objectif, et elles soulignent les objectifs plus larges du Mouvement pour le libre accès. En réfléchissant au mouvement au cours des deux dernières décennies, le comité directeur note que :

&lt;blockquote&gt;
Il apparaît de plus en plus clairement que l’accès ouvert n’est pas une fin en soi, mais un moyen d’atteindre d’autres objectifs, parmi lesquels figurent avant tout l’équité, l’utilisabilité, et la durabilité de la recherche. Il nous faut désormais évaluer le développement de l’accès ouvert au regard de ces objectifs et de ce qui peut les faire progresser ou les desservir. Il nous faut adopter des stratégies de développement de l’accès ouvert cohérentes avec ces objectifs et à même de contribuer à leur mise en œuvre. (BOAI 2022)
&lt;/blockquote&gt;

En soulignant la nécessité d'infrastructures ouvertes, de changements politiques et culturels, et d'une attention encore plus grande aux questions d'équité, les recommandations du 20e anniversaire 2022 du BOAI réaffirment le rôle vital du libre accès dans l'écosystème de la science ouverte.

==Ouvrages cités==
*BOAI. 2002. «&amp;#8239;L’Initiative de Budapest pour l’accès ouvert&amp;#8239;». Le 14 février 2002. [https://www.budapestopenaccessinitiative.org/read/french-translation/ https://www.budapestopenaccessinitiative.org/read/french-translation/]. 

*BOAI. 2022. “L’Initiative de Budapest pour l’accès ouvert&amp;#8239;». Le 15 mars 2022. [https://www.budapestopenaccessinitiative.org/boai20/boai20-french-translation/ https://www.budapestopenaccessinitiative.org/boai20/boai20-french-translation/]. 

*Bosman, Jeroen, Jan Erik Frantsvåg, Bianca Kramer, Pierre-Carl Langlais, et Vanessa Proudman. 2021. «&amp;#8239;OA Diamond Journals Study. Part 1: Findings&amp;#8239;». [https://doi.org/10.5281/zenodo.4558704 https://doi.org/10.5281/zenodo.4558704]. 

*Boston, A. J. 2022. «&amp;#8239;Guest Post: Open Access and the Direction Moving Forward&amp;#8239;». ''The Scholarly Kitchen''. Le 26 avril 2022. [https://scholarlykitchen.sspnet.org/2022/04/26/guest-post-open-access-and-the-direction-moving-forward/ https://scholarlykitchen.sspnet.org/2022/04/26/guest-post-open-access-and-the-direction-moving-forward/]. 

*Hinchliffe, Lisa Janicke. 2023. «&amp;#8239;The Double-Cost of Green-via-Gold&amp;#8239;». ''The Scholarly Kitchen''. Le 25 avril 2023. [https://scholarlykitchen.sspnet.org/2023/04/25/green-via-gold/ https://scholarlykitchen.sspnet.org/2023/04/25/green-via-gold/]. 

*Ratan, Kristen. 2022. «&amp;#8239;Scaling Diamond OA: Universities as Centers of Open Publishing Excellence.&amp;#8239;» ''Educopia Institute Community Cultivators'' (blog). Le 9 septembre 2022. [https://educopia.org/scaling-diamond-oa/ https://educopia.org/scaling-diamond-oa/]. 

*Roh, Charlotte, Harrison W. Inefuku, et Emily Drabinsky. 2020. «&amp;#8239;Scholarly Communications and Social Justice&amp;#8239;». De ''Reassembling Scholarly Communications: Histories, Infrastructures, and Global Politics of Open Access'', édité by Martin Paul Eve et Jonathan Gray. MIT Press. [https://doi.org/10.7551/mitpress/11885.001.0001 https://doi.org/10.7551/mitpress/11885.001.0001]. 

*Schmidt, Christian. 2022. «&amp;#8239;20 Years of Budapest OA Initiative (BOAI) Inspire OA at UVic&amp;#8239;». ''Scholarly Communication @ UVic'' (blog). Le 2 août 2022. [https://onlineacademiccommunity.uvic.ca/scholarlycommunications/tag/boai/ https://onlineacademiccommunity.uvic.ca/scholarlycommunications/tag/boai/]. 

*Unsettling Knowledge Inequities. 2021. «&amp;#8239;Budapest Open Access Initiative: Twenty Years On&amp;#8239;». le 12 octobre 2021. ''Knowledge Equity Lab'', le saison 2, épisode 3. [http://knowledgeequitylab.ca/podcast/s2ep3/ http://knowledgeequitylab.ca/podcast/s2ep3/].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>oeocu4d0k8csbch5d0vzaqevuojqfvt</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La sécurité de la recherche et la science ouverte au Canada</title>
    <ns>0</ns>
    <id>82372</id>
    <revision>
      <id>745435</id>
      <parentid>745155</parentid>
      <timestamp>2025-06-26T23:28:55Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745435</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="34396" sha1="0c59uojuvk5477y110vrziz1j4o82wx" xml:space="preserve">''Cette observation a été écrite par Caroline Winter (avec des remerciements à Aaron Mauro et John Simpson pour leurs commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

La sécurité de la recherche, c'est-à-dire la capacité d’identifier les risques pour les processus et les produits de la recherche et de prendre des mesures pour les atténuer, est une préoccupation de longue date pour la communauté de la recherche et ses parties prenantes, y compris les individus et individues jusqu’aux gouvernements nationaux. Bien que l'ouverture et la collaboration soient essentielles pour faire avancer la recherche, une plus grande ouverture peut également entraîner de plus grands risques. Sécuriser les données et les connaissances numériques et d'autres extrants intangibles est particulièrement difficile. Cela a été mis en évidence pendant la pandémie de COVID-19, lorsque le pivot vers des environnements de travail virtuels et des niveaux sans précédent de collaboration mondiale et de partage de la recherche se sont accompagnés de menaces de sécurité accrues (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Science Ouverte et COVID-19|Science ouverte et COVID-19]]&amp;#8239;»).

La sécurité de la recherche est une vaste question qui se rapporte à toutes les facettes de la recherche. Pour les chercheurs et chercheuses et les institutions individuelles, le vol de données et d'autres problèmes de sécurité peuvent entraver la recherche, menacer la propriété intellectuelle et affecter l'admissibilité au financement (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les droits de propriété intellectuelle et la science ouverte en Europe|Les droits de propriété intellectuelle et la science ouverte en Europe]]&amp;#8239;»). La sécurité de la recherche est également une question de sécurité nationale puisque les données et les connaissances détournées peuvent être utilisées à des fins de renseignement national ou militaire néfastes. La sécurité est particulièrement préoccupante pour la recherche économiquement précieuse et à double usage – celle qui a des applications civiles et militaires potentielles – comme dans les domaines des infrastructures essentielles et de la recherche sur des sujets humains ainsi que de l'informatique quantique et de l'intelligence artificielle, qui sont tous deux des outils potentiels pour les cyberattaques ainsi que les domaines cibles actuels (Gouvernement du Canada 2023; OCDE 2022 ; Owens 2023a ; Science Canada 2021).

Le vol de données de recherche et/ou personnelles est une menace courante, car les données stockées sur les disques durs et les clés USB peuvent être volées ou égarées et les cyberattaques peuvent causer des violations de données et endommager les systèmes informatiques. Les attaques d'hameçonnage ont tendance à cibler des chercheurs et chercheuses individuels pour qui la sécurité n'est peut-être pas une priorité (OCDE 2022).

La sécurité de la recherche est également menacée par les «&amp;#8239;acteurs malfaisants&amp;#8239;», qui peuvent être des collaborateurs, des chercheurs invités, des étudiants ou d'autres personnes qui visent à détourner ou à altérer la recherche pour leur propre profit (p. ex., dans le cas de concurrents commerciaux) ou pour le bénéfice d'autres personnes (p. ex. des états hostiles, des groupes du crime organisé, des organisations terroristes). Ces acteurs malfaisants peuvent agir par choix ou être forcés ou contraints (Science Canada 2021).

Étant donné que la sécurité de la recherche est une question de plus en plus urgente, l'élaboration de politiques dans ce domaine est très active. Le document politique de l'Organisation de coopération et de développement économiques (OCDE) [https://doi.org/10.1787/39ee9438-fr ''Intégrité et sécurité dans l'écosystème mondial de la recherche''], publié en juin 2022, traite d'un certain nombre de politiques et d'initiatives de sécurité de la recherche de l'Australie, du Japon, des Pays-Bas, du Royaume-Uni et des États-Unis, élaborées par des gouvernements nationaux, des organismes de financement, des établissements de recherche publics, des associations universitaires, des universités, des projets de recherche internationaux, et des organisations politiques internationales (p. ex., le G7, la Commission européenne, le Global Research Council). Bon nombre de ces politiques traitent de l'établissement d'évaluations des risques dans les processus existants (p. ex. l'évaluation des demandes de financement), de la détermination et de la gestion des menaces et des conflits d'intérêts, ainsi que des lignes directrices sur la diligence raisonnable.

Le document politique de l'OCDE reconnaît que le sujet de la sécurité de la recherche peut être difficile à discuter, controversé et polarisant, mais souligne qu'il est essentiel de le considérer néanmoins. Il offre sept recommandations de haut niveau pour la communauté de la recherche :

# Souligner l'importance de la liberté de la recherche scientifique et de la collaboration internationale en tant qu'élément clé de l'écosystème mondial de la recherche
# Intégrer les considérations relatives à la sécurité de la recherche dans les cadres nationaux et institutionnels pour l'intégrité de la recherche
# Promouvoir une approche proportionnée et systématique de la gestion des risques dans la recherche
# Promouvoir l'ouverture et la transparence en matière de conflits d'intérêts ou d'engagement
# Mettre au point des directives claires, rationaliser les procédures et limiter la bureaucratie inutile
# Mobiliser l'ensemble des secteurs et des institutions pour élaborer des politiques plus intégrées et efficaces
# Améliorer le partage d’informations sur l'intégrité et la sécurité de la recherche à l’échelle internationale (10)

Le Canada a également élaboré des politiques sur la sécurité de la recherche. En décembre 2019, le U15 Regroupement des universités de recherche du Canada et Universités Canada ont publié [https://www.univcan.ca/wp-content/uploads/2020/08/attenuer-les-risques-economiques-et-geopolitiques-associes-aux-projets-de-recherche-sensibles-dec-2019.pdf ''Atténuer les risques économiques et géopolitiques associés aux projets de recherche sensibles : Guide à l'intention des chercheurs universitaires'']. Le guide traite de divers types de risques en plus de l'appropriation illicite de données. Par exemple, il souligne que, comme tous les chercheurs ne jouissent pas du même degré de liberté académique, la publication de certains résultats pourrait mettre en danger les partenaires internationaux et que les risques pour les droits humains doivent être évalués dans le cadre des plans de voyage des chercheurs (10).

Le gouvernement du Canada a également publié un groupe d'énoncés de politique connexes sur la sécurité de la recherche :

[https://www.canada.ca/fr/service-renseignement-securite/nouvelles/2020/05/declaration-du-cse-et-scrs-le-14-mai-2020.html '''Déclaration du CSE et SCRS, le 14 mai 2020 ''']: Cette déclaration du Centre de la sécurité des télécommunications (CST) et du Service canadien du renseignement de sécurité (SCRS) répond aux préoccupations accrues au sujet de la recherche et de la sécurité nationale liées à l'incertitude générée par la COVID-19. Il met en garde contre les menaces à la propriété intellectuelle ainsi qu'aux renseignements personnels, citant une [https://www.cyber.gc.ca/fr/alertes-avis/cybermenaces-pesant-sur-les-organismes-de-sante-canadiens alerte du Centre canadien pour la cybersécurité] et une [https://www.canada.ca/fr/affaires-mondiales/nouvelles/2020/04/declaration-sur-les-cybermenaces-visant-le-secteur-de-la-sante.html déclaration d'Affaires mondiales Canada] sur l'augmentation des cybermenaces pour le secteur de la santé.

[https://www.canada.ca/fr/innovation-sciences-developpement-economique/nouvelles/2020/09/enonce-de-politique-sur-la-securite-de-la-recherche-et-la-covid-19.html '''Énoncé de politique sur la sécurité de la recherche et la COVID-19, le 14 septembre 2020 ''']: Cet énoncé d'Innovation, Sciences et Développement économique Canada (ISDE) réaffirme l'engagement du gouvernement du Canada à l'égard de la science ouverte et rappelle à la communauté de la recherche de demeurer vigilant et d'examiner ses politiques et pratiques en matière de cybersécurité face aux menaces à la sécurité continues.

[https://www.canada.ca/fr/innovation-sciences-developpement-economique/nouvelles/2021/03/enonce-de-politique-sur-la-securite-de-la-recherche--printemps2021.html '''Énoncé de politique sur la sécurité de la recherche – Printemps 2021, le 24 mars 2021 ''']: Cet énoncé d'ISDE fait état d'une augmentation des niveaux de menace pour la recherche et la sécurité nationale et rappelle à la communauté de la recherche l'énoncé de politique de septembre 2020. Il note également qu'il a demandé au Groupe de travail mixte du gouvernement du Canada et des universités d'élaborer des lignes directrices sur les risques pour guider les chercheurs dans l'examen des questions de sécurité nationale liées à leurs recherches. Ces [https://science.gc.ca/site/science/fr/protegez-votre-recherche/lignes-directrices-outils-pour-mise-oeuvre-securite-recherche/lignes-directrices-securite-nationale-pour-partenariats-recherche Lignes directrices sur la sécurité nationale pour les partenariats de recherche] ont été publiées en juillet 2021. 

[https://www.canada.ca/fr/innovation-sciences-developpement-economique/nouvelles/2023/02/declaration-des-ministres-champagne-duclos-et-mendicino-sur-la-protection-de-la-recherche-canadienne.html '''Déclaration des ministres Champagne, Duclos et Mendicino sur la protection de la recherche canadienne, le 14 février 2023 ''']: Cette déclaration d'ISDE des Ministères de l'Innovation, des Sciences et de l'Industrie ; Santé ; et la Sécurité publique note encore une fois un niveau accru de menaces et annonce un changement dans la politique de financement pour les trois organismes : «&amp;#8239;Une demande de subvention de recherche dans un domaine sensible sera refusée si l'un des chercheurs travaillant sur le projet est affilié à une université, un institut de recherche ou un laboratoire rattaché à une organisation militaire ou à un organisme de défense nationale ou de sécurité d’un acteur étatique étranger qui représente un risque pour notre sécurité nationale&amp;#8239;» (ISDE 2023).

De plus, le [https://www.budget.canada.ca/2022/report-rapport/chap2-fr.html budget fédéral de 2022 du Canada ]a instauré un financement de 125 millions de dollars pour le [https://www.rsf-fsr.gc.ca/apply-demande/research_security-securite-recherche-fra.aspx Fonds de soutien à la recherche ]pour aider les établissements postsecondaires à renforcer leur capacité en matière de sécurité de la recherche, ainsi que 34,6 millions de dollars sur cinq ans et un financement permanent de 8,4 millions de dollars pour établir un centre de la sécurité de la recherche pour conseiller les établissements de recherche.

Bien que la sécurité de la recherche soit une question complexe, les chercheurs peuvent prendre des mesures pour se protéger et protéger leur travail. Le portail [https://science.gc.ca/site/science/fr/protegez-votre-recherche Protégez votre recherche] du gouvernement du Canada comprend de l'information sur la sécurité de la recherche ainsi que des outils et des lignes directrices à l'intention des chercheurs et des établissements. Les outils [https://science.gc.ca/site/science/fr/protegez-votre-recherche/lignes-directrices-outils-pour-mise-oeuvre-securite-recherche/evaluez-votre-profil-risque Évaluez votre profil de risque] et [https://science.gc.ca/site/science/fr/protegez-votre-recherche/lignes-directrices-outils-pour-mise-oeuvre-securite-recherche/attenuez-risques-lies-securite-recherche Atténuez les risques liés à la sécurité de la recherche] fournissent des conseils pratiques précis pour aider les chercheurs à évaluer et à gérer les risques propres à leurs projets. Les ressources partagées par l'entremise de ce portail sont celles du [https://science.gc.ca/site/science/fr/protegez-votre-recherche/renseignements-generaux-securite-recherche/propos-gouvernement-canada-groupe-travail-universites Groupe de travail sur les universités], qui travaille à la science ouverte, collaborative et sécurisée au Canada.

==La sécurité de la recherche dans la presse==
L'une des questions abordées dans la presse universitaire et populaire était un programme pilote élaboré en réponse à l'énoncé de politique de mars 2021 dans lequel les demandes de financement pour les [https://www.nserc-crsng.gc.ca/innovate-innover/alliance-alliance/index_fra.asp Subventions Alliance du CRSNG] ont été examinées par le SCRS et le CST. Des articles dans [https://www.affairesuniversitaires.ca/actualites/actualites-article/le-manque-de-clarte-lors-des-evaluations-de-risque-pour-la-securite-nationale-est-denonce/ ''Affaires universitaires''], [https://www.cbc.ca/news/politics/ottawa-reserach-champagne-security-1.6099163 ''CBC News''], le ''Globe and Mail ''([https://www.theglobeandmail.com/politics/article-ottawa-imposes-national-security-risk-assessments-for-university/ annonçant le projet pilote en 2021] et ses [https://www.theglobeandmail.com/canada/article-nserc-research-grants-sensitive/ résultats en 2023]) et [https://sciencebusiness.net/news/Cybersecurity/canadian-security-services-block-more-30-grant-proposals ''ScienceBusiness''] rapportent que, sur les quelque 1000 demandes de financement reçues par le CRSNG, 48 ont été signalées pcomme ayant besoin d’être examinéesur examen et 32 d'entre elles se sont vu refuser le financement pour des raisons de sécurité. 

À la suite de ce programme pilote, des examens de sécurité sont prévus pour toutes les demandes de financement des trois organismes. Cependant, certains chercheurs ont critiqué le programme pour son manque de transparence et de clarté (Owens 2023b). L'examen préalable ne peut pas mettre fin aux projets potentiellement risqués, puisque les projets qui se voient refuser du financement du CRSNG peuvent obtenir un financement équivalent auprès de leurs partenaires internationaux, et les projets qui ne cherchent pas à obtenir le financement fédéral ne seront pas examinés (Fife et Chase 2021). En mai 2023, le [https://www.thestar.com/news/canada/canada-set-to-name-foreign-labs-universities-that-pose-risk-to-national-security/article_4344a58d-f9f0-5e93-8604-82529aaff253.html ''Toronto Star''] a rapporté que l'ISDE était en train d'élaborer une politique énumérant des domaines de recherche et des établissements de préoccupation spécifiques pour relever certains de ces défis.

Une autre question abordée dans la presse est la menace spécifique à la sécurité de la recherche de la part de l'État chinois. Écrivant au sujet du programme pilote de dépistage, Brian Owens note que «&amp;#8239;[b]ien qu’on n’y nomme aucune organisation ni aucun pays explicitement&amp;#8239;» dans la Déclaration sur la protection de la recherche canadienne de février 2023, «&amp;#8239;il est généralement admis que les laboratoires et les entreprises chinoises présentent un risque particulier en raison de leurs liens étroits et souvent nébuleux avec les forces armées ainsi que des allégations d’usage abusif des droits de propriété intellectuelle&amp;#8239;» (Owens 2023b). La Chine a été largement discutée comme une menace pour la sécurité de la recherche dans la presse internationale, y compris des articles dans [https://globalnews.ca/news/9488207/canada-china-research-crackdown/ ''Global News''], [https://www.science.org/content/article/canada-moves-ban-funding-risky-foreign-collaborations ''Science''] et [https://www.timeshighereducation.com/news/canadian-scientists-questioned-agents-over-china-links ''Times Higher Education''].

Bien que la plupart des politiques (y compris la politique s’inclus le d’OCDE) aient adopté une approche agnostique par pays, des préoccupations ont été soulevées – comme dans des articles pour l'[https://www.theatlantic.com/ideas/archive/2021/12/china-initiative-intellectual-property-theft/621058/ ''Atlantic'']'', ''la [https://www.chronicle.com/newsletter/latitudes/2023-04-12 ''Chronicle of Higher Education''], [https://policyoptions.irpp.org/magazines/july-2023/canadian-research-china-collaboration/ ''Policy Options''] et [https://www.youtube.com/watch?v=IxobEDHW-Zs ''ScienceBusiness''], et [https://www.affairesuniversitaires.ca/articles-de-fond/article/la-securite-nationale-et-la-recherche-font-ils-bon-menage/ ''Affaires universitaires'']'' – ''au sujet de l'accent implicite mis sur les menaces de la Chine. [https://www.caut.ca/bulletin/2023/05/executive-directors-corner-academic-freedom-and-national-security David Robinson] décrit ces risques dans un article pour le bulletin de l'Association canadienne des professeurs d'université (ACPPU) : 

&lt;blockquote&gt;
La recherche universitaire peut présenter des risques légitimes pour la sécurité nationale, mais nous devons, en tant que communauté, nous garder de tout excès. Nous devons veiller à ce que les universitaires ne soient pas ciblés en raison de leur origine ethnique et à ce que les règles ne soient pas si larges qu’elles restreignent la recherche et l'érudition légitimes. La loi sur l'influence étrangère ne doit pas non plus être utilisée à mauvais escient pour cibler les universitaires qui critiquent la politique militaire ou étrangère du Canada. (Robinson 2023)
&lt;/blockquote&gt;

Comme le fait remarquer Robinson, l'accent mis sur les menaces de la Chine a conduit à un climat de peur de collaborer avec des chercheurs et chercheuses chinois qui entrave la recherche et les relations de collaboration et met les chercheurs et chercheuses individuels en danger.

==Réponses de la communauté INKE==
Les recherches d'Aaron Mauro, membre du partenariat INKE, se concentrent actuellement sur la cybersécurité de la recherche. Son livre de 2022 [https://www.bloomsbury.com/us/hacking-in-the-humanities-9781350231009/ ''Hacking in the Humanities : Cybersecurity, Speculative Fiction, and Navigating a Digital Future'' (2022) ]'' ''traite d'une approche de recherche qui prioritise la sécurité. Son [https://www.fu-berlin.de/en/sites/dhc/programme/termine/_Termin-Archiv_EN/DHCLs/2022-06-07_DHCL-Mauro.html discours du même nom] au Dahlem Humanities Center en 2022 soutient que les projets d’humanités numériques doivent adopter les meilleures pratiques de sécurité dans la façon dont nous planifions, menons et communiquons la recherche et que les humanistes numériques sont bien placés pour poser les questions critiques nécessaires. 

Mauro a donné une conférence au Digital Humanities Summer Institute (DHSI) 2021intitulée [https://web.archive.org/web/20210227025734/https:/dhsi.org/dhsi-2021-online-edition-institute-lectures/ «&amp;#8239;Human Exploits : Cybersecurity and the Humanities&amp;#8239;»,] et enseigne un cours DHSI sur [https://dhsi.org/on-campus-courses2024/ la cybersécurité pour les humanistes].

Parmi d'autres écrits liés à la cybersécurité, Mauro a écrit plusieurs articles pour ''The Conversation. ''Dans [https://theconversation.com/working-from-home-during-the-coronavirus-pandemic-creates-new-cybersecurity-threats-134954 «&amp;#8239;Working from Home during the Coronovirus Pandemic Creates New Cybersecurity Threats&amp;#8239;»,] il décrit comment les menaces telles que l’hameçonnage et le ransomware sont devenues de plus en plus courantes pendant la pandémie et le besoin d'une infrastructure plus sécurisée et de meilleures habitudes de sécurité par les utilisateurs. Dans [https://theconversation.com/ukrainian-cultural-artifacts-are-at-risk-during-the-russian-invasion-but-digitizing-them-may-offer-some-protection-185673 «&amp;#8239;Ukrainian Cultural Artifacts are at Risk during the Russian Invasion, but Digitizing Them my Offer Some Protection&amp;#8239;»,] il décrit comment les cyberattaques et la rhétorique russes menacent le patrimoine culturel ukrainien ainsi que sa sécurité nationale. Bien que la numérisation puisse créer des sauvegardes de documents du patrimoine culturel, note-t-il, elle dépend des infrastructures qui sont également menacées (pour plus sur la numérisation des documents du patrimoine culturel, voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La Stratégie canadienne de numérisation du patrimoine documentaire|La Stratégie canadienne de numérisation du patrimoine documentaire]]&amp;#8239;»).

==La sécurité de la recherche et la communauté universitaire élargie==
De nombreuses initiatives dans l'ensemble de la communauté universitaire canadien portent sur des questions de sécurité de la recherche. À l'échelle nationale, par exemple, l'Alliance de recherche numérique du Canada (l'Alliance) a lancé en décembre 2022 [https://alliancecan.ca/fr/nouveautes/nouvelles/les-politiques-et-normes-de-cybersecurite-sont-maintenant-disponibles un ensemble de normes et de politiques de cybersécurité] liées à l'infrastructure nationale, abordant [https://alliancecan.ca/fr/document/741 la classification des données], la [https://alliancecan.ca/fr/document/739 gestion des données], [https://alliancecan.ca/fr/document/737 la gestion des vulnérabilités] et [https://alliancecan.ca/fr/document/733 la gestion des risques liés à la cybersécurité]. L'Alliance souligne également [https://alliancecan.ca/fr/nouveautes/nouvelles/mois-de-la-sensibilisation-la-cybersecurite le Mois de la sensibilisation à la cybersécurité 2023] avec une série d'ateliers en ligne tenus tout au long du mois d'octobre, chacun portant sur une question liée à la sécurité de la recherche numérique.

Toujours à l'échelle nationale, le [https://canssoc.ca/fr/ Canadian Shared Security Operations Centre (CanSSOC)], une collaboration entre [https://www.canarie.ca/fr/ CANARIE] et [https://www.canarie.ca/nren/ le Réseau national de la recherche et de l'éducation (RNRE), ]coordonne les services de cybersécurité locaux, régionaux et nationaux partout au Canada.

Les institutions et les organisations prennent également des mesures. Par exemple, en septembre 2021, le U15 a publié une [https://u15.ca/fr/publications/statements-releases/declaration-du-u15-sur-la-protection-des-valeurs-canadiennes-et-de-la-recherche-canadienne/ Déclaration du U15 sur la protection des valeurs canadiennes et de la recherche canadienne] qui souligne la nécessité que les politiques de sécurité soient claires, transparentes et prises en compte, reconnaissant que 

&lt;blockquote&gt;
la liberté académique et l'autonomie institutionnelle font partie des principes fondamentaux qui font que nos institutions sont à l'abri de toute ingérence politique, peuvent parler en toute franchise aux autorités et sont en mesure de répondre aux besoins sociaux, culturels et économiques des Canadiens. (Regroupement 2021)
&lt;/blockquote&gt;

En février 2023, l'Université de Waterloo a organisé une [https://uwaterloo.ca/research/research-security-conference conférence sur la sécurité de la recherche] afin de sensibiliser les gens à des questions clés et d'encourager la discussion, y compris sur le potentiel de discrimination raciale en raison des mesures de sécurité. Il a également abordé l'évolution du rôle des bureaux des services de recherche, car de nombreux établissements ont maintenant des divisions, des bureaux et / ou du financement dédié à la sécurité de la recherche. 

Et, bien qu'il n’est pas spécifiquement une politique de sécurité de la recherche, [https://fnigc.ca/fr/les-principes-de-pcap-des-premieres-nations/ Les principes de PCAP® des Premières Nations] du Centre de gouvernance de l'information des Premières Nations traitent de la propriété, du contrôle, de l'accès et de la possession, qui ont tous trait à l'intégrité et à la sécurité des données.

==Sécurité de la recherche et la science ouverte==
Un défi clé pour la science ouverte et sécurisée est que l'ouverture, la collaboration et le partage qui sont à la base des mouvements ouverts sont précisément ce que les acteurs malfaisants exploitent pour saper la sécurité de la recherche. Similairement, les infrastructures numériques et les technologies de communication en ligne qui rendent possible la science ouverte sont également particulièrement vulnérables aux attaques.

Un défi de sécurité connexe qui est aussi particulièrement pertinent pour la science ouverte est que plus les informations sont partagées ouvertement, plus le risque qu'elles soient utilisées à des fins néfastes est grand, comme [https://www.wired.co.uk/article/making-science-more-open-is-good-for-research-but-bad-for-security Grace Browne] s’explique dans un article pour ''Wired''. La recherche sur la COVID-19 pourrait être utilisée pour développer des bioarmes, par exemple, et le code d'intelligence générale artificielle génératif pourrait être utilisé pour diffuser de la désinformation. L'essor des serveurs de préimpression ouverts, en particulier pour la recherche à double usage, est particulièrement préoccupante parce que cette recherche n'est pas encore évaluée par les pairs et peut contenir des erreurs ou poser des risques potentiels pour la sécurité qui n'ont pas été identifiés. Notant que l'ouverture amplifie le risque déjà existant que la recherche soit utilisée de manière non intentionnelle et nuisible, Browne soutient qu'il est temps que la science ouverte réponde à ses risques, avant que le pire ne se réalise (Browne 2022).

En plus des efforts canadiens décrits ci-dessus, des efforts sont en cours dans le monde entier pour développer une culture de recherche axée sur la sécurité, souvent liée à des questions qui recoupent la science ouverte. Par exemple, les [https://www.nature.com/articles/s41597-020-0486-7 TRUST Principles for Digital Repositories] (transparence, responsabilité, accent mis sur l'utilisateur, durabilité, technologie), qui reconnaissent que les infrastructures numériques que les chercheurs utilisent pour déposer et sourcer des données doivent être sécurisées et fiables (voir «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/Les principes TRUST pour les dépôts numériques|Les principes TRUST pour les dépôts numériques]]&amp;#8239;»). Dans leur [https://www.carl-abrc.ca/fr/nouvelles/principes-trust-pour-les-depots-numeriques/ approbation conjointe des principes], l'Association des bibliothèques de recherche du Canada (ABRC) et Portage (2020) ont noté que la technologie comprend «&amp;#8239;la capacité d’identifier immédiatement des menaces de sécurité et d'y répondre de manière efficace&amp;#8239;».

Educause a un [https://www.educause.edu/cybersecurity-and-privacy-guide guide de sécurité et de confidentialité] contenant des informations et des ressources pour soutenir l'élaboration de politiques et les programmes d'éducation pour la communauté de l'enseignement supérieur. En janvier 2022, la Commission européenne a publié [https://op.europa.eu/en/publication-detail/-/publication/3faf52e8-79a2-11ec-9136-01aa75ed71a1 ''Tackling R&amp;I Foreign Interference''], un document de travail contenant des lignes directrices spécifiques pour les organismes de recherche afin d'atténuer les risques de sécurité tout en faisant progresser la science ouverte. 

Ce ne sont là que quelques exemples d'initiatives en cours dans le monde pour s'attaquer à la question complexe de la sécurité de la recherche. Ils reflètent le consensus parmi les intervenants en matière de sécurité de la recherche selon lequel l'ouverture doit être équilibrée avec la sécurité tout en respectant les libertés académiques : une reconnaissance des avantages de travailler ouvertement et en collaboration au-delà des frontières nationales et des risques légitimes pour la sécurité encourus. 

==Ouvrages cités==
*ABRC (Association des bibliothèques de recherche du Canada). 2020. «&amp;#8239;L'ABRC et Portage adhérent aux principes TRUST pour les dépôts numériques&amp;#8239;». Le 31 juillet 2020. [https://www.carl-abrc.ca/news/trust-principles-for-digital-repositories/ https://www.carl-abrc.ca/news/trust-principles-for-digital-repositories/].

*Browne, Grace. 2022. «&amp;#8239;Making Science More Open is Good for Research––But Bad for Security&amp;#8239;». ''Wired'', le 22 avril 2022. [https://www.wired.com/story/making-science-more-open-good-research-bad-security/ https://www.wired.com/story/making-science-more-open-good-research-bad-security/].

*Fife, Robert, et Steven Chase. 2021. «&amp;#8239;Ottawa Imposes National-Security Risk Assessments for University Researchers Seeking Federal Funds&amp;#8239;». ''The Globe and Mail'', le 12 juillet 2021. [https://www.theglobeandmail.com/politics/article-ottawa-imposes-national-security-risk-assessments-for-university/ https://www.theglobeandmail.com/politics/article-ottawa-imposes-national-security-risk-assessments-for-university/].

*Gouvernement du Canada. 2021. «&amp;#8239;Qui constitue une menace?&amp;#8239;» Le 11 juillet 2021. [https://science.gc.ca/site/science/fr/protegez-votre-recherche/renseignements-generaux-securite-recherche/qui-constitue-menace https://science.gc.ca/site/science/fr/protegez-votre-recherche/renseignements-generaux-securite-recherche/qui-constitue-menace].

*Gouvernement du Canada. 2023. «&amp;#8239;Pourquoi devriez-vous protéger votre recherche?&amp;#8239;» Le 31 mars 2023. [https://science.gc.ca/site/science/fr/protegez-votre-recherche/renseignements-generaux-securite-recherche/pourquoi-devriez-vous-proteger-votre-recherche https://science.gc.ca/site/science/fr/protegez-votre-recherche/renseignements-generaux-securite-recherche/pourquoi-devriez-vous-proteger-votre-recherche].

*ISDE (Innovation, Sciences et Développement Économique Canada). 2023. «&amp;#8239;Déclaration des ministres Champagne, Duclos et Mendicino sur la protection de la recherche canadienne&amp;#8239;». Gouvernement du Canada. February 14, 2023. [https://www.canada.ca/fr/innovation-sciences-developpement-economique/nouvelles/2023/02/declaration-des-ministres-champagne-duclos-et-mendicino-sur-la-protection-de-la-recherche-canadienne.html https://www.canada.ca/fr/innovation-sciences-developpement-economique/nouvelles/2023/02/declaration-des-ministres-champagne-duclos-et-mendicino-sur-la-protection-de-la-recherche-canadienne.html].

*Mauro, Aaron. 2022. «&amp;#8239;Hacking in the Humanities : Cybersecurity, Speculative Fiction, and Navigating a Digital Future&amp;#8239;». Dahlem Humanities Center (DHC). Le 7 juin 2022. [https://www.fu-berlin.de/en/sites/dhc/videothek/Videothek/908-DHCL-Mauro/index.html https://www.fu-berlin.de/en/sites/dhc/videothek/Videothek/908-DHCL-Mauro/index.html].

*OCDE (Organisation de coopération et de développement économiques). 2022. «&amp;#8239;Intégrité et sécurité dans l'écosystème mondial de la recherche&amp;#8239;». OECD Science, Technology and Industry Policy Papers, no. 130. [https://doi.org/10.1787/39ee9438-fr https://doi.org/10.1787/39ee9438-fr].

*Owens, Brian. 2023a. «&amp;#8239;La sécurité nationale et la recherche font-ils bon ménage ?&amp;#8239;». ''Affaires universitaires'', le 14 juin 2023. [https://www.affairesuniversitaires.ca/articles-de-fond/article/la-securite-nationale-et-la-recherche-font-ils-bon-menage/ https://www.affairesuniversitaires.ca/articles-de-fond/article/la-securite-nationale-et-la-recherche-font-ils-bon-menage/].

*Owens, Brian. 2023b. «&amp;#8239;Le manque de clarté lors des évaluations de risque pour la sécurité nationale est dénoncé&amp;#8239;». ''Affaires universitaires'', le 23 mars 2023. [https://www.affairesuniversitaires.ca/actualites/actualites-article/le-manque-de-clarte-lors-des-evaluations-de-risque-pour-la-securite-nationale-est-denonce/ https://www.affairesuniversitaires.ca/actualites/actualites-article/le-manque-de-clarte-lors-des-evaluations-de-risque-pour-la-securite-nationale-est-denonce/].

*Robinson, David. 2023. «&amp;#8239;Liberté académique et sécurité nationale&amp;#8239;». ''Bulletin de l'ACPPU'', le juin 2023. [https://www.caut.ca/fr/bulletin/2023/05/le-coin-du-directeur-general-liberte-academique-et-securite-nationale https://www.caut.ca/fr/bulletin/2023/05/le-coin-du-directeur-general-liberte-academique-et-securite-nationale].

*Regroupement des universités de recherche canadiennes U15. 2021. «&amp;#8239;Déclaration du U15 sur la protection des valeurs canadiennes et de la recherche canadienne&amp;#8239;». Groupe U15 des universités de recherche canadiennes. Le 28 septembre 2021. [https://u15.ca/fr/publications/statements-releases/declaration-du-u15-sur-la-protection-des-valeurs-canadiennes-et-de-la-recherche-canadienne/ https://u15.ca/fr/publications/statements-releases/declaration-du-u15-sur-la-protection-des-valeurs-canadiennes-et-de-la-recherche-canadienne/].

*Regroupement des universités de recherche canadiennes et universités du Canada U15. 2019. «&amp;#8239;Atténuer les risques économiques et géopolitiques associés aux projets de recherche sensibles : guide à l’intention des chercheurs universitaires&amp;#8239;». [https://www.univcan.ca/wp-content/uploads/2020/08/attenuer-les-risques-economiques-et-geopolitiques-associes-aux-projets-de-recherche-sensibles-dec-2019.pdf https://www.univcan.ca/wp-content/uploads/2020/08/attenuer-les-risques-economiques-et-geopolitiques-associes-aux-projets-de-recherche-sensibles-dec-2019.pdf].

*Science Canada. 2021. «&amp;#8239;CSIS Research Security Briefing&amp;#8239;». Le 9 juillet 2021. [https://www.youtube.com/watch?v=LSu5ObwzM8c https://www.youtube.com/watch?v=LSu5ObwzM8c].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>0c59uojuvk5477y110vrziz1j4o82wx</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Une révision de la Politique des trois organismes sur le libre accès aux publications (2015)</title>
    <ns>0</ns>
    <id>82373</id>
    <revision>
      <id>745438</id>
      <parentid>745156</parentid>
      <timestamp>2025-06-26T23:32:35Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745438</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="26276" sha1="rzpm9xptxaamtsq6edtzpo6ngudq33z" xml:space="preserve">''Cette observation a été rédigée par Caroline Winter et Brittany Amell (nous remercions Elizabeth Kalbfleisch, Jessica Clark et Suzanne Beth pour leurs commentaires et leurs contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

Le 4 juillet 2023, [https://science.gc.ca/site/science/fr/financement-interorganismes-recherche/politiques-lignes-directrices/libre-acces/presidents-respectifs-organismes-federaux-financement-recherche-canada-annoncent-revision-politique les présidents des trois organismes nationaux de financement de la recherche du Canada] - les [https://cihr-irsc.gc.ca/f/193.html Instituts de recherche en santé du Canada (IRSC)], le [https://www.nserc-crsng.gc.ca/index_fra.asp Conseil de recherches en sciences naturelles et en génie du Canada (CRSNG)], et le [https://www.sshrc-crsh.gc.ca/home-accueil-fra.aspx Conseil de recherches en sciences humaines du Canada (CRSH)] ont annoncé leur intention de revoir la [https://science.gc.ca/site/science/fr/financement-interorganismes-recherche/politiques-lignes-directrices/libre-acces/politique-trois-organismes-libre-acces-aux-publications-2015 Politique des trois organismes sur le libre accès aux publications] (2015). Une version révisée de la politique devrait être publiée en 2025.

«&amp;#8239;Nous étions à l’avant-garde en 2015, mais ce n’est plus le cas aujourd’hui. Il faut refondre la politique en fonction de ce qui se fait à l’échelle internationale depuis quelques années&amp;#8239;».  déclare Michael Donaldson, directeur des initiatives stratégiques chez Canadian Science Publishing (tel que cité dans [https://www.affairesuniversitaires.ca/articles-de-fond/article/lheure-est-au-rattrapage-en-matiere-de-libre-acces/ Owens 2023]). La version 2015 de la politique de libre accès des trois agences autorise un embargo pouvant aller jusqu'à 12 mois.

L’annonce souligne l’engagement des agences «&amp;#8239;à accroître la diffusion des résultats de la recherche et à accélérer la mobilisation des connaissances en garantissant que les articles évalués par des pairs résultant de la recherche financée par l’agence soient disponibles gratuitement et immédiatement&amp;#8239;». Il contextualise l’examen des politiques aux côtés de plusieurs développements politiques récents. L'un d'eux est[https://science.gc.ca/site/science/fr/bureau-conseillere-scientifique-chef/science-ouverte/feuille-route-pour-science-ouverte  la ][https://science.gc.ca/site/science/fr/bureau-conseillere-scientifique-chef/science-ouverte/feuille-route-pour-science-ouverte Feuille de route du Canada pour la science ouverte], publié par le conseiller scientifique en chef du Canada en février 2020, qui demandait que les publications scientifiques fédérales soient en libre accès d’ici janvier 2023, dans le but d’atteindre «&amp;#8239;le libre accès par défaut sans période d’embargo&amp;#8239;» (Gouvernement du Canada 2020).

Un autre est le [https://www8.cao.go.jp/cstp/kokusaiteki/g7_2023/230513_g7_communique.pdf Communiqué des ministres des sciences et technologies du G7] de mai 2023 qui aborde diverses questions allant de l’invasion russe de l’Ukraine à la recherche spatiale. Tout au long du communiqué, on souligne l’importance de l’ouverture aux côtés de la durabilité et de la sécurité : «&amp;#8239;Nous pensons que l’ouverture est fondamentale, la sécurité est essentielle, et la liberté et l’intégrité sont cruciales&amp;#8239;» (Ministres de la science et de la technologie du G7 2023, 3 ; voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/La sécurité de la recherche et la science ouverte au Canada|La sécurité de la recherche et la science ouverte au Canada]]&amp;#8239;»).

En plus, en 2021, les Fonds de recherche du Québec (FRQ) ont annoncé qu'en s'associant à d'autres organismes de financement ainsi qu'à la cOAlition S, ils rendront l'accès à leurs articles scientifiques immédiatement disponible (voir [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les Fonds de recherche du Québec rejoignent la cOAlition S|«&amp;#8239;The Fonds de Recherche du Québec Join cOAlition S&amp;#8239;»]]).

L’annonce s’appuie également sur la politique de libre accès de l’UNESCO, citant [https://www.unesco.org/fr/open-access la ][https://www.unesco.org/fr/open-access définition de l’arthrose immédiate] et notant les meilleures pratiques décrites dans la [https://unesdoc.unesco.org/ark:/48223/pf0000379949.locale=en Recommandation de l'UNESCO sur la science ouverte] (voir [https://ospolicyobservatory.uvic.ca/open-science-and-the-unesco-initiative/ «&amp;#8239;La science ouverte et l’initiative de l’UNESCO&amp;#8239;»] et «&amp;#8239;[[Observations préliminaires : Observatoire des politiques d'Érudition ouverte, 2017-2020/La Recommandation de l’UNESCO sur la science ouverte|La Recommandation de l’UNESCO sur la science ouverte]]&amp;#8239;»]).

La première étape de l'examen a été une enquête en ligne clôturée en septembre 2023 (résultats disponibles [https://science.gc.ca/site/science/en/interagency-research-funding/policies-and-guidelines/open-access/tri-agency-open-access-policy-publications-policy-review-survey-results ici]). Les prochaines étapes comprennent des séances de consultation avec les groupes de parties prenantes sur les thèmes clés qui ont émergé de l'enquête.

==L’examen de la politique de libre accès des trois agences dans la presse==
Bien que la révision de la politique n'ait pas été largement couverte par la presse, un article de [https://www.affairesuniversitaires.ca/articles-de-fond/article/lheure-est-au-rattrapage-en-matiere-de-libre-acces/ Brian Owens] publié dans ''Affaires universitaires'' en avril 2023 anticipe l’évolution des trois agences vers le libre accès immédiat.

Owens note que, même si la politique canadienne de libre accès de 2015 a fait preuve de leadership dans ce domaine, la politique nationale n’a pas réussi à suivre le rythme des développements internationaux, faisant référence au [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le mémo Nelson : Une politique d’accès public mis à jour aux États-Unis|Mémo Nelson]] publié par le Bureau de la politique scientifique et technologique (The Office of Science and Technology Policy) des États-Unis en août 2022 et le Plan S européen publié en 2018, qui appellent tous deux à un libre accès immédiat (voir «&amp;#8239;[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Le mémo Nelson : Une politique d’accès public mis à jour aux États-Unis|Le mémo Nelson : Une politique d’accès public mis à jour aux États-Unis]]&amp;#8239;» et la [https://ospolicyobservatory.uvic.ca/tag/plan-s/ série d'Observations sur le Plan S]).

Owens attribue la nécessité d’une mise à jour politique en partie à la pandémie de COVID-19. Stefanie Haustein qui affirme qu’en raison de la pandémie, «&amp;#8239;Cette pratique commerciale consistant à ralentir l’accès à la science pour en tirer des bénéfices ne tient plus la route&amp;#8239;», dit-elle (Owens 2023)

l’idée selon laquelle la science devrait ralentir pour que les entreprises puissent réaliser des bénéfices a désormais changé dans les têtes&amp;#8239;» (Owens 2023).

De la même manière, dans la [https://www.slaw.ca/2024/01/12/an-open-letter-on-open-access/ lettre ouverte récemment publiée en ligne dans un magazine juridique canadien], le fondateur du Public Knowledge Project et un des membres de la Société royale du Canada, John Willinsky (2024), note à quel point «&amp;#8239;c’est une autre histoire pour le libre accès&amp;#8239;» aujourd’hui, «&amp;#8239;suite à la pandémie et face à un changement climatique dévastateur&amp;#8239;».

«&amp;#8239;Au milieu des fausses nouvelles et des discours sur la post-vérité, le libre accès est actuellement considéré par les éditeurs, les chercheurs et les universités comme l’avenir de l’édition scientifique. Ce consensus autour de la valeur du libre accès prend diverses formes de publication, allant du transfert des coûts de publication aux auteurs des abonnements à la demande aux bibliothèques de soutenir les revues en libre accès&amp;#8239;», explique Willinsky (2024).

En réfléchissant plus loin, Willinsky (2024) écrit : «&amp;#8239;La question aujourd’hui ne porte pas sur la durée des embargos ni sur qui a financé telle ou telle étude. Il s’agit de savoir comment garantir que toute la science soit ouverte à un prix équitable. Il s’agit de savoir comment instaurer le libre accès en temps opportun, sans le libre accès des grands éditeurs profitant du libre accès. . . La question aujourd’hui est donc bien davantage de trouver des moyens financièrement durables de faire du libre accès le principe de fonctionnement de la recherche, car c’est une meilleure façon de faire de la science&amp;#8239;».

==Réponses de la communauté au sens large==
L'annonce de l'examen a été largement republiée par les universités de tout le pays, mais comme l'examen des politiques est en cours, les réponses de l'INKE et des communautés plus larges se développeront probablement au fil du temps.

La [https://library.queensu.ca/about-us/news-events/queens-and-tri-agencys-update-national-open-access-policy Bibliothèque de l'Université Queen's] a publié une déclaration exprimant sa préoccupation quant au fait que la révision des politiques ne renforcera davantage les modèles commerciaux d’édition fondés sur les frais de traitement des articles (APC) qui aggravent les inégalités existantes dans le système de recherche mondial et sont financièrement insoutenables (Bibliothèque de l’Université Queen’s 2023).

[https://www.coalition-publi.ca/news-nouvelles/reponse-revision-politique-libre-acces Coalition Publica (2023)] a publié une déclaration exprimant son «&amp;#8239;soutien enthousiaste&amp;#8239;» à la révision, «&amp;#8239;en particulier à la lumière de l'évolution du paysage mondial de l'édition en libre accès&amp;#8239;», notant en outre la nécessité de développer une stratégie nationale qui aborde à la fois: «&amp;#8239;L'élaboration d'une stratégie nationale pour la mise en œuvre progressive du libre accès diamant répondra efficacement aux enjeux propres aux diverses communautés universitaires et permettra aux revues canadiennes portées par ces communautés de rendre la recherche disponible en libre accès dès sa publication.»

«&amp;#8239;Les détails de la nouvelle politique immédiate de libre accès seront importants et devraient être établis en consultation avec les nombreuses parties prenantes dans ce domaine, y compris les fournisseurs d'infrastructures de publication scientifique numérique et les revues savantes canadiennes&amp;#8239;», déclare Jessica Clark, coordonnatrice principale (développement du libre accès) à Érudit. «&amp;#8239;Plus précisément, la nouvelle politique doit être adaptée au large éventail de disciplines de recherche au Canada et offrir des voies équitables et durables vers un accès libre immédiat -- y compris le libre accès diamant, le modèle répandu parmi les revues de sciences humaines et sociales au Canada, où aucun frais n'est facturé ni aux lecteurs, nit aux auteurs&amp;#8239;». ''Note : Faites défiler la page vers le bas pour lire l'intégralité du commentaire de Jessica Clark.''

Elizabeth Kalbfleisch, chargée de projet à l'Association canadienne des bibliothèques de recherche (ABRC), ajoute : «&amp;#8239;Les résultats du sondage communautaire publié par les trois agences, publiés en décembre, confirment le large soutien de la communauté des bibliothèques en faveur du libre accès, plus que toute autre profession représentée. En conséquence, 93 % des bibliothécaires interrogés ont indiqué leur soutien au libre accès, le libre accès diamant étant le modèle préféré. Cela confirme ce que nous entendons de la part de nos membres, même si le libre accès n’est qu’une partie de la transition vers une recherche ouverte dans laquelle nous nous engageons&amp;#8239;».

Kalbfleisch souligne que, pour être vraiment viable, «&amp;#8239;Les changements politiques doivent s’accompagner d’un changement culturel et d’une refonte du processus d’évaluation de la recherche [qui] ne fait que commencer&amp;#8239;». ''Note : Faites défiler la page vers le bas pour lire l'intégralité du commentaire d'Elizabeth Kalbfleisch.''

À peu près au même moment l’année dernière, l’ABRC a publié un plan d’action en partenariat avec le Réseau canadien du savoir pour la recherche (CKRN) afin d’élaborer une feuille de route commune pour l’érudition ouverte. La feuille de route, intitulée «&amp;#8239;Vers une bourse d’études ouverte : Un plan d’action pour les bibliothèques de recherche et universitaires canadiennes jusqu’en 2025&amp;#8239;», est accessible [https://www.carl-abrc.ca/wp-content/uploads/2023/05/Towards-an-Open-Scholarship-Action-Plan-FR_FINAL.docx-002.pdf ici.]

==L’examen des politiques de libre accès des trois agences et la publication secondaire Droits==
Le passage au libre accès immédiat suggéré par l’annonce de l’examen par les trois organismes alignerait la politique canadienne sur le libre accès avec d’autres politiques nationales et internationales. Comme l’ont soutenu certains membres de la communauté des chercheurs, cela offre également l’occasion d’examiner et éventuellement de réviser la ''Loi sur le droit d'auteur ''afin d’améliorer l’accès à la recherche financée par des fonds publics grâce à des droits de publication secondaires.

Les droits de publication secondaires, qui permettent de republier des recherches financées par des fonds publics dans des référentiels libre accès ou ailleurs, constituent une voie vers le libre accès, souvent compris comme un libre accès vert. Bien que certains éditeurs autorisent ce type de republication, ils appellent souvent à des embargos, stipulent que seuls les manuscrits acceptés par l'auteur (examen par les pairs mais pré-révision) peuvent être republiés, ou imposent d'autres restrictions.

Dans un [https://cfla-fcab.ca/wp-content/uploads/2023/07/CFLA-Secondary-Publishing-Rights-and-Open-Access-Position-Statement_FR.docx.pdf exposé de position] de juillet 2023, la Fédération canadienne des associations de bibliothèques (FCAB) demande au gouvernement canadien «&amp;#8239;de présenter une modification à la Loi sur le droit d’auteur reconnaissant les droits d’exploitation secondaire des auteurs universitaires à l’appui de l’accès immédiat à la recherche financée par le secteur public publiée dans les revues scientifiques&amp;#8239;».

Il note [https://libereurope.eu/draft-law-for-the-use-of-publicly-funded-scholarly-publications/ que des changements législatifs similaires] sont en cours en Europe, motivés en partie par l'Association des bibliothèques européennes de recherche (Liber).

Dans un morceau pour ''La conversation'', [https://theconversation.com/secondary-publishing-rights-can-improve-public-access-to-academic-research-209761 Brianne Selman et Mark Swartz] (2023) soutiennent également que la Loi canadienne sur le droit d’auteur devrait être révisée pour permettre la publication secondaire même si elle n’est pas autorisée par les éditeurs, soulignant que «&amp;#8239;si le Canada devait adopter une loi similaire en conjonction avec la révision de la politique des trois agences, nous pourrions devenir un leader mondial des publications scientifiques en libre accès&amp;#8239;».

La question de savoir si les décideurs politiques canadiens répondront à ces appels visant à faire progresser l’érudition ouverte grâce au libre accès sera déterminée au fur et à mesure du déroulement du processus d’examen.

==D'autres commentaires==
''Jessica Clark, coordonnatrice principale, développement du libre accès, Érudit ''

«&amp;#8239;L'annonce des trois agences est une nouvelle positive pour l'écosystème canadien de la recherche et des communications savantes, d'autant plus que les agences ont clairement indiqué que la politique révisée soutiendrait le libre accès immédiat&amp;#8239;», a déclaré Jessica Clark, coordonnatrice principale, développement du libre accès, du Plateforme canadienne de diffusion de la recherche Érudit ([http://erudit.org érudit.org]). «&amp;#8239;Cela permettra de rendre largement disponibles les résultats de la recherche financée par le gouvernement fédéral et d'aligner la politique fédérale canadienne sur ce qui se passe déjà au Québec, suite à l'adoption du Plan S par les Fonds de recherche du Québec, ainsi que de s'aligner sur des politiques de libre accès plus avancées autour du monde. Les détails de la nouvelle politique de libre accès immédiat seront importants et devraient être établis en consultation avec les nombreux intervenants dans ce domaine, y compris les fournisseurs d'infrastructures d'édition scientifique numérique et les revues savantes canadiennes. Plus précisément, la nouvelle politique doit être adaptée au large éventail de disciplines de recherche au Canada et offrir des voies équitables et durables vers un libre accès immédiat, y compris le libre accès diamant -- le modèle répandu parmi les revues de sciences humaines et sociales du Canada, où aucun frais n'est facturé. aux lecteurs ou aux auteurs. La communauté de l’édition savante d’Érudit est prête et disposée à collaborer avec les trois agences dans le processus de consultation politique&amp;#8239;».

''Elizabeth Kalbfleisch, chargée de projet, Association canadienne des bibliothèques de recherche''

L’annonce l’été dernier d’une révision de la Politique des trois organismes sur le libre accès aux publications a été accueillie avec intérêt par la communauté des bibliothèques de recherche que nous représentons, dont 29 sont universitaires et deux sont des institutions fédérales. D'un point de vue politique, le Canada a un certain rattrapage à faire pour suivre l'évolution de la situation à l'échelle internationale. Même au niveau national, les trois agences sont en retard par rapport aux engagements d'ouverture pris au Québec par les FRQ. La suppression de l'embargo d'un an que la politique autorise actuellement en faveur du libre accès immédiat élève le Canada aux termes du mémo OSTP aux États-Unis, du Plan S à travers le monde et de la propre politique de libre accès de l'UNESCO en vigueur depuis 2013.

Les [https://science.gc.ca/site/science/fr/financement-interorganismes-recherche/politiques-lignes-directrices/libre-acces/resultats-sondage-revision-politique-trois-organismes-libre-acces-aux-publications  résultats d'un sondage communautaire publié par les trois agences], publiés en décembre, confirment le large soutien de la communauté des bibliothèques en faveur du libre accès, plus que toute autre profession représentée. En conséquence, 93 % des bibliothécaires interrogés ont indiqué leur soutien au libre accès, Diamond OA étant le modèle préféré. Cela confirme ce que nous entendons de la part de nos membres, même si le libre accès n’est qu’une partie de la transition vers une recherche ouverte dans laquelle nous sommes engagés.

L’année dernière, l’ABRC s’est associé au RCDR pour élaborer notre propre feuille de route commune visant à ouvrir «&amp;#8239;[https://www.carl-abrc.ca/wp-content/uploads/2023/05/Towards-an-Open-Scholarship-Action-Plan-FR_FINAL.docx-002.pdf Vers le savoir libre: un plan d’action canadien pour 2025 pour les bibliothèques de recherches et les bibliothèques universitaires]&amp;#8239;». Nous faisons des progrès dans plusieurs domaines identifiés dans le plan d’action, notamment : le pilotage d’une plateforme canadienne de référentiels institutionnels partagés DSpace en partenariat avec l’OCUL et le Scholars Portal de l’Université de Toronto ; soutenir une nouvelle équipe d'engagement communautaire dans l'édition en bibliothèque ; héberger et prendre en charge deux consortiums d'identifiants persistants ; un soutien continu aux revues en libre accès par le biais de Coalition Publica ; via des accords de lecture et de publication, réaffectant les investissements d’abonnement des bibliothèques vers l’exonération des frais de traitement des articles (APC) des auteurs canadiens, ce qui donne lieu à des milliers d’articles en libre accès chaque année ; et mobiliser un groupe de travail pour élaborer des pratiques exemplaires visant à améliorer la visibilité mondiale du contenu canadien. Notre approche à plusieurs volets s'étend au-delà de la politique pour aborder les aspects techniques, administratifs et culturels liés à l'érudition ouverte.

Le changement de politique des trois organismes marquera un pas en avant important vers le libre accès, mais une série d'autres avancées sont nécessaires pour garantir que les chercheurs canadiens et leurs établissements ont la capacité et la préparation de s'y conformer ; les nouveaux engagements doivent être réalisables et durables pour provoquer un réel changement. Cela nécessite la bonne foi de tous les coins de l’écosystème de recherche canadien – les bailleurs de fonds, les éditeurs, les administrateurs de recherche, les bibliothèques et les chercheurs – mais cela nécessite également une responsabilité partagée et un investissement partagé. En outre, pour une véritable viabilité, les changements politiques doivent s’accompagner d’un changement culturel et d’une refonte du processus d’évaluation de la recherche qui vient tout juste de commencer.

==Références==
*Adem, Alejandro, Ted Hewitt et Michael Strong. 2023. «&amp;#8239;Les présidents respectifs des organismes fédéraux de financement de la recherche au Canada annoncent une révision de la Politique des trois organismes sur le libre accès aux publications&amp;#8239;». ''Gouvernement du Canada'' (communiqué de presse). 4 juillet 2023. [https://science.gc.ca/site/science/fr/financement-interorganismes-recherche/politiques-lignes-directrices/libre-acces/presidents-respectifs-organismes-federaux-financement-recherche-canada-annoncent-revision-politique https://science.gc.ca/site/science/fr/financement-interorganismes-recherche/politiques-lignes-directrices/libre-acces/presidents-respectifs-organismes-federaux-financement-recherche-canada-annoncent-revision-politique].

*Coalition Publique. 2023. «&amp;#8239;Coalition Publica soutient la révision de la Politique des trois organismes sur le libre accès aux publications&amp;#8239;». ''Coalition Publique ''(communiqué de presse). 12 décembre 2023. [https://www.coalition-publi.ca/news-nouvelles/tri-agency-response https://www.coalition-publi.ca/news-nouvelles/tri-agency-response]

*Fédération canadienne des associations de bibliothèques (FCAB). 2023. «&amp;#8239;Droits d’exploitation secondaire et libre accès&amp;#8239;». [https://cfla-fcab.ca/wp-content/uploads/2023/07/CFLA-Secondary-Publishing-Rights-and-Open-Access-Position-Statement_FR.docx.pdf https://cfla-fcab.ca/wp-content/uploads/2023/07/CFLA-Secondary-Publishing-Rights-and-Open-Access-Position-Statement_FR.docx.pdf].

*Gouvernement du Canada. 2020. «&amp;#8239;Feuille de route pour la science ouverte&amp;#8239;» ''Bureau du conseiller scientifique en chef du Canada. ''février 2020. [https://science.gc.ca/site/science/fr/bureau-conseillere-scientifique-chef/science-ouverte/feuille-route-pour-science-ouverte https://science.gc.ca/site/science/fr/bureau-conseillere-scientifique-chef/science-ouverte/feuille-route-pour-science-ouverte].

*Ministres des sciences et de la technologie du G7. 2023. «&amp;#8239;G7 Science and Technology Ministers’ Communique&amp;#8239;». [https://www8.cao.go.jp/cstp/kokusaiteki/g7_2023/230513_g7_communique.pdf https://www8.cao.go.jp/cstp/kokusaiteki/g7_2023/230513_g7_communique.pdf].

*Owens, Brian. 2023. «&amp;#8239;L’heure est au rattrapage en matière de libre accès&amp;#8239;». ''Affaires universitaires'', 19 avril 2023. [https://www.affairesuniversitaires.ca/articles-de-fond/article/lheure-est-au-rattrapage-en-matiere-de-libre-acces/ https://www.affairesuniversitaires.ca/articles-de-fond/article/lheure-est-au-rattrapage-en-matiere-de-libre-acces/].

*Bibliothèque de l'Université Queen's. 2023. «&amp;#8239;Mise à jour de la politique nationale de libre accès de la Reine et des trois agences&amp;#8239;». ''Bibliothèque de l'Université Queen's''. 25 août 2023. [https://library.queensu.ca/about-us/news-events/queens-and-tri-agencys-update-national-open-access-policy https://library.queensu.ca/about-us/news-events/queens-and-tri-agencys-update-national-open-access-policy].

*Selman, Brianne et Mark Swartz. 2023. «&amp;#8239;Les droits de publication secondaires peuvent améliorer l'accès du public à la recherche universitaire&amp;#8239;». ''La conversation''. 25 juillet 2023. [http://theconversation.com/secondary-publishing-rights-can-improve-public-access-to-academic-research-209761 http://theconversation.com/secondary-publishing-rights-can-improve-public-access-to-academic-research-209761].

*Willinsky, John. 2024. «&amp;#8239;Une lettre ouverte sur le libre accès&amp;#8239;». ''Slaw : le magazine juridique en ligne du Canada'' (Blog). 12 janvier 2024. [https://www.slaw.ca/2024/01/12/an-open-letter-on-open-access/ https://www.slaw.ca/2024/01/12/an-open-letter-on-open-access/].

*Winter, Caroline. 2022. «&amp;#8239;Les Fonds de recherche du Québec rejoignent la cOAlition S&amp;#8239;». Open Scholarship Policy Observatory. [https://fr.wikibooks.org/wiki/Extension_:_Observatoire_des_politiques_d'Érudition_ouverte,_2021-2024/Les_Fonds_de_recherche_du_Qu%C3%A9bec_rejoignent_la_cOAlition_S https://fr.wikibooks.org/wiki/Extension_:_Observatoire_des_politiques_d'Érudition_ouverte,_2021-2024/Les_Fonds_de_recherche_du_Qu%C3%A9bec_rejoignent_la_cOAlition_S]

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>rzpm9xptxaamtsq6edtzpo6ngudq33z</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Réponses à l’intelligence artificielle</title>
    <ns>0</ns>
    <id>82376</id>
    <revision>
      <id>745440</id>
      <parentid>745158</parentid>
      <timestamp>2025-06-26T23:35:01Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745440</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="37030" sha1="b2a5uuxwtdi7w4si3z0vwpgn3zh83jb" xml:space="preserve">''Ce rapport «&amp;#8239;Insights and Signals&amp;#8239;» a été rédigé par Brittany Amell (avec nos remerciements à John Willinsky, John Maxwell et William Bowen pour leurs commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

Les rapports'' «&amp;#8239;Policy Insights and Signals&amp;#8239;» ''scrutent l'horizon afin d'identifier et d'analyser les tendances émergentes et les signaux précurseurs susceptibles d'influer sur les orientations politiques futures en matière de libre accès et d'érudition ouverte et sociale. Ils ont tendance à mettre en évidence les changements dans la technologie, l'opinion et les sentiments du public, et/ou les changements réglementaires à l'intérieur et à l'extérieur du Canada. Tout comme les observations politiques de l'OSPO, les rapports sur les perspectives et les signaux visent à aider les partenaires à élaborer des stratégies proactives, réactives et tournées vers l'avenir.

Ce rapport'' Insights and Signals'' est le premier d'une série qui se concentre sur l'évolution des discussions centrées sur l'intelligence artificielle (IA), en particulier l'IA générative (genAI) et les grands modèles de langage (LLM), et sur les implications qu'elles peuvent avoir pour l'accès libre et la recherche sociale ouverte. 

D'autres rapports «&amp;#8239;Insights and Signals&amp;#8239;» consacrés à l'intelligence artificielle vous intéressent ? Vous les trouverez [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/L’IA générative et l’édition savante|ici]] et [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les agences fédérales de financement de la recherche annoncent un projet de lignes directrices sur l’utilisation de l’intelligence artificielle générative|ici]].

Les points abordés dans ce rapport sont les suivants

* Une brève introduction à l'intelligence artificielle générative, avec des commentaires de John Maxwell
* [https://www.consilium.europa.eu/fr/press/press-releases/2024/05/21/artificial-intelligence-ai-act-council-gives-final-green-light-to-the-first-worldwide-rules-on-ai/ La première loi mondiale sur l'intelligence artificielle] adoptée en mai 2024 par le Conseil de l'Union européenne.
* L'inclusion de l'intelligence artificielle dans la [https://www.parl.ca/legisinfo/fr/projet-de-loi/44-1/c-27 loi de mise en œuvre de la Charte numérique du Canada] (2022), ainsi que les critiques de [https://news.westernu.ca/2024/04/proposed-ai-legislation/ Joanna Redden] (2024), professeure associée à la faculté d'études sur l'information et les médias de l'université Western, de critique la législation proposée par le Canada en matière d'intelligence artificielle dans sa forme actuelle.
* Plusieurs réactions à l'IA au Canada de la part de revues, d'établissements postsecondaires, de sociétés savantes et d'organismes subventionnaires, ainsi que certaines préoccupations fondamentales soulevées par ces groupes.
* Une [https://www.pm.gc.ca/fr/nouvelles/communiques/2024/04/07/pour-avantage-canadien-matiere-dintelligence-artificielle annonce] du premier ministre Justin Trudeau (2024) concernant son intention de consacrer 2,4 milliards de dollars pour assurer un avantage canadien en matière d'intelligence artificielle
* Réponses des partenaires de l'INKE John Willinsky (fondateur du Public Knowledge Project) et John Maxwell (professeur associé d'édition à l'Université Simon Fraser)
* Certains silences discursifs proposés à prendre en considération, tels que les perspectives sur l[https://montrealethics.ai/in-consideration-of-indigenous-data-sovereignty-data-mining-as-a-colonial-practice/ 'extraction des données comme pratique,] et la [https://ubctoday.ubc.ca/news/june-06-2024/indigenous-data-stewardship-stands-against-extractivist-ai souveraineté des données autochtones ]

Ce rapport se termine par quelques questions et considérations clés.

'''Remarque : Nous vous présentons nos excuses en avance, car la plupart des sources mentionnées dans ce rapport sont disponibles en anglais uniquement.'''

==Présentation succincte de l'intelligence artificielle générative==
Les débats largement répandus sur l'avenir de l'intelligence artificielle et la nécessité de cadres éthiques et de politiques réglementaires pour atténuer les dommages potentiels, relancés en 2022 par la première version du système d'intelligence artificielle générative (IA) [https://chat.openai.com/auth/login ChatGPT] d'OpenAI, continuent de retenir l'attention des chercheurs et des médias. Les outils d'intelligence artificielle générative tels que ChatGPT et [https://www.bing.com/ Bing] de Microsoft (tous deux alimentés par GPT-4 d'OpenAI) et [https://gemini.google.com/ Gemini de Google] (Bard, précédemment) peuvent être utilisés pour générer de la poésie, des essais, du code, des traductions et des réponses à des examens, ainsi que des images et des vidéos.

Cependant, si ces outils ont un potentiel énorme, ils créent également des défis et, dans certains cas, des préjudices (par exemple, [https://datajusticelab.org/data-harm-record/ «&amp;#8239;Data Harm Record&amp;#8239;» par Redden et al. 2020] ; voir également, de manière générale, [https://mitpress.mit.edu/9780262548328/more-than-a-glitch/ Broussard 2024], Noble 2018 et O'Neil 2016). Selon Josh Nicholson, cofondateur et PDG de Scite.ai, le modèle de langage large Galactica de Meta pour la science a été «&amp;#8239;retiré en moins d'une semaine parce qu'il était si problématique. Vous pouviez lui donner des instructions et obtenir un article complet en retour, mais il pouvait être raciste ou complètement erroné&amp;#8239;» ([https://www.wiley.com/en-us/network/research-libraries/libraries-archives-databases/open-access/making-ai-an-opportunity-for-open-access cité dans Wiley 2024], 1).

L'intelligence artificielle générative, ou genAI comme nous l'appelons ici, est utilisée pour décrire des outils tels que ceux mentionnés ci-dessus, mais elle décrit en réalité un changement fondamental dans la conception des instructions qui peuvent être suivies pour accomplir une tâche, également connues sous le nom d'algorithmes (Danaher et al. 2017). Ce changement a entraîné l'abandon des algorithmes «&amp;#8239;descendants&amp;#8239;» (où les ensembles de règles pour les algorithmes étaient définis de manière exhaustive par les programmeurs) au profit d'algorithmes d'apprentissage automatique «&amp;#8239;ascendants&amp;#8239;» (où un algorithme est essentiellement formé pour développer son propre ensemble de règles). Les algorithmes d'apprentissage automatique consistent à donner à la machine des données, un objectif, un retour d'information pour lui indiquer qu'elle est sur la bonne voie, puis à lui laisser du temps pour trouver la meilleure façon de suivre les instructions et d'atteindre l'objectif (Fry 2018, p. 11). En d'autres termes, la genAI s'appuie sur l'utilisation de diverses techniques statistiques pour produire les résultats qui émerveillent nombre d'entre nous (Gorwa et al. 2020 ; [https://blogs.lse.ac.uk/politicsandpolicy/why-artificial-intelligence-is-a-misnomer/ Whiteley 2023]).

En effet, le poème que vous avez demandé à ChatGPT de générer est le résultat de calculs probabilistes qui sélectionnent les mots en fonction de leur probabilité de s'adapter (statistiquement) au contexte. Cela semble moins romantique, mais c'est peut-être important - John Maxwell (professeur associé d'édition à l'université Simon Fraser), partenaire d'INKE, le pense en tout cas.

Répondant à cet article par courriel, John Maxwell a écrit : «&amp;#8239;Je suis de plus en plus préoccupé par le fait qu'en réagissant (à la fois individuellement et collectivement, de manière causale et formelle) à l'essor de l'apprentissage en profondeur, du texte génératif et des technologies de l'image - en suivant l'exemple de l'industrie qui les ‹ IA › - nous jouons le jeu d'un groupe de promoteurs d'investissements très habiles et, en même temps, nous sabotons nos propres sensibilités critiques à l'égard des diverses innovations rassemblées sous ce parapluie&amp;#8239;». (Vous pouvez lire l'intégralité de la réponse de John Maxwell en défilant jusqu'à la section «&amp;#8239;Réponses du partenariat INKE&amp;#8239;» ci-dessous).

Maxwell n'est pas le seul à tirer la sonnette d'alarme. Dans un [https://blogs.lse.ac.uk/politicsandpolicy/why-artificial-intelligence-is-a-misnomer/ article] publié sur le blog de la l'École d'économie et de sciences politiques de Londres, Paul Whiteley affirme que «&amp;#8239;l’intelligence artificielle&amp;#8239;» est une appellation erronée, inventée par l'informaticien John McCarthy en 1950 (et anthropomorphisée par le reste d'entre nous depuis lors).

Même ChatGPT est d'accord. Lorsque nous avons demandé à ChatGPT s'il pensait que les utilisateurs avaient tendance à l'anthropomorphiser, il a généré le «&amp;#8239;résultat statistique&amp;#8239;» suivant :

&lt;blockquote&gt;
Oui, les gens m'anthropomorphisent souvent ! C'est tout à fait naturel ; le langage humain et l'interaction impliquent souvent des hypothèses sur des expériences, une compréhension ou des intentions partagées. Étant donné que mes réponses relèvent de la conversation et imitent les schémas du langage humain, les utilisateurs peuvent parfois m'attribuer des pensées, des sentiments ou des intentions, même si je n'ai pas d'expérience, de conscience ou de compréhension personnelle. La familiarité de la conversation peut faire oublier que les réponses proviennent de modèles plutôt que d'un sentiment intérieur. C'est fascinant parce que cela met en évidence à quel point les gens sont prêts à chercher une connexion, même avec une technologie qui est fondamentalement différente de l'esprit humain.
&lt;/blockquote&gt;

John Maxwell (professeur associé d'édition à l'université Simon Fraser et partenaire de l'INKE) nous met toutefois en garde contre cette anthropomorphisation, car elle rend difficile l'élaboration des réponses politiques significatives :

&lt;blockquote&gt;
Alors que, par exemple, «&amp;#8239;LLM&amp;#8239;» définit une technologie spécifique avec des caractéristiques spécifiques pour lesquelles nous pourrions développer une réponse politique cohérente, le terme «&amp;#8239;IA&amp;#8239;» est un fourre-tout de science-fiction qui comporte un ensemble de connotations utopiques, dystopiques et eschatologiques bien médiatisées (et monétisées). Il est peu probable que nous puissions apporter une réponse significative à un objet aussi mal défini. J'espère que, lorsque nous commencerons à élaborer des lignes directrices et des politiques, nous pourrons commencer à différencier ces technologies et à les désigner par leurs noms et fonctions spécifiques, au lieu de répéter le battage médiatique selon lequel ces boîtes noires massives, mystérieuses et appartenant à des entreprises, résoudront simultanément les problèmes de l'humanité tout en constituant une menace existentielle.
&lt;/blockquote&gt;

==L'UE annonce l'approbation de la première loi mondiale sur l'intelligence artificielle==
Sur le plan politique, le Conseil de l'UE [https://www.consilium.europa.eu/fr/press/press-releases/2024/05/21/artificial-intelligence-ai-act-council-gives-final-green-light-to-the-first-worldwide-rules-on-ai/ a officiellement approuvé] en mai dernier la [https://www.consilium.europa.eu/fr/press/press-releases/2024/05/21/artificial-intelligence-ai-act-council-gives-final-green-light-to-the-first-worldwide-rules-on-ai/ première loi mondiale sur l'intelligence artificielle.] La législation suivra une «&amp;#8239;approche fondée sur le risque, ce qui signifie que plus le risque de causer des dommages à la société est élevé, plus les règles sont strictes&amp;#8239;», explique le Conseil dans un [https://www.consilium.europa.eu/en/press/press-releases/2024/05/21/artificial-intelligence-ai-act-council-gives-final-green-light-to-the-first-worldwide-rules-on-ai/ communiqué de presse].

«&amp;#8239;Avec la législation sur l'IA, l'Europe souligne l'importance de la confiance, de la transparence et de l'obligation de rendre des comptes pour ce qui est des nouvelles technologies, tout en veillant dans le même temps à ce que cette technologie en évolution rapide puisse prospérer et stimuler l'innovation européenne&amp;#8239;», déclare Mathieu Michel, Secrétaire d'État fédéral belge à la Digitalisation, chargé de la Simplification administrative, de la Protection de la vie privée et de la Régie des bâtiments ([https://www.consilium.europa.eu/fr/press/press-releases/2024/05/21/artificial-intelligence-ai-act-council-gives-final-green-light-to-the-first-worldwide-rules-on-ai/ Conseil, 2024]).

Quatre organes directeurs, dont «&amp;#8239;un groupe scientifique d'experts indépendants&amp;#8239;», seront chargés de veiller à l'application de la loi sur l'IA. Trois autres organes comprennent un bureau de l'IA au sein de la Commission européenne, un forum consultatif pour les parties prenantes et un conseil de l'IA composé de représentants des États membres ([https://www.consilium.europa.eu/fr/press/press-releases/2024/05/21/artificial-intelligence-ai-act-council-gives-final-green-light-to-the-first-worldwide-rules-on-ai/ Conseil, 2024]).

==Vers une réglementation de l'intelligence artificielle au Canada?==
''' '''Au Canada, l'inclusion de l'intelligence artificielle dans le projet de la loi C-27 (Loi de 2022 sur la mise en œuvre de la Charte du numérique) fait toujours l'objet d'un examen en comité à la Chambre des communes depuis sa deuxième lecture il y a plus d'un an, en avril 2023.

[https://news.westernu.ca/2024/04/proposed-ai-legislation/ Selon Joanna Redden] (2024), professeure à la faculté d'études sur l'information et les médias de l'Université Western, qui critique la législation canadienne sur l'IA proposée dans sa forme actuelle, de nombreux Canadiens ont déjà peu confiance dans l'utilisation croissante de l'IA, même si [https://medium.com/politics-ai/an-overview-of-national-ai-strategies-2a70ec6edfd le Canada a été le premier pays à introduire une stratégie nationale en matière d'IA]. Faisant écho aux préoccupations de personnes telles qu'[https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4658004 Andrew Clement] (professeur émérite, Université de Toronto), ainsi que [https://www.amo-oma.ca/en/ai-policy-report/ McKelvey et ses collègues (2024]), Redden suggère que cette méfiance est due, en partie, à un manque de consultation publique significative, «&amp;#8239;en dépit des préoccupations profondes du public&amp;#8239;». Redden note que la législation proposée est non seulement «&amp;#8239;déjà en décalage avec les besoins des Canadiens&amp;#8239;», mais qu'elle est également «&amp;#8239;en deçà des approches réglementaires adoptées par d'autres nations&amp;#8239;», telles que celle récemment approuvée par [https://www.consilium.europa.eu/fr/press/press-releases/2024/05/21/artificial-intelligence-ai-act-council-gives-final-green-light-to-the-first-worldwide-rules-on-ai/ l'Union européenne] ou le [https://www.whitehouse.gov/briefing-room/presidential-actions/2023/10/30/executive-order-on-the-safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence/ décret publié par la Maison Blanche] en 2023.

Certains des besoins identifiés par Redden incluent la garantie que les utilisations de l’IA par les entreprises et les gouvernements sont transparentes et qu’il existe des mécanismes efficaces pour maintenir la surveillance et la responsabilité. En outre, Redden soutient qu’il est essentiel de consacrer des fonds pour garantir le maintien des «&amp;#8239;registres d’IA&amp;#8239;» publics. En outre, Joanna Redden estime qu'il est essentiel de consacrer des fonds à la tenue de «registres d'IA&amp;#8239;» publics (note : les registres d'IA, [https://tagcanada.shinyapps.io/register/ tels que celui mis au point par Redden et ses collègues], permettent de savoir où et comment l'IA et d'autres systèmes automatisés sont utilisés).

Si elle est adoptée, la [https://www.parl.ca/legisinfo/fr/projet-de-loi/44-1/c-27 Loi de 2022 sur la mise en œuvre de la Charte du numérique] (également connue sous le nom de «&amp;#8239;loi édictant la loi sur la protection de la vie privée du consommateur, la loi sur le Tribunal de la protection des renseignements personnels et des données et la loi sur l'intelligence artificielle et les données, et apportant des modifications corrélatives et connexes à d'autres lois&amp;#8239;») serait la première loi axée sur la réglementation de l'IA au Canada.

Actuellement, les gestionnaires et les développeurs d'IA générative au Canada sont invités à s'engager volontairement à [https://ised-isde.canada.ca/site/ised/en/voluntary-code-conduct-responsible-development-and-management-advanced-generative-ai-systems respecter ]un [https://ised-isde.canada.ca/site/isde/fr/code-conduite-volontaire-visant-developpement-gestion-responsables-systemes-dia-generative-avances Code de conduite volontaire visant un développement et une gestion responsables des systèmes d'IA générative avancés]. Ce code de conduite volontaire met l'accent sur six résultats : la responsabilité, la sécurité, la justice et l'équité, la transparence, la surveillance humaine et le suivi, ainsi que la validité et la robustesse.

==Réponses des revues, des établissements d'enseignement postsecondaire, des sociétés savantes et des organismes subventionnaires à l'IA au Canada==
Dans le but de freiner l'utilisation abusive de l'IA générative, '''plusieurs revues '''(voir [https://www.cmaj.ca/content/195/34/E1168 ici], [https://www.caaa.ca/fr/ ici] et [https://www.jogc.com/article/S1701-2163(23)00167-6/fulltext ici]), '''établissements d'enseignement postsecondaire '''(voir [https://uwaterloo.ca/information-systems-technology/about/policies-standards-and-guidelines/guidance-artificial-intelligence-use ici] et [https://www.senecapolytechnic.ca/about/policies/generative-ai-policy.html ici] pour des exemples, ainsi qu'[https://cdlra-acrfl.ca/wp-content/uploads/2024/05/2023-AI-Special-Topics-Report.pdf ici] pour un commentaire plus général et [https://higheredstrategy.com/ai-observatory-home/ ici] pour l'observatoire de HESA sur l'IA dans le secteur postsecondaire au Canada), '''associations savantes '''(voir [https://publicationethics.org/guidance/cope-position/authorship-and-ai-tools ici] et [https://www.carl-abrc.ca/wp-content/uploads/2023/12/Generative-Artificial-Intelligence-A-Brief-Primer-FR.pdf ici]) et '''organismes subventionnaires '''(en savoir plus [https://science.gc.ca/site/science/fr/financement-interorganismes-recherche/politiques-lignes-directrices/lutilisation-lintelligence-artificielle-generative-dans-lelaboration-levaluation-propositions ici] et [https://ospolicyobservatory.uvic.ca/trois-organismes-ia/ ici]) sont en train d'élaborer et de publier des déclarations, des politiques et/ou des lignes directrices qui définissent les attentes concernant ce qui est considéré comme une utilisation équitable ou responsable de l'IA dans leurs contextes respectifs.

Les préoccupations relatives à la responsabilité, à la paternité, à la transparence, à la divulgation de l'utilisation, à la responsabilité, à l'exactitude, à la partialité, à la sécurité, à la confidentialité et à la vie privée, ainsi qu'aux droits d'auteur et à la propriété intellectuelle reviennent constamment dans ces déclarations, politiques et lignes directrices. Plusieurs revues ainsi que de grands éditeurs tels que SAGE, Elsevier et Wiley interdisent explicitement de citer un outil d'IA (tel que ChatGPT) comme auteur car, comme l'écrit Tulandi (2023) dans une revue médicale canadienne, «&amp;#8239;la qualité d'auteur implique des responsabilités et des tâches qui ne peuvent être attribuées et exécutées que par des êtres humains&amp;#8239;» (paragraphe 7).

Outre les préoccupations soulevées ci-dessus, l'ABRC, ou l'[https://www.carl-abrc.ca/wp-content/uploads/2023/12/Generative-Artificial-Intelligence-A-Brief-Primer-FR.pdf Association des bibliothèques de recherche du Canada (2023)], recommande que les réponses à l'IA générative tiennent également compte des impacts sociaux associés à l'utilisation de l'IA, notamment qui a accès aux outils d'IA générative et qui n'y a pas accès, que ce soit pour des raisons financières ou autres. [https://blog.core.ac.uk/2023/03/17/core-gpt-combining-open-access-research-and-ai-for-credible-trustworthy-question-answering/ Citant les travaux d'un groupe de chercheurs associés à l'Open University au Royaume-Uni], l'ABRC (2023) se demande également si la combinaison d'articles en libre accès et d'articles payants dans le développement d'ensembles de données utilisés pour former l'IA générative pourrait améliorer sa fiabilité et sa crédibilité, bien qu'elle note également le risque d'implications juridiques.

Alors que les débats relatifs à la loi de mise en œuvre de la Charte numérique se poursuivent, le Premier ministre Justin Trudeau (2024) a [https://www.pm.gc.ca/fr/nouvelles/communiques/2024/04/07/pour-avantage-canadien-matiere-dintelligence-artificielle annoncé son intention] de consacrer 2,4 milliards de dollars à la «&amp;#8239;sécurisation de l'avantage du Canada en matière d'IA&amp;#8239;», bien qu'il soit intéressant de noter que seulement 2 % de ce financement (50 millions de dollars) est destiné à l'exploration des impacts sociaux associés à l'utilisation accrue de l'IA.

==Questions et considérations clés==
Les idées et les signaux décrits ci-dessus indiquent que les développements récents de l'IA générative, ainsi que son intégration continue dans divers contextes académiques (et plus largement dans la société), posent des défis importants aux personnes impliquées dans l'élaboration des réponses politiques.

En même temps, même s'il est important de prêter attention aux réponses existantes, les silences discursifs ou les absences (c'est-à-dire ce qui n'est '''pas '''dit, ou peut-être ce qui '''n'est pas '''amplifié et repris dans les rapports sur ce sujet) sont tout aussi importants et méritent d'être pris en considération.

Parmi les absences notables proposées, citons la question de savoir si l'utilisation du contenu en ligne par les LLM est considérée comme une utilisation équitable (ainsi que d'autres considérations relatives au droit d'auteur). D'autres absences importantes concernent l'impact social et écologique des grands modèles de langage (LLM) et les matériaux, la main-d'œuvre et la puissance de calcul nécessaires pour les maintenir – en parallèle avec les conversations sur la durabilité dans les humanités numériques (comme [https://doi.org/10.1093/llc/fqab025 celle] de Johanna Drucker 2021 ou [https://www.thebritishacademy.ac.uk/publishing/journal-british-academy/10/facing-the-challenge-of-digital-sustainability-as-humanities-researchers/ celle] de Joanna Tucker 2022). D'autres incluent les implications des LLM pour les souverainetés des données Autochtone ([https://www.unesco.org/fr/articles/un-nouveau-rapport-et-des-lignes-directrices-pour-maintenir-la-souverainete-des-donnees-autochtones l'UNESCO publie un nouveau rapport et des lignes directrices pour maintenir la souveraineté des données autochtones qui s’inscrivent dans les développements de l'intelligence artificielle]), ainsi que les implications que les souverainetés (des données) autochtone peuvent avoir pour la réflexion sur «&amp;#8239;l’IA éthique&amp;#8239;» (Gaertner 2024 ; Roberts and Montoya 2024).

Par exemple, en réfléchissant à l'intersection entre les nouvelles formes d'[https://www.arts.ubc.ca/news/indigenous-data-stewardship-stands-against-extractivist-ai/ IA et la souveraineté et la gestion des données autochtones], le professeur associé David Gaertner (Institute for Critical Indigenous Studies, UBC) établit d'autres liens entre l'IA formée sur de grands modèles linguistiques et les impacts du colonialisme de peuplement :

&lt;blockquote&gt;
Les technologies de l'IA, formées sur de grands modèles linguistiques, reflètent la privation des droits et la violence imposées par le colonialisme de peuplement tout en les redistribuant à l'échelle. Les algorithmes institutionnalisent une dynamique de pouvoir dans laquelle les récits linguistiques et culturels dominants sont davantage ancrés et amplifiés dans l'infrastructure sociale, tandis que l'expression personnelle devient de plus en plus obsolète et marginale. L'émergence des rapports détaillant la manière dont l'internet se cannibalise actuellement et génère de nouveaux contenus d'IA à partir de matériaux d'IA existants, également connue sous le nom de «&amp;#8239;[https://en.wikipedia.org/wiki/Dead_Internet_theory théorie de l'Internet Mort]&amp;#8239;», amplifie encore ces préoccupations.
&lt;/blockquote&gt;

Cependant, nombreux sont ceux qui soulignent que les questions relatives au développement et à l'utilisation éthiques de l'IA sont souvent adressées aux entreprises privées et aux organisations qui utilisent leurs modèles. Qu'en est-il des membres de la communauté, des universitaires et des parties prenantes ? L'IA restera-t-elle uniquement entre les mains des entreprises privées et des sociétés à but lucratif ?

Pas nécessairement. Certains commencent à explorer des approches de l'apprentissage automatique fondées sur les biens communs, comme [https://openfuture.eu/our-work/ai-and-the-commons/ Open Future, une] organisation à but non lucratif basée en Europe qui souhaite étudier les risques et les avantages potentiels associés aux nouveaux cadres de partage des modèles d'IA sous licence libre. Le commentaire suivant, que John Willinsky (fondateur du Public Knowledge Project et partenaire de l'INKE) a partagé avec nous, va dans le même sens :

&lt;blockquote&gt;
Bien qu'il y ait des raisons de s'inquiéter des récentes avancées de l'IA, les universitaires ont également la responsabilité d'explorer les contributions et les avancées potentielles de l'IA pour la recherche et l'érudition. Depuis un certain temps, le [https://pkp.sfu.ca/ Public Knowledge Project] se tourne vers l'IA pour résoudre les problèmes urgents liés à l'équité et à la qualité des ressources dans les communications savantes, avec un succès limité. Il mène actuellement des recherches sur la capacité des grands modèles de langage à relever le défi de longue date que représente le développement d'un moyen durable pour les revues accès libre diamant de publier dans les formats standard HTML et PDF, ainsi que d'exporter des fichiers en JATS XML. (Le commentaire de John Willinsky peut être lu dans son intégralité ci-dessous).
&lt;/blockquote&gt;

Il est intéressant de noter que plusieurs modèles d'IA ont [https://www.forbes.com/sites/bernardmarr/2024/05/07/the-best-open-source-generative-ai-models-available-today/ déjà été publiés] sous la [https://www.apache.org/licenses/LICENSE-2.0 licence Apache 2.0] (une licence de logiciel permissive qui autorise l'utilisation du logiciel à toutes fins, y compris la distribution, la modification et la distribution de versions modifiées sans redevances, selon [https://en.wikipedia.org/wiki/Apache_License Wikipédia]), et d'autres pourraient être publiés avant la fin de l'année (des [https://www.theverge.com/2024/10/24/24278999/openai-plans-orion-ai-model-release-december rumeurs ]indiquent qu'OpenAI publiera son dernier modèle, «&amp;#8239;Orion&amp;#8239;», en décembre 2024).

==Réponses du partenariat INKE==
''Réponse de John Willinsky (Fondateur, Public Knowledge Project) :''
&lt;blockquote&gt;
Bien qu'il y ait des raisons de s'inquiéter des récentes avancées de l'IA, les universitaires ont également la responsabilité d'explorer les contributions et les avancées potentielles de l'IA pour la recherche et l'érudition. Depuis un certain temps, le [https://pkp.sfu.ca/ Public Knowledge Project] se tourne vers l'IA pour résoudre les problèmes urgents liés à l'équité et à la qualité des ressources dans les communications savantes, avec un succès limité. Il mène actuellement des recherches sur la capacité des grands modèles de langage à relever le défi de longue date que représente le développement d'un moyen durable pour les revues Diamond OA de publier dans les formats standard HTML et PDF, ainsi que d'exporter des fichiers en JATS XML. L'objectif principal de ce travail est d'établir si les LLM peuvent être suffisamment adaptés pour automatiser de manière fiable le balisage HTML et JATS XML des manuscrits des auteurs (étant donné que ce balisage nécessite actuellement des compétences techniques ou des paiements qui dépassent la capacité de la plupart des revues Diamond OA). Ce travail a atteint le stade initial de la preuve de concept, et les travaux se poursuivent sur sa valeur comparative (par rapport à d'autres outils) et sur les moyens d'intégrer et de maintenir un tel service de balisage dans le flux de travail éditorial.
&lt;/blockquote&gt;

''Réponse de John Maxwell (professeur associé d'édition à l'université Simon Fraser) :''
&lt;blockquote&gt;
Je crains de plus en plus qu'en réagissant (à la fois individuellement et collectivement, de manière causale et formelle) à l'essor des technologies d'apprentissage en profondeur, de texte génératif et d'image - en suivant l'exemple de l'industrie qui les appelle «&amp;#8239;IA&amp;#8239;» - nous fassions le jeu d'un groupe de promoteurs d'investissements très habiles et que nous minions en même temps notre propre sensibilité critique à l'égard des diverses innovations rassemblées sous cette égide. Le terme «&amp;#8239;IA&amp;#8239;» sert depuis plusieurs décennies déjà de marque d'aspiration pour une grande variété de technologies informatiques. Aujourd'hui, c'est le nom de marque d'un investissement massif de capitaux finançant une collection d'approches disparates d'apprentissage profond : LLM, modèles de diffusion, systèmes de reconnaissance faciale et autres outils. Il s'agit de technologies spécifiques qui existent et qui ont un impact sur les études et le travail. Mais alors que, par exemple, «&amp;#8239;LLM&amp;#8239;» définit une technologie spécifique avec des caractéristiques spécifiques pour lesquelles nous pourrions développer une réponse politique cohérente, le terme «&amp;#8239;IA&amp;#8239;» est un fourre-tout de science-fiction qui porte avec lui un ensemble de connotations utopiques, dystopiques et eschatologiques bien médiatisées (et monétisées). Il est peu probable que nous puissions apporter une réponse significative à un objet aussi mal défini. J'espère que, lorsque nous commencerons à élaborer des lignes directrices et des politiques, nous pourrons commencer à différencier ces technologies et à les désigner par leurs noms et fonctions spécifiques, au lieu de répéter le battage médiatique selon lequel ces boîtes noires massives, mystérieuses et appartenant à des entreprises résoudront simultanément les problèmes de l'humanité tout en constituant une menace existentielle. Il semblerait que les investisseurs en capital-risque et les hommes du battage médiatique nous aient devancés sur la ligne de départ ; nous devons rapidement mettre en place un appareil critique (par exemple, des études scientifiques et technologiques) pour l'analyse et l'élaboration de politiques et de lignes directrices efficaces.
&lt;/blockquote&gt;

==Références==
*Association bibliothèques de recherche du Canada. 2023. «&amp;#8239;Intelligence artificielle générative : Une brève introduction pour les établissements de l’ABRC&amp;#8239;». [https://www.carl-abrc.ca/wp-content/uploads/2023/12/Generative-Artificial-Intelligence-A-Brief-Primer-FR.pdf https://www.carl-abrc.ca/wp-content/uploads/2023/12/Generative-Artificial-Intelligence-A-Brief-Primer-FR.pdf].

*Broussard, Meredith. 2024. ''More than a Glitch: Confronting Race, Gender, and Ability Bias in Tech''. First MIT Press paperback edition. Cambridge, Massachusetts and London, England: The MIT Press.

*«&amp;#8239;C-27 (44-1) : Loi édictant la Loi sur la protection de la vie privée des consommateurs, la Loi sur le Tribunal de la protection des renseignements personnels et des données et la Loi sur l'intelligence artificielle et les données et apportant des modifications corrélatives et connexes à d'autres lois&amp;#8239;». Parlement du Canada. Consulté le 30 octobre 2024. [https://www.parl.ca/legisinfo/fr/projet-de-loi/44-1/c-27 https://www.parl.ca/legisinfo/fr/projet-de-loi/44-1/c-27]

*Drucker, Johanna. 2021. «&amp;#8239;Sustainability and Complexity: Knowledge and Authority in the Digital Humanities&amp;#8239;». ''Digital Scholarship in the Humanities'' 36 (2): ii86–ii94. [https://doi.org/10.1093/llc/fqab025 https://doi.org/10.1093/llc/fqab025].

*Fitzpatrick, Kathleen. 2024. «&amp;#8239;Open Infrastructures for the Future of Knowledge Production&amp;#8239;». Keynote presented at ''Creative Approaches to Open Social Scholarship: Canada (An Implementing New Knowledge Environments (INKE) Partnership Gathering)''. Montreal, Canada.[https://doi.org/10.25547/6GG1-7B37  https://doi.org/10.25547/6GG1-7B37].

*Fry, Hannah. 2019. ''Hello World: Being Human in the Age of Algorithms''. New York: W.W. Norton &amp; Company.

*Gaertner, David. 2024. «&amp;#8239;Indigenous Data Stewardship Stands against Extractivist AI&amp;#8239;». ''UBC Faculty of Arts'' (blog). 18 juin 2024. [https://www.arts.ubc.ca/news/indigenous-data-stewardship-stands-against-extractivist-ai/ https://www.arts.ubc.ca/news/indigenous-data-stewardship-stands-against-extractivist-ai/]

*Gorwa, Robert, Reuben Binns, and Christian Katzenbach. 2020. «&amp;#8239;Algorithmic Content Moderation: Technical and Political Challenges in the Automation of Platform Governance&amp;#8239;». ''Big Data &amp; Society'' 7 (1): 2053951719897945. [https://doi.org/10.1177/2053951719897945 https://doi.org/10.1177/2053951719897945].

*McKelvey, Fenwick, Sophie Toupin, and Maurice Jones. 2024. «&amp;#8239;Introduction&amp;#8239;». In ''Northern Lights and Silicon Dreams: AI Governance in Canada (2011-2022)'', edited by Fenwick McKelvey, Johnathan Roberge, and Sophie Toupin, 7–30. Montreal, Canada: Shaping AI. [https://www.amo-oma.ca/wp-content/uploads/2024/04/ORA-CA-Policy.pdf https://www.amo-oma.ca/wp-content/uploads/2024/04/ORA-CA-Policy.pdf].

*Noble, Safiya Umoja. 2018. ''Algorithms of Oppression: How Search Engines Reinforce Racism''. New York: New York University Press.

*O’Neil, Cathy. 2017. ''Weapons of Math Destruction: How Big Data Increases Inequality and Threatens Democracy''. New York: Crown.

*Pride, David. 2023. «&amp;#8239;CORE-GPT: Combining Open Access Research and AI for Credible, Trustworthy Question Answering&amp;#8239;». ''CORE'' (blog). 17 mars 2023. [https://blog.core.ac.uk/2023/03/17/core-gpt-combining-open-access-research-and-ai-for-credible-trustworthy-question-answering/ https://blog.core.ac.uk/2023/03/17/core-gpt-combining-open-access-research-and-ai-for-credible-trustworthy-question-answering/].

*Redden, Joanna, Jessica Brand, and Vanesa Terzieva. 2020. «&amp;#8239;Data Harm Record&amp;#8239;». Data Justice Lab. 2020. [https://datajusticelab.org/data-harm-record/ https://datajusticelab.org/data-harm-record/].

*Redden, Joanna. 2024. «&amp;#8239;Canada’s AI Legislation Misses the Mark&amp;#8239;». ''Western News'' (blog). 12 avril 2024. [https://news.westernu.ca/2024/04/proposed-ai-legislation/ https://news.westernu.ca/2024/04/proposed-ai-legislation/].

*Roberts, Jennafer Shae, and Laura N. Montoya. 2023. «&amp;#8239;In Consideration of Indigenous Data Sovereignty: Data Mining as a Colonial Practice&amp;#8239;». In ''Proceedings of the Future Technologies Conference (FTC) 2023, Volume 2'', edited by Kohei Arai, 180–96. Cham: Springer Nature Switzerland. [https://doi.org/10.1007/978-3-031-47451-4_13 https://doi.org/10.1007/978-3-031-47451-4_13].

*Roberts, Jennafer Shae. 2024. «&amp;#8239;In Consideration of Indigenous Data Sovereignty: Data Mining as a Colonial Practice&amp;#8239;». ''Montreal AI Ethics Institute'' (blog). 23 janvier 2024. [https://montrealethics.ai/in-consideration-of-indigenous-data-sovereignty-data-mining-as-a-colonial-practice/ https://montrealethics.ai/in-consideration-of-indigenous-data-sovereignty-data-mining-as-a-colonial-practice/].

*Tucker, Joanna. 2022. «&amp;#8239;Facing the Challenge of Digital Sustainability as Humanities Researchers&amp;#8239;». ''Journal of the British Academy'', 10: 93–120. [https://doi.org/10.5871/jba/010.093 https://doi.org/10.5871/jba/010.093].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>b2a5uuxwtdi7w4si3z0vwpgn3zh83jb</sha1>
    </revision>
  </page>
  <page>
    <title>Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/L’IA générative et l’édition savante</title>
    <ns>0</ns>
    <id>82377</id>
    <revision>
      <id>745442</id>
      <parentid>745159</parentid>
      <timestamp>2025-06-26T23:45:28Z</timestamp>
      <contributor>
        <username>LodestarChariot2</username>
        <id>120009</id>
      </contributor>
      <minor />
      <comment>Liens mis à jour</comment>
      <origin>745442</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22636" sha1="gs0zaea0fy58eyijd30jxouqd75a8zz" xml:space="preserve">''Ce rapport « Insights and Signals » a été rédigé par Brittany Amell (avec nos remerciements à John Willinsky, John Maxwell et William Bowen pour leurs commentaires et contributions), pour le Electronic Textual Cultures Laboratory et le partenariat Implementing New Knowledge Environments.''

==Résumé==
Les rapports'' «&amp;#8239;Policy Insights and Signals&amp;#8239;» ''scrutent l’horizon afin d’identifier et d’analyser les tendances émergentes et les signaux précurseurs susceptibles d’influer sur les orientations politiques futures en matière de libre accès et d’érudition ouverte et sociale. Ils ont tendance à mettre en évidence les changements dans la technologie, l’opinion et les sentiments du public, et/ou les changements réglementaires à l’intérieur et à l’extérieur du Canada. Tout comme les observations politiques de l’OSPO, les rapports sur les perspectives et les signaux visent à aider les partenaires à élaborer des stratégies proactives, réactives et tournées vers l’avenir.

Ce rapport sur les perspectives et les signaux poursuit l'examen par l'OSPO de l'évolution du dialogue sur les implications de l'IA générative pour les bourses d'études ouvertes et l'édition en libre accès. «&amp;#8239;L'IA générative fait référence à une classe d'algorithmes qui guident la création de divers types de contenu ([https://sites.broadviewpress.com/ai/talking/ Dobrin, 2023]). Parfois évoquée dans le même temps que [https://chatgpt.com/ ChatGPT], [https://openai.com/index/dall-e-2/ DALL-E 2] ou [https://gemini.google.com/ Gemini], nous commençons déjà à voir l'impact de l'IA générative sur l'édition savante, malgré son introduction relativement récente.

Compte tenu de l'intérêt croissant pour les implications de l'IA générative pour le libre accès et la communication savante en général, ce rapport s'articule autour des discussions récentes sur les risques et les opportunités potentiels pour le secteur. Vous êtes intéressé par d’autres rapports «&amp;#8239;Insights and Signals&amp;#8239;» consacrés à l’IA ? Vous les trouverez [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Les agences fédérales de financement de la recherche annoncent un projet de lignes directrices sur l’utilisation de l’intelligence artificielle générative|ici]] ou [[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Réponses à l’intelligence artificielle|ici]].

Les points abordés dans ce rapport sont les suivants :

* [https://sr.ithaka.org/blog/generative-ai-and-scholarly-publishing/ Une annonce récente] d'Ithaka S+R concernant un nouveau projet de recherche axé sur l'IA générative et l'édition savante.
* [https://scholarlykitchen.sspnet.org/2024/06/06/guest-post-doajs-role-in-supporting-trust-in-scholarly-journals-current-challenges-and-future-solutions/ Un article invité de] Shen et Ball (DOAJ) sur le Scholarly Kitchen concernant l'augmentation du nombre d'articles rétractés et la crise de confiance envers les revues en libre accès dans un contexte d'innovations en matière d'IA générative.
* Une [https://www.coalition-s.org/towards-responsible-publishing/ proposition de] la cOAlition S concernant l'édition responsable
* Les applications potentielles des principes FAIR à l'élaboration de politiques en réponse à l'IA générative, ainsi que le chevauchement entre ces principes et ceux mentionnés dans un [https://research-and-innovation.ec.europa.eu/document/2b6cf7e5-36ac-41cb-aab5-0d32050143dc_en récent guide sur l'utilisation responsable de l'IA] dans la recherche publié par la direction générale de la recherche et de l'innovation de la Commission européenne.
* Le [https://doi.org/10.1590/SciELOPreprints.6799 Publication Facts Label] (PFL - également : [https://pkp.sfu.ca/2024/05/06/pkp-publication-facts-label/ ici]), ainsi qu'une [https://pkp.sfu.ca/2024/09/06/announcing-publication-facts-label-for-ojs/ annonce récente du Public Knowledge Project] concernant l'essai du PFL pour les revues fonctionnant avec OJS (v 3.3 ou plus).

'''''Remarque : Nous vous présentons nos excuses en avance, car la plupart des sources mentionnées dans ce rapport sont disponibles en anglais uniquement.'''''

==Le groupe de recherche sur l'édition savante annonce un nouveau projet explorant les implications de l'IA générative==
Le groupe de recherche [https://sr.ithaka.org/about/ Ithaka S+R] a récemment annoncé son [https://sr.ithaka.org/blog/generative-ai-and-scholarly-publishing/ intention d'entreprendre un nouveau projet de recherche axé sur l'IA générative et l'édition savante :] «&amp;#8239;L'évolution rapide des besoins et des attentes des utilisateurs, le potentiel de l'IA générative pour atténuer les défis systémiques tenaces dans le secteur de l'édition savante, et la prise de conscience des risques que l'IA générative fait peser sur les connaissances des experts exigent que nous trouvions le temps de réfléchir en profondeur à ce que l'IA générative ''signifie ''pour l'édition savante commesecteur et à sa valeur en tant que composante de l'infrastructure partagée qui soutient la recherche et les communications savantes et scientifiques&amp;#8239;» (Ruediger et Bergstrom, 2024). Ce projet examinera les opportunités, les risques et les implications stratégiques que l'IA générative pourrait avoir pour l'édition savante. Il s'appuie sur l'étude d'Ithaka S+R de 2023, «&amp;#8239;[https://sr.ithaka.org/publications/the-second-digital-transformation-of-scholarly-publishing/ The Second Digital Transformation of Scholarly Publishing]&amp;#8239;», qui examinait les besoins partagés en matière d'infrastructures de communication savante à la lumière des transformations numériques (Bergstrom, Rieger et Schonfeld, 2024).

Comme l'écrivent Shen et Ball (2024) [https://scholarlykitchen.sspnet.org/2024/06/06/guest-post-doajs-role-in-supporting-trust-in-scholarly-journals-current-challenges-and-future-solutions/ dans leur article invité pour The Scholarly Kitchen,] bien que les menaces à la confiance et à la crédibilité aient toujours été au centre des préoccupations d'organisations telles que le Directory of Open Access Journals (DOAJ), ces menaces sont devenues encore plus urgentes. Constatant une augmentation du nombre d'articles rétractés, qui a atteint le chiffre record de 10 000 en 2023, Shen et Ball (2024) expliquent qu'il est devenu nécessaire de prendre des mesures supplémentaires pour préserver la confiance et la crédibilité à l'ère de l'IA générative.

Pour le DOAJ, l'une de ces mesures a consisté à former une équipe chargée d'enquêter sur les «&amp;#8239;cas présumés de pratiques douteuses&amp;#8239;». Ces pratiques douteuses sont signalées soit par des membres de la communauté du DOAJ au sens large, soit par ceux qui participent au processus d'évaluation de la demande d'inclusion d'une revue dans le DOAJ. Une fois le signalement effectué, les membres de l'équipe examinent de près les articles publiés par la revue, ainsi que la composition et la compétence de son comité de rédaction, ses pratiques d'évaluation par les pairs et d'autres facteurs.

«&amp;#8239;Comme les pratiques prédatrices continuent d'évoluer, nos enquêtes deviennent de plus en plus complexes&amp;#8239;», écrivent Shen et Ball (2024). «&amp;#8239;Nous consultons parfois des experts externes en la matière pour obtenir leurs conseils. Rien qu'en 2023, nous avons mené un total de 409 enquêtes sur des revues et des éditeurs, dont beaucoup ont abouti à des exclusions du DOAJ d'au moins un an&amp;#8239;».

Aider les éditeurs et le public à évaluer la crédibilité d'une publication est une chose à laquelle les membres du Public Knowledge Project (PKP) ont beaucoup réfléchi. Le Publication Facts Label, conceptualisé à l'origine par John Willinsky (fondateur du Public Knowledge Project et présenté plus en détail [https://pkp.sfu.ca/2024/05/06/pkp-publication-facts-label/ ici] et [https://doi.org/10.1590/SciELOPreprints.6799 ici]), en est un exemple. Basé sur le Nutrition Facts Label - ce tableau bien connu que l'on trouve sur les emballages alimentaires au Canada et aux États-Unis - le Publication Facts Label (ou PFL en abrégé) regroupe huit normes en un guide facile à consulter que les plateformes d'édition peuvent utiliser pour présenter l'intégrité d'une publication à un large public (Willinsky et Pimental). PKP [https://pkp.sfu.ca/2024/09/06/announcing-publication-facts-label-for-ojs/ a récemment annoncé] la mise à l'essai du Publication Facts Label pour les revues utilisant l'Open Journal Systems (v 3.3 ou plus). En installant un plug-in, comme expliqué [https://pkp.sfu.ca/2024/09/06/announcing-publication-facts-label-for-ojs/ ici], le PFL peut être affiché automatiquement sur la page d'accueil d'un article.

==La cOAlition S élabore une proposition de publication responsable==
Alors qu'Ithaka S+R se prépare à avancer dans son projet, la [https://www.coalition-s.org/about/ cOAlition S] (associée au [https://www.coalition-s.org/why-plan-s/ Plan S)] a terminé la phase de consultation de sa proposition intitulée «&amp;#8239;[https://www.coalition-s.org/towards-responsible-publishing/ Vers une édition responsable]&amp;#8239;».

«&amp;#8239;Poussés par le même ‹ devoir de diligence pour le bon fonctionnement du système scientifique › qui a inspiré le Plan S, les bailleurs de fonds qui forment la cOAlition S explorent maintenant une nouvelle vision de la communication savante ; une vision qui promet d'être plus efficace, plus abordable et plus équitable, pour finalement bénéficier à la société dans son ensemble&amp;#8239;», écrivent Bodo Stern (chef des initiatives stratégiques à l'Howard Hughes Medical Institute) et Johan Rooryck (directeur exécutif de la cOAlition S) dans un [https://www.coalition-s.org/blog/introducing-the-towards-responsible-publishing-proposal-from-coalition-s/ billet de blog annonçant la proposition.] La cOAlition S a révisé la proposition sur la base des commentaires reçus entre novembre 2023 et avril 2024, et a partagé la proposition révisée avec une réunion des bailleurs de fonds du cOAlition S en juin.

Les réactions à la proposition ont été rendues publiques par cOAlitionS [https://zenodo.org/records/11243942 ici.]

La proposition «&amp;#8239;Vers une publication responsable&amp;#8239;» met en avant un ensemble de principes qui peuvent être utilisés pour guider les décisions concernant la manière de soutenir «&amp;#8239;la diffusion de la recherche de manière responsable, équitable et durable&amp;#8239;» (Stern et al. 2023, 2) - une phrase qui évoque les priorités clés nommées dans l[https://eua.eu/downloads/publications/eua%20os%20agenda.pdf 'Agenda de la science ouverte 2025 de l'Association européenne des universités]. L'Open Science Agenda de l'Association, qui a été publié en février 2022 en prévision de la conférence et de l'assemblée générale qui se tiendront en 2025-2026, énonce plusieurs priorités et objectifs, dont celui de faire en sorte que toutes les universités européennes fassent partie d'un «&amp;#8239;écosystème d'édition savante juste&amp;#8239;» d'ici à 2025 ([https://www.scienceeurope.org/media/yg3ho4tp/doa-conf-vinciane-gaillard.pdf Gaillard, 2022]).

Vinciane Gaillard (directrice adjointe pour la recherche et l'innovation, Association européenne des universités) décrit un écosystème d'édition savante juste comme étant «&amp;#8239;transparent, diversifié, économiquement abordable et durable, techniquement interopérable et piloté par la communauté des chercheurs et ses institutions par le biais de politiques coordonnées&amp;#8239;» ([https://www.scienceeurope.org/media/yg3ho4tp/doa-conf-vinciane-gaillard.pdf diapositive 4)].

==Elsevier lance ScopusAI==
Au début de l'année 2024, [https://www.elsevier.com/about/press-releases/launch-of-scopus-ai-to-help-researchers-navigate-the-world-of-research Elsevier a annoncé le lancement de ScopusAI], un outil d'intelligence artificielle proposé aux institutions sur une base d'abonnement. Selon le site web d'Elsevier, [https://www.elsevier.com/products/scopus/scopus-ai ScopusAI] sert de «&amp;#8239;guide expert&amp;#8239;» que les chercheurs peuvent utiliser pour naviguer dans «&amp;#8239;la vaste étendue de la connaissance humaine dans Scopus&amp;#8239;». En plus de résumer la littérature disponible dans Scopus, l'outil est apparemment aussi capable de «&amp;#8239;repérer&amp;#8239;» ce qu'Elsevier appelle «&amp;#8239;l'espace blanc&amp;#8239;» dans la littérature afin que les chercheurs puissent ostensiblement mieux identifier les types de contributions qu'ils peuvent apporter. Il est inquiétant de constater que les résumés générés par l'outil renvoient à ce qu'Elsevier et l'outil ScopusAI considèrent comme des documents «&amp;#8239;fondamentaux&amp;#8239;» pour un sujet donné - il s'agit «&amp;#8239;d'articles à fort impact qui sont le plus souvent cités par les articles utilisés dans les résumés&amp;#8239;». Outre les décisions algorithmiques concernant les articles considérés comme fondamentaux, l'outil offre également la possibilité de «&amp;#8239;découvrir des experts&amp;#8239;» dans un domaine. Cependant, l'outil ne prend en compte que les articles et les profils qui figurent déjà dans Scopus qui est déjà connu comme une base de données qui surreprésente les universitaires et les chercheurs d'Europe, d'Océanie et d'Amérique du Nord par rapport aux universitaires et aux chercheurs d'autres régions du monde (Asubiaro et al. 2024).

==Questions et considérations clés==
[[Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024/Réponses à l’intelligence artificielle|Les idées et les signaux décrits ci-dessus et ailleurs indiquent que l'intégration de l'IA générative dans l'édition savante]] présente à la fois des opportunités et des défis, ainsi que des implications significatives pour la qualité, l'intégrité et l'accessibilité des résultats de l'édition savante. Plusieurs questions se posent pour l'élaboration des politiques, notamment

* Quelle est la place éventuelle de l'IA générative dans l'édition en libre accès ?
* Comment les éditeurs en libre accès peuvent-ils guider l'utilisation responsable, éthique et crédible de l'IA générative ?

Par exemple, John Willinsky (fondateur du Public Knowledge Project) nous a fait savoir que le PKP étudie activement la manière dont l'IA basée sur de grands modèles linguistiques pourrait contribuer à la durabilité de l'édition en libre accès :

L'objectif principal de ce travail est d'établir si les LLM peuvent être suffisamment adaptés pour automatiser de manière fiable le balisage HTML et JATS XML des manuscrits des auteurs (étant donné que ce balisage nécessite actuellement des compétences techniques ou des paiements qui dépassent la capacité de la plupart des revues Diamond OA). Ce travail a atteint le stade initial de la preuve de concept, et les travaux se poursuivent sur sa valeur comparative (par rapport à d'autres outils) et sur les moyens d'intégrer et de maintenir un tel service de balisage dans le flux de travail éditorial. (Lisez l'intégralité du commentaire de John Willinsky ci-dessous).

En plus de ces questions, les lecteurs pourraient également se demander quelles leçons et perspectives clés du mouvement de l'accès libre, du discours, de la recherche et de la littérature pourraient être appliquées au paysage en évolution de l'IA générative, le cas échéant. Par exemple, les principes FAIR pour la gestion et l'intendance des données ([https://www.nature.com/articles/sdata201618 Wilkinson et al. 2016]) - envisagés à l'origine comme un moyen de soutenir la réutilisation des données savantes en veillant à ce qu'elles soient trouvables, accessibles, interopérables et réutilisables - pourraient servir d'exemple. Les principes FAIR ont été réinterprétés pour s'appliquer aux logiciels, aux flux de travail, aux outils, aux algorithmes et, de plus en plus, aux modèles d'IA ([https://www.nature.com/articles/s41597-023-02298-6 Huerta et al. 2023]). Dans le même ordre d'idées, la Direction générale de la recherche et de l'innovation de la Commission européenne a récemment [https://research-and-innovation.ec.europa.eu/document/2b6cf7e5-36ac-41cb-aab5-0d32050143dc_en publié un ensemble de principes visant à orienter l'utilisation responsable de l'IA générative dans la recherche]. On peut dire que ces principes recoupent les principes FAIR, ce qui offre d'autres possibilités de réflexion. (Pour mémoire, les quatre principes clés sont la fiabilité, l'honnêteté, le respect et la responsabilité).

==Commentaires du partenariat INKE==
''Réponse de John Willinsky (fondateur, Public Knowledge Project) :''

&lt;blockquote&gt;
Bien qu'il y ait des raisons de s'inquiéter des récentes avancées de l'IA, les universitaires ont également la responsabilité d'explorer les contributions et les avancées potentielles de l'IA pour la recherche et l'érudition. Depuis un certain temps, le [https://pkp.sfu.ca/ Public Knowledge Project] se tourne vers l'IA pour résoudre les problèmes urgents liés à l'équité et à la qualité des ressources dans les communications savantes, avec un succès limité. Il mène actuellement des recherches sur la capacité des grands modèles de langage à relever le défi de longue date que représente le développement d'un moyen durable pour les revues Diamond OA de publier dans les formats standard HTML et PDF, ainsi que d'exporter des fichiers en JATS XML. L'objectif principal de ce travail est d'établir si les LLM peuvent être suffisamment adaptés pour automatiser de manière fiable le balisage HTML et JATS XML des manuscrits des auteurs (étant donné que ce balisage nécessite actuellement des compétences techniques ou des paiements qui dépassent la capacité de la plupart des revues Diamond OA). Ce travail a atteint le stade initial de la preuve de concept, et les travaux se poursuivent sur sa valeur comparative (par rapport à d'autres outils) et sur les moyens d'intégrer et de maintenir un tel service de balisage dans le flux de travail éditorial.
&lt;/blockquote&gt;

==Références==
*Ahari, Juni. 2024. «&amp;#8239;Generative AI and Scholarly Publishing&amp;#8239;». ''Ithaka S+R ''(blog). 23 avril 2024. [https://sr.ithaka.org/blog/generative-ai-and-scholarly-publishing/ https://sr.ithaka.org/blog/generative-ai-and-scholarly-publishing/].

*Asubiaro, Toluwase, Sodiq Onaolapo et David Mills. 2024. «&amp;#8239;Regional disparities in Web of Science and Scopus journal coverage&amp;#8239;». ''Scientometrics ''129 (3) : 1469–91. [https://doi.org/10.1007/s11192-024-04948-x https://doi.org/10.1007/s11192-024-04948-x].

*Bergstrom, Tracy, Oya Y. Rieger et Roger C. Schonfeld. 2024. «&amp;#8239;The Second Digital Transformation of Scholarly Publishing: Strategic Context and Shared Infrastructure&amp;#8239;». Ithaka S+R. [https://doi.org/10.18665/sr.320210 https://doi.org/10.18665/sr.320210].

*Chiarelli, Andrea, Ellie Cox, Rob Johnson, Ludo Waltman, Wolfgang Kaltenbrunner, André Brasil, Andrea Reyes Elizondo et Stephen Pinfield. 2024. «&amp;#8239;Towards Responsible Publishing&amp;#8239;» : Findings from a global stakeholder consultation. cOAlition S. Zenodo. [https://doi.org/10.5281/zenodo.11243942 https://doi.org/10.5281/zenodo.11243942].

*Directorate-General for Research and Innovation. 2024. «&amp;#8239;Living Guidelines on the Responsible Use of Generative AI in Research (Version 1)&amp;#8239;». Brussels: European Commission. [https://research-and-innovation.ec.europa.eu/document/download/2b6cf7e5-36ac-41cb-aab5-0d32050143dc_en?filename=ec_rtd_ai-guidelines.pdf https://research-and-innovation.ec.europa.eu/document/download/2b6cf7e5-36ac-41cb-aab5-0d32050143dc_en?filename=ec_rtd_ai-guidelines.pdf].

*Dobrin, Sidney I. 2023. «&amp;#8239;Talking about Generative AI: A Guide for Educators&amp;#8239;». Version 1. Broadview Press. [https://sites.broadviewpress.com/ai/talking/ https://sites.broadviewpress.com/ai/talking/].

*Gaillard, Vinciane. 2022. «&amp;#8239;Encouraging/Supporting Sustainability in the Diamond Action Plan Community&amp;#8239;». Presented at the 2022 Diamond Open Access Conference, September. [https://www.scienceeurope.org/media/yg3ho4tp/doa-conf-vinciane-gaillard.pdf https://www.scienceeurope.org/media/yg3ho4tp/doa-conf-vinciane-gaillard.pdf]

*Huerta, E. A., Ben Blaiszik, L. Catherine Brinson, Kristofer E. Bouchard, Daniel Diaz, Caterina Doglioni, Javier M. Duarte, et al. 2023. «&amp;#8239;FAIR for AI: An Interdisciplinary and International Community Building Perspective&amp;#8239;». ''Scientific Data'' 10 (1): 487. [https://doi.org/10.1038/s41597-023-02298-6 https://doi.org/10.1038/s41597-023-02298-6].

*Shen, Cenyu, and Joanna Ball. 2024. «&amp;#8239;DOAJ’s Role in Supporting Trust in Scholarly Journals: Current Challenges and Future Solutions&amp;#8239;». ''The Scholarly Kitchen'' (blog). June 6, 2024. [https://scholarlykitchen.sspnet.org/2024/06/06/guest-post-doajs-role-in-supporting-trust-in-scholarly-journals-current-challenges-and-future-solutions/ https://scholarlykitchen.sspnet.org/2024/06/06/guest-post-doajs-role-in-supporting-trust-in-scholarly-journals-current-challenges-and-future-solutions/].

*Stern, Bodo, et Johan Rooryck. 2023. «&amp;#8239;Introducing the ‘Towards Responsible Publishing’ Proposal from cOAlition S | Plan S&amp;#8239;». sOApbox : A Plan S Blog (blog). 31 octobre 2023. [https://www.coalition-s.org/blog/introducing-the-towards-responsible-publishing-proposal-from-coalition-s/ https://www.coalition-s.org/blog/introducing-the-towards-responsible-publishing-proposal-from-coalition-s/].

*Stern, Bodo, Zoé Ancion, Andreas Björke, Ashley Farley, Marte Qvenild, Katharina Rieck, Jeroen Sondervan, et al. 2023. «&amp;#8239;Towards Responsible Publishing : Seeking Input from the Research Community to a Draft Proposal from cOAlition S&amp;#8239;», octobre. [https://doi.org/10.5281/ZENODO.8398480 https://doi.org/10.5281/ZENODO.8398480].

*Wilkinson, Mark D., Michel Dumontier, IJsbrand Jan Aalbersberg, Gabrielle Appleton, Myles Axton, Arie Baak, Niklas Blomberg, et al. 2016. «&amp;#8239;The FAIR Guiding Principles for Scientific Data Management and Stewardship&amp;#8239;». ''Scientific Data'' 3 (1): 160018. [https://doi.org/10.1038/sdata.2016.18 https://doi.org/10.1038/sdata.2016.18].

[[Catégorie:Extension : Observatoire des politiques d'Érudition ouverte, 2021-2024 (livre)]]</text>
      <sha1>gs0zaea0fy58eyijd30jxouqd75a8zz</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/057</title>
    <ns>0</ns>
    <id>82540</id>
    <revision>
      <id>745374</id>
      <timestamp>2025-06-26T12:01:26Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745374</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1871" sha1="b61m7id8fkode0kyrqkktabbaokno0c" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/053| '''Application''']]
:


[[File:Analyse de réseau à l'aide de systèmes linéaires (le problème exemple 3a).png|thumb|]]

En regardant le réseau nous pouvons écrire :


     Entrées  = Sorties

 A = x1       = x2 + x3
 B = x2 + x4  = x5  
 C = x5 + x6  = x7
 D = x3 + x7  = x8
 E = x8       = x1 + x4 + x6
 
 posons x1 = 50; x3 = 20; x5 = 60; x8 = 90; 
 
 A = 50       = x2 + 20
 B = x2 + x4  = 60  
 C = 60 + x6  = x7
 D = 20 + x7  = 90
 E = 90       = 50 + x4 + x6 
 
 
 arrangeons le système
 
  -x2      = +20 -50
  +x2 +x4  = +60  
  +x6 -x7  = -60
  +x7      = +90 -20
  -x4 -x6  = +50 -90    
 

 Soit
 // x2   x4   x6   x7
  
  -x2   +0   +0   +0   +0   = +20 -50
  +x2  +x4   +0   +0   +0   = +60  
   +0   +0  +x6  -x7   +0   = -60
   +0   +0   +0  +x7   +0   = +90 -20
   +0  -x4  -x6   +0   +0   = +50 -90
 

Le code en langage C (Les coefficients sont de valeurs complexes) :

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA*C2 + Cb*C2)]={
// x2       x4       x6       x7
   -1,+0,   +0,+0,   +0,+0,   +0,+0,   +0,+0,    +20-50,+0,
   +1,+0,   +1,+0,   +0,+0,   +0,+0,   +0,+0,    +60,   +0,  
   +0,+0,   +0,+0,   +1,+0,   -1,+0,   +0,+0,    -60,   +0,
   +0,+0,   +0,+0,   +0,+0,   +1,+0,   +0,+0,    +90-20,+0,
   +0,+0,   -1,+0,   -1,+0,   +0,+0,   +0,+0,    +50-90,+0
};
&lt;/syntaxhighlight&gt; 
 

[[File:Analyse de réseau à l'aide de systèmes linéaires (le problème exemple 3b).png|thumb|]]

La solution est donné par la résolution du système :

   x2    x4    x6    x7 
   +1    +0    +0    +0    +0   +30 
   +0    +1    +0    +0    +0   +30 
   +0    +0    +1    +0    +0   +10 
   +0    +0    +0    +1    +0   +70 
   +0    +0    +0    +0    +0    +0 


   x2 = +30;    x4 = +30;    x6 = +10;    x7 = +70;
   
   et x1 = 50; x3 = 20; x5 = 60; x8 = 90;   

{{AutoCat}}</text>
      <sha1>b61m7id8fkode0kyrqkktabbaokno0c</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/054</title>
    <ns>0</ns>
    <id>82541</id>
    <revision>
      <id>745375</id>
      <timestamp>2025-06-26T12:06:55Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745375</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2448" sha1="byft5zltqlrb1zuupxnkggkxef107q8" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/053| '''Application''']]
:

Installer et compiler ces fichiers dans votre répertoire de travail.


[[File:Network Analysis Using Linear Systems ex 01a.png|thumb|]]


{{Fichier|c00a.c|largeur=70%|info=|icon=Crystal128-source-c.svg}}
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
/* ------------------------------------ */
/*  Save as :   c00a.c                  */
/* ------------------------------------ */
#include &quot;w_a.h&quot;
/* ------------------------------------ */
#define   RA R4
#define   CA C4
#define   Cb C1
/* ------------------------------------ */
int main(void)
{
double ab[RA*(CA*C2+Cb*C2)]={
//  x1       x2       x3       
    +1,+0,   +1,+0,   +0,+0,   +0,+0,   +50,    +0,  // A
    +0,+0,   -1,+0,   -1,+0,   +0,+0,   -40,    +0,  // B
    +0,+0,   +0,+0,   +1,+0,   +0,+0,   +20 -10,+0,  // C
    -1,+0,   +0,+0,   +0,+0,   +0,+0,   -30 +10 +0   // D  
};

double **Ab =   ca_A_mZ(ab,i_Abr_Ac_bc_mZ(RA,CA,Cb));
double **A  = c_Ab_A_mZ(Ab,i_mZ(RA,CA));
double **b  = c_Ab_b_mZ(Ab,i_mZ(RA,Cb));

  clrscrn();
  printf(&quot; A :&quot;);
  p_mRZ(A,S5,P0,C7);
  printf(&quot; b :&quot;);
  p_mRZ(b,S5,P0,C7);
  printf(&quot; Ab :&quot;);
  p_mRZ(Ab,S5,P0,C7);
  getchar();

  clrscrn();
  printf(&quot; Copy/Past into the octave window.\n\n&quot;);
  p_Octave_mZ(Ab,&quot;Ab&quot;,P0,P0);
  printf(&quot;\n rref(Ab,.00000000001)\n\n&quot;);
  printf(&quot;  gj_TP_mZ(Ab) :\n\n&quot;
      &quot;   x1    x2    x3  &quot;);
  gj_mZ(Ab);
  p_mRZ(Ab,S5,P0,C7);
  stop();

  f_mZ(Ab);
  f_mZ(b);
  f_mZ(A);
  
  return 0;
}
/* ------------------------------------ */
/* ------------------------------------ */
&lt;/syntaxhighlight&gt; 
 

[[File:Network Analysis Using Linear Systems ex 01b.png|thumb|]]

 '''Exemple de sortie écran :'''
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
 A :
   +1    +1    +0    +0 
   +0    -1    -1    +0 
   +0    +0    +1    +0 
   -1    +0    +0    +0 

 b :
  +50 
  -40 
  +10 
  -20 

 Ab :
   +1    +1    +0    +0   +50 
   +0    -1    -1    +0   -40 
   +0    +0    +1    +0   +10 
   -1    +0    +0    +0   -20 


 Copy/Past into the octave window.

 Ab=[
+1+0*i,+1+0*i,+0+0*i,+0+0*i,+50+0*i;
+0+0*i,-1+0*i,-1+0*i,+0+0*i,-40+0*i;
+0+0*i,+0+0*i,+1+0*i,+0+0*i,+10+0*i;
-1+0*i,+0+0*i,+0+0*i,+0+0*i,-20+0*i]


 rref(Ab,.00000000001)

  gj_mZ(Ab) :

   x1    x2    x3  
   +1    +0    +0    +0   +20 
   +0    +1    +0    +0   +30 
   +0    +0    +1    +0   +10 
   +0    +0    +0    +0    +0 

 Press return to continue. 
&lt;/syntaxhighlight&gt;

{{AutoCat}}</text>
      <sha1>byft5zltqlrb1zuupxnkggkxef107q8</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/056</title>
    <ns>0</ns>
    <id>82542</id>
    <revision>
      <id>745376</id>
      <timestamp>2025-06-26T12:11:12Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745376</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2431" sha1="lxjnw30kit84xak17qdtxa6qurnooas" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/053| '''Application''']]
:

Installer et compiler ces fichiers dans votre répertoire de travail.


[[File:Network Analysis Using Linear Systems ex 02a.png|thumb|]]


{{Fichier|c00b.c|largeur=70%|info=|icon=Crystal128-source-c.svg}}
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
/* ------------------------------------ */
/*  Save as :   c00b.c                  */
/* ------------------------------------ */
#include &quot;w_a.h&quot;
/* ------------------------------------ */
#define   RA R4
#define   CA C4
#define   Cb C1
/* ------------------------------------ */
int main(void)
{
double ab[RA*(CA*C2+Cb*C2)]={
//  x1      x3      x4       
    +1,+0,  +0,+0,  +0,+0,  +0,+0,  +20+10,   +0, // A
    +0,+0,  +1,+0,  +0,+0,  +0,+0,  +60-10-30,+0, // B   
    +0,+0,  -1,+0,  +1,+0,  +0,+0,  +20,      +0, // C
    -1,+0,  +0,+0,  -1,+0,  +0,+0,  -100+30,  +0  // D  
};

double **Ab = ca_A_mZ(ab,i_Abr_Ac_bc_mZ(RA,CA,Cb));
double **A  = c_Ab_A_mZ(Ab,i_mZ(RA,CA));
double **b  = c_Ab_b_mZ(Ab,i_mZ(RA,Cb));

  clrscrn();
  printf(&quot; A :&quot;);
  p_mRZ(A,S5,P0,C7);
  printf(&quot; b :&quot;);
  p_mRZ(b,S5,P0,C7);
  printf(&quot; Ab :&quot;);
  p_mRZ(Ab,S5,P0,C7);
  getchar();

  clrscrn();
  printf(&quot; Copy/Past into the octave window.\n\n&quot;);
  p_Octave_mZ(Ab,&quot;Ab&quot;,P0,P0);
  printf(&quot;\n rref(Ab,.00000000001)\n\n&quot;);
  printf(&quot;  gj_mZ(Ab) :\n\n&quot;
      &quot;   x1    x3    x4 &quot;);
  gj_mZ(Ab);
  p_mRZ(Ab,S5,P0,C7);
  stop();

  f_mZ(Ab);
  f_mZ(b);
  f_mZ(A);
  
  return 0;
}
/* ------------------------------------ */
/* ------------------------------------ */

&lt;/syntaxhighlight&gt; 
 

[[File:Network Analysis Using Linear Systems ex 02b.png|thumb|]]

 '''Exemple de sortie écran :'''
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
 A :
   +1    +0    +0    +0 
   +0    +1    +0    +0 
   +0    -1    +1    +0 
   -1    +0    -1    +0 

 b :
  +30 
  +20 
  +20 
  -70 

 Ab :
   +1    +0    +0    +0   +30 
   +0    +1    +0    +0   +20 
   +0    -1    +1    +0   +20 
   -1    +0    -1    +0   -70 


 Copy/Past into the octave window.

 Ab=[
+1+0*i,+0+0*i,+0+0*i,+0+0*i,+30+0*i;
+0+0*i,+1+0*i,+0+0*i,+0+0*i,+20+0*i;
+0+0*i,-1+0*i,+1+0*i,+0+0*i,+20+0*i;
-1+0*i,+0+0*i,-1+0*i,+0+0*i,-70+0*i]


 rref(Ab,.00000000001)

  gj_mZ(Ab) :

   x1    x3    x4 
   +1    +0    +0    +0   +30 
   +0    +1    +0    +0   +20 
   +0    +0    +1    +0   +40 
   +0    +0    +0    +0    +0 

 Press return to continue. 
&lt;/syntaxhighlight&gt;

{{AutoCat}}</text>
      <sha1>lxjnw30kit84xak17qdtxa6qurnooas</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/058</title>
    <ns>0</ns>
    <id>82543</id>
    <revision>
      <id>745377</id>
      <timestamp>2025-06-26T12:15:47Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745377</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2852" sha1="7mn682mb6bucx1h0wlott7ecg9fqr0s" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/053| '''Application''']]
:

Installer et compiler ces fichiers dans votre répertoire de travail.


[[File:Analyse de réseau à l'aide de systèmes linéaires (le problème exemple 3a).png|thumb|]]


{{Fichier|c00c.c|largeur=70%|info=|icon=Crystal128-source-c.svg}}
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
/* ------------------------------------ */
/*  Save as :   c00c.c                  */
/* ------------------------------------ */
#include &quot;w_a.h&quot;
/* ------------------------------------ */
#define   RA R5
#define   CA C5
#define   Cb C1
/* ------------------------------------ */
int main(void)
{
double ab[RA*(CA*C2+Cb*C2)]={
// x2       x4       x6       x7
   -1,+0,   +0,+0,   +0,+0,   +0,+0,   +0,+0,    +20 -50,+0,
   +1,+0,   +1,+0,   +0,+0,   +0,+0,   +0,+0,    +60,    +0,  
   +0,+0,   +0,+0,   +1,+0,   -1,+0,   +0,+0,    -60,    +0,
   +0,+0,   +0,+0,   +0,+0,   +1,+0,   +0,+0,    +90 -20,+0,
   +0,+0,   -1,+0,   -1,+0,   +0,+0,   +0,+0,    +50 -90,+0
};

double **Ab =   ca_A_mZ(ab,i_Abr_Ac_bc_mZ(RA,CA,Cb));
double **A  = c_Ab_A_mZ(Ab,i_mZ(RA,CA));
double **b  = c_Ab_b_mZ(Ab,i_mZ(RA,Cb));

  clrscrn();
  printf(&quot; A :&quot;);
  p_mRZ(A,S5,P0,C7);
  printf(&quot; b :&quot;);
  p_mRZ(b,S5,P0,C7);
  printf(&quot; Ab :&quot;);
  p_mRZ(Ab,S5,P0,C7);
  getchar();

  clrscrn();
  printf(&quot; Copy/Past into the octave window.\n\n&quot;);
  p_Octave_mZ(Ab,&quot;Ab&quot;,P0,P0);
  printf(&quot;\n rref(Ab,.00000000001)\n\n&quot;);
  printf(&quot;  gj_mZ(Ab) :\n\n&quot;
      &quot;   x2    x4    x6    x7 &quot;);
  gj_mZ(Ab);
  p_mRZ(Ab,S5,P0,C7);
  stop();

  f_mZ(Ab);
  f_mZ(b);
  f_mZ(A);
  
  return 0;
}
/* ------------------------------------ */
/* ------------------------------------ */
&lt;/syntaxhighlight&gt; 
 

[[File:Analyse de réseau à l'aide de systèmes linéaires (le problème exemple 3b).png|thumb|]]

 '''Exemple de sortie écran :'''
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
 A :
   -1    +0    +0    +0    +0 
   +1    +1    +0    +0    +0 
   +0    +0    +1    -1    +0 
   +0    +0    +0    +1    +0 
   +0    -1    -1    +0    +0 

 b :
  -30 
  +60 
  -60 
  +70 
  -40 

 Ab :
   -1    +0    +0    +0    +0   -30 
   +1    +1    +0    +0    +0   +60 
   +0    +0    +1    -1    +0   -60 
   +0    +0    +0    +1    +0   +70 
   +0    -1    -1    +0    +0   -40 


 Copy/Past into the octave window.

 Ab=[
-1+0*i,+0+0*i,+0+0*i,+0+0*i,+0+0*i,-30+0*i;
+1+0*i,+1+0*i,+0+0*i,+0+0*i,+0+0*i,+60+0*i;
+0+0*i,+0+0*i,+1+0*i,-1+0*i,+0+0*i,-60+0*i;
+0+0*i,+0+0*i,+0+0*i,+1+0*i,+0+0*i,+70+0*i;
+0+0*i,-1+0*i,-1+0*i,+0+0*i,+0+0*i,-40+0*i]


 rref(Ab,.00000000001)

  gj_mZ(Ab) :

   x2    x4    x6    x7 
   +1    +0    +0    +0    +0   +30 
   +0    +1    +0    +0    +0   +30 
   +0    +0    +1    +0    +0   +10 
   +0    +0    +0    +1    +0   +70 
   +0    +0    +0    +0    +0    +0 

 Press return to continue. 
&lt;/syntaxhighlight&gt;

{{AutoCat}}</text>
      <sha1>7mn682mb6bucx1h0wlott7ecg9fqr0s</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/05a</title>
    <ns>0</ns>
    <id>82544</id>
    <revision>
      <id>745385</id>
      <timestamp>2025-06-26T14:13:27Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745385</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="978" sha1="djfbtm2xcu472vzh9b5sipodd70l1fn" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/a26| '''Gauss-Jordan''']]
:

{{Partie{{{type|}}}|Analyse d'un circuit électrique}}


{| class=&quot;wikitable&quot;
|+ Premier exemple :
|-
| * [[Mathc complexes/05b| Présentation]] || [[File:Electrical Networks Using Linear Systems 1a.png|thumb|]]|| * [[Mathc complexes/05c| Résolution]]  || [[File:Electrical Networks Using Linear Systems 1b.png|thumb|]]
|}


{| class=&quot;wikitable&quot;
|+ Deuxième exemple :
|-
| * [[Mathc complexes/05d| Présentation]] || [[File:Electrical Networks Using Linear Systems 2a.png|thumb|]]|| * [[Mathc complexes/05e| Résolution]]  || [[File:Electrical Networks Using Linear Systems 2b.png|thumb|]]
|}


{| class=&quot;wikitable&quot;
|+ Troisième exemple :
|-
| * [[Mathc complexes/05f| Présentation]] || [[File:Electrical Networks Using Linear Systems 3a.png|thumb|]]|| * [[Mathc complexes/05g| Résolution]]  || [[File:Electrical Networks Using Linear Systems 3b.png|thumb|]]
|}


{{AutoCat}}</text>
      <sha1>djfbtm2xcu472vzh9b5sipodd70l1fn</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/05b</title>
    <ns>0</ns>
    <id>82545</id>
    <revision>
      <id>745388</id>
      <timestamp>2025-06-26T14:21:36Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745388</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1793" sha1="omakd1rtmj1x2096nosdspjeyfy668k" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/05a| '''Application''']]
:


[[File:Electrical Networks Using Linear Systems 1a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I1 + I2 = I3


 Au noeud B :
 
     Entrées = Sortie
     I3      = I1 + I2

 Soit :
 
 a) I1 + I2 - I3 = 0


 Partie gauche du circuit :
 
    I2 R2 - I1 R1 =0
 
 b) - I1 R1 + I2 R2 = 0


 Partie droite du circuit :
 
    120 - I2 R2 - I3 R3 =0
 
 c) I2 R2 + I3 R3 = 120


 Partie extérieure du circuit :
 
    120 - I3 R3 - I1 R1 = 0
 
 d) I1 R1 + I3 R3  = 120

 
 Donc:
 
 a)  I1    + I2    - I3     = 0    
 b) -I1 R1 + I2 R2          = 0
 c)          I2 R2 + I3 R3  = 120 
 d)  I1 R1         + I3 R3  = 120
  
  
 Avec R1 = 60, R2 = 30, R3 = 20  

 a)  I1    + I2    - I3     = 0    
 b) -I1 60 + I2 30          = 0
 c)          I2 30 + I3 20  = 120 
 d)  I1 60         + I3 20  = 120


 Arrangeons le système
    I1    I2    I3
    
    +1    +1    -1    = 0    
   -60   +30    +0    = 0
    +0   +30   +20    = 120 
   +60    +0   +20    = 120

  
Le code en langage C : (Dans cette page j'ai laisser les coefficients réelles pour simplifier)

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
// I1    I2    I3    
   +1,   +1,   -1,   +0,    +0,
  -60,  +30,   +0,   +0,    +0,  
   +0,  +30,  +20,   +0,    +120,
  +60,   +0,  +20,   +0,    +120
};
&lt;/syntaxhighlight&gt; 


[[File:Electrical Networks Using Linear Systems 1b.png|thumb|]]

La solution est donné par la résolution du système :

   I1    I2    I3  
   +1    +0    +0    +0    +1 
   +0    +1    +0    +0    +2 
   -0    -0    +1    -0    +3 
   +0    +0    +0    +0    +0 


  I1 = 1A; I2 = 2A; I3 = 3A;


{{AutoCat}}</text>
      <sha1>omakd1rtmj1x2096nosdspjeyfy668k</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/05d</title>
    <ns>0</ns>
    <id>82546</id>
    <revision>
      <id>745393</id>
      <timestamp>2025-06-26T14:30:25Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745393</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3846" sha1="2h8bgoapl0c5vfvwttlfbqs4v6k6dgd" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/05a| '''Application''']]
:

[[File:Electrical Networks Using Linear Systems 2a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I1      = I2 + I3

 Au noeud B :
 
     Entrées = Sortie
     I3      = I4 + I5

 Au noeud C :
 
     Entrées = Sortie
     I2 + I5 = I6

 Au noeud D :
 
     Entrées = Sortie
     I6 + I4 = I1

 Soit :
 
 a) +I1 -I2 -I3              = 0
            +I3 -I4 -I5      = 0
        +I2         +I5 -I6  = 0
   -I1          +I4     +I6  = 0

 Partie gauche du circuit :
 
    90 -I2 R2 - I6 R61 =   0
 
 b)    -I2 R2 - I6 R6  = -90

 Partie droite haute du circuit :
 
    I2 R2 - I3 R3 - I5 R5 = 0
 
 c) I2 R2 - I3 R3 - I5 R5 = 0

 Partie droite basse du circuit :
 
      I6 R6 + I5 R5 - I4 R4 = 0
 
 d) - I4 R4 + I5 R5 + I6 R6 = 0

 Partie extérieure du circuit :
 
    90 - I3 R3 - I4 R4 = 0
 
 e)  - I3 R3 - I4 R4 = -90

 Donc:
 
 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 R2                          -I6 R6 = -90
 c)        +I2 R2  -I3 R3          -I5 R5         =   0 
 d)                        -I4 R4  +I5 R5  +I6 R6 =   0
 e)                -I3 R3  -I4 R4                 = -90

 Avec R2 = 50, R3 = 20, R4 = 50, 
      R5 = 10, R6 = 20 

 a)   +I1  -I2     -I3                            =   0
                   +I3      -I4    -I5            =   0
           +I2                     +I5     -I6    =   0
      -I1                   +I4            +I6    =   0
 b)        -I2 50                          -I6 20 = -90
 c)        +I2 50  -I3 20          -I5 10         =   0 
 d)                        -I4 50  +I5 10  +I6 20 =   0
 e)                -I3 20  -I4 50                 = -90

 Arrangeons le système
      I1   I2   I3   I4   I5   I6
    
      +1   -1   -1   +0   +0   +0   0  0     0
      +0   +0   +1   -1   -1   +0   0  0     0
      +0   +1   +0   +0   +1   -1   0  0     0
      -1   +0   +0   +1   +0   +1   0  0     0
      +0  -50   +0   +0   +0  -20   0  0   -90
      +0  +50  -20   +0  -10   +0   0  0     0 
      +0   +0   +0  -50  +10  +20   0  0     0
      +0   +0  -20  -50   +0   +0   0  0   -90

Le code en langage C :  (Dans cette page j'ai laisser les coefficients réelles pour simplifier)

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//    I1    I2    I3    I4    I5    I6    
      +1,   -1,   -1,   +0,   +0,   +0,   0,  0,     0,
      +0,   +0,   +1,   -1,   -1,   +0,   0,  0,     0,
      +0,   +1,   +0,   +0,   +1,   -1,   0,  0,     0,
      -1,   +0,   +0,   +1,   +0,   +1,   0,  0,     0,
      +0,  -50,   +0,   +0,   +0,  -20,   0,  0,   -90,
      +0,  +50,  -20,   +0,  -10,   +0,   0,  0,     0, 
      +0,   +0,   +0,  -50,  +10,  +20,   0,  0,     0,
      +0,   +0,  -20,  -50,   +0,   +0,   0,  0,   -90,
};
&lt;/syntaxhighlight&gt; 


[[File:Electrical Networks Using Linear Systems 2b.png|thumb|]]

La solution est donné par la résolution du système :


  I1     I2     I3     I4     I5     I6 
 +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +3.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 
 I1 = 3,    I2 = 1,   I3 = 2,   I4 = 1,   I5 = 1,   I6 = 2,

{{AutoCat}}</text>
      <sha1>2h8bgoapl0c5vfvwttlfbqs4v6k6dgd</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/05f</title>
    <ns>0</ns>
    <id>82547</id>
    <revision>
      <id>745398</id>
      <timestamp>2025-06-26T14:45:55Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745398</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3861" sha1="ihhf3zgv38wbv4lnjfwle1eeiv9vjxk" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/05a| '''Application''']]
:

[[File:Electrical Networks Using Linear Systems 3a.png|thumb|]]

En étudiant le circuit dans le sens des aiguilles d'une montre, nous pouvons écrire :

 Au noeud A :
 
     Entrées = Sortie
     I2 + I3 = I1

 Au noeud B :
 
     Entrées = Sortie
     I4      = I3 + I5

 Au noeud C :
 
     Entrées = Sortie
     I6 + I5 = I4

 Au noeud D :
 
     Entrées = Sortie
     I1      = I6 + I2

 Soit :
 
 a) -I1  +I2  +I3                 = 0
              -I3  +I4  -I5       = 0
                   -I4  +I5  +I6  = 0
    +I1  -I2                 -I6  = 0

 Partie gauche du circuit :
 
  -90 +I1 R1 + I2 R2 =   0
 
 b)     +I1 R1 +I2 R2 =   +90

 Partie centrale du circuit :
 
    -I2 R2 + I3 R3 + I4 R4 + I6 R6 = 0
 
 c) -I2 R2 +I3 R3 +I4 R4 +I6 R6 = 0

 Partie droite du circuit :
  
    90 - I5 R5 - I4 R4 = 0
 
 d)    -I4 R4 -I5 R5  = -90

 Partie extérieure du circuit :
 
    -90 + I1 R1 + I3 R3 + 90 - I5 R5 + I6 R6 = 0
 
 e)     +I1 R1 +I3 R3  -I5 R5 +I6 R6 = 0

 Donc:
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 R1  +I2 R2                                  = +90
 c)         -I2 R2  +I3 R3  +I4 R4          +I6 R6  =  +0
 d)                         -I4 R4  -I5 R5          = -90
 e) +I1 R1          +I3 R3          -I5 R5  +I6 R6  =  +0

 Avec R1 = 15, R2 = 60, R3 = 15, R4 = 15, R5 = 60, R6 = 15 
 
 a) -I1     +I2     +I3                             =  +0
                    -I3     +I4      -I5            =  +0
                            -I4      +I5    +I6     =  +0
    +I1     -I2                             -I6     =  +0
 b) +I1 15  +I2 60                                  = +90
 c)         -I2 60  +I3 15  +I4 15          +I6 15  =  +0
 d)                         -I4 15  -I5 60          = -90
 e) +I1 15          +I3 15          -I5 60  +I6 15  =  +0

 Arrangeons le système
     I1   I2   I3   I4   I5   I6
    
 a)  -1   +1   +1   +0   +0   +0     +0
     +0   +0   -1   +1   -1   +0     +0
     +0   +0   +0   -1   +1   +1     +0
     +1   -1   +0   +0   +0   -1     +0
 b) +15  +60   +0   +0   +0   +0    +90
 c)  +0  -60  +15  +15   +0  +15     +0
 d)  +0   +0   +0  -15  -60   +0    -90
 e) +15   +0  +15   +0  -60  +15     +0

Le code en langage C :  (Dans cette page j'ai laisser les coefficients réelles pour simplifier)

&lt;syntaxhighlight lang=&quot;c&quot;&gt;
double ab[RA*(CA+Cb)]={
//   I1    I2    I3    I4    I5    I6    
     -1,   +1,   +1,   +0,   +0,   +0,   +0, +0,   +0,
     +0,   +0,   -1,   +1,   -1,   +0,   +0, +0,   +0,
     +0,   +0,   +0,   -1,   +1,   +1,   +0, +0,   +0,
     +1,   -1,   +0,   +0,   +0,   -1,   +0, +0,   +0,
    +15,  +60,   +0,   +0,   +0,   +0,   +0, +0,  +90,
     +0,  -60,  +15,  +15,   +0,  +15,   +0, +0,   +0,
     +0,   +0,   +0,  -15,  -60,   +0,   +0, +0,  -90,
    +15,   +0,  +15,   +0,  -60,  +15,   +0, +0,   +0
};
&lt;/syntaxhighlight&gt; 

[[File:Electrical Networks Using Linear Systems 3b.png|thumb|]]
 La solution est donné par la résolution du système :
  
  I1     I2     I3     I4     I5     I6 
 +1.00  -0.00  -0.00  +0.00  -0.00  +0.00  -0.00  -0.00  +2.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 
 I1 = 2,    I2 = 1,   I3 = 1,   I4 = 2,   I5 = 1,   I6 = 1,
{{AutoCat}}</text>
      <sha1>ihhf3zgv38wbv4lnjfwle1eeiv9vjxk</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/05c</title>
    <ns>0</ns>
    <id>82548</id>
    <revision>
      <id>745399</id>
      <timestamp>2025-06-26T15:23:43Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745399</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2410" sha1="2lqdfjyuh3mub223lnjt4lquhlnerjc" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/05a| '''Application''']]
:

Installer et compiler ces fichiers dans votre répertoire de travail.


[[File:Electrical Networks Using Linear Systems 1a.png|thumb|]]


{{Fichier|c00a.c|largeur=70%|info=|icon=Crystal128-source-c.svg}}
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
/* ------------------------------------ */
/*  Save as :   c00a.c                  */
/* ------------------------------------ */
#include &quot;w_a.h&quot;
/* ------------------------------------ */
#define   RA R4
#define   CA C4
#define   Cb C1
/* ------------------------------------ */
int main(void)
{
double ab[RA*(CA*C2+Cb*C2)]={
// I1       I2       I3    
   +1,+0,   +1,+0,   -1,+0,   +0,+0,    +0,  +0,
  -60,+0,  +30,+0,   +0,+0,   +0,+0,    +0,  +0,  
   +0,+0,  +30,+0,  +20,+0,   +0,+0,    +120,+0,
  +60,+0,   +0,+0,  +20,+0,   +0,+0,    +120,+0
};

double **Ab =   ca_A_mZ(ab,i_Abr_Ac_bc_mZ(RA,CA,Cb));
double **A  = c_Ab_A_mZ(Ab,i_mZ(RA,CA));
double **b  = c_Ab_b_mZ(Ab,i_mZ(RA,Cb));

  clrscrn();
  printf(&quot; A :&quot;);
  p_mRZ(A,S5,P0,C7);
  printf(&quot; b :&quot;);
  p_mRZ(b,S5,P0,C7);
  printf(&quot; Ab :&quot;);
  p_mRZ(Ab,S5,P0,C7);
  getchar();

  clrscrn();
  printf(&quot; Copy/Past into the octave window.\n\n&quot;);
  p_Octave_mZ(Ab,&quot;Ab&quot;,P0,P0);
  printf(&quot;\n rref(Ab,.00000000001)\n\n&quot;);
  printf(&quot;  gj_mZ(Ab) :\n\n&quot;
         &quot;   I1    I2    I3  &quot;);
  gj_mZ(Ab);
  p_mRZ(Ab,S5,P0,C7);
  stop();

  f_mZ(Ab);
  f_mZ(b);
  f_mZ(A);
  
  return 0;
}
/* ------------------------------------ */
/* ------------------------------------ */
&lt;/syntaxhighlight&gt; 
 

[[File:Electrical Networks Using Linear Systems 1b.png|thumb|]]

 '''Exemple de sortie écran :'''
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
 A :
   +1    +1    -1    +0 
  -60   +30    +0    +0 
   +0   +30   +20    +0 
  +60    +0   +20    +0 

 b :
   +0 
   +0 
 +120 
 +120 

 Ab :
   +1    +1    -1    +0    +0 
  -60   +30    +0    +0    +0 
   +0   +30   +20    +0  +120 
  +60    +0   +20    +0  +120 

 Copy/Past into the octave window.

 Ab=[
+1+0*i,+1+0*i,-1+0*i,+0+0*i,+0+0*i;
-60+0*i,+30+0*i,+0+0*i,+0+0*i,+0+0*i;
+0+0*i,+30+0*i,+20+0*i,+0+0*i,+120+0*i;
+60+0*i,+0+0*i,+20+0*i,+0+0*i,+120+0*i]


 rref(Ab,.00000000001)

  gj_mZ(Ab) :

   I1    I2    I3  
   +1    +0    +0    +0    +1 
   +0    +1    +0    +0    +2 
   +0    +0    +1    +0    +3 
   +0    +0    +0    +0    +0 

 Press return to continue. 
&lt;/syntaxhighlight&gt;

{{AutoCat}}</text>
      <sha1>2lqdfjyuh3mub223lnjt4lquhlnerjc</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/05e</title>
    <ns>0</ns>
    <id>82549</id>
    <revision>
      <id>745400</id>
      <timestamp>2025-06-26T15:27:03Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745400</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3893" sha1="n2h0k9uwvkreh1h6xh7543d4t4tpajd" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/05a| '''Application''']]
:


Installer et compiler ces fichiers dans votre répertoire de travail.


[[File:Electrical Networks Using Linear Systems 2a.png|thumb|]]


{{Fichier|c00b.c|largeur=70%|info=|icon=Crystal128-source-c.svg}}
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
/* ------------------------------------ */
/*  Save as :   c00b.c                 */
/* ------------------------------------ */
#include &quot;w_a.h&quot;
/* ------------------------------------ */
#define   RA R8
#define   CA C8
#define   Cb C1
/* ------------------------------------ */
int main(void)
{
double ab[RA*(CA*C2+Cb*C2)]={
//I1      I2      I3      I4      I5      I6    
  +1,+0,  -1,+0,  -1,+0,  +0,+0,  +0,+0,  +0,+0,  0,+0, 0,+0,    0,+0,
  +0,+0,  +0,+0,  +1,+0,  -1,+0,  -1,+0,  +0,+0,  0,+0, 0,+0,    0,+0,
  +0,+0,  +1,+0,  +0,+0,  +0,+0,  +1,+0,  -1,+0,  0,+0, 0,+0,    0,+0,
  -1,+0,  +0,+0,  +0,+0,  +1,+0,  +0,+0,  +1,+0,  0,+0, 0,+0,    0,+0,
  +0,+0, -50,+0,  +0,+0,  +0,+0,  +0,+0, -20,+0,  0,+0, 0,+0,  -90,+0,
  +0,+0, +50,+0, -20,+0,  +0,+0, -10,+0,  +0,+0,  0,+0, 0,+0,    0,+0,
  +0,+0,  +0,+0,  +0,+0, -50,+0, +10,+0, +20,+0,  0,+0, 0,+0,    0,+0,
  +0,+0,  +0,+0, -20,+0, -50,+0,  +0,+0,  +0,+0,  0,+0, 0,+0,  -90,+0
};

double **Ab = ca_A_mZ(ab,i_Abr_Ac_bc_mZ(RA,CA,Cb));
double **A  = c_Ab_A_mZ(Ab,i_mZ(RA,CA));
double **b  = c_Ab_b_mZ(Ab,i_mZ(RA,Cb));

  clrscrn();
  printf(&quot; Ab :\n&quot;
         &quot;  I1     I2     I3     I4     I5     I6 &quot;);
  p_mRZ(Ab,S6,P2,C9);
  getchar();

  clrscrn();
  printf(&quot; Copy/Past into the octave window.\n\n&quot;);
  p_Octave_mZ(Ab,&quot;Ab&quot;,P0,P0);
  printf(&quot;\n rref(Ab,.00000000001)\n\n&quot;);
  getchar();

  clrscrn();
  printf(&quot;  gj_mZ(Ab) :\n\n&quot;
         &quot;  I1     I2     I3     I4     I5     I6 &quot;);
  gj_mZ(Ab);
  p_mRZ(Ab,S6,P2,C9);
  stop();

  f_mZ(Ab);
  f_mZ(b);
  f_mZ(A);
  
  return 0;
}
/* ------------------------------------ */
/* ------------------------------------ */
&lt;/syntaxhighlight&gt; 
 

[[File:Electrical Networks Using Linear Systems 2b.png|thumb|]]

 '''Exemple de sortie écran :'''
&lt;syntaxhighlight lang=&quot;c&quot;&gt;

 Ab :
  I1     I2     I3     I4     I5     I6 
 +1.00  -1.00  -1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +1.00  -1.00  -1.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +1.00  +0.00  +0.00  +1.00  -1.00  +0.00  +0.00  +0.00 
 -1.00  +0.00  +0.00  +1.00  +0.00  +1.00  +0.00  +0.00  +0.00 
 +0.00 -50.00  +0.00  +0.00  +0.00 -20.00  +0.00  +0.00 -90.00 
 +0.00 +50.00 -20.00  +0.00 -10.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00 -50.00 +10.00 +20.00  +0.00  +0.00  +0.00 
 +0.00  +0.00 -20.00 -50.00  +0.00  +0.00  +0.00  +0.00 -90.00 


 Copy/Past into the octave window.

 Ab=[
+1+0*i,-1+0*i,-1+0*i,+0+0*i,+0+0*i,+0+0*i,+0+0*i,+0+0*i,+0+0*i;
+0+0*i,+0+0*i,+1+0*i,-1+0*i,-1+0*i,+0+0*i,+0+0*i,+0+0*i,+0+0*i;
+0+0*i,+1+0*i,+0+0*i,+0+0*i,+1+0*i,-1+0*i,+0+0*i,+0+0*i,+0+0*i;
-1+0*i,+0+0*i,+0+0*i,+1+0*i,+0+0*i,+1+0*i,+0+0*i,+0+0*i,+0+0*i;
+0+0*i,-50+0*i,+0+0*i,+0+0*i,+0+0*i,-20+0*i,+0+0*i,+0+0*i,-90+0*i;
+0+0*i,+50+0*i,-20+0*i,+0+0*i,-10+0*i,+0+0*i,+0+0*i,+0+0*i,+0+0*i;
+0+0*i,+0+0*i,+0+0*i,-50+0*i,+10+0*i,+20+0*i,+0+0*i,+0+0*i,+0+0*i;
+0+0*i,+0+0*i,-20+0*i,-50+0*i,+0+0*i,+0+0*i,+0+0*i,+0+0*i,-90+0*i]


 rref(Ab,.00000000001)

  gj_mZ(Ab) :

  I1     I2     I3     I4     I5     I6 
 +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +3.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 

 Press return to continue. 
&lt;/syntaxhighlight&gt;

{{AutoCat}}</text>
      <sha1>n2h0k9uwvkreh1h6xh7543d4t4tpajd</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/05g</title>
    <ns>0</ns>
    <id>82550</id>
    <revision>
      <id>745401</id>
      <timestamp>2025-06-26T15:32:24Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745401</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3758" sha1="qqgfvpek1jawholtcoz5gjenncqwui0" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/05a| '''Application''']]
:

Installer et compiler ces fichiers dans votre répertoire de travail.


[[File:Electrical Networks Using Linear Systems 3a.png|thumb|]]


{{Fichier|c00c.c|largeur=70%|info=|icon=Crystal128-source-c.svg}}
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
/* ------------------------------------ */
/*  Save as :   c00c.c                  */
/* ------------------------------------ */
#include &quot;w_a.h&quot;
/* ------------------------------------ */
#define   RA R8
#define   CA C8
#define   Cb C1
/* ------------------------------------ */
int main(void)
{
double ab[RA*(CA*C2+Cb*C2)]={
//   I1      I2      I3      I4      I5      I6    
     -1,+0,  +1,+0,  +1,+0,  +0,+0,  +0,+0,  +0,+0,  +0,+0,+0,+0,  +0,+0,
     +0,+0,  +0,+0,  -1,+0,  +1,+0,  -1,+0,  +0,+0,  +0,+0,+0,+0,  +0,+0,
     +0,+0,  +0,+0,  +0,+0,  -1,+0,  +1,+0,  +1,+0,  +0,+0,+0,+0,  +0,+0,
     +1,+0,  -1,+0,  +0,+0,  +0,+0,  +0,+0,  -1,+0,  +0,+0,+0,+0,  +0,+0,
    +15,+0, +60,+0,  +0,+0,  +0,+0,  +0,+0,  +0,+0,  +0,+0,+0,+0, +90,+0,
     +0,+0, -60,+0, +15,+0, +15,+0,  +0,+0, +15,+0,  +0,+0,+0,+0,  +0,+0,
     +0,+0,  +0,+0,  +0,+0, -15,+0, -60,+0,  +0,+0,  +0,+0,+0,+0, -90,+0,
    +15,+0,  +0,+0, +15,+0,  +0,+0, -60,+0, +15,+0,  +0,+0,+0,+0,  +0,+0
};    

double **Ab = ca_A_mZ(ab,i_Abr_Ac_bc_mZ(RA,CA,Cb));
double **A  = c_Ab_A_mZ(Ab,i_mZ(RA,CA));
double **b  = c_Ab_b_mZ(Ab,i_mZ(RA,Cb));

  clrscrn();
  printf(&quot; Ab :\n&quot;
         &quot;  I1     I2     I3     I4     I5     I6 &quot;);
  p_mRZ(Ab,S6,P2,C9);
  getchar();

  clrscrn();
  printf(&quot; Copy/Past into the octave window.\n\n&quot;);
  p_Octave_mZ(Ab,&quot;Ab&quot;,P0,P0);
  printf(&quot;\n rref(Ab,.00000000001)\n\n&quot;);
  getchar();

  clrscrn();
  printf(&quot;  gj_mZ(Ab) :\n\n&quot;
         &quot;  I1     I2     I3     I4     I5     I6 &quot;);
  gj_mZ(Ab);
  p_mRZ(Ab,S6,P2,C9);
  stop();

  f_mZ(Ab);
  f_mZ(b);
  f_mZ(A);
  
  return 0;
}
/* ------------------------------------ */
/* ------------------------------------ */
&lt;/syntaxhighlight&gt; 
 

[[File:Electrical Networks Using Linear Systems 3b.png|thumb|]]

 '''Exemple de sortie écran :'''
&lt;syntaxhighlight lang=&quot;c&quot;&gt;
 ------------------------------------ 
 Ab :
  I1     I2     I3     I4     I5     I6 
 -1.00  +1.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  -1.00  +1.00  -1.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  -1.00  +1.00  +1.00  +0.00  +0.00  +0.00 
 +1.00  -1.00  +0.00  +0.00  +0.00  -1.00  +0.00  +0.00  +0.00 
+15.00 +60.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 +90.00 
 +0.00 -60.00 +15.00 +15.00  +0.00 +15.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00 -15.00 -60.00  +0.00  +0.00  +0.00 -90.00 
+15.00  +0.00 +15.00  +0.00 -60.00 +15.00  +0.00  +0.00  +0.00 


 ------------------------------------ 
 Copy/Past into the octave window.

 Ab=[
-1,+1,+1,+0,+0,+0,+0,+0,+0;
+0,+0,-1,+1,-1,+0,+0,+0,+0;
+0,+0,+0,-1,+1,+1,+0,+0,+0;
+1,-1,+0,+0,+0,-1,+0,+0,+0;
+15,+60,+0,+0,+0,+0,+0,+0,+90;
+0,-60,+15,+15,+0,+15,+0,+0,+0;
+0,+0,+0,-15,-60,+0,+0,+0,-90;
+15,+0,+15,+0,-60,+15,+0,+0,+0]


 rref(Ab,.00000000001)


 ------------------------------------ 
  gj_TP_mR(Ab) :

  I1     I2     I3     I4     I5     I6 
 +1.00  -0.00  -0.00  +0.00  -0.00  +0.00  -0.00  -0.00  +2.00 
 +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +0.00  +2.00 
 +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +1.00  +0.00  +0.00  +1.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 
 +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00  +0.00 

 Press return to continue. 
&lt;/syntaxhighlight&gt;

{{AutoCat}}</text>
      <sha1>qqgfvpek1jawholtcoz5gjenncqwui0</sha1>
    </revision>
  </page>
  <page>
    <title>Mathc complexes/05h</title>
    <ns>0</ns>
    <id>82551</id>
    <revision>
      <id>745459</id>
      <timestamp>2025-06-27T11:54:44Z</timestamp>
      <contributor>
        <username>Xhungab</username>
        <id>23827</id>
      </contributor>
      <comment>news</comment>
      <origin>745459</origin>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="838" sha1="kwqp01j6dou75ikihks3jimpngqcn3j" xml:space="preserve">__NOTOC__
[[Catégorie:Mathc complexes (livre)]]
:
[[Mathc complexes/a26| '''Gauss-Jordan''']]
:

{{Partie{{{type|}}}|Equilibrer une équation chimique }}


&lt;math&gt;\mathrm{x_1CH_4 + x_2O_2 \longrightarrow x_3CO_2 + x_4H_2O}&lt;/math&gt;

* [[Mathc complexes/05i| Créer le système]]
* [[Mathc complexes/05j| Résoudre le système]]
* [[Mathc complexes/05k| Calculer les coefficients]]


&lt;math&gt;\mathrm{x_1C_3H_8 +x_2O_2 \longrightarrow x_3CO_2+ x_4H_2O}&lt;/math&gt;

* [[Mathc complexes/05l| Créer le système]]
* [[Mathc complexes/05m| Résoudre le système]]
* [[Mathc complexes/05n| Calculer les coefficients]]


&lt;math&gt;\mathrm{x_1NH_3 + x_2O_2 \longrightarrow x_3NO + x_4H_2O}&lt;/math&gt;

* [[Mathc complexes/05o| Créer le système]]
* [[Mathc complexes/05p| Résoudre le système]]
* [[Mathc complexes/05q| Calculer les coefficients]]


{{AutoCat}}</text>
      <sha1>kwqp01j6dou75ikihks3jimpngqcn3j</sha1>
    </revision>
  </page>
</mediawiki>