Kjent for alle er at Monteringsspråk er det raskeste av noen problemer, og av den grunn er den mest brukt i kjernen til de forskjellige operativsystemene, og det samme skjer i sanntidsprosjekter der avansert elektronikk brukes. Problemet kommer senere, når den koden må opprettholdes, og den ikke er det, og derfor Når det gjelder Linux-kjernen, har utviklerne valgt å oversette den montererkoden til C.
C er det mest representative Linux-programmeringsspråket (faktisk, av alle * nix-plattformer), ble den utviklet av Dennis Ritchie og Ken Thompson i 1972, ble den laget på et Unix PDP-11-system og var en del av Unix versjon 2. Gitt den høye ytelsen og bærbarheten, begynte den å bli brukt mer og mer i implementeringen av operativsystemer og derfor Linus Torvalds Han brukte det til prosjektet sitt da han i 1990 lette etter et gratis og åpent alternativ til Minix.
Selvfølgelig, til tross for så mange styrker, har Assembler noen fordeler i forhold til C som vi nevnte i begynnelsen, så denne avgjørelsen har overrasket, men i henhold til hva kommenterer Andy Lutomirsky på kjernepostlistene er arbeidet ditt godt i gang og Linux-kjernen 4.1 vil være den første til å innlemme denne Assembler-kildekoden som omskrives til C. Nærmere bestemt går alt relatert til utgang til brukermodus, som for tiden består av en blanding av kode fra disse to programmeringsspråkene, men som med tanke på lite vedlikehold blir stadig mer komplisert når du oppdaterer.
Er det den kode i Assembler Det har ikke blitt oppdatert på lenge, og det betyr at nye utviklere ikke er helt klare på driften, og det som er verre, det ville ikke være lett å oppdatere det. I stedet for å prøve noen delvis endring har de valgt å begynne å endre alle disse Assembler-rutinene til C, og personlig tror jeg at selv om noen kjøringshastigheter kan gå tapt (noe som kan være minimal hvis koden C new er effektiv) ny og klar kode er alltid å foretrekke fremfor å være utdatert og med nesten null muligheter for oppdatering fordi det ikke er godt forstått hvordan det ble implementert.
For det første er det ENSAMBLADOR, på spansk.
For det andre må alt språk kompileres (eller tolkes), så resultatets godhet avhenger av COMPILER (eller tolk)
Siden C-kompilatoren har forbedret seg mye og samleren en veldig liten (fordi den allerede var veldig bra), er forskjellen i et samlet program skrevet i C sammenlignet med den samme som skrevet i assembler i dag ubetydelig eller ikke-eksisterende (før den var ikke).
Selv forskjellen mellom kompilerte (C og andre) og tolket (Java og andre) programmer har også blitt sterkt minimert.
Så mye enklere å vedlikeholde C enn montør, er det en veldig god beslutning å gjøre disse endringene i kjernen når du foretar en kostnadsnytteanalyse, svakheter, trusler, styrker og muligheter, eller andre som fungerer.
for beslutningstaking.
Til Miguel Mayol Tur: Først og fremst snakker hver programmerer som kan skryte av å være en, MONTERING og forstår engelsk. De andre bruker Visual Basic og kaller seg programmører. Så synd. Og for det andre kompilerer ikke montøren. Hva programmene som håndterer det gjør, er å konvertere mnemonics til byte direkte. Programmering i Assembler snakker til maskinen på samme språk, men for å gjøre det litt enklere brukes mnemonics i stedet for direkte å skrive de tilsvarende byte. Det er en en-til-en korrespondanse mellom et sett med byte og en instruksjon i Assembler. Men dette vet selvfølgelig bare en ekte programmerer, en av dem som sier MONTERING. Følgelig er det ingen forbedringer av "omformeren" fra montør til opkoder fordi programmereren har ansvaret for å gjøre den forbedringen. C-kompilatorer (og andre språk) oversetter instruksjoner til forhåndsopprettede makrorepresentasjoner av assembler (eller maskinkode), og forbedringene er gitt av hvordan disse konverteringene er.
Hvorfor bruke C? Fordi det er lettere å gjennomgå og vedlikeholde noe som er mer lesbart. De fleste forstår ikke direkte opcoder for samler eller mnemonics. Så enkelt som det.
Jeg gidder ikke engang å snakke om Java, som selv om det ble pålagt som standard for lenge siden, nå avskyr av de som forstår kode.
Men ikke tro meg, spør Google om det jeg sa her er falskt.
Hilsen
Hei Chigüire, øynene mine faller fra ansiktet mitt og tenker at du ikke er i stand til å skrive på spansk uten å bruke ord av angelsaksisk opprinnelse: det sies «assembler».
Selvfølgelig, på en ting er jeg enig med deg, det er bedre å ikke snakke om java, for å si tull er det bedre å la det være. Jeg hadde en venn som var som deg, men en snekker (ikke en ekspertprogrammerer), og han sa at det beste var håndsagen og de andre verktøyene, for ikke å nevne, han strammet til og med skruene med den. For et eksempel å følge!
Det engelske språket er alltid roten til alle beregningsbetingelser. Sånn er det, selv om vi spansktalende ikke vil ha det. Legg til dette at det er termer som ikke kan oversettes som "bit", "byte", "unix", "linux", "DOS" og mange andre. Og det er noen som KAN oversettes, men det er ingen tilfeller som "CMOS", "CSS", "RAM" fordi det er noen initialer som ikke har noe med teknologi å gjøre, og til og med å eksistere finnes de ikke en gang i Google . Det nytter ikke å oversette når meldingen som er produsert er uleselig. Konklusjon: Det er å foretrekke at tekniske eller beregningsmessige problemer bruker tekniske ord på engelsk. Av samme grunn: Jeg foretrekker å skrive at jeg bruker "windows" for å si at jeg bruker operativsystemet "windows". Og jeg snakker helst om CSS og at jeg bruker type = »text / css enn å prøve å si at jeg bruker« stilark med type lik diagonal tekststilark ». Helse.
Programmer skrevet på et forsamlingsspråk blir alltid utarbeidet, tolket aldri. Imidlertid er det ingenting galt med å bruke spansk i stedet for Spanglish. Egennavn blir aldri oversatt, men tekniske begreper er når de ikke er populære akronymer. Uansett, alle kan snakke som de vil mens vi fremdeles kan forstå.