Kendt af alle er det Samlersprog er det hurtigste af nogle problemer, og af den grund er det mest brugt i kernen i de forskellige operativsystemer, og det samme sker i realtidsprojekter, hvor avanceret elektronik bruges. Problemet kommer senere, når denne kode skal opretholdes, og den ikke er det, og derfor I tilfælde af Linux-kernen har udviklerne valgt at oversætte denne Assembler-kode til C.
C er det mest repræsentative Linux-programmeringssprog (faktisk af alle * nix-platforme blev den udviklet af Dennis Ritchie og Ken Thompson i 1972 blev det lavet på et Unix PDP-11-system og var en del af Unix version 2. På grund af sin høje ydeevne og bærbarhed begyndte det at blive brugt mere og mere til implementering af operativsystemer og derfor Linus Torvalds Han brugte det til sit projekt, da han tilbage i 1990 ledte efter et gratis og åbent alternativ til Minix.
Selvom Assembler på trods af så mange styrker har nogle fordele i forhold til C, som vi nævnte i starten, så denne beslutning har overrasket, men i henhold til hvad kommenterer Andy Lutomirsky på kernel mailinglisterne er dit arbejde godt i gang og Linux-kerne 4.1 vil være den første til at inkorporere denne Assembler-kildekode, der omskrives til C. Specifikt alt, der vedrører udgange til brugertilstand, som i øjeblikket består af en blanding af kode fra disse to programmeringssprog, men som på grund af den lave vedligeholdelse bliver mere og mere kompliceret, når der opdateres.
Er det den kode i Assembler Det er ikke blevet opdateret i lang tid, og det betyder, at nye udviklere ikke er helt klare over dens drift, og hvad der er værre, det ville ikke være let at opdatere det. Så i stedet for at prøve nogle delvise ændringer har de valgt at begynde at ændre alle disse Assembler-rutiner til C, og personligt tror jeg, at selvom nogle eksekveringshastigheder kan gå tabt (hvilket kan være minimal, hvis koden C new er effektiv) ny og klar kode foretrækkes altid frem for at være forældet og med næsten nul muligheder for opdatering fordi det ikke er godt forstået, hvordan det blev implementeret.
For det første er det ENSAMBLADOR på spansk.
For det andet skal alt sprog KOMPILERES (eller fortolkes), så resultatets godhed afhænger af COMPILEREN (eller tolken)
Da C-compileren er forbedret meget, og samleren er meget lille (fordi den allerede var meget god), er forskellen i et samlet program skrevet i C i dag sammenlignet med den samme, der er skrevet i assembler, i dag ubetydelig eller ikke-eksisterende (det var ikke 't før).
Selv forskellen mellem kompilerede (C og andre) og fortolkede (Java og andre) programmer er også blevet stærkt minimeret.
Så meget lettere at vedligeholde C end assembler, er det en meget sund beslutning at foretage disse ændringer i kernen, når man foretager en cost-benefit-analyse, svagheder, trusler, styrker og muligheder eller andre, der fungerer.
til beslutningstagning.
Til Miguel Mayol Tur: Først og fremmest taler enhver programmør, der hævder at være en, MONTERING og forstår engelsk. De andre bruger Visual Basic og kalder sig programmører. Sikke en skam. Og for det andet KOMPILATOREN IKKE KOMPILERER. Hvad de programmer, der håndterer det, er at konvertere mnemonics til bytes direkte. Programmering i Assembler taler til maskinen på samme sprog, men for at gøre det lidt nemmere bruges mnemonics i stedet for direkte at skrive de tilsvarende bytes. Der er en en-til-en korrespondance mellem et sæt bytes og en instruktion i Assembler. Men dette ved det naturligvis kun en ægte programmør, en af dem der siger MONTERING. Derfor er der ingen forbedringer af "konverteren" fra samler til opkoder, fordi programmøren har ansvaret for at foretage denne forbedring. Kompilatorerne til C (og andre sprog) oversætter instruktioner til forudbestemte makrorepræsentationer af assembler (eller maskinkode), og forbedringerne gives af, hvordan disse konverteringer er.
Hvorfor bruge C? Fordi det er lettere at gennemgå og vedligeholde noget, der er mere læsbart. De fleste mennesker forstår ikke direkte samleropkoder eller -nemnikker. Så simpelt er det.
Ikke engang vil jeg gider at tale om Java, som skønt det blev indført som en standard for længe siden nu afskydes af dem, der forstår kode.
Men tro mig ikke, spørg Google, hvis det, jeg sagde her, er falsk.
hilsen
Hej Chigüire, mine øjne falder fra mit ansigt og tænker at du ikke er i stand til at skrive på spansk uden at bruge udtryk af angelsaksisk oprindelse: det siges "samler".
Selvfølgelig, i en ting er jeg enig med dig, bedre ikke at tale om java, for at sige nonsens er det bedre at lade det være. Jeg havde en ven, der var som dig, men en tømrer (ikke en ekspertprogrammerer), og han sagde, at det bedste var saven og de andre værktøjer, for ikke at nævne, han strammede endda skruerne med den. Hvilket eksempel at følge!
Det engelske sprog er altid roden til alle beregningsudtryk. Sådan er det, selvom vi spansktalende ikke ønsker det. Tilføj til dette, at der er udtryk, der ikke kan oversættes som "bit", "byte", "unix", "linux", "DOS" og mange andre. Og der er nogle, der KAN oversættes, men der er ingen tilfælde som "CMOS", "CSS", "RAM", fordi der er nogle initialer, der ikke har noget at gøre med teknologi, og for at afslutte det findes de ikke engang i Google . Der er ingen mening i at oversætte, når den producerede besked er uleselig. Konklusion: Det foretrækkes, at tekniske eller beregningsmæssige problemer bruger tekniske udtryk på engelsk. Af samme grund: Jeg foretrækker at skrive, at jeg bruger "windows" for at sige, at jeg bruger operativsystemet "windows". Og jeg foretrækker at tale om CSS, og at jeg bruger type = »text / css end at prøve at sige, at jeg bruger« typografiark med typen lig med diagonal tekstformatark ». Sundhed.
Programmer skrevet på et forsamlingssprog kompileres altid og fortolkes aldrig. Der er dog intet galt med at bruge spansk i stedet for spanglish. Ejendomsnavne oversættes aldrig, men tekniske udtryk er, når de ikke er populære akronymer. Under alle omstændigheder kan alle tale som de vil, mens vi stadig kan forstå.