Wszyscy o tym wiedzą Najszybszy jest język asemblera w niektórych przypadkach iz tego powodu jest najczęściej używany w jądrze różnych systemów operacyjnych i to samo dzieje się w projektach czasu rzeczywistego, w których używana jest zaawansowana elektronika. Problem pojawia się później, gdy ten kod wymaga konserwacji, a tak nie jest, i dlatego W przypadku jądra Linuksa programiści zdecydowali się przetłumaczyć ten kod Assemblera na C.
C jest najbardziej reprezentatywnym językiem programowania Linuksa (właściwie ze wszystkich platform * nix), został opracowany przez Dennis Ritchie i Ken Thompson w 1972 roku, został wykonany na systemie Unix PDP-11 i był częścią Unix w wersji 2. Biorąc pod uwagę jego wysoką wydajność i przenośność, zaczął być coraz częściej używany we wdrażaniu systemów operacyjnych, a zatem Linus Torvalds Użył go w swoim projekcie, gdy w 1990 roku szukał wolnej i otwartej alternatywy dla Minix.
Oczywiście, pomimo tak wielu mocnych stron, Asembler ma pewne zalety w stosunku do C, o czym wspomnieliśmy na początku, więc ta decyzja zaskoczyła, ale zgodnie z czym komentuje Andy Lutomirsky na listach dyskusyjnych jądra twoja praca jest już zaawansowana i Jądro Linux 4.1 będzie pierwszym, który włączy ten przepisany kod źródłowy Assemblera do C. W szczególności wszystko związane z wyjściem do trybu użytkownika, który obecnie składa się z mieszanki kodu z tych dwóch języków programowania, ale który, biorąc pod uwagę jego niskie koszty utrzymania, jest coraz bardziej skomplikowany podczas aktualizacji.
Jest to, że kod w asemblerze Od dawna nie był aktualizowany, co oznacza, że nowi programiści nie są do końca pewni co do jego działania, a co gorsza, aktualizacja nie byłaby łatwa. Tak więc, zamiast próbować częściowej zmiany, zdecydowali się zacząć zmieniać wszystkie te procedury asemblera na C i osobiście uważam, że chociaż część szybkości wykonywania może zostać utracona (co może być minimalne, jeśli kod C new jest wydajny) nowy i przejrzysty kod jest zawsze lepszy od przestarzałego i prawie zerowych możliwości aktualizacji ponieważ nie jest dobrze zrozumiane, w jaki sposób zostało wdrożone.
Przede wszystkim jest to ENSAMBLADOR w języku hiszpańskim.
Po drugie, cały język musi być KOMPILOWANY (lub zinterpretowany), więc dobroć wyniku zależy od KOMPILERA (lub tłumacza)
Ponieważ kompilator C bardzo się poprawił, a assembler bardzo mało (bo był już bardzo dobry), obecnie różnica między programem skompilowanym napisanym w C a tym samym napisanym w asemblerze jest znikoma lub nie istnieje (wcześniej nie było).
Nawet różnica między programami skompilowanymi (C i inne) a zinterpretowanymi (Java i inne) również została znacznie zminimalizowana.
Tak więc, ponieważ utrzymanie C jest znacznie łatwiejsze niż asembler, bardzo rozsądną decyzją jest wprowadzenie tych zmian w jądrze, podczas przeprowadzania analizy kosztów i korzyści, słabych stron, zagrożeń, mocnych stron i szans lub innych, które działają.
do podejmowania decyzji.
Do Miguela Mayola Tura: Przede wszystkim każdy programista, który chwali się tym, że jest kimś, mówi ASSEMBLER i rozumie angielski. Inni używają Visual Basic i nazywają siebie programistami. Jaka szkoda. Po drugie, asembler NIE KOMPILUJE. Programy, które się tym zajmują, to bezpośrednia konwersja mnemoników na bajty. Programowanie w asemblerze polega na rozmowie z maszyną w tym samym języku, ale aby to nieco ułatwić, zamiast bezpośredniego wpisywania odpowiednich bajtów używane są mnemoniki. Istnieje zgodność jeden do jednego między zestawem bajtów a instrukcją w asemblerze. Ale to wie, oczywiście, tylko prawdziwy programista, jeden z tych, którzy mówią ASSEMBLER. W związku z tym nie ma żadnych ulepszeń w „konwerterze” z asemblera na opkody, ponieważ programista jest odpowiedzialny za wprowadzanie tych ulepszeń. Kompilatory C (i inne języki) tłumaczą instrukcje na wstępnie ustalone makropreprezentacje asemblera (lub kodu maszynowego), a ulepszenia wynikają z tego, jak te konwersje są.
Dlaczego warto używać C? Ponieważ łatwiej jest przeglądać i utrzymywać coś, co jest bardziej czytelne. Większość ludzi nie rozumie bezpośrednio kodów operacyjnych ani mnemoników asemblera. Tak proste jak to.
Nie będę nawet mówić o Javie, która choć została narzucona jako standard dawno temu, teraz jest znienawidzona przez tych, którzy rozumieją kod.
Ale nie wierz mi, zapytaj Google, czy to, co tutaj powiedziałem, jest fałszywe.
pozdrowienia
Cześć Chigüire, oczy mi opadają, myśląc, że nie jesteś w stanie pisać po hiszpańsku bez używania terminów pochodzenia anglosaskiego: mówi się „asembler”.
Oczywiście w jednej kwestii się z tobą zgadzam, lepiej nie mówić o Javie, bo żeby mówić bzdury, lepiej to zostawić. Miałem przyjaciela, który był jak ty, ale stolarzem (nie ekspertem programistą) i powiedział, że najlepszą rzeczą była piła ręczna i inne narzędzia, nie wspominając o tym, że nawet dokręcał nią śruby. Cóż za przykład do naśladowania!
Język angielski jest zawsze podstawą wszystkich terminów obliczeniowych. Tak jest, nawet jeśli my, mówiący po hiszpańsku, tego nie chcemy. Dodaj do tego, że istnieją terminy, których nie można przetłumaczyć jako „bit”, „bajt”, „unix”, „linux”, „DOS” i wiele innych. Są też takie, które MOGĄ zostać przetłumaczone, ale nie ma czegoś takiego jak „CMOS”, „CSS”, „RAM”, ponieważ istnieją inicjały, które nie mają nic wspólnego z technologią, a na dodatek nie ma ich nawet w Google. Nie ma sensu tłumaczyć, kiedy utworzona wiadomość jest nieczytelna. Wniosek: ze względów technicznych lub obliczeniowych lepiej jest używać terminów technicznych w języku angielskim. Z tego samego powodu: wolę pisać, że używam „windows”, aby powiedzieć, że używam „windows” systemu operacyjnego. I wolę mówić o CSS i że używam type = »text / css niż próbować powiedzieć, że używam« arkuszy stylów o typie równym arkuszom stylów tekstu po przekątnej ». Zdrowie.
Programy napisane w asemblerze są zawsze kompilowane, nigdy nie są interpretowane. Jednak nie ma nic złego w używaniu hiszpańskiego zamiast hiszpańskiego. Nazwy własne nigdy nie są tłumaczone, ale terminy techniczne są stosowane, gdy nie są popularnymi akronimami. W każdym razie każdy może mówić, jak chce, a my wciąż możemy to zrozumieć.