Dlaczego nie masz systemu operacyjnego opartego na języku wysokiego poziomu? Czy języki niskiego poziomu są bardziej wydajne?


44

Bez zarozumiałości chciałbym, abyś rozważył taką możliwość. Większość systemów operacyjnych opiera się obecnie na językach dość niskiego poziomu (głównie C / C ++). Nawet nowe, takie jak Android, używają JNI, a podstawowa implementacja jest w C

W rzeczywistości (jest to obserwacja osobista) wiele programów napisanych w C działa o wiele szybciej niż ich odpowiedniki wysokiego poziomu (np .: Transmisja (klient bittorrent na Ubuntu) jest o wiele szybsza niż Vuze (Java) lub Potop (Python) ). Nawet kompilatory Pythona są napisane w C, chociaż PyPy jest wyjątkiem.

Czy jest więc jakiś konkretny powód? Dlaczego wszystkie nasze tak zwane „języki wysokiego poziomu” ze świetnymi koncepcjami „OOP” nie mogą być użyte do stworzenia solidnego systemu operacyjnego?

Zasadniczo mam 2 pytania.

  1. Dlaczego aplikacje napisane w językach niskiego poziomu są bardziej wydajne niż ich odpowiedniki HLL? Czy języki niskiego poziomu działają lepiej z tego prostego powodu, że mają niski poziom i są łatwiej tłumaczone na kod maszynowy?
  2. Dlaczego nie mamy pełnego systemu operacyjnego opartego całkowicie na języku wysokiego poziomu?

36
Sugerujesz, że tylko „języki wysokiego poziomu” są zorientowane obiektowo, co nie jest prawdą.
Uooo

2
@rtindru „Całkiem niski poziom języka” (głównie C / C ++)? Jaka jest zatem twoja definicja języka wysokiego poziomu? Musisz jasno określić swoją definicję / interpretację języka wysokiego poziomu. Python jest w rzeczywistości językiem skryptowym, ponieważ jest uruchamiany bezpośrednio na silniku (IDLE lub terminal wiersza poleceń), jeśli do tej pory nie zdawałeś sobie z tego sprawy. Jest bardzo dobry powód (filozoficzny i praktyczny), dlaczego C / C ++ są używane jako języki implementacji dla wielu systemów operacyjnych, ale jestem pewien, że tutaj zaawansowani użytkownicy prawdopodobnie nie wskoczą do tego pytania.
hagubear

10
Android nie jest zupełnie nowym systemem operacyjnym. To tylko kolejny smak Linuksa.
Den

3
@hagubear Istnieje bardzo dobry powód (filozoficzny i praktyczny), dlaczego C / C ++ są używane jako języki implementacji dla wielu systemów operacyjnych . Co to jest bardzo dobry powód?
rtindru

2
Jeśli dobrze rozumiem, system operacyjny dla maszyn LISP został napisany w LISP. Chociaż być może można argumentować, że używany dialekt był językiem niskiego poziomu?
Robert Fisher

Odpowiedzi:


38

Microsoft przeprowadził bardzo interesujące badania w tym kierunku, jeśli spojrzysz na Osobliwość:

http://research.microsoft.com/en-us/projects/singularity/

Ponadto Mothy Roscoe i wsp. Pracowali nad Barrelfish, który używa języka programowania z ograniczeniami Eclipse jako usługi systemu operacyjnego w celu rozwiązania wszystkich problemów związanych z zarządzaniem systemem operacyjnym i alokacją zasobów:

http://www.barrelfish.org/


Wow, nie mogę głosować, potrzebuję 15 powtórzeń ... właśnie dołączyłem dzisiaj! Wielkie dzięki.
rtindru

9
@rtindru: nawet z 1 punktem powtórzenia możesz zaakceptować odpowiedź Co to znaczy, że odpowiedź jest „zaakceptowana”?
Marjan Venema

6
Akceptacja odpowiedzi ogranicza liczbę nowych odpowiedzi / dyskusji. Osobiście odradzam przyjmowanie (na to konkretne pytanie) przynajmniej przez kolejny dzień.
Brian

1
Chciałbym dodać Cosmos do grupy: open source, trzecia strona, nie tak interesująca jak osobliwość, ale ma kilka fajnych pomysłów! cosmos.codeplex.com
Lorenzo Dematté

38

