Własny system operacyjny w C++

czy jest jakaś możliwosć napisania os tylko w c++?

Jest. W niczym nie jest gorszy od C.

Bootloader w asm chocby trochę - choć jest niejasne jaki sens przykładasz do słowa OS.

świat idzie do przodu !
kiedyś młodzi chcieli zrobić system operacyjny w assembler, a teraz jest c++
za 5 lat będzie pytanie "Operating System w JS"
i znając życie nawet ktoś to zrobi :D

Adamek Adam napisał(a):

świat idzie do przodu !
kiedyś młodzi chcieli zrobić system operacyjny w assembler, a teraz jest c++
za 5 lat będzie pytanie "Operating System w JS"
i znając życie nawet ktoś to zrobi :D

Ja czytałem o eksperymentalnym systemie operacyjnym w Javie.

nintyfan napisał(a):

Adamek Adam napisał(a):

świat idzie do przodu !
kiedyś młodzi chcieli zrobić system operacyjny w assembler, a teraz jest c++
za 5 lat będzie pytanie "Operating System w JS"
i znając życie nawet ktoś to zrobi :D

Ja czytałem o eksperymentalnym systemie operacyjnym w Javie.

Masz jakieś namiary na taki system w Javie? w ogóle jak rozumiecie termin "system operacyjny"? Bo jeśli tylko jako samo GUI czyli interfejs graficzny do interakcji z użytkownikiem to raczej nie powinno być problemu.
Natomiast system operacyjny jako kernel space + user space pisany w Javie - to hm... pojawiają mi się wątpliwości i pytania:

• czy Java ma bezpośredni dostęp do sprzętu - mam na myśli bezpośrednie odwołania do pamięci - np. MMIO?
• czy Java ma bezpośredni dostęp do wszystkich stopni uprzywilejowania procesora?
• czy potrafi obsługiwać wyjątki procesora?
• czy Java ma wsparcie w sobie do obsługi wszystkich możliwych procesorów sprzętowych - nie wirtualnych?
• czy Java zna w ogóle pojęcie sterownika urządzenia?
• czy Java w ogóle rozróżnia pojęcia user-space i kernel-space?
• czy Java ma wsparcie do atomowych operacji bepośrednio na procesorze?

Z Javą niewiele mam doświadczenia - stąd te pytania. Ogólnie to Java sprawia wrażenie pasożytowania na bazowym jakimś systemie operacyjnym - czyli ktoś za nią musi odwalić najgorszą robotę. Ale mogę się mylić. Jeśli tak - to proszę o argumenty merytoryczne.

@vtx:

Jarek Pałka Bare metal Java

W skrócie: są fajnie zaprojektowane akcesory do RAM out of heap itd ...

To nowości wchodzące od kilku lat, nie istniejące < ver 11

Tutaj macie projekt w którym to faktycznie robili :>

https://joeduffyblog.com/2015/11/03/blogging-about-midori/

https://en.wikipedia.org/wiki/Midori_(operating_system)

Midori (which means green in Japanese) was the code name for a managed code operating system (OS) being developed by Microsoft with joint effort of Microsoft Research. It had been reported to be a possible commercial implementation of the OS Singularity, a research project begun in 2003 to build a highly dependable OS in which the kernel, device drivers, and application software are all written in managed code. It was designed for concurrency, and could run a program spread across multiple nodes at once. It also featured a security model that sandboxes applications for increased security. Microsoft had mapped out several possible migration paths from Windows to Midori. Midori was discontinued some time in 2015, though many of its concepts were used in other Microsoft projects.

PolskaGra napisał(a):

czy jest jakaś możliwosć napisania os tylko w c++?

operacje na rejestrach procesora w c++ to strasznie karkołomne nieintuicyjne pisanie.
napisz sb bootloader, przejdź w tryb chroniony zauważ, że bez "myślenia i rozumienia" sprzętu w kategoriach asemblerowych .... się nie da
zalety c++ ujawniają się przy programowaniu obiektowym, które umożliwia właśnie działający system operacyjny. więc raczej błędne koło.
pisząc w c++ proceduralnie - Brak sensu.

Po co w C++, skoro jest Rust? I tak, jest sporo projektów OSów pisanych w Ruscie:
https://www.redox-os.org/
https://github.com/flosse/rust-os-comparison

Zwracam uwagę wszystkim piszącym o assemblerze, że nie żyjemy w latach 2000ch. Jest UEFI z biblioteką EDK2, która załatwia większość bardzo niskopoziomowych rzeczy za nas. Można spokojnie napisać OSa bez znajomości assemblera.

Haiku jest pisane w C++ i podobno ma obiektowe API. Tylko ten C++ w kernelu będzie miał bardzo mało wspólnego z C++ w user space.

main avast napisał(a):

operacje na rejestrach procesora w c++ to strasznie karkołomne nieintuicyjne pisanie.
napisz sb bootloader, przejdź w tryb chroniony zauważ, że bez "myślenia i rozumienia" sprzętu w kategoriach asemblerowych .... się nie da

Warto zauważyć, że również jezyk C (standard) o ile mi wiadomo w żaden sposób czegoś takiego nie wspiera.

vtx napisał(a):

