Vraag Exotische architecturen waar de normcommissies voor zorgen


Ik weet dat de C- en C ++ -standaarden vele aspecten van de taalimplementatie verlaten, alleen omdat als er een architectuur met andere kenmerken is, het erg moeilijk of onmogelijk zou zijn om er een standaard conforme compiler voor te schrijven.

Ik weet dat 40 jaar geleden elke computer zijn eigen unieke specificatie had. Ik ken echter geen van de momenteel gebruikte architecturen waarin:

  • CHAR_BIT != 8
  • signed is niet het complement van twee (ik hoorde dat Java hier problemen mee had).
  • Drijvende komma voldoet niet aan IEEE 754 (bewerken: ik bedoel "niet in IEEE 754 binaire codering").

De reden waarom ik vraag is dat ik mensen vaak uitleg dat het goed is dat C ++ geen andere low-level aspecten zoals fixed sized types oplegt. Het is goed, omdat het in tegenstelling tot 'andere talen' uw code draagbaar maakt als het correct wordt gebruikt (Bewerken: omdat het kan worden geporteerd naar meer architecturen zonder emulatie van aspecten op een laag niveau van de machine, zoals bijv. Twee-complement rekenkunde op teken + magnitude-architectuur) . Maar ik voel me slecht dat ik zelf niet op een specifieke architectuur kan wijzen.

Dus de vraag is: welke architecturen vertonen de bovengenoemde eigenschappen?

uint*_ts zijn optioneel.


139
2017-08-07 09:30


oorsprong


antwoorden:


Bekijk deze eens

Unisys ClearPath Dorado-servers

het aanbieden van achterwaartse compatibiliteit voor mensen die nog niet al hun Univac-software hebben gemigreerd.

Belangrijkste punten:

  • 36-bits woorden
  • CHAR_BIT == 9
  • iemands complement
  • 72-bit non-IEEE floating point
  • afzonderlijke adresruimte voor code en gegevens
  • -Word aangepakt
  • geen speciale stack-pointer

Weet niet of ze een C ++ - compiler aanbieden, maar ze kon.


En nu is er een link naar een recente editie van hun C-handleiding opgedoken:

Referentiehandleiding Unisys C Compiler Programming

Paragraaf 4.5 heeft een tabel met gegevenstypen met 9, 18, 36 en 72 bits.

enter image description here


104
2017-08-07 11:40



Geen van je veronderstellingen geldt voor mainframes. Om te beginnen, ik weet het niet van een mainframe dat IEEE 754 gebruikt: IBM gebruikt basispunt 16 drijvende komma, en beide Unisys-mainframes gebruiken base 8. De Unisys-machines zijn een beetje speciaal in veel andere opzichten: Bo heeft de 2200-architectuur genoemd, maar de MPS-architectuur is nog vreemder: woorden met 48-bits tags. (Of het woord nu een pointer is of niet, hangt af van een bit in het woord.) En de numerieke representaties zijn zo ontworpen dat er geen echte is onderscheid tussen drijvend punt en integraal rekenen: het zweven punt is basis 8; het vereist geen normalisatie, en in tegenstelling tot elk andere zwevende punt die ik heb gezien, wordt het decimaalteken rechts van de mantisse, in plaats van links, en gebruikt de ondertekende magnitude voor de exponent (in aanvulling op de mantisse). Met de resultaten die een integrale drijvende-kommawaarde heeft (of kan) exact hetzelfde bit hebben representatie als een geheel getal met een ondertekende magnitude. En er zijn geen zwevende punt rekenkundige instructies: als de exponenten van de twee waarden zijn beide 0, de instructie integraal rekenkundig, anders wel drijvende komma rekenkunde. (Een voortzetting van de taggingfilosofie in de architectuur.) Dat betekent dat terwijl intmag 48 bits, 8 in beslag nemen van hen moet 0 zijn, anders zal de waarde niet als een geheel getal worden behandeld.


47
2017-08-07 23:02



Volledige naleving van IEEE 754 is zeldzaam in drijvende-komma-implementaties. En het verzwakken van de specificatie in dat opzicht maakt veel optimalisaties mogelijk.

De subnorm-ondersteuning verschilt bijvoorbeeld tussen x87 en SSE.

Optimalisaties zoals het fuseren van een vermenigvuldiging en toevoeging die gescheiden waren in de broncode, veranderen de resultaten enigszins, maar het is een goede optimalisatie op sommige architecturen.

Of op x86 strenge IEEE-naleving kan vereisen dat bepaalde vlaggen worden ingesteld of extra overdrachten tussen drijvende-komma-registers en normaal geheugen om het te dwingen het opgegeven zwevende-kommatortype te gebruiken in plaats van de interne 80-bits drijvers.

En sommige platforms hebben helemaal geen vlotters voor hardware en moeten ze dus in software emuleren. En sommige vereisten van IEEE 754 kunnen duur zijn om in software te implementeren. Vooral de afrondingsregels kunnen een probleem zijn.

Mijn conclusie is dat je geen exotische architectuur nodig hebt om in situaties terecht te komen waarin je niet altijd een strikte naleving van IEEE wilt garanderen. Om deze reden garandeerden weinig programmeertalen strikte IEEE-conformiteit.


38
2017-08-07 09:38



ik vond deze link vermeldt een aantal systemen waar CHAR_BIT != 8. Ze bevatten

sommige TI DSP's hebben CHAR_BIT == 16

BlueCore-5-chip (een Bluetooth   chip van Cambridge Silicon Radio) die heeft CHAR_BIT == 16.

