Dat is bij iedereen bekend Assembler-taal is de snelste voor sommige problemen en om deze reden wordt het het meest gebruikt in de kern van de verschillende besturingssystemen en hetzelfde gebeurt voor real-time projecten waarbij geavanceerde elektronica wordt gebruikt. Het probleem komt later, wanneer die code moet worden onderhouden en dat is het niet, en daarom In het geval van de Linux-kernel hebben de ontwikkelaars ervoor gekozen om die Assembler-code naar C te vertalen.
C is de meest representatieve Linux-programmeertaal (eigenlijk, van alle * nix-platforms), werd het ontwikkeld door Dennis Ritchie en Ken Thompson in 1972, het werd gemaakt op een Unix PDP-11-systeem en maakte deel uit van Unix-versie 2. Gezien zijn hoge prestaties en draagbaarheid, werd het steeds meer gebruikt bij de implementatie van besturingssystemen en daarom Linus Torvalds Hij gebruikte het voor zijn project toen hij in 1990 op zoek was naar een gratis en open alternatief voor Minix.
Natuurlijk, ondanks zoveel sterke punten, heeft Assembler enkele voordelen ten opzichte van C, zoals we in het begin al noemden, dus deze beslissing was verrast, maar volgens wat zegt Andy Lutomirsky op de kernel-mailinglijsten is uw werk in volle gang en Linux-kernel 4.1 zal de eerste zijn die deze herschrijving van de Assembler-broncode naar C opneemt In het bijzonder alles met betrekking tot het verlaten van de gebruikersmodus, die momenteel bestaat uit een mix van code van deze twee programmeertalen, maar die, gezien het lage onderhoud, steeds gecompliceerder wordt bij het updaten.
Is dat de code in Assembler Het is lange tijd niet bijgewerkt en dat betekent dat nieuwe ontwikkelaars niet helemaal duidelijk zijn over de werking ervan, en wat erger is, het zou niet gemakkelijk zijn om het bij te werken. Dus in plaats van een gedeeltelijke verandering te proberen, hebben ze ervoor gekozen om al die Assembler-routines naar C te veranderen, en persoonlijk denk ik dat, hoewel sommige uitvoeringssnelheid verloren kan gaan (wat minimaal kan zijn als de code C new efficiënt is) nieuwe en duidelijke code heeft altijd de voorkeur boven verouderd en met bijna nul mogelijkheden om te updaten omdat niet goed wordt begrepen hoe het werd geïmplementeerd.
In de eerste plaats is het ENSAMBLADOR, in het Spaans.
Ten tweede moet alle taal zijn COMPILED (of geïnterpreteerd), dus de goedheid van het resultaat hangt af van de COMPILER (of de tolk)
Omdat de C-compiler veel is verbeterd en de assembler heel weinig (omdat het al erg goed was), is het verschil tussen een gecompileerd programma geschreven in C en hetzelfde geschreven in assembler tegenwoordig verwaarloosbaar of niet-bestaand (voordat het was niet).
Zelfs het verschil tussen gecompileerde (C en andere) en geïnterpreteerde (Java en andere) programma's is ook sterk geminimaliseerd.
Omdat het veel gemakkelijker is om C te onderhouden dan assembler, is het een zeer goede beslissing om deze veranderingen in de kernel door te voeren, bij het uitvoeren van een kosten-batenanalyse, zwakke punten, bedreigingen, sterke punten en kansen of andere die werken.
voor besluitvorming.
Aan Miguel Mayol Tur: Allereerst spreekt elke programmeur die beweert iemand te zijn, ASSEMBLER en verstaat hij Engels. De anderen gebruiken Visual Basic en noemen zichzelf programmeurs. Wat jammer. En ten tweede COMPILEERT de Assembler NIET. Wat de programma's doen die ermee omgaan, is geheugensteuntjes rechtstreeks naar bytes converteren. Programmeren in Assembler is in dezelfde taal tegen de machine spreken, maar om het wat gemakkelijker te maken worden geheugensteuntjes gebruikt in plaats van direct de corresponderende bytes te schrijven. Er is een één-op-één-overeenkomst tussen een byteset en een Assembler-instructie. Maar dit weet natuurlijk alleen een echte programmeur, een van degenen die ASSEMBLER zeggen. Bijgevolg zijn er geen verbeteringen aan de "converter" van assembler naar opcodes, omdat de programmeur verantwoordelijk is voor het aanbrengen van die verbetering. C-compilers (en andere talen) vertalen instructies in vooraf opgestelde macroweergaven van assembler (of machinecode) en de verbeteringen worden bepaald door hoe die conversies zijn.
Waarom C gebruiken? Omdat het gemakkelijker is om iets te beoordelen en te onderhouden dat beter leesbaar is. De meeste mensen begrijpen assembler-opcodes of geheugensteuntjes niet direct. Zo simpel is het.
Ik zal niet eens de moeite nemen om over Java te praten, dat hoewel het lang geleden als standaard werd opgelegd, nu wordt verafschuwd door degenen die code wel begrijpen.
Maar geloof me niet, vraag Google of wat ik hier zei niet waar is.
groeten
Hallo Chigüire, mijn ogen vallen van mijn gezicht, denkend dat je niet in het Spaans kunt schrijven zonder termen van Angelsaksische oorsprong te gebruiken: er wordt gezegd «assembler».
Over één ding ben ik het natuurlijk met je eens: het is beter om niet over java te praten, want om onzin te zeggen, is het beter om het te laten. Ik had een vriend die net als jij was, maar een timmerman (geen ervaren programmeur) en hij zei dat het beste de handzaag en het andere gereedschap was, om nog maar te zwijgen van het feit dat hij er zelfs de schroeven mee aandraaide. Wat een voorbeeld om te volgen!
De Engelse taal staat altijd aan de basis van alle computationele termen. Zo is het, zelfs als wij Spaanstaligen het niet willen. Voeg hieraan toe dat er termen zijn die niet kunnen worden vertaald als "bit", "byte", "unix", "linux", "DOS" en vele anderen. En er zijn er enkele die KUNNEN worden vertaald, maar er is geen geval zoals "CMOS", "CSS", "RAM" omdat er enkele initialen zijn die niets met technologie te maken hebben en als klap op de vuurpijl bestaan ze niet eens in Google . Vertalen heeft geen zin als het geproduceerde bericht onleesbaar is. Conclusie: Voor technische of rekenkundige problemen verdient het de voorkeur om technische termen in het Engels te gebruiken. Om dezelfde reden: ik schrijf liever dat ik "windows" gebruik om te zeggen dat ik het besturingssysteem "windows" gebruik. En ik spreek liever over CSS en dat ik type = »text / css gebruik dan om te proberen te zeggen dat ik« style sheet sheets met type gelijk aan diagonale text style sheets »gebruik. Gezondheid.
Programma's geschreven in een assembleertaal worden altijd gecompileerd, nooit geïnterpreteerd. Er is echter niets mis met het gebruik van Spaans in plaats van Spaans. De juiste namen worden nooit vertaald, maar technische termen zijn wanneer het geen populaire acroniemen zijn. Hoe dan ook, iedereen kan spreken zoals hij wil, zolang we het nog kunnen verstaan.