czy Java ma bezpośredni dostęp do sprzętu - mam na myśli bezpośrednie odwołania do pamięci - np. MMIO?
czy Java ma bezpośredni dostęp do wszystkich stopni uprzywilejowania procesora?
czy potrafi obsługiwać wyjątki procesora?
czy Java ma wsparcie w sobie do obsługi wszystkich możliwych procesorów sprzętowych - nie wirtualnych?
czy Java zna w ogóle pojęcie sterownika urządzenia?
czy Java w ogóle rozróżnia pojęcia user-space i kernel-space?
czy Java ma wsparcie do atomowych operacji bepośrednio na procesorze?

A teraz w miejsce java wpisujemy C i staramy się odpowiedzieć na te same pytania - proszę o wskazanie odpowiednich rozdziałów w specyfikacji C.

Masz jakieś namiary na taki system w Javie?

W całości w Javie nie, ale podobnie nie ma systemu operacyjnego napisanego w całości w C :-)

(PS https://en.wikipedia.org/wiki/Singularity_(operating_system), https://en.wikipedia.org/wiki/SharpOS)

vtx napisał(a):

nintyfan napisał(a):

Adamek Adam napisał(a):

świat idzie do przodu !
kiedyś młodzi chcieli zrobić system operacyjny w assembler, a teraz jest c++
za 5 lat będzie pytanie "Operating System w JS"
i znając życie nawet ktoś to zrobi :D

Ja czytałem o eksperymentalnym systemie operacyjnym w Javie.

Masz jakieś namiary na taki system w Javie? w ogóle jak rozumiecie termin "system operacyjny"? Bo jeśli tylko jako samo GUI czyli interfejs graficzny do interakcji z użytkownikiem to raczej nie powinno być problemu.
Natomiast system operacyjny jako kernel space + user space pisany w Javie - to hm... pojawiają mi się wątpliwości i pytania:

• czy Java ma bezpośredni dostęp do sprzętu - mam na myśli bezpośrednie odwołania do pamięci - np. MMIO?
• czy Java ma bezpośredni dostęp do wszystkich stopni uprzywilejowania procesora?
• czy potrafi obsługiwać wyjątki procesora?
• czy Java ma wsparcie w sobie do obsługi wszystkich możliwych procesorów sprzętowych - nie wirtualnych?
• czy Java zna w ogóle pojęcie sterownika urządzenia?
• czy Java w ogóle rozróżnia pojęcia user-space i kernel-space?
• czy Java ma wsparcie do atomowych operacji bepośrednio na procesorze?

Z Javą niewiele mam doświadczenia - stąd te pytania. Ogólnie to Java sprawia wrażenie pasożytowania na bazowym jakimś systemie operacyjnym - czyli ktoś za nią musi odwalić najgorszą robotę. Ale mogę się mylić. Jeśli tak - to proszę o argumenty merytoryczne.

Namiarów nie mam. Czytałem o nim w newsie na starych Dobrych Programach. Java posiada możliwość integracji z innymi językami. Specjalistą od Javy nie jestem, i nigdy nie pisałem większego programu w niej, ani nie korzystałem z API do integracji z innym językiem. W Javie każda klasa jest pochodną jednego korzenia. Dałoby się pewnie napisać OS, poprzez implementację własnej biblioteki standardowej i dodanie kodu assemblera do jądra.

lata temu MS otworzył projekty jak midori i singularity. Oba na gihub. To było w czymś c# podobnym ale jak pamiętam i tak było kawałki w C(i może w asm).
Co do javy pamiętam że takie coś Java os i to końcówka lat 90-tych.
Pewnie w jakimś googlu czy ms nadal coś dziergają w jezykach zarządzanych ale tego nikt z nas nie zobaczy.

no to ja wrzucę swoją cegiełkę - używaliście tego systemu operacyjnego? I ważne pytanie CZY O NIM SŁYSZELIŚCIE ? Ja tak, jest całkiem mały i szybki.

A najciekawsze jest to, że prawdopodobnie na jednym ze screenów jest polski FASM T. Grysztara z tego co pamiętam
I to jest właśnie prawdziwe programowanie

jarekr000000 napisał(a):

main avast napisał(a):

operacje na rejestrach procesora w c++ to strasznie karkołomne nieintuicyjne pisanie.
napisz sb bootloader, przejdź w tryb chroniony zauważ, że bez "myślenia i rozumienia" sprzętu w kategoriach asemblerowych .... się nie da

Warto zauważyć, że również jezyk C (standard) o ile mi wiadomo w żaden sposób czegoś takiego nie wspiera.

Tak, same czyste C w niektórych sytuacjach nie wystarczy i trzeba się posiłkować asemblerem. Ale to wszystko zależy od jakiego poziomu startujemy. Bez wstawek asemblerowych w niektórych sytuacjach się nie obędzie.
Edit: Ale ale, całkiem zapomniałem o słowie kluczowym register i operacjach bitowych na uint-ach przecież to jest dostępne od ręki - a mam wrażenie, że właśnie o to chodziło @main avast.

vtx napisał(a):

czy Java ma bezpośredni dostęp do sprzętu - mam na myśli bezpośrednie odwołania do pamięci - np. MMIO?

ioremap()
*(uint32_t *)0xfeedbeef = 0xffff1234;
Oczywiście ioremap() to funkcja API ale również napisana w C z możliwymi wstawkami asemblerowymi

czy Java ma bezpośredni dostęp do wszystkich stopni uprzywilejowania procesora?

Tutaj mogą okazać się potrzebne drobne wstawki asm

czy potrafi obsługiwać wyjątki procesora?

Zależy jak sprzęt informuje o wyjątkach - ale to może być kwestia instalacji handlerów w C pod określonymi adresami w sprzęcie

czy Java ma wsparcie w sobie do obsługi wszystkich możliwych procesorów sprzętowych - nie wirtualnych?

Znowu zależy na jakim poziomie operujemy, ale z poziomu języka C + wstawki asm jest pewna dowolność ale nie jest ona limitowana możliwościami języka C

czy Java zna w ogóle pojęcie sterownika urządzenia?

C potrafi operować bezpośrednio na pamięci zamapowanej danego urządzenia więc jest w stanie samodzielnie kontrolować dany układ

czy Java w ogóle rozróżnia pojęcia user-space i kernel-space?

Zależy znowu gdzie jesteśmy - czy w kernelu czy w user-space. Ale program w C pisany dla kernela a program w C dla user-space to dwa całkiem odmienne światy - więc rozróżnienie jest. Te dwa różne światy oczywiście zapewniają całkiem różne dostępy i ochronę.

czy Java ma wsparcie do atomowych operacji bepośrednio na procesorze?

W C jest dostęp bezproblemowy do wstawek asm bezpośrednio do rzeczywistego, fizycznego procesora bez konieczności pośrednictwa jakichś wirtualizujących rozwiązań.

A teraz w miejsce java wpisujemy C i staramy się odpowiedzieć na te same pytania - proszę o wskazanie odpowiednich rozdziałów w specyfikacji C.

Hm... Nie podałeś ani jednego argumentu, który odpowiadałby na moje pytania. Szkoda.
Nie jestem też pewien czy oczekujesz ode mnie, że podam ze specyfikacji C jakieś słowa kluczowe, które będą specjalnie zaprojektowane i specjalizowane do konkretnych zastosowań - jak np.:

• osobne słowo kluczowe do dostępu do MMIO
• osobne słowo kluczowe operujące na koprocesorach
• przełączanie zegarów w systemach embedded
  ? No nie żartujmy :)