En natuurlijk is er een vraag over Stack Overflow: Welke platforms hebben iets anders dan 8-bits tekens

Wat betreft niet-twee-complement-systemen is er een interessante samenvatting comp.lang.c ++. gemodereerd. Samengevat: er zijn platforms met een 'complement- of teken- en magnitude-weergave.


38
2017-08-07 09:38



Ik ben er vrij zeker van dat VAX-systemen nog steeds in gebruik zijn. Ze ondersteunen geen IEEE floating-point; ze gebruiken hun eigen formaten. Alpha ondersteunt zowel VAX- als IEEE-drijvende-komma-indelingen.

Cray-vectormachines, zoals de T90, hebben ook hun eigen drijvende-komma-indeling, hoewel nieuwere Cray-systemen IEEE gebruiken. (De T90 die ik gebruikte, werd enkele jaren geleden buiten gebruik gesteld, ik weet niet of er nog steeds een actief apparaat wordt gebruikt.)

De T90 had / heeft ook enkele interessante representaties voor aanwijzers en integers. Een native adres kan alleen naar een 64-bits woord verwijzen. De compilers C en C ++ hadden CHAR_BIT == 8 (noodzakelijk omdat het Unicos draaide, een smaak van Unix, en moest samenwerken met andere systemen), maar een native adres kon alleen naar een 64-bits woord verwijzen. Alle byte-niveau-bewerkingen werden gesynthetiseerd door de compiler en a void* of char* opgeslagen een byte-offset in de hoge orde 3 bits van het woord. En ik denk dat sommige typen integer padding bits hadden.

IBM-mainframes zijn een ander voorbeeld.

Aan de andere kant hoeven deze specifieke systemen dat niet te doen nodig sluit wijzigingen in de taalstandaard uit. Cray toonde geen bijzonder belang bij het upgraden van zijn C-compiler naar C99; vermoedelijk is hetzelfde van toepassing op de C ++ - compiler. Het macht redelijk zijn om de vereisten aan te scherpen voor gehoste implementaties, zoals het vereisen van CHAR_BIT == 8, drijvende-komma in IEEE-indeling, of niet de volledige semantiek, en 2's-aanvulling zonder opvulbits voor getekende gehele getallen. Oude systemen zouden eerdere taalstandaarden kunnen blijven ondersteunen (C90 stierf niet toen C99 uitkwam), en de vereisten zouden losser kunnen zijn voor vrijstaande implementaties (ingebedde systemen) zoals DSP's.

Aan de andere kant kunnen er goede redenen voor zijn toekomst systemen om dingen te doen die vandaag als exotisch zouden worden beschouwd.


22
2017-08-08 17:46



CHAR_BITS

Volgens gcc broncode:

CHAR_BIT is 16 bits voor 1750a, dsp16xx architecturen.
CHAR_BIT is 24 bits voor dsp56k architectuur.
CHAR_BIT is 32 bits voor c4x architectuur.

Je kunt gemakkelijk meer vinden door te doen:

find $GCC_SOURCE_TREE -type f | xargs grep "#define CHAR_TYPE_SIZE"

of

find $GCC_SOURCE_TREE -type f | xargs grep "#define BITS_PER_UNIT"

als CHAR_TYPE_SIZE is passend gedefinieerd.

IEEE 754-conformiteit

Als de doelarchitectuur geen floating point-instructies ondersteunt, gcc kan software fallback genereren die standaard niet standaard voldoet. Meer dan speciale opties (zoals -funsafe-math-optimizations heks schakelt ook het behoud van tekens voor nullen uit) kan worden gebruikt.


14
2017-10-13 15:03



IEEE 754 binaire weergave was tot voor kort ongebruikelijk op GPU's, zie GPU Floating-Point Paranoia.

EDIT: in de opmerkingen is een vraag gerezen of het floating point van de GPU relevant is voor de gebruikelijke computerprogrammering, los van de grafische weergave. Jazeker! De meeste high-performance dingen die tegenwoordig industrieel worden berekend, worden gedaan op GPU's; de lijst bevat AI, datamining, neurale netwerken, fysieke simulaties, weersvoorspelling en nog veel meer. Een van de links in de opmerkingen laat zien waarom: orde van grootte drijvende-kommawinst van GPU's.

Iets anders dat ik zou willen toevoegen, dat relevanter is voor de OP-vraag: wat deden mensen 10-15 jaar geleden toen GPU-drijvend punt niet IEEE was en wanneer er geen API zoals vandaag OpenCL of CUDA was om GPU's te programmeren? Geloof het of niet, vroege GPU-compu- terpioniers zijn erin geslaagd programmeer GPU's zonder een API om dat te doen! Ik ontmoette een van hen in mijn gezelschap. Dit is wat hij deed: hij codeerde de gegevens die hij nodig had om te berekenen als een afbeelding met pixels die de waarden vertegenwoordigden waar hij aan werkte, gebruikte vervolgens OpenGL om de bewerkingen uit te voeren die hij nodig had (zoals "Gaussiaanse vervaging" om een ​​convolutie te vertegenwoordigen met een normale verdeling , enz.), en decodeerde het resulterende beeld weer in een reeks resultaten. En dit was nog steeds sneller dan met CPU!

Dit heeft NVidia ertoe aangezet om hun interne gegevens uiteindelijk binair compatibel te maken met IEEE en een API te introduceren die is gericht op berekening in plaats van beeldmanipulatie.


6
2017-10-13 16:37