Calcul pe 31 de biți - 31-bit computing

În arhitectura computerului , numere întregi de 31 de biți , adrese de memorie sau alte unități de date sunt cele care au o lățime de 31 de biți .

În 1983, IBM a introdus adresarea de 31 de biți în arhitectura mainframe System / 370 -XA ca o actualizare la fizica și virtuala de 24 de biți și fizică de 24 de biți / virtuală / 26 de biți , adresarea modelelor anterioare. Această îmbunătățire a permis spațiilor de adresă să fie de 128 de ori mai mari, permițând programelor să adreseze memoria de peste 16  MB (denumită „deasupra liniei”). Au fost incluse asistență pentru COBOL , FORTRAN și ulterior pe Linux / 390 .

La începutul anilor 1980, a fost introdus Motorola 68012 ; avea date pe 32 de biți și registre de adrese, așa cum a făcut Motorola 68010 , dar în loc să furnizeze cei 24 de biți inferiori ai unei adrese pe pinii de adresă, a furnizat toți, cu excepția bitului 30, pe pinii de adresă.

Mainframe-uri IBM pe 31 de biți

Arhitectură

În arhitecturile System / 360 , altele decât arhitecturile 360/67 și System / 370 timpurii , registrele cu scop general aveau o lățime de 32 de biți, mașina făcea operații aritmetice pe 32 de biți și adresele erau întotdeauna stocate în cuvinte pe 32 de biți, deci arhitectura a fost considerată pe 32 de biți , dar mașinile au ignorat primii 8 biți ai adresei, rezultând o adresare pe 24 de biți. Cu extensia XA, doar bitul de comandă înaltă (bitul 0) din cuvânt a fost ignorat pentru adresare. O excepție este că instrucțiunile de comutare a modului au folosit și bitul 0. Au existat cel puțin două motive pentru care IBM nu a implementat adresarea pe 32 de biți a 360/67

1. Instrucțiunile de control al buclei BXH și BXLE au făcut comparații semnate.
2. O mare parte din software-ul existent a folosit bitul 0 ca indicator de sfârșit de listă.

Tranziție

Tranziția a fost dificilă: programatorii de limbaj de asamblare, inclusiv arhitecții și dezvoltatorii proprii de sisteme de operare IBM, foloseau octetul de rezervă în partea de sus a adreselor pentru steaguri de aproape douăzeci de ani. IBM a ales să furnizeze două forme de adresare pentru a minimiza durerea: dacă bitul cel mai semnificativ (bitul 0) al unei adrese pe 32 de biți era activat, următorii 31 de biți erau interpretați ca adresa virtuală. Dacă cel mai semnificativ bit a fost dezactivat, atunci doar cei 24 de biți inferiori au fost tratați ca adresă virtuală (la fel ca în cazul sistemelor pre-XA). Astfel, programele ar putea continua să utilizeze cei șapte biți de ordin inferior ai octetului superior în alte scopuri, atâta timp cât au lăsat bitul superior oprit. Singurele programe care necesită modificări au fost cele care setează bitul de sus (cel mai la stânga) al unui cuvânt care conține o adresă. Acest lucru a afectat, de asemenea, comparațiile de adrese: bitul din stânga unui cuvânt este interpretat, de asemenea, ca un bit-semn în aritmetica complementului 2, indicând un număr negativ dacă bitul 0 este activat. Programele care utilizează instrucțiuni de comparație aritmetică semnate ar putea obține rezultate inversate. Două adrese echivalente ar putea fi comparate ca neegale dacă una dintre ele avea bitul de semn activat chiar dacă biții rămași erau identici. Cea mai mare parte a acestui lucru a fost invizibilă pentru programatorii care foloseau limbaje de nivel înalt, cum ar fi COBOL sau FORTRAN , iar IBM a ajutat tranziția cu hardware în mod dual pentru o perioadă de timp.

Anumite instrucțiuni ale mașinii în acest mod de adresare de 31 de biți modifică bitul modului de adresare ca efect secundar posibil intenționat. De exemplu, instrucțiunile originale de apelare subrutină BAL, Branch and Link și echivalentul său de registru, BALR, Branch and Link Register, stochează anumite informații de stare, codul lungimii instrucțiunii, codul de condiție și masca programului, în octetul de sus a adresei de retur. A fost adăugată o instrucțiune BAS, Branch și Save, pentru a permite adresele de retur de 31 de biți. BAS, și echivalentul său de registru-registru, BASR, Branch and Save Register, a făcut parte din setul de instrucțiuni al System / 360 Model 67 , care a fost singurul model System / 360 care permite adrese mai lungi de 24 de biți. Aceste instrucțiuni au fost menținute, dar au fost modificate și extinse pentru adresarea pe 31 de biți.