Akurat C+asm są w stanie same sobie zapewnić dostęp do sprzętu bez konieczności pośrednictwa i wykorzystywania niższych warstw systemu operacyjnego a tym bardziej software'owej wirtualizacji.

A odnośnie jeszcze samych moich pytań - to chyba nieprecyzyjnie się tutaj wyraziłem - bo chodziło mi o całość - czyli java+jvm.
Z tego co wiem to java jest uzależniona od jvm na chwilę obecną - więc chyba należy traktować jedno i drugie jako całość - bo nie przeskoczysz jvm-a i nie dostaniesz się bezpośrednio do rzeczywistego sprzętu. Zawsze będziesz mieć jakąś dodatkową warstwę abstrakcji.
Tak ja to widzę - ale jeśli się mylę - to mnie poprawcie :)

A to może jeszcze jedno pytanko:
Czy Java+jvm są w stanie same z siebie ruszyć sprzęt od resetu procesora rzeczywistego i zainicjować wszystkie niskopoziomowe funkcje całego sprzętu? Czyli przykładowo SDRAM, zegary systemowe skonfigurować power management?

Raczej nie - java jest uzależniona i odseparowana warstwą wirtualizacji - więc raczej nici z OS-a z prawdziwego zdarzenia. I taki miał być ogólny wydźwięk mojego posta :)

A teraz poproszę o argumenty merytoryczne jako odpowiedzi na moje pytania.

AnyKtokolwiek napisał(a):

Jest. W niczym nie jest gorszy od C.

To jest dziwne, bo możemy sobie zapisać jakąś instrukcję procesora w C++ po prostu jako string "\xc3" i teraz czy piszemy ten program za pomocą samego C++ czy jednak używamy instrukcji procesora dla danej architektury?

Komputer po włączeniu ładuje sobie BIOS i nowszy UEFI z takiej małej pamięci EEPROM do ramu i można korzystać z przerwań biosa jak z przewań systemu operacyjnego gdyż po prostu jest to załadowany program od początku do ramu i tam leży.

Teraz jak wybierzemy bootowanie systemu, to zwykle wczytujemy pierwszy fragment 512bajtów, tam musimy zrobić pewne przygotowania, wczytanie wszystkiego z dysku za pomocą tych przerwań, które BIOS wcześniej dodał do ramu, nie wiem jak w UEFI jest dawno temu robiłem swój system operacyjny.

Każdy procesor ma swoje instrukcje i instrukcje specjalne takie, które nie występują logicznie w językach programowania.
Można stworzyć biblioteki, które opakują różne te operacje dla różnych systemów, ale zwykle jest tak, że jeden procesor coś takiego posiada, a inny nie.

