# 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`.