Instrucțiuni suplimentare în sprijinul adresării 24/31 biți includ două noi instrucțiuni de apel / returnare înregistrare-înregistrare care efectuează, de asemenea, o modificare a modului de adresare (de ex. Modul de ramificare și salvare și setare, BASSM, versiunea 24/31 biți a unui apel în care adresa de legătură, inclusiv modul este salvată și o ramură este dusă la o adresă într-un mod posibil diferit, și BSM, Branch și Set Mode, versiunea de 24/31 biți a unei returnări, în care returnarea este direct la adresa de legătură salvată anterior și în modul său anterior). Luate împreună, BASSM și BSM permit apeluri de 24 de biți la 31 de biți (și revin la 24 de biți), apeluri de 31 de biți la 24 de biți (și revin la 31 de biți), apeluri de 24 de biți la 24 de biți ( și reveniți la 24 de biți) și apeluri de 31 de biți la 31 de biți (și reveniți la 31 de biți).

La fel ca BALR 14,15 (forma de apel pe 24 de biți), BASSM este utilizat ca BASSM 14,15, unde adresa și modul de legătură sunt salvate în registrul 14, iar o ramură este dusă la adresa și modul subrutinei specificat în registrul 15. Oarecum similar cu BCR 15,14 (forma pe 24 de biți a unei returnări necondiționate), BSM este utilizat ca BSM 0,14, unde 0 indică faptul că modul curent nu este salvat (programul părăsește subrutină, oricum) și o întoarcere la apelant la adresa și modul specificate în registrul 14 urmează să fie luate. Consultați publicația IBM MVS / Extended Architecture System Programming Library: 31-Bit Addressing, GC28-1158-1, pentru exemple extinse de utilizare a BAS, BASR, BASSM și BSM, în special, pp. 29-30.

370 / arhitectura ESA

În anii 1990, IBM a introdus arhitectura 370 / ESA (denumită ulterior 390 / ESA și în cele din urmă ESA / 390 sau System / 390, pe scurt S / 390), finalizând evoluția către adresarea virtuală completă pe 31 de biți și păstrând acest flag de mod de adresare. Aceste arhitecturi ulterioare permit mai mult de 2 GB de memorie fizică și permit mai multe spații de adrese simultane de până la 2 GB fiecare în dimensiune. De la mijlocul anului 2006, existau prea multe programe constrânse în mod nejustificat de acest mod de adresare multiplu pe 31 de biți.

z / Arhitectură

IBM a rupt bariera de adresare liniară de 2 GB („bara”) în 2000 odată cu introducerea primului sistem z / Architecture pe 64 de biți , IBM zSeries Model 900. Spre deosebire de tranziția XA, z / Architecture nu rezervă un bit de top pentru a identifica codul anterior. z / Architecture menține compatibilitatea cu codul de 24 de biți și 31 de biți, chiar și codul mai vechi rulează concomitent cu codul mai nou de 64 de biți.

Linux / 390

Deoarece Linux / 390 a fost lansat pentru prima dată pentru hardware-ul de adresare de date pe 32 de biți / 31 de biți în 1999, aplicațiile Linux mainframe inițiale compilate în modul pre-z / Architecture sunt, de asemenea, limitate la adresarea de 31 de biți. Această limitare a dispărut cu hardware pe 64 de biți, Linux pe 64 de biți pe IBM Z și aplicații Linux pe 64 de biți. Distribuțiile Linux pe 64 de biți rulează în continuare programe de adresare de date pe 32 de biți / 31 de biți. Adresarea de 31 de biți a IBM permite codului de 31 de biți să utilizeze memorie suplimentară. Cu toate acestea, în orice moment, cel mult 2 GB se află în fiecare spațiu de adrese de lucru. Pentru Linux non-64-bit pe procesoare cu adresare de 31 de biți, este posibil să alocați memorie deasupra barei de 2 GB ca disc RAM. Suportul kernel Linux pe 31 de biți (nu spațiul utilizatorului) a fost eliminat în versiunea 4.1.

Ruby & Smalltalk

Interpretorii pentru limbile Ruby & Smalltalk folosesc cel mai mic bit pentru a spune dacă o valoare este sau nu un număr întreg. Acest lucru înseamnă că pe mașinile pe 32 de biți (sau pe mașinile pe 16 biți cu pointeri pe 32 de biți), numerele întregi de 31 de biți sunt neîncasate. În caz de revărsare, rezultatul se încadrează într-un obiect în cutie, ceea ce înseamnă că trebuie alocat și colectat gunoi. Astfel, dacă aveți valori pe 32 de biți care nu se încadrează în formatul semnat pe 31 de biți, acestea vor fi foarte ineficiente în acei interpreți. Același lucru este valabil și pentru numărul întreg de 63 de biți pe computere pe 64 de biți. Modele similare pot fi găsite în LISP și în unele dintre celelalte limbi ale căror variabile pot lua valori de orice tip. În unele cazuri, a existat suport hardware pentru acest tip de proiectare: consultați Arhitectura etichetată și mașina Lisp .

Referințe