Np. możemy podzielić pamięć ram przy paginacji, na ring0 dla systemu i ring3 dla użytkownika.
I teraz wchodzą do gry zabezpieczenia, jako że użytkownik może mieć jeszcze virtualną pamięć to może nie mieć dostępu do kernela, ale kernel będzie miał dostęp do użytkownika i żeby zablokować możliwość kernelowi dostęp do użytkownika są też specjalne instrukcje procesora, stac np. set access, bez tego wystąpi przerwanie jak coś zrobimy z poziomu kernela u użytkownika, dlatego zwykle system jak linux implementujący te zabezpieczenie wymaga robienia copy_from_user, lub copy_to_user, który wewnątrz wywołuje te instrukcje procesora dla danej architektury, zwykle system operacyjny enkapsuluje te operacje, a z poziomu języka programowania używamy po prostu jakichś funkcji, które wewnątrz wywołują operacje assemblera.

Nawet hardware debuggowanie to jest sprzętowe i języki programowania go nie wspierają tak wysokopoziomowo, chodź wiadomo można zrobić bilbiotekę, która opakuje dla różnych procesorów.
A tak wymagane jest czytanie dokumentacji procesora, która wyjaśnia jak rozwiązywać pewne problemy i co jest zalecane.

Każdy rdzeń ma własne dane swojego procesu i specjalną instrukcję do dostępu do danych o procesie, więcej ciekawych operacji jest implementowana na poziomie kernela, na pewno hakowanie jądra jest ciekawe.

CloudPro napisał(a):

To jest dziwne, bo możemy sobie zapisać jakąś instrukcję procesora w C++ po prostu jako string "\xc3" i teraz czy piszemy ten program za pomocą samego C++ czy jednak używamy instrukcji procesora dla danej architektury?

To są wszystko rozszerzenia - nie cechy standardu języka.

Dawno na komputerach posiadajacych system nie pisałem wstawek. Ale "jakoś" mi sie wydaje, ze nie ejst limitujace, ze nie da się wstawić w mneijszych czy wiekszych potach rozkazu czy pięciu, tylko we jakiś potemcjalnych "context switchingach" nie dających się wyrazić w C/C++. Mam przed oczami jakieś np przełaczanie stosów, aby ganiało kilka wątków *)

*) wątek dla "nas programistów" to coś nieco innego niż dla low-lewelowców / mikroprocesoworców

PS n/t C++ a system warto wspomnieć o polskim schedulerze w C++ o nazwie"distortos" by Freddie Chopin z Elektrody również github, ... więc się da

vtx napisał(a):

vtx napisał(a):

czy Java ma bezpośredni dostęp do sprzętu - mam na myśli bezpośrednie odwołania do pamięci - np. MMIO?

ioremap()
*(uint32_t *)0xfeedbeef = 0xffff1234;
Oczywiście ioremap() to funkcja API ale również napisana w C z możliwymi wstawkami asemblerowymi

Pięknie, tyle że taką funkcję można dostarczyć do prawie każdego języka w tym javy i PHP.

czy Java ma bezpośredni dostęp do wszystkich stopni uprzywilejowania procesora?

Tutaj mogą okazać się potrzebne drobne wstawki asm

Jak wyżej. Nie widziałem wstawek w ASM w PHP, ale skoro można w C to można i w PHP.

czy potrafi obsługiwać wyjątki procesora?

Zależy jak sprzęt informuje o wyjątkach - ale to może być kwestia instalacji handlerów w C pod określonymi adresami w sprzęcie

W standardzie C nic na ten temat nie ma. A jak to nie jest standard tylko jakieś rozszerzenie - to jak wyżej można to zrobić też w javie i PHP :-)

czy Java ma wsparcie w sobie do obsługi wszystkich możliwych procesorów sprzętowych - nie wirtualnych?

Znowu zależy na jakim poziomie operujemy, ale z poziomu języka C + wstawki asm jest pewna dowolność ale nie jest ona limitowana możliwościami języka C

Jak wyżej

czy Java zna w ogóle pojęcie sterownika urządzenia?

C potrafi operować bezpośrednio na pamięci zamapowanej danego urządzenia więc jest w stanie samodzielnie kontrolować dany układ

Java też potrafi operować na pamięci zmapowanej (pliki/ urządzenia).

czy Java w ogóle rozróżnia pojęcia user-space i kernel-space?

Zależy znowu gdzie jesteśmy - czy w kernelu czy w user-space. Ale program w C pisany dla kernela a program w C dla user-space to dwa całkiem odmienne światy - więc rozróżnienie jest. Te dwa różne światy oczywiście zapewniają całkiem różne dostępy i ochronę.

To, że się inaczej pisze programy to wiadomo, w javie też się inaczej pisze gry, inaczej HFT, a inaczej aplikacje bankowe.
Ale w standardzie nic nie ma o tym. Jak również nie ma o user-space i kernel-space. Tak jak w C.

czy Java ma wsparcie do atomowych operacji bepośrednio na procesorze?

W C jest dostęp bezproblemowy do wstawek asm bezpośrednio do rzeczywistego, fizycznego procesora bez konieczności pośrednictwa jakichś wirtualizujących rozwiązań.

