Mindenki által ismert az Az összeállító nyelv a leggyorsabb néhány kérdésben, és emiatt a leggyakrabban a különböző operációs rendszerek kernelében használják, és ugyanez történik valós idejű projektek esetében is, ahol fejlett elektronikát használnak. A probléma később jelentkezik, amikor ezt a kódot karbantartani kell, és nem A Linux kernel esetében a fejlesztők úgy döntöttek, hogy lefordítják az Assembler kódot C-re.
A C a legreprezentatívabb Linux programozási nyelv (valójában az összes * nix platform közül) fejlesztette ki Dennis Ritchie és Ken Thompson 1972-ben Unix PDP-11 rendszeren készült, és része volt a Unix 2. verziójának. Nagy teljesítményének és hordozhatóságának köszönhetően egyre inkább az operációs rendszerek megvalósításában kezdték használni, ezért Linus Torvalds Akkor használta fel a projektjéhez, amikor még 1990-ben egy ingyenes és nyílt alternatívát keresett a Minix számára.
Természetesen a sok erősség ellenére az Assemblernek van néhány előnye a C-vel szemben, amint azt az elején említettük, így ez a döntés meglepett, de kommentálja Andy Lutomirsky a kernel levelezőlistáin a munkád jól halad és Linux kernel 4.1 lesz az első, aki beépíti ezt az Assemblerből C-be írt forráskódot. Pontosabban, minden, ami a felhasználói módból való kilépéshez kapcsolódik, amely jelenleg e két programozási nyelv kódjainak keverékéből áll, de amely alacsony karbantartása miatt egyre bonyolultabb a frissítés során.
Ez az kód az Assemblerben Hosszú ideje nem frissítették, és ez azt jelenti, hogy az új fejlesztők nem teljesen tisztában vannak a működésével, és ami még rosszabb, nem lenne könnyű frissíteni. Így ahelyett, hogy megpróbáltak volna részleges változtatásokat választani, elkezdték megváltoztatni az összes Assembler rutint C-re, és személy szerint úgy gondolom, hogy bár némi végrehajtási sebesség elveszhet (ami minimális lehet, ha az új C kód hatékony) az új és egyértelmű kód mindig előnyösebb, mint az elavult és szinte nulla frissítési lehetőség mert nem érthető jól, hogyan hajtották végre.
Először az ENSAMBLADOR, spanyolul.
Másodszor, minden nyelvet le kell fordítani (vagy értelmezni kell), így az eredmény jósága a fordítótól (vagy a tolmácstól) függ
Mivel a C fordító sokat javított, az assembler pedig nagyon keveset (mert már nagyon jó volt), manapság a C-ben írt fordított program különbsége ugyanahhoz az összegyűjtőhöz képest elhanyagolható vagy nem létezik (előtte nem volt).
Még a fordított (C és mások) és az értelmezett (Java és mások) programok közötti különbség is nagymértékben minimalizálódott.
Tehát, mivel sokkal könnyebb karbantartani a C-t, mint az assembler, nagyon jó döntés ezeket a változásokat a kernelben végrehajtani, amikor költség-haszon elemzést, gyengeségeket, fenyegetéseket, erősségeket és lehetőségeket, vagy bármely más működőképes elemzést végezünk.
a döntéshozatalhoz.
Miguel Mayol Turnak: Először is, minden programozó, aki egynek vallja magát, ÖSSZESZERELŐT beszél és ért angolul. A többiek a Visual Basic-et használják, és programozónak hívják magukat. De kár. Másodszor pedig az Összeszerelő NEM SZERKEZIK. Amit az azt kezelő programok csinálnak, az a mnemonikát közvetlenül bájtokká alakítja. Az Assembler programozása ugyanazon a nyelven beszél a géppel, de annak kissé könnyebbé tétele érdekében a megfelelő bájtok közvetlen megírása helyett mnemonikát használnak. Az Assembler bájtkészlete és utasításai között egy az egyben megfelelés van. De ezt természetesen csak egy igazi programozó tudja, azok egyike, akik azt mondják, hogy ÖSSZESZERELŐ. Következésképpen nincsenek javítások a "konverteren" az összeállítótól az opkódig, mert a programozó felelős a fejlesztésért. A C (és más nyelvek) fordítói lefordítják az utasításokat az assembler (vagy gépi kód) előre elkészített makro reprezentációiba, és a fejlesztéseket az adott konverziók adják.
Miért érdemes használni a C-t? Mert könnyebb áttekinteni és fenntartani az olvashatóbbakat. A legtöbb ember nem érti közvetlenül az assembler opkódjait vagy a mnemóniákat. Egyszerű a dolog.
Még a Java-ról sem fogok szóba állni, amelyet ugyan már régen szabványként vezettek be, de mostanában utálják azokat, akik értenek a kódhoz.
De ne higgy nekem, kérdezze meg a Google-t, hogy hamis-e az, amit itt mondtam
Üdvözlet
Helló, Chigüire, a szemem lehull az arcomról, arra gondolva, hogy nem tudsz spanyolul írni anélkül, hogy használnád az angolszász eredetű kifejezéseket: azt mondják, hogy "összeszerelő".
Természetesen egy dologban egyetértek veled, jobb, ha nem beszélsz a java-ról, mert hülyeségeket mondani jobb, ha hagyod. Volt olyan barátom, aki olyan volt, mint te, de asztalos (nem szakértő programozó), és azt mondta, hogy a legjobb a kézifűrész és a többi eszköz, nem beszélve arról, hogy még a csavarokat is meghúzta vele. Micsoda követendő példa!
Az angol nyelv mindig az összes számítási kifejezés gyökere. Ez így van, még akkor is, ha mi, spanyolul beszélők nem akarjuk. Ehhez tedd hozzá, hogy vannak olyan kifejezések, amelyeket nem lehet lefordítani "bit", "byte", "unix", "linux", "DOS" és még sok más kifejezésként. És vannak olyanok, amelyeket LEHET lefordítani, de nincs olyan eset, mint a "CMOS", "CSS", "RAM", mert vannak olyan kezdőbetűk, amelyeknek semmi köze nincs a technológiához, és tetejére még a Google-ban sem léteznek . Nincs értelme lefordítani, ha az előállított üzenet olvashatatlan. Következtetés: A műszaki vagy számítási kérdésekben előnyösebb, ha angolul használjuk a szakkifejezéseket. Ugyanezen okból: Inkább azt írom, hogy "Windows" -ot használok, hogy azt mondjam, hogy az "Windows" operációs rendszert használom. Inkább a CSS-ről beszélek, és arról, hogy a type = »text / css-t használom, mint azt próbálni mondani, hogy« átlós szöveg-stíluslapokkal megegyező típusú stíluslapokat használok ». Egészség.
Az összeállítási nyelven írt programokat mindig összeállítják, soha nem értelmezik. Azonban nincs semmi baj, ha Spanglish helyett spanyolul használunk. A tulajdonneveket soha nem fordítják le, de a szakkifejezések akkor fordulnak elő, amikor nem népszerű mozaikszavak. Egyébként mindenki úgy beszélhet, ahogy akar, míg mi még megértjük.