Wiele zależy od tego, gdzie umieścisz podział na języki niskiego i wysokiego poziomu. Na przykład różni ludzie mają tendencję do umieszczania języka takiego jak C ++ po różnych stronach tego podziału.

Jeśli chodzi o twoje pytania:

  1. Nie wierzę, że istnieje taka różnica między językami niskiego i wysokiego poziomu, ale bardziej różnica między językami interpretowanymi a językami, które kompilują się z instrukcjami natywnymi.

    Ale może też występować różnica w kulturze między programistami, w których ci, którzy używają języka niskiego poziomu, bardziej skupiają się na aspektach wydajności podjętych przez siebie wyborów (projektowych).

  2. Jeśli uważasz, że C ++ jest na wysokim poziomie, to przynajmniej jeden system operacyjny jest napisany w całości w języku wysokiego poziomu (Symbian OS jest napisany w C ++). To, co powstrzymuje Cię przed napisaniem systemu operacyjnego w większości języków wysokiego poziomu, to dwie rzeczy:

    • System operacyjny potrzebuje niskiego poziomu dostępu do pamięci i sprzętu i wykonuje na nich brudne sztuczki. Ten rodzaj dostępu jest ogólnie uważany za niebezpieczny dla programów na poziomie aplikacji, więc wiele języków wysokiego poziomu nie pozwala na to.
    • System operacyjny musi zostać uruchomiony bez obecności oprogramowania pomocniczego, takiego jak tłumacze. To sprawia, że ​​niezwykle trudno jest napisać system operacyjny w języku, którego nie można łatwo skompilować w natywne instrukcje.

35
Nie ma czegoś takiego jak język interpretowany lub język kompilujący się z instrukcjami natywnymi. Język jest zbiorem reguł matematycznych, nie jest interpretowany ani kompilowany, po prostu jest . Interp. i komp. są cechami tłumacza lub kompilatora, a nie języka. Każdy język można zaimplementować za pomocą kompilatora lub tłumacza. Obecnie większość języków ma zarówno interpretowane, jak i skompilowane implementacje. Istnieją interpretery dla C i wszystkich głównych implementacji JavaScript kompilowanych do kodu natywnego. A co to właściwie jest kod macierzysty? Jeśli skompiluję Javę do kodu bajtowego JVM i uruchomię
Jörg W Mittag

11
że na procesorze Java, a ja kompiluję kod maszynowy C do ARM i uruchamiam go na interpreterie ARM, ponieważ mój komputer nie ma procesora ARM, co sprawia, że ​​ARM jest natywny, a JVML nie?
Jörg W Mittag

5
@ JörgWMittag: Jeśli masz procesor, który może bezpośrednio wykonać kod bajtowy Java (bez użycia dodatkowej JVM), to kod bajtowy Java jest rodzimym kodem dla tego procesora. Ponadto nie wykluczam możliwości napisania systemu operacyjnego w języku, który jest zazwyczaj interpretowany lub wykonywany na maszynie wirtualnej, ale czyni to mniej oczywistymi wyborami.
Bart van Ingen Schenau

15
@ JörgWMittag - Zgadzam się, że każdy język może być skompilowany lub zinterpretowany (skompiluj skrypt bash; użyj zinterpretowanego C ++ (CINT / Cling)), ale wiele decyzji dotyczących projektowania języka zależy od tego, czy zostanie to zinterpretowane, skompilowane lub obu. Język, który powoduje, że ręcznie deklarujesz / inicjujesz zmienne o typie statycznym, ręcznie przydzielasz / zwalniasz pamięć, wykonujesz arytmetykę wskaźników, pamiętasz, aby sprawdzić granice tablic, będzie mniej wygodny w interpreterie (w porównaniu z językiem, który zbiera pamięć, określa typ dynamiczny, sprawdza granice tablic). Czy ta linia jest w 100% czysta? Nie, ale różnica istnieje w praktyce.
dr jimbob

15

Istnieje wiele dobrych powodów.

Dzisiejszy język niskiego poziomu był wczoraj językiem wysokiego poziomu

Tak, wierzcie lub nie, dawno temu nawet C było postrzegane jako język wysokiego poziomu. Nawet ~ 20 lat temu było dość powszechne, aby opisywać go jako język „średniego poziomu”. To był czas, kiedy OO było tak popularne jak dziś, Java nie istniała, C # nie istniało, nawet C ++ nie był jeszcze odpowiednio ustandaryzowany.

Historyczna bezwładność

Systemy operacyjne, których używasz dzisiaj, mają głębokie, głębokie korzenie w historii. Windows wraca do wczesnych / środkowych lat 80., Unix wraca do wczesnych / środkowych lat 70. W systemach operacyjnych jest DUŻO starego, działającego kodu i na ogół nie chcesz przepisywać starego, działającego kodu.

W pewnym momencie musisz przejść do sprzętu

Dzieje się tak w jądrze, w sterownikach, w podsystemach zarządzania pamięcią, w systemie plików. Na pewno możesz nałożyć na niego język wysokiego poziomu, ale nadal potrzebujesz możliwości bardziej bezpośredniego dostępu do sprzętu oferowanego przez język niższego poziomu.

Ruchliwość

Nie mam na myśli przenośności na inny sprzęt lub inny system operacyjny, ponieważ dziś jest to powszechnie rozumiane; to jest bardziej subtelne. Jedną z głównych zalet dostarczania interfejsu opartego na języku C jest fakt, że praktycznie każdy inny istniejący język może zawierać link do C. Nawet interfejs API systemu Windows jest obecnie interfejsem API opartym na języku C z tego powodu.

Osobiste preferencje

Niektóre osoby po prostu wolą programować w ten sposób, co może być głównym czynnikiem. Na przykład Linus Torvalds ma słynne zdanie przeciwko C ++, co wyraźnie pokazuje, że jeśli chodzi o niego, C zawsze będzie jego wybranym narzędziem do tego rodzaju pracy (treść zdania i czy zgadzasz się z nim, czy nie) nie ma znaczenia w tej dyskusji; wystarczy fakt, że istnieje rant).

Podsumowując, powinny one jasno ustalić, dlaczego system operacyjny został pierwotnie napisany w czymś w rodzaju C w dawnych czasach i dlaczego bardzo znaczące fragmenty - nawet dzisiaj - pozostają takie.


13

Głównym powodem dominacji C w systemach operacyjnych jest historia - obecne systemy operacyjne głównego nurtu, takie jak Windows i wszystkie formy Uniksa (BSD, Solaris, HP-UX, MacOS X, ... a także klony takie jak Linux) wracają długo zanim OO i inne konstrukty „wysokiego poziomu” stały się głównym nurtem.

Rdzeń systemu operacyjnego oprócz wydajności wymaga bardzo szczegółowych instrukcji dotyczących sprzętu i pełnej kontroli nad pamięcią, które języki takie jak C radzą sobie bardzo dobrze.

W przypadku systemów osadzonych czasami istnieją systemy operacyjne wykorzystujące języki wyższego poziomu dla większych części systemu. Jednym z godnych uwagi przykładów jest JavaOS firmy Sun.

W przypadku powszechnych systemów operacyjnych godnym uwagi przykładem nieużywanie C jest również klasyczny MacOS przed MacOS X - napisany w dużej części dialektem Pascala, który pozwalał na pewną formę orientacji obiektowej.


12

Po pierwsze, istnieją pewne problemy z uruchamianiem. Większość funkcji ułatwiających obsługę języków wysokiego poziomu opiera się na abstrakcjach, które jądro musi sam zapewnić. Jak napisać menedżera pamięci w języku, który wymaga menedżera pamięci? Jak pisać sterowniki we / wy bez korzystania z ładnych standardowych bibliotek we / wy w twoim języku? Jak tworzyć prymityw wątków i synchronizacji bez korzystania z bibliotek języka?

Po drugie, jest niezwykle przydatny i znacznie bardziej czytelny podczas pisania systemów operacyjnych, aby móc przypisać zmienną do określonej lokalizacji pamięci. W C jest to łatwe, a każdy programista w C wie, jak to zrobić. Jeśli jest to nawet możliwe w językach wyższego poziomu, jest tak rzadkie, że tylko guru wiedzą, jak to zrobić.

Innymi słowy, kiedy weźmiesz pod uwagę wszystkie ograniczenia i modyfikacje, które musisz zaakceptować, C i C ++ zaczną wyglądać o wiele łatwiej.


2
Twój pierwszy akapit nie ma sensu. Sterownik we / wy w C również nie używa stdio.h. Niestandardowa implementacja mutex nie używa pthreads. Właśnie to oznacza wdrożenie go samemu! I to jest niezależne od używanego języka. Nie oznacza to, że języki wysokiego poziomu są dobrym wyborem do zadań niskiego poziomu (zazwyczaj nie są to moje doświadczenia).

Jestem tego świadomy. Po prostu wskazuję, że wiele z tego, co odróżnia język wysokiego poziomu od języka niskiego poziomu, znajduje się w tych częściach języka, które są niedostępne w rozwoju jądra. Kiedy porównasz języki rdzeń do rdzeń, C nie wygląda już tak spartańsko.
Karl Bielefeldt

Niezupełnie prawda. Choć trzeba jakiś kod, który nie korzysta z X do wdrożenia x, wszystkie pozostały kod może zależeć od tego kodu i wykorzystanie X.

Trafne spostrzeżenie.
Karl Bielefeldt

6

Po pierwsze, ładowanie wymaga co najmniej małej części do napisania w asemblerze lub równoważnej.

Po drugie, system operacyjny został napisany w bezsprzecznie HLL - Lisp Machine . (Fakt, że zawiodła komercyjnie, miał więcej wspólnego z tym, że inny sprzęt stawał się tańszy szybciej, a zwycięstwo Gorzej jest lepsze niż z brakami jego filozofii lub projektu).

Po trzecie, C ++ jest zorientowany obiektowo i na wysokim poziomie, więc jak zauważyli inni, Symbian OS jest kolejnym przykładem.

Po czwarte, nowe systemy operacyjne nie są obecnie potrzebne. Mamy już sporo linuksowych i bsdowych smaków, które działają na prawie każdym sprzęcie, a stworzenie zupełnie nowego systemu operacyjnego od podstaw jest dość drogie.


Brakowało Ci komputerów mainframe Burroughs B5000. Ich system operacyjny został napisany w Burroughs Extended ALGOL.
John R. Strohm,

1
there is little need for new OSes at this timeNadal nie zdecydowałem, czy to prawda, czy nie. Tak, nowoczesne systemy operacyjne (nowoczesne okna (NT) / nowoczesny Unix) są wszystkim, czego potrzebujemy, funkcjonalnością i wydajnością. Ale ledwo: rodzą się w innym obszarze, w którym „sieć” była korporacyjna / uniwersytecka, a użytkownicy ufali, a multiproc to 2/4 procesorów. Są do pewnego stopnia „nękani” nadmiernym zaufaniem (rootkity, złośliwe oprogramowanie, wirusy ...). Zaczynam myśleć, że istnieje przestrzeń dla nowoczesnego, bezpiecznego, izolowanego systemu operacyjnego ... z lepszym wsparciem dla równoległości (lepiej niż wątki)
Lorenzo Dematté

Lisp jest niski poziom, CARa CDRto IBM 704 assembler makr ! Nawet C segreguje wbudowany zestaw , zamiast traktować go jak każdą inną funkcję. Biorąc pod uwagę Lisp CARi CDRpracę nad x86, ARM i całą gamę ponad ISA, jest to imponująco przenośny zestaw. (Side note każdemu mogę mylić: Tak, Lisp jest językiem wysokiego poziomu. CARI CDRbędące makra asemblera właśnie szczegółów wdrażania, a nie główną cechą;).)
8bittree

4

Aby lepiej fazować to, co napisałem wcześniej.

Maszyny Burroughs 5xxx - 6xxx nie miały języka asemblera. Najniższym dostępnym językiem było rozszerzenie do Algolu. Algol został zaimplementowany sprzętowo. System operacyjny i wszystkie języki zostały napisane w Algolu. Wyprzedził wszystkie konkurencyjne maszyny tamtych czasów. Wymagało to również znacznie mniej kodu, co znacznie ułatwiło utrzymanie. Miał sprzęt stosu, który obsługiwał rekurencyjny język, taki jak Algol.

System operacyjny Burroughs przekształcił się w wersję o nazwie MCP. MCP działa obecnie w systemach Unisys.


3

Większość wymienionych wyżej języków wyższego poziomu ma funkcję, która nie pasuje dobrze do systemów operacyjnych: automatyczne zarządzanie pamięcią. Podczas pisania systemu w czasie rzeczywistym nie można polegać na śmieciarzu - ani miękkim (jakim jest system operacyjny), ani nawet najgorszym. Cytując Tanenbaum [i]:

Niektóre rzeczy, których C nie ma, obejmują wbudowane ciągi, wątki, pakiety, klasy, obiekty, bezpieczeństwo typów i wyrzucanie elementów bezużytecznych. Ten ostatni jest pokazowym ogranicznikiem dla systemów operacyjnych. Cała pamięć w C jest albo statyczna, albo jawnie przydzielona i zwolniona przez programistę, zwykle z funkcją biblioteki malloc i za darmo . Jest to ostatnia właściwość - całkowita kontrola programisty nad pamięcią - wraz z wyraźnymi wskaźnikami, które sprawiają, że C jest atrakcyjny do pisania systemów operacyjnych. Systemy operacyjne są w pewnym stopniu systemami czasu rzeczywistego, nawet te ogólnego przeznaczenia. W przypadku wystąpienia przerwania system operacyjny może mieć tylko kilka mikrosekund na wykonanie pewnych czynności lub utratę krytycznych informacji. Niedopuszczalne jest uruchamianie wywozu śmieci w dowolnym momencie.

Teraz możesz argumentować, że C ++ jest również dobrym kandydatem, ponieważ oferuje ręczne zarządzanie pamięcią. C ++ był już używany w niektórych systemach operacyjnych, takich jak Symbian (wspomniany przez Barta ) i BeOS. Ale IMHO C jest wciąż najszybszym językiem, który można przenosić w wielu architekturach bez dużego wysiłku (w przeciwieństwie do montażu konkretnej architektury).

[i]: Nowoczesne systemy operacyjne wydanie 3, strona 73


3
Maszyny Symbolics miały automatyczne zarządzanie pamięcią. Smalltalk zrobił na Alto. To było w latach 80. System typu liniowego całkowicie eliminuje konieczność stosowania GC. To rozwiązane problemy, gdybyśmy tylko mogli o tym pamiętać!
Frank

Byłoby możliwe, aby język obejmował automatyczne zarządzanie pamięcią, ale zawiera specjalny rodzaj „głęboko przypiętego” odniesienia i pozwala metodom na jawne zadeklarowanie, że nie będą one uzyskiwać dostępu do żadnego nieprzypiętego odniesienia ani wywoływać żadnych metod, które mogłyby to zrobić. Nie byłoby potrzeby, aby zbieracz śmieci stop-the-world zakłócał działanie kodu w metodzie, która nie miałaby dostępu do żadnych obiektów, które mogłyby być modyfikowane przez GC.
supercat

2

Jak zauważyli inni, kilka systemów operacyjnych zostało napisanych w językach wysokiego poziomu. Być może chodzi ci o to, że wszystkie odnoszące sukcesy, masowe rynki, ogólne zastosowania systemu operacyjnego zostały napisane w kombinacji kombinacji a, C i C ++?

Większość języków wysokiego poziomu ma mnóstwo przydatnych funkcji, które wiążą się z kosztami wydajności. Zautomatyzowane zarządzanie pamięcią jest oczywistym przykładem, sprawdzanie granic tablic to kolejny. Jeśli piszesz system operacyjny ogólnego przeznaczenia, możesz spotkać się z sytuacjami, w których kara za wydajność tych pomocnych funkcji jest większa niż jesteś skłonny zapłacić. W tym momencie chciałbyś móc je wyłączyć. Języki takie jak Python, C # i Java różnią się pod względem funkcji, które można wyłączyć, ale żaden z nich nie jest tak wszechstronny jak C lub C ++ pod tym względem.

W tym aspekcie C i C ++ są prawie tak wszechstronne, jak czysty montaż. Jeśli zdecydujesz, że potrzebujesz dziesięciu różnych menedżerów pamięci obejmujących dziesięć różnych scenariuszy alokacji pamięci, możesz zaimplementować je wszystkie w C i C ++ oraz ładować i zwalniać je według własnego uznania. Do diabła, nie musisz nawet łączyć się ze standardowymi bibliotekami wykonawczymi C lub kodem startowym, jeśli nie chcesz.


0

Prawdziwa odpowiedź to Pieniądze . Nie ma dostatecznych korzyści z systemu operacyjnego na wysokim poziomie językowym, aby uzasadnić przeznaczenie zasobów na zbudowanie jednego z nich, a następnie wprowadzenie go do głównego nurtu. Zbudowanie nowego sterownika dla każdego sprzętu, który musi obsługiwać, wiąże się z ogromnymi kosztami.

Istnieją różne systemy operacyjne napisane w językach wysokiego poziomu, których głównym celem są badania, takie jak Oberon i Singularity .

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.