278 lines
7.4 KiB
Markdown
278 lines
7.4 KiB
Markdown
# 40. Targets, plateformes, architectures, ABI, distributions et capabilities
|
|
|
|
## 40.1 Dimensions orthogonales — V1 REQUIS — FIGÉES
|
|
|
|
La Bible distingue explicitement :
|
|
|
|
```text
|
|
TargetFamily
|
|
Platform
|
|
Architecture
|
|
ABI
|
|
Distribution
|
|
Capability
|
|
Feature
|
|
ArtifactKind
|
|
ExportFormat
|
|
```
|
|
|
|
Ces dimensions ne doivent pas être fusionnées dans une chaîne opaque ni confondues entre elles.
|
|
|
|
Une cible de compilation concrète est décrite par la combinaison des dimensions pertinentes.
|
|
|
|
## 40.2 Représentation Core des domaines — V1 REQUIS — FIGÉE EN PRINCIPE
|
|
|
|
Le choix entre `enum` et type d'identifiant extensible dépend de la nature sémantique du domaine, et non d'une tentative de protéger artificiellement V1/V2 contre toute évolution.
|
|
|
|
Les domaines naturellement fermés pour une version donnée peuvent être des `enum` Core, par exemple :
|
|
|
|
```text
|
|
Endianness
|
|
PackageType
|
|
Linkage
|
|
Deployment
|
|
```
|
|
|
|
Une valeur peut être ajoutée ou une représentation corrigée pendant V1/V2 si un besoin réel apparaît. Ces générations étant internes, un tel changement peut nécessiter l'adaptation simultanée du compilateur, du Core, du SDK et des outils.
|
|
|
|
Les domaines intrinsèquement ouverts ou liés à l'écosystème externe sont de meilleurs candidats à des types d'identifiants compiler/Core-known extensibles, notamment :
|
|
|
|
```text
|
|
Platform
|
|
Architecture
|
|
ABI
|
|
Distribution
|
|
Capability
|
|
ArtifactKind
|
|
ExportFormat
|
|
```
|
|
|
|
`TargetFamily` peut être un `enum` ou un identifiant extensible selon la forme finale retenue pendant l'implémentation V1 ; cette décision ne doit pas modifier le modèle du manifest.
|
|
|
|
Exemples de valeurs compiler-known :
|
|
|
|
```text
|
|
Platform::Linux
|
|
Platform::Windows
|
|
Architecture::X86_64
|
|
Architecture::AArch64
|
|
ABI::Gnu
|
|
Distribution::Debian
|
|
Capability::FileSystem
|
|
ArtifactKind::NativeExecutable
|
|
```
|
|
|
|
La représentation binaire/interne exacte de ces types reste une décision du Core/toolchain V1. Avant la première baseline publique V3+, la priorité est la cohérence sémantique et l'absence de verrou architectural inutile.
|
|
|
|
## 40.3 Target families — V1 REQUIS / RÉSERVÉ
|
|
|
|
V1 doit réellement supporter le chemin LLVM pour au minimum :
|
|
|
|
```text
|
|
Native
|
|
Embedded
|
|
```
|
|
|
|
Les familles suivantes doivent être réservables sans refonte du modèle :
|
|
|
|
```text
|
|
Browser
|
|
Wasm
|
|
Jvm
|
|
JavaScript
|
|
```
|
|
|
|
D'autres familles futures pourront être ajoutées sans changer la forme du manifest.
|
|
|
|
L'interpréteur V1 est un moteur d'exécution Saselang et n'est pas confondu avec une `TargetFamily` machine.
|
|
|
|
## 40.4 Platforms — V1 REQUIS / RÉSERVÉ
|
|
|
|
Le modèle doit pouvoir représenter notamment :
|
|
|
|
```text
|
|
Linux
|
|
Windows
|
|
MacOS
|
|
FreeBSD
|
|
Android
|
|
iOS
|
|
None
|
|
```
|
|
|
|
`None` représente une cible sans OS, notamment bare-metal/embedded.
|
|
|
|
La liste n'est pas fermée.
|
|
|
|
## 40.5 Architectures — V1 REQUIS / RÉSERVÉ
|
|
|
|
Le modèle doit au minimum être capable de représenter les grandes familles que LLVM peut cibler, notamment :
|
|
|
|
```text
|
|
X86
|
|
X86_64
|
|
Arm
|
|
AArch64
|
|
RiscV32
|
|
RiscV64
|
|
Wasm32
|
|
```
|
|
|
|
La liste exacte officiellement validée par Saselang V1 dépend de la toolchain LLVM/runtime/sysroot disponibles ; le modèle ne doit pas l'empêcher d'évoluer.
|
|
|
|
## 40.6 ABI — V1 REQUIS / RÉSERVÉ
|
|
|
|
Le modèle doit pouvoir représenter notamment :
|
|
|
|
```text
|
|
Gnu
|
|
Musl
|
|
Msvc
|
|
Darwin
|
|
Eabi
|
|
Eabihf
|
|
None
|
|
```
|
|
|
|
Saselang peut utiliser les triples LLVM en interne, mais le triple LLVM brut n'est pas la seule abstraction publique du target.
|
|
|
|
## 40.7 Distribution — V1 RÉSERVÉ / FUTUR V3+
|
|
|
|
`Distribution` est distincte de `Platform` et de l'ABI.
|
|
|
|
Elle doit pouvoir représenter à terme des familles telles que :
|
|
|
|
```text
|
|
Debian
|
|
Ubuntu
|
|
Rhel
|
|
Fedora
|
|
Arch
|
|
Alpine
|
|
```
|
|
|
|
ainsi que leur version lorsque pertinente.
|
|
|
|
Cette dimension sert principalement à :
|
|
|
|
```text
|
|
résoudre/découvrir des dépendances système ;
|
|
exprimer des contraintes d'environnement de distribution ;
|
|
produire des packages/export formats spécifiques.
|
|
```
|
|
|
|
Elle n'est pas requise pour toute compilation native V1.
|
|
|
|
## 40.8 Capabilities — V1 REQUIS — SQUELETTE FIGÉ
|
|
|
|
Les capabilities décrivent des capacités réelles de l'environnement et non des options libres du package.
|
|
|
|
V1 doit pouvoir représenter au minimum :
|
|
|
|
```text
|
|
Heap
|
|
FileSystem
|
|
Environment
|
|
Process
|
|
Threads
|
|
Network
|
|
Sockets
|
|
Clock
|
|
DynamicLoading
|
|
SharedMemory
|
|
StandardInput
|
|
StandardOutput
|
|
StandardError
|
|
```
|
|
|
|
Le modèle doit aussi permettre de décrire les capacités atomiques pertinentes sans supposer qu'elles sont identiques sur tous les targets.
|
|
|
|
Une capability statique signifie que l'environnement fournit la capacité ; elle ne garantit pas qu'une opération runtime particulière réussira.
|
|
|
|
## 40.9 Propriétaires et identifiants de capabilities — V1 REQUIS — DIRECTION FIGÉE
|
|
|
|
Les capabilities utilisent une nomenclature hiérarchique commune, ASCII, en minuscules, séparée par `.`.
|
|
|
|
Le premier segment identifie le propriétaire sémantique :
|
|
|
|
```text
|
|
language.*
|
|
core.*
|
|
target.*
|
|
platform.*
|
|
sdk.*
|
|
```
|
|
|
|
Exemples conceptuels :
|
|
|
|
```text
|
|
language.exceptions
|
|
core.numeric.float128
|
|
core.collections.array
|
|
target.atomic.int64
|
|
target.simd.float32
|
|
platform.filesystem
|
|
platform.network
|
|
sdk.logging
|
|
```
|
|
|
|
Cette organisation permet de regrouper les capacités par propriétaire et d'éviter un registre global plat.
|
|
|
|
Les noms exacts et le registre exhaustif seront stabilisés avec le Core/SDK, mais un même concept ne doit pas recevoir des conventions concurrentes telles que `hasFloat128`, `supports_float128` et `numeric-f128`.
|
|
|
|
Les packages utilisateurs ne doivent pas usurper les espaces de noms de capabilities réservés à la toolchain/Core/SDK.
|
|
|
|
## 40.10 Niveaux de capacité — V1 REQUIS — FIGÉ EN PRINCIPE
|
|
|
|
Trois niveaux conceptuels sont distingués :
|
|
|
|
```text
|
|
Language-required
|
|
sémantique nécessaire à tout compilateur Saselang conforme
|
|
|
|
Core-required-for-supported-type
|
|
contrat Core obligatoire dès que le type/capacité fondamentale existe
|
|
sur le target
|
|
|
|
Core/target optional capability
|
|
fonctionnalité réellement optionnelle ou spécifique d'un environnement
|
|
```
|
|
|
|
Exemple : si un target supporte `float128`, les conversions Core fondamentales définies par la matrice numérique pour `float128` doivent être disponibles.
|
|
|
|
Le target ne peut pas exposer `float128` tout en supprimant arbitrairement certaines conversions fondamentales simplement parce que le matériel n'offre pas une instruction native correspondante.
|
|
|
|
## 40.11 Émulation logicielle — V1 REQUIS — FIGÉ
|
|
|
|
Lorsqu'une fonctionnalité fondamentale peut raisonnablement être émulée de façon conforme, l'absence d'un support matériel natif ne la rend pas indisponible.
|
|
|
|
```text
|
|
instruction native disponible
|
|
lowering/backend direct ou optimisé
|
|
|
|
instruction native absente
|
|
implémentation logicielle conforme
|
|
```
|
|
|
|
La différence doit porter sur les performances, pas sur la sémantique visible.
|
|
|
|
Un target réellement contraint peut ne pas fournir un type/capacité fondamentale entière. Dans ce cas, le diagnostic doit porter sur cette capacité ou ce type, plutôt que sur l'absence aléatoire d'une méthode secondaire.
|
|
|
|
## 40.12 Compatibilité target/dépendance — V1 REQUIS — FIGÉE EN PRINCIPE
|
|
|
|
Un package ou une dépendance peut déclarer des contraintes de target/platform/ABI/capabilities.
|
|
|
|
Le resolver/build doit détecter les incompatibilités avant la compilation effective lorsqu'elles sont déterminables.
|
|
|
|
Une dépendance native peut fournir des mappings distincts selon :
|
|
|
|
```text
|
|
TargetFamily
|
|
Platform
|
|
Architecture
|
|
ABI
|
|
Distribution
|
|
```
|
|
|
|
sans changer son identité logique `vendor/package@requirement`.
|