W javie są funkcje biblioteczne, które zapewniają np. CAS itd. Realizowane w praktyce przez odpowiednie instukcje CPU. Znowu nie ma różnicy.

A teraz w miejsce java wpisujemy C i staramy się odpowiedzieć na te same pytania - proszę o wskazanie odpowiednich rozdziałów w specyfikacji C.

Hm... Nie podałeś ani jednego argumentu, który odpowiadałby na moje pytania. Szkoda.

To co chciałem pokazać, że z punktu widzenia argumentów powyżej Java i C jednakowo nie nadają się do pisania systemów operacyjnych.
To, że w C napisano OSy wynika z tego, że są popisane dodatkowe narzędzia i rozszerzenia kompilatorów/linkerów, które jednak ze standardem C nie mają wiele wspólnego.
Takie narzędzia i rozszerzenia można napisać do prawie dowolnego języka - włączając to Javę, Javaskrypt czy PHP.
Co nie znaczy, że ma to jakikolwiek sens.

A odnośnie jeszcze samych moich pytań - to chyba nieprecyzyjnie się tutaj wyraziłem - bo chodziło mi o całość - czyli java+jvm.
Z tego co wiem to java jest uzależniona od jvm na chwilę obecną - więc chyba należy traktować jedno i drugie jako całość - bo nie przeskoczysz jvm-a i nie dostaniesz się bezpośrednio do rzeczywistego sprzętu. Zawsze będziesz mieć jakąś dodatkową warstwę abstrakcji.

1. Java działa też bez JVM (java native - jvm staje się RTSem)
2. Dostawanie się do sprzętu - wystarczy dodać odpowiednie funkcje (tak jak podałeś sam wyżej). To po prostu będzie rozszerzenie.

A to może jeszcze jedno pytanko:
Czy Java+jvm są w stanie same z siebie ruszyć sprzęt od resetu procesora rzeczywistego i zainicjować wszystkie niskopoziomowe funkcje całego sprzętu? Czyli przykładowo SDRAM, zegary systemowe skonfigurować power management?

Jak wyżej - C również tego nie potrafi - bo nie ma pojęcia rejestrów procesora itp. Więc trzeba odpowiednie funkcje/rozszerzenia było pododawać - podobnie można zrobić w innych językach. (i się robi)

Raczej nie - java jest uzależniona i odseparowana warstwą wirtualizacji - więc raczej nici z OS-a z prawdziwego zdarzenia. I taki miał być ogólny wydźwięk mojego posta :)

C jest odseparowane warstwą abstrakcji. Więc nici z OSa :-)

Ogólny wydźwięk mojego posta ma być taki - żeby zrobić OS to do typowego jezyka trzeba pododawać trochę rozszerzeń i funkcji bibliotecznych. Można to zrobić z prawie każdym językiem. Co nie znaczy, że warto.
W przypadku Javy jakimś problemem z robieniem OS jest GC, którego standard wymaga. Aczkolwiek nie jest to problem nie do przeskoczenia, bo
swego czasu powstało nawet coś takiego jak JavaRT, a jednym z dostępnych standardowo GC jest np. Epsilon GC (czyli brak). Oznacza to, że np. w trybie jądra taka java mogła by sobie działać bez GC i być wystarczająco RT, żeby pisać w tym sterowniki/krytyczne sekcje.

Oczywiście nie zachęcam nikogo do pisania OSów w Javie:

• choć C się do tego nie nadaje :-) - ze względów bezpieczeństwa,
• to Java, mimo - że wielokrotnie lepsza od C nadal nie jest wystarczająco bezpieczna jak na obecne standardy,

Więc już niech lepiej te OSy piszą w Rust lub jakimś podzbiorze C++ czy czymś innym.

elwis napisał(a):

Zwracam uwagę wszystkim piszącym o assemblerze, że nie żyjemy w latach 2000ch. Jest UEFI z biblioteką EDK2, która załatwia większość bardzo niskopoziomowych rzeczy za nas. Można spokojnie napisać OSa bez znajomości assemblera.

OS na peceta ... taaaaak ... choc zaczynam mieć wątpliwości, bo zdanie mówi tylko o bootloaderze, a OS to dalece więcej niż bootloader.
OS ogólny - nie. W całej reszcie świata ani UEFI, ani BIOS nie ma

jarekr000000 napisał(a):

main avast napisał(a):

operacje na rejestrach procesora w c++ to strasznie karkołomne nieintuicyjne pisanie.
napisz sb bootloader, przejdź w tryb chroniony zauważ, że bez "myślenia i rozumienia" sprzętu w kategoriach asemblerowych .... się nie da

Warto zauważyć, że również jezyk C (standard) o ile mi wiadomo w żaden sposób czegoś takiego nie wspiera.

...

A teraz w miejsce java wpisujemy C i staramy się odpowiedzieć na te same pytania - proszę o wskazanie odpowiednich rozdziałów w specyfikacji C.

Dokładnie tak jest.
Wszytsko jest ekstenszynem, wszelkie _AX=0x1234; __int__(0x21) (Borland) asm { ld ax, 16 GCC itd...

Więc apostołom C można powiedzieć, że tak samo do pisania OS nadawał by się Pascal z ekstensyznami (w praktyce kazdy realny Pascal oprócz mainframów to miał). Skądinąd przepiękny przykład, że brak arytmetyki wskaźników niczego nie kastruje w możliwosciach programowania systemowego, i nie ma jakiegos mitycznego czaru C do tego celu

@elwis:

Jest UEFI z biblioteką EDK2, która załatwia większość bardzo niskopoziomowych rzeczy za nas. Można spokojnie napisać OSa bez znajomości assemblera.

Czy gdybyś wziął EDK2, zbootował się do shella i odpalił swoją zewnętrzną binarkę (twój OS), to wtedy byłoby to uznane jako OS?

WeiXiao napisał(a):

@elwis:

Jest UEFI z biblioteką EDK2, która załatwia większość bardzo niskopoziomowych rzeczy za nas. Można spokojnie napisać OSa bez znajomości assemblera.

Czy gdybyś wziął EDK2, zbootował się do shella i odpalił swoją zewnętrzną binarkę (twój OS), to wtedy byłoby to uznane jako OS?

Nie, specyfikacja UEFI mówi jasno jak wygląda proces bootowania i nie każda binarka odpalona w shellu jest systemem operacyjnym. Jednak OS zabootowany z UEFI ma dostęp do jego API.

https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/6_stage_4_boot_to_os

jarekr000000 napisał(a):

vtx napisał(a):

vtx napisał(a):

czy Java ma bezpośredni dostęp do sprzętu - mam na myśli bezpośrednie odwołania do pamięci - np. MMIO?

ioremap()
*(uint32_t *)0xfeedbeef = 0xffff1234;
Oczywiście ioremap() to funkcja API ale również napisana w C z możliwymi wstawkami asemblerowymi

Pięknie, tyle że taką funkcję można dostarczyć do prawie każdego języka w tym javy i PHP.

No nie - skoro nie masz dostępu do sprzętu bezpośrednio to jak chcesz uzyskać chociażby adres, pod którym jest udostępniany dany obszar np. karty PCI? Zdaje się w javie operujesz na wirtualnym sprzęcie - czyli musi być jakaś warstwa abstrakcji i wirtualizacji, która będzie pośredniczyć w komunikacji ze sprzętem.

czy Java ma bezpośredni dostęp do wszystkich stopni uprzywilejowania procesora?

Tutaj mogą okazać się potrzebne drobne wstawki asm

Jak wyżej. Nie widziałem wstawek w ASM w PHP, ale skoro można w C to można i w PHP.

Eh, to może ja przypomnę jak działać powinno wnioskowanie:
"mam argumenty merytoryczne - więc jestem w stanie na ich podstawie wyciągnąć wnioski"
tutaj tak jakbyś próbował odwrócić ten proces:
"mam wnioski - to teraz do tych wniosków znajdę sobie jakieś argumenty, które będą mi pasować"

• stosowanie analogii: skoro C daje radę to czemu nie możnaby tego zrobić w php?

czy potrafi obsługiwać wyjątki procesora?

Zależy jak sprzęt informuje o wyjątkach - ale to może być kwestia instalacji handlerów w C pod określonymi adresami w sprzęcie

W standardzie C nic na ten temat nie ma. A jak to nie jest standard tylko jakieś rozszerzenie - to jak wyżej można to zrobić też w javie i PHP :-)

No nie rozumiemy się kompletnie. Wiesz na czym np. w takim ARM-ie polega instalacja handlera wyjątków, przerwań? Na zwykłym skopiowaniu adresu handlera pod określony adres w pamięci. I niby C nie wspiera takiej operacji? Zasadniczo to do każdej takiej próby zbicia moich argumentów powinienem dodać, że zarówno java jak i php są tylko aplikacjami użytkownika - użytkownikami funkcjonalności dostarczanej im przez kernel i w związku z tym podlegają wszystkim ograniczeniom związanym z tym że są w innym ringu procesora jeśli chodzi o dostępy i niewiele mogą same zrobić. Dodatkowo podlegają procesowi schedulingu i wywłaszczania co może powodować sytuacje typu race condition. Bez jawnego wsparcia (jakichś pluginów w kernelu) dla javy lub php nie ma szans w/g mnie na bezpieczną obsługę wyjątków procesora.

czy Java ma wsparcie w sobie do obsługi wszystkich możliwych procesorów sprzętowych - nie wirtualnych?

Znowu zależy na jakim poziomie operujemy, ale z poziomu języka C + wstawki asm jest pewna dowolność ale nie jest ona limitowana możliwościami języka C

Jak wyżej

Ja też mógłbym udzielić jakiejś odpowiedzi na jedno pytanie a potem sobie pod pozostałymi powklejać "jak wyżej" bez głębszego zrozumienia tematu. Java z tego co się orientuję widzi procesor jako zasób tylko wirtualnie. I ten wirtualny procesor jest symulowany przez oprogramowanie. Czyli nie masz też bezpośredniości w tym kierunku:
np. wyjątek procesora -> handler obsługi w javie dla tego wątku, bo zawsze będziesz mieć kod pośredniczący, tłumaczący i dostosowujący niskopoziomowe dane ze sprzętu na jakiegoś callbacka w javie.

czy Java zna w ogóle pojęcie sterownika urządzenia?

C potrafi operować bezpośrednio na pamięci zamapowanej danego urządzenia więc jest w stanie samodzielnie kontrolować dany układ

Java też potrafi operować na pamięci zmapowanej (pliki/ urządzenia).

Sama z siebie? Nie korzysta do tego czasem z usług kernela? W czym jest kernel napisany? W Javie? A przerwania? Jak widzisz możliwość skutecznego i bezpiecznego obsługiwania przerwań? I znowu biorąc pod uwagę to że jvm to zwykły proces usera - znowu masz pole do wyścigów i deadlocków.

czy Java w ogóle rozróżnia pojęcia user-space i kernel-space?

Zależy znowu gdzie jesteśmy - czy w kernelu czy w user-space. Ale program w C pisany dla kernela a program w C dla user-space to dwa całkiem odmienne światy - więc rozróżnienie jest. Te dwa różne światy oczywiście zapewniają całkiem różne dostępy i ochronę.

To, że się inaczej pisze programy to wiadomo, w javie też się inaczej pisze gry, inaczej HFT, a inaczej aplikacje bankowe.
Ale w standardzie nic nie ma o tym. Jak również nie ma o user-space i kernel-space. Tak jak w C.

Ciągle mam wrażenie, że nie widzisz szerszego kontekstu. W C możesz pisać i w kernel i userspace. Kontekst decyduje co przysługuje programiście w kernelu a co w userspace. W javie znowu jesteś ograniczony tym co zapewnia położony poniżej kernel. Kernel w C+asm zarządza zasobami. Napiszesz kernel w javie? No nie - bo cały czas chodzi o to, że java jest niesamodzielna jako aplikacja userspace'owa.
W kernelu cała sprawa głównie opiera się na interakcji ze sprzętem - korzystając z odwołań do pamięci czy to RAM czy zamapowanej + obsługa przerwań i wyjątków.
W javie zdaje się nie masz możliwości bezpiecznego krozystania z tej funkcjonalności bez kombinowania - czyli masz ryzyko wywłaszczenia jvm-a na jakiś czas i race codition gotowe.

czy Java ma wsparcie do atomowych operacji bepośrednio na procesorze?

W C jest dostęp bezproblemowy do wstawek asm bezpośrednio do rzeczywistego, fizycznego procesora bez konieczności pośrednictwa jakichś wirtualizujących rozwiązań.

W javie są funkcje biblioteczne, które zapewniają np. CAS itd. Realizowane w praktyce przez odpowiednie instukcje CPU. Znowu nie ma różnicy.

Skoro java widzi tylko wirtualną reprezentację rzeczywistego procesora a jvm działa jako zwykła aplikacja użytkownika to znowu bez wsparcia samego kernela nic nie zrobisz.
Czyli znowu: java pasożytuje a nie zapewnia kontrolowanie dostępów do sprzętu.

A teraz w miejsce java wpisujemy C i staramy się odpowiedzieć na te same pytania - proszę o wskazanie odpowiednich rozdziałów w specyfikacji C.

Hm... Nie podałeś ani jednego argumentu, który odpowiadałby na moje pytania. Szkoda.

To co chciałem pokazać, że z punktu widzenia argumentów powyżej Java i C jednakowo nie nadają się do pisania systemów operacyjnych.

To stwierdzenie do pewnego stopnia mnie rozbawiło :) Możliwość operacji bezpośrednio na rejestrach rzeczywistego procesora, możliwość wstawek asemblerowych, transferów danych bezpośrednio do i z rejestrów, dostęp do fizycznej pamięci - rozumiem to za mało żeby uznać, że C nadaje się do pisania OS-ów.

To, że w C napisano OSy wynika z tego, że są popisane dodatkowe narzędzia i rozszerzenia kompilatorów/linkerów, które jednak ze standardem C nie mają wiele wspólnego.
Takie narzędzia i rozszerzenia można napisać do prawie dowolnego języka - włączając to Javę, Javaskrypt czy PHP.
Co nie znaczy, że ma to jakikolwiek sens.

Bliskość dostępu do kodu maszynowego z poziomu języka C - to była chyba najbardziej istotna i przesądzająca kwestia. Tak mi się wydaje.

A odnośnie jeszcze samych moich pytań - to chyba nieprecyzyjnie się tutaj wyraziłem - bo chodziło mi o całość - czyli java+jvm.
Z tego co wiem to java jest uzależniona od jvm na chwilę obecną - więc chyba należy traktować jedno i drugie jako całość - bo nie przeskoczysz jvm-a i nie dostaniesz się bezpośrednio do rzeczywistego sprzętu. Zawsze będziesz mieć jakąś dodatkową warstwę abstrakcji.

1. Java działa też bez JVM (java native - jvm staje się RTSem)

Dobrze, a w czym napisany jest taki jvm w takim przypadku? W javie? Rozumiem, że taki rts jest dedykowanym rozwiązaniem pod określoną grupę rozwiązań sprzętowych.

3. Dostawanie się do sprzętu - wystarczy dodać odpowiednie funkcje (tak jak podałeś sam wyżej). To po prostu będzie rozszerzenie.

Biorąc pod uwagę to, że nie znam specyfiki powyższego rozwiązania java native, o którym piszesz - nie będę się tutaj wypowiadać.

A to może jeszcze jedno pytanko:
Czy Java+jvm są w stanie same z siebie ruszyć sprzęt od resetu procesora rzeczywistego i zainicjować wszystkie niskopoziomowe funkcje całego sprzętu? Czyli przykładowo SDRAM, zegary systemowe skonfigurować power management?

Jak wyżej - C również tego nie potrafi - bo nie ma pojęcia rejestrów procesora itp. Więc trzeba odpowiednie funkcje/rozszerzenia było pododawać - podobnie można zrobić w innych językach. (i się robi)

Raczej nie - java jest uzależniona i odseparowana warstwą wirtualizacji - więc raczej nici z OS-a z prawdziwego zdarzenia. I taki miał być ogólny wydźwięk mojego posta :)

C jest odseparowane warstwą abstrakcji. Więc nici z OSa :-)

Ale to tylko warstwa abstrakcji API a nie warstwa wirtualizacji zasobów sprzętowych. W C nie masz bariery typu jvm, której nie da się przeskoczyć - i z której po prostu zawsze musisz korzystać.

Ogólny wydźwięk mojego posta ma być taki - żeby zrobić OS to do typowego jezyka trzeba pododawać trochę rozszerzeń i funkcji bibliotecznych. Można to zrobić z prawie każdym językiem. Co nie znaczy, że warto.
W przypadku Javy jakimś problemem z robieniem OS jest GC, którego standard wymaga. Aczkolwiek nie jest to problem nie do przeskoczenia, bo
swego czasu powstało nawet coś takiego jak JavaRT, a jednym z dostępnych standardowo GC jest np. Epsilon GC (czyli brak). Oznacza to, że np. w trybie jądra taka java mogła by sobie działać bez GC i być wystarczająco RT, żeby pisać w tym sterowniki/krytyczne sekcje.

Oczywiście nie zachęcam nikogo do pisania OSów w Javie:

• choć C się do tego nie nadaje :-) - ze względów bezpieczeństwa,
• to Java, mimo - że wielokrotnie lepsza od C nadal nie jest wystarczająco bezpieczna jak na obecne standardy,

Więc już niech lepiej te OSy piszą w Rust lub jakimś podzbiorze C++ czy czymś innym.

@vtx

Java z tego co się orientuję widzi procesor jako zasób tylko wirtualnie.

Język według ciebie potrzebuje być CPU-aware?

Cały czas piszesz w taki sposób jakbyś zapominał że to że web-javka lata na JVM, wcale nie oznacza że nie możesz wziąć kodu javowego i wyemitować dokładnie tego samego (no dobra, teoretycznie) co z kodu C.

A idąc jeszcze z innej strony, czy jeżeli masz milion LoC w Javie, ale masz thin-layer nad sprzętem, to oznacza to że nie masz OSa w Javie?

Przecież chyba wszyscy w jakimś stopniu piszą sobie nakładki nad sprzętem

WeiXiao napisał(a):

@vtx

Java z tego co się orientuję widzi procesor jako zasób tylko wirtualnie.

język według ciebie potrzebuje być CPU-aware?

W przypadku języka stosowanego w zastosowaniach niskopoziomowych dobrze, gdyby umożliwiał jak najbardziej intuicyjną i małoskomplikowaną translację kodu z tego języka na asm plus jakieś wspomaganie możliwości używania instrukcji asm. Ale samą translacją na kod maszynowy ma się zajmować kompilator.

@vtx

W przypadku języka stosowanego w zastosowaniach niskopoziomowych dobrze, gdyby umożliwiał jak najbardziej intuicyjną i małoskomplikowaną translację kodu z tego języka na asm plus jakieś wspomaganie możliwości używania instrukcji asm. Ale samą translacją na kod maszynowy ma się zajmować kompilator.

Nadal to jest tylko twoje życzenie i coś typu "nice-to-have" aniżeli techniczne ograniczenie

WeiXiao napisał(a):

@vtx

W przypadku języka stosowanego w zastosowaniach niskopoziomowych dobrze, gdyby umożliwiał jak najbardziej intuicyjną i małoskomplikowaną translację kodu z tego języka na asm plus jakieś wspomaganie możliwości używania instrukcji asm. Ale samą translacją na kod maszynowy ma się zajmować kompilator.

Nadal to jest tylko twoje życzenie i coś typu "nice-to-have" aniżeli techniczne ograniczenie

Raczej nie "nice-to-have" ale "I-have-it-already" :)

Teoretycznie da się w większości języków napisać OS. W jednym trzeba robić więcej kombinowania i łatania, a efekt końcowy i tak może być wątpliwej jakości, w innych mniej.

W praktyce starych systemów, na których rozwój poszły miliardy zielonych, nie przepisuje na nowy język tylko dlatego, że ktoś ma taką zachciankę. Ludzie od systemów mają swoje preferencje i mówiąc delikatnie Java nią nie jest, ludzie od Javy czy podobnej klasy języka często nie znają się na praktycznej konstrukcji systemów współpracujących ze sprzętem, wiec ich nie tworzą. Ot i cała tajemnica.