Știut de toți este că Limbajul asamblatorului este cel mai rapid din anumite probleme și din acest motiv, este cel mai utilizat în nucleul diferitelor sisteme de operare și la fel se întâmplă și în cazul proiectelor în timp real în care sunt utilizate electronice avansate. Problema apare mai târziu, atunci când codul trebuie menținut și nu este, și, prin urmare În cazul kernel-ului Linux, dezvoltatorii au ales să traducă acel cod Assembler în C.
C este cel mai reprezentativ limbaj de programare Linux (de fapt, dintre toate platformele * nix), a fost dezvoltat de Dennis Ritchie și Ken Thompson în 1972, a fost realizat pe un sistem Unix PDP-11 și a făcut parte din versiunea Unix 2. Având în vedere performanțele și portabilitatea ridicate, a început să fie utilizat din ce în ce mai mult în implementarea sistemelor de operare și, prin urmare, Linus Torvalds L-a folosit pentru proiectul său, când în 1990 căuta o alternativă liberă și deschisă la Minix.
Desigur, în ciuda atâtor puncte forte, Assembler are unele avantaje față de C așa cum am menționat la început, astfel încât această decizie a surprins, dar în funcție de ce comentează Andy Lutomirsky pe listele de corespondență ale kernel-ului, lucrările dvs. sunt bine în curs și Kernel Linux 4.1 va fi primul care va încorpora acest cod sursă de asamblare rescris în C. Mai exact, tot ceea ce ține de ieșirile în modul utilizator, care constă în prezent dintr-un amestec de cod din aceste două limbaje de programare, dar care, având în vedere întreținerea redusă, este din ce în ce mai complicat la actualizare.
Este asta cod în Assembler Nu a fost actualizat de mult timp și asta înseamnă că noii dezvoltatori nu sunt complet clari cu privire la funcționarea sa și, ceea ce este mai rău, nu ar fi ușor să îl actualizăm. Astfel, în loc să încerce o schimbare parțială, au ales să înceapă să schimbe toate rutinele de asamblare în C și personal cred că, deși se poate pierde o anumită viteză de execuție (care poate fi minimă dacă codul C nou este eficient) un cod nou și clar este întotdeauna de preferat să-l depășească și cu aproape zero posibilități de actualizare deoarece nu se înțelege bine cum a fost implementat.
În primul rând este ENSAMBLADOR, în spaniolă.
În al doilea rând, toate limbile trebuie să fie COMPILATE (sau interpretate), deci bunătatea rezultatului depinde de COMPILER (sau de interpret)
Deoarece compilatorul C s-a îmbunătățit foarte mult și asamblorul unul foarte puțin (pentru că era deja foarte bun), în zilele noastre diferența unui program compilat scris în C comparativ cu același program scris în asamblator este neglijabilă sau inexistentă (înainte de aceasta nu a fost).
Chiar și diferența dintre programele compilate (C și altele) și cele interpretate (Java și altele) a fost, de asemenea, foarte redusă.
Deci, fiind mult mai ușor de întreținut C decât asamblorul, este o decizie foarte solidă să faci aceste modificări în nucleu, atunci când faci o analiză cost-beneficiu, puncte slabe, amenințări, puncte forte și oportunități sau orice altul care funcționează.
pentru luarea deciziilor.
Pentru Miguel Mayol Tur: În primul rând, fiecare programator care pretinde că este unul vorbește ASSEMBLER și înțelege limba engleză. Ceilalți folosesc Visual Basic și se numesc programatori. Ce păcat. Și în al doilea rând, asamblatorul NU SE COMPILĂ. Ce fac programele care se ocupă de el este să convertească mnemonica în octeți direct. Programarea în Assembler vorbește cu mașina în același limbaj, dar pentru a ușura un pic, sunt folosite mnemonice în loc să scrieți direct octeții corespunzători. Există o corespondență unu-la-unu între un set de octeți și o instrucțiune în Assembler. Dar asta, desigur, știe doar un programator adevărat, unul dintre cei care spun ASAMBLATOR. În consecință, nu există îmbunătățiri ale „convertorului” de la asamblare la opcodes deoarece programatorul este cel care se ocupă de realizarea acelei îmbunătățiri. Compilatoarele C (și alte limbi) traduc instrucțiunile în reprezentări macro prestabilite ale ansamblorului (sau codului mașinii), iar îmbunătățirile sunt date de modul în care sunt aceste conversii.
De ce să folosești C? Pentru că este mai ușor să revizuiți și să întrețineți ceva mai lizibil. Majoritatea oamenilor nu înțeleg în mod direct codurile de operare sau mnemonice ale ansamblorului. Simplu ca buna ziua.
Nici măcar nu mă voi deranja să vorbesc despre Java, care, deși a fost impus ca standard cu mult timp în urmă, este acum detestat de cei care înțeleg codul.
Dar nu mă crede, întrebați Google dacă ceea ce am spus aici este fals.
În ceea ce priveşte
Bună ziua Chigüire, ochii îmi cad de pe față gândindu-mă că nu ești capabil să scrii în spaniolă fără a folosi termeni de origine anglo-saxonă: se spune „asamblator”.
Desigur, la un singur lucru sunt de acord cu dvs., este mai bine să nu vorbiți despre java, pentru că pentru a spune prostii este mai bine să o lăsați. Am avut un prieten care era ca tine, dar tâmplar (nu un programator expert) și a spus că cel mai bun lucru a fost ferăstrăul de mână și celelalte instrumente, ca să nu mai vorbim, chiar a strâns șuruburile cu el. Ce exemplu de urmat!
Limba engleză este întotdeauna la baza tuturor termenilor de calcul. Așa este, chiar dacă noi vorbitorii de spaniolă nu o dorim. Adăugați la aceasta că există termeni care nu pot fi traduși ca „bit”, „octet”, „unix”, „linux”, „DOS” și mulți alții. Și există unele care S-AR PUTEA traduce, dar nu există nici un caz ca „CMOS”, „CSS”, „RAM”, deoarece există unele inițiale care nu au nimic de-a face cu tehnologia și, pentru a completa, nici măcar nu există în Google . Nu are rost să traduci când mesajul produs este ilizibil. Concluzie: Este de preferat pentru probleme tehnice sau de calcul să se utilizeze termeni tehnici în limba engleză. Din același motiv: prefer să scriu că folosesc „windows” pentru a spune că folosesc sistemul de operare „windows”. Și prefer să vorbesc despre CSS și că folosesc type = »text / css decât să încerc să spun că folosesc« foi de foi de stil cu tip egal cu foi de stil diagonale de text ». Sănătate.
Programele scrise într-un limbaj de asamblare sunt întotdeauna compilate, niciodată interpretate. Cu toate acestea, nu este nimic în neregulă cu utilizarea spaniolei în loc de spanglish. Numele proprii nu sunt niciodată traduse, dar termenii tehnici sunt atunci când nu sunt acronime populare. Oricum, fiecare poate vorbi după bunul plac, în timp ce noi încă putem înțelege.