Architectures exotiques qui intéressent les comités de normalisation
Je sais que les normes C et C++ laissent de nombreux aspects du langage définis par l'implémentation simplement parce que s'il existe une architecture avec d'autres caractéristiques, il serait très difficile, voire impossible, d'écrire un compilateur conforme aux normes pour cela.
Je sais qu'il y a 40 ans, chaque ordinateur avait ses propres spécifications. Cependant, je ne connais aucune architecture utilisée aujourd'hui où:
CHAR_BIT != 8signedn'est pas un complément à deux (j'ai entendu Java a eu des problèmes avec celui-ci).- Le point flottant n'est pas conforme à la norme IEEE 754 (Edit: je voulais dire "pas dans l'encodage binaire IEEE 754").
La raison pour laquelle je pose la question est que j'explique souvent aux gens qu'il est bon que C++ n'impose aucun autre aspect de bas niveau comme les types de taille fixe†. C'est bien parce que contrairement aux `` autres langages '', il rend votre code portable lorsqu'il est utilisé correctement (Edit: car il peut être porté sur plus d'architectures sans nécessiter d'émulation des aspects de bas niveau de la machine, comme par exemple l'arithmétique du complément à deux sur l'architecture signe + amplitude) . Mais je me sens mal de ne pas pouvoir pointer moi-même vers une architecture spécifique.
La question est donc: quelles architectures présentent les propriétés ci-dessus?
† uint*_ts sont facultatifs.
Jetez un oeil à celui-ci
Serveurs Unisys ClearPath Dorado
offrant une compatibilité descendante pour les personnes qui n'ont pas encore migré tous leurs logiciels Univac.
Points clés:
- Mots de 36 bits
CHAR_BIT == 9- son complément
- Virgule flottante non IEEE 72 bits
- espace d'adressage séparé pour le code et les données
- Adressé par mot
- pas de pointeur de pile dédié
Je ne sais pas s'ils proposent un compilateur C++, mais ils pourraient .
Et maintenant, un lien vers une édition récente de leur manuel C est apparu:
Manuel de référence de programmation du compilateur Unisys C
La section 4.5 contient un tableau des types de données avec 9, 18, 36 et 72 bits.
Aucune de vos hypothèses ne s'applique aux mainframes. Pour commencer, je ne connais pas de mainframe qui utilise IEEE 754: IBM utilise la virgule flottante base 16, et les deux mainframes Unisys utilisent la base 8. Les machines Unisys sont un peu spéciales à bien d'autres égards: Bo a mentionné le 2200 architecture, mais l'architecture MPS est encore plus étrange: mots balisés 48 bits. (Que le mot soit ou non un pointeur dépend d'un peu du mot.) Et les représentations numériques sont conçues de manière à ce qu'il n'y ait pas de réelle distinction entre virgule flottante et arithmétique intégrale: le point flottant est la base 8; il ne nécessite pas de normalisation, et contrairement à tous les autres virgules flottantes que j'ai vues, il place la décimale à droite de la mantisse, plutôt qu'à gauche, et utilise une amplitude signée pour l'exposant (en plus de la mantisse). Avec les résultats qu'une valeur à virgule flottante intégrale a (ou peut avoir) exactement la même représentation binaire qu'un entier de magnitude signé. Et il n'y a pas d'instructions arithmétiques à virgule flottante: si les exposants des deux valeurs sont tous les deux 0, l'instruction fait de l'arithmétique intégrale, sinon, elle fait de l'arithmétique à virgule flottante. (Une continuation de la philosophie de balisage dans l'architecture.) Ce qui signifie que tandis que int peut occuper 48 bits, 8 d'entre eux doivent être 0, sinon la valeur ne sera pas traitée comme un entier.
La pleine conformité IEEE 754 est rare dans les implémentations à virgule flottante. Et l'affaiblissement des spécifications à cet égard permet de nombreuses optimisations.
Par exemple, le support subnorm diffère entre x87 et SSE.
Les optimisations telles que la fusion d'une multiplication et d'un ajout qui étaient séparés dans le code source modifient légèrement les résultats aussi, mais c'est une optimisation agréable sur certaines architectures.
Ou sur x86, la stricte conformité IEEE peut nécessiter la définition de certains indicateurs ou des transferts supplémentaires entre les registres à virgule flottante et la mémoire normale pour l'obliger à utiliser le type à virgule flottante spécifié au lieu de ses flottants 80 bits internes.
Et certaines plates-formes n'ont aucun flotteur matériel et doivent donc les émuler dans un logiciel. Et certaines des exigences de l'IEEE 754 peuvent être coûteuses à implémenter dans les logiciels. En particulier, les règles d'arrondi pourraient poser problème.
Ma conclusion est que vous n'avez pas besoin d'architectures exotiques pour entrer dans des situations où vous ne voulez pas toujours garantir une stricte conformité IEEE. Pour cette raison, peu de langages de programmation garantissent une stricte conformité IEEE.
J'ai trouvé ce lien énumérant certains systèmes où CHAR_BIT != 8. Ils incluent
certains TI DSP ont
CHAR_BIT == 16Puce BlueCore-5 (une puce Bluetooth de Cambridge Silicon Radio) qui a
CHAR_BIT == 16.
Et bien sûr, il y a une question sur Stack Overflow: Quelles plates-formes ont autre chose que le caractère 8 bits
En ce qui concerne les systèmes à complément non deux, il y a une lecture intéressante sur comp.lang.c ++. Modéré . En résumé: il existe des plateformes ayant leur complément ou leur représentation de signe et de magnitude.
Je suis assez sûr que les systèmes VAX sont toujours utilisés. Ils ne prennent pas en charge la virgule flottante IEEE; ils utilisent leurs propres formats. Alpha prend en charge les formats à virgule flottante VAX et IEEE.
Les machines à vecteurs Cray, comme le T90, ont également leur propre format à virgule flottante, bien que les nouveaux systèmes Cray utilisent IEEE. (Le T90 que j'ai utilisé a été mis hors service il y a quelques années; je ne sais pas s'il en existe encore.)
Le T90 avait également/a quelques représentations intéressantes pour les pointeurs et les entiers. Une adresse native ne peut pointer que vers un mot 64 bits. Les compilateurs C et C++ avaient CHAR_BIT == 8 (nécessaire car il exécutait Unicos, une version d'Unix, et devait interagir avec d'autres systèmes), mais une adresse native ne pouvait pointer que vers un mot 64 bits. Toutes les opérations au niveau octet ont été synthétisées par le compilateur, et un void* ou char* a stocké un décalage d'octet dans les 3 bits de poids fort du mot. Et je pense que certains types entiers avaient des bits de remplissage.
Les mainframes IBM sont un autre exemple.
D'un autre côté, ces systèmes particuliers n'ont pas besoin nécessairement d'empêcher les modifications de la norme de langage. Cray n'a montré aucun intérêt particulier pour la mise à niveau de son compilateur C vers C99; probablement la même chose appliquée au compilateur C++. Il pourrait être raisonnable de resserrer les exigences pour les implémentations hébergées, comme exiger CHAR_BIT == 8, le format IEEE à virgule flottante sinon la sémantique complète, et le complément à 2 sans bits de remplissage pour les entiers signés. Les anciens systèmes pouvaient continuer à prendre en charge les normes de langage antérieures (C90 n'est pas mort lors de la sortie de C99), et les exigences pourraient être plus lâches pour les implémentations autonomes (systèmes embarqués) tels que les DSP.
D'un autre côté, il pourrait y avoir de bonnes raisons pour que les systèmes futurs fassent des choses qui seraient considérées comme exotiques aujourd'hui.
CHAR_BITS
Selon gcc code source:
CHAR_BIT est 16 bits pour les architectures 1750a, dsp16xx.CHAR_BIT est 24 bits pour dsp56k architecture.CHAR_BIT est 32 bits pour l'architecture c4x.
Vous pouvez facilement en trouver plus en faisant:
find $GCC_SOURCE_TREE -type f | xargs grep "#define CHAR_TYPE_SIZE"
ou
find $GCC_SOURCE_TREE -type f | xargs grep "#define BITS_PER_UNIT"
si CHAR_TYPE_SIZE est correctement défini.
Conformité IEEE 754
Si l'architecture cible ne prend pas en charge les instructions à virgule flottante, gcc peut générer un logiciel de secours qui n'est pas conforme aux normes par défaut. Plus que des options spéciales (comme -funsafe-math-optimizations qui désactive également la préservation des signes pour les zéros) peut être utilisé.
La représentation binaire IEEE 754 était rare sur les GPU jusqu'à récemment, voir GPU Floating-Point Paranoia .
EDIT: une question a été soulevée dans les commentaires si la virgule flottante GPU est pertinente pour la programmation informatique habituelle, sans rapport avec les graphiques. Putain, oui! La chose la plus performante actuellement calculée industriellement se fait sur les GPU; la liste comprend l'IA, l'exploration de données, les réseaux de neurones, les simulations physiques, les prévisions météorologiques et bien plus encore. L'un des liens dans les commentaires montre pourquoi: un ordre de grandeur avantage en virgule flottante des GPU.
Une autre chose que j'aimerais ajouter, qui est plus pertinente pour la question OP: qu'est-ce que les gens faisaient il y a 10-15 ans lorsque le virgule flottante GPU n'était pas IEEE et quand il n'y avait pas d'API comme OpenCL ou CUDA d'aujourd'hui pour programmer les GPU? Croyez-le ou non, les premiers pionniers de l'informatique GPU ont réussi à programmer des GPU sans API pour le faire ! J'en ai rencontré un dans mon entreprise. Voici ce qu'il a fait: il a encodé les données dont il avait besoin pour calculer comme une image avec des pixels représentant les valeurs sur lesquelles il travaillait, puis a utilisé OpenGL pour effectuer les opérations dont il avait besoin (comme "flou gaussien" pour représenter une convolution avec une distribution normale , etc.) et décodé l'image résultante dans un tableau de résultats. Et c'était encore plus rapide que d'utiliser le CPU!
Des choses comme ça ont incité NVidia à enfin rendre leurs données internes binaires compatibles avec IEEE et à introduire une API orientée sur le calcul plutôt que sur la manipulation d'images.