Skocz do zawartości

Zarchiwizowany

Ten temat jest archiwizowany i nie można dodawać nowych odpowiedzi.

JohnBelushi

Robię system operacyjny.

Polecane posty

Ja bym radził się najpierw uczyć C++, a później Assemblera. Czemu?

Żeby móc choćby jakiś programik do tego języka napisać.

Co do samej idei - IMO lepszym pomysłem, niż pisanie systemu, który umrze zaraz, jest przyjrzenie się jadrowi Linuxa i stworzenie własnej dystrubycji.

Wszystko masz gotowe - ext4, GRUB, dużo sterowników, większość programów wystarczy dostosować do dystrybucji.

A dystrybucja jak będzie ciekawa, innowacyjna, to będzie żyć bardzo długo, bo społeczność open source będzie ją rozwijać.

Ew. można się pobawić w rozwijanie ReactOS'a.

Ale to już martwy system, tych paru developerów, którzy go trzymają przy fazie beta życiu, odejdzie, kiedy na Linuxa wejdzie Steam.

Link do komentarza
Udostępnij na innych stronach

Wszystko masz gotowe - ext4, GRUB, dużo sterowników, większość programów wystarczy dostosować do dystrybucji.

Zrobienie wszystkiego samemu jest znacznie bardziej edukacyjne wink_prosty.gif

Żeby móc choćby jakiś programik do tego języka napisać.

Chyba nie rozumiem co masz na myśli

Znaczniej łatwiej jest nauczyć się tworzyć strony

Kto co lubi, ja przykładowo nie znoszę robienia stron (od strony wizualnej, cała ta zabawa html,css etc.)

Link do komentarza
Udostępnij na innych stronach

Znaczniej łatwiej jest nauczyć się tworzyć strony

Kto co lubi, ja przykładowo nie znoszę robienia stron (od strony wizualnej, cała ta zabawa html,css etc.)

Ta.. ja też nie lubię bawić się CSS i HTML, ale za to lubię pisać kod w PHP :)

Lecz trudniej chyba nauczyć się C++, niż np. PHP, które jest dosyć łatwe, gdyż w C++ przede wszystkim musisz rozumieć kod, który piszesz, a w PHP często się tak zdarza, że piszę już z pamięci....

Link do komentarza
Udostępnij na innych stronach

Jak trzeba to i tydzien wystarczy, zalezy jak kto sobie 'zadowalajacy poziom' przyjmie smile_prosty.gif

Jeśli masz na myśli pisanie systemu 10 lat to się zgadzam.

Jeśli masz na myśli naukę języka w tydzień, to się zgadzam.

Dla niedowiarków:

Bill Gates, Steve Jobs zaczynali sami w dwie-trzy osoby....

To już w sumie są dobre podwaliny pod jakąś religię ;)

Link do komentarza
Udostępnij na innych stronach

@Mormegil

Nie chodzi mi o programy napisane obiektowo w C, tylko obiektowo w C++ vs. strukturalnie w C.

Bez sensu smile_prosty.gif

To tak jakbyś napisał sortowanie bąbelkowe w C++ i quicksotrta w C, a następnie stwierdził, że C daje szybsze programy, za to w C++ pisze się łatwiej.

Jeżeli dla obu języków zastosuje różne podejścia to nie dowiedziemy, że jeden z nich jest "szybszy".

Swoją drogą wcale nie jestem przekonany czy kod obiektowy w C++, byłby wolniejszy od strukturalnego w C. Dobra modularyzacja kodu, którą obiektowość znacznie ułatwia, pozwala na precyzyjniejsze optymalizacje na niskim poziomie i na optymalizacje wysokopoziomowe. Dobra modularyzacja również znacząco ułatwia testowanie, co pozwala zebrać doskonalsze dane z profilera.

Link do komentarza
Udostępnij na innych stronach

@Hakken

No, o to, żeby pisać programy na system, przejęzyczyłem się.

Ta.. ja też nie lubię bawić się CSS i HTML, ale za to lubię pisać kod w PHP smile_prosty.gif

Phi... wolę pisać w whitespace, to jest język dla prawdziwych programistów!

Ew. Shakespeare. Nazwanie kogoś "świnią" obniża wartość zmiennej o 1 biggrin_prosty.gif

Koniec OT z mojej strony

Link do komentarza
Udostępnij na innych stronach

Bez sensu smile_prosty.gif

To tak jakbyś napisał sortowanie bąbelkowe w C++ i quicksotrta w C, a następnie stwierdził, że C daje szybsze programy, za to w C++ pisze się łatwiej.

Jeżeli dla obu języków zastosuje różne podejścia to nie dowiedziemy, że jeden z nich jest "szybszy".

Przyjmijmy, że mamy jakiś problem algorytmiczny. Obaj znamy optymalne rozwiązanie, zasiadamy więc do pisania.

Ja piszę strukturalnie w C, Ty piszesz obiektowo w C++.

Potem wprowadzamy jednakowe dane i mierzymy czasy obliczeń. Na tej podstawie można stwierdzić czyj program jest szybszy. Pomimo różnic w kodzie, algorytm jest ten sam, więc jedyną zmienną pozostaje język.

Zresztą prosty przykład: scanf/printf jest dużo szybszy od cout/cin. Już przy małej liczbie wczytań i wypisań różnice w czasie są spore.

Link do komentarza
Udostępnij na innych stronach

Wg. mnie system ma być: Wydajny, dobrze zoptymalizowany, biorący mało zasobów i w miarę funkcjonalny oraz z ładną szatą graficzną ; >

Dobrze by było wszczepić do systemu jeżeli zdobędziesz doświadczenie, parę programów tj. GIMP, HWM, HDTune itp.

Takich w miarę przydatnych. No cóż, czekam na efekty Twojej pracy i trzymam kciuki.

Tak wiem że to nie jest łatwe, ale cóż nikt od razu nie umie zrobić szpagatu.

Powodzenia i zero problemów ;)

Link do komentarza
Udostępnij na innych stronach

Na moim BLOGU znajduje się jeden wpis o tym, że robię system operacyjny.

Ale to tylko tak dla zabawy, a programowania i reszty zaczynam się uczyć.

Żebyście nie pomyśleli, że to jest mój PRAWDZIWY system operacyjny, dla którego założyłem ten temat. wink_prosty.gif

Byłeś wielokrotnie upominany, żebyś bardziej przyłożył się do pisania postów.

To jest froum, a nie czat, blog czy twitter. Ten post przykładowo nie ma żadnej wartości dla dyskusji. - Hakken

Link do komentarza
Udostępnij na innych stronach

Zresztą prosty przykład: scanf/printf jest dużo szybszy od cout/cin. Już przy małej liczbie wczytań i wypisań różnice w czasie są spore.

No i właśnie o to mi chodziło. Stosujesz kompletnie różne rozwiązania dla obu języków i na tej podstawie "dowodzisz", że jeden z nich jest szybszy, a drugi wygodniejszy.

Jedyne czego "dowiodłeś" to, że wstawienie większej liczby elementów do bufora lepiej zrobić na raz, niż pojedynczo.

Ciągle twierdzę, że użycie C nie gwarantuje wydajniejszego programu/systemu niż C++. Wręcz przeciwnie, C++ ułatwia uzyskanie "optymalnej" architektury, a co za tym idzie wydajniejszy program/system.

Link do komentarza
Udostępnij na innych stronach

@up

Chcesz używać printf/scanf w programie pisanym obiektowo ? ok...

@Mormegil

Porównuję różne rozwiązania, bo i języki są różne. Oczywistym jest, że gdyby wszytko było takie samo, to nie byłoby żadnej różnicy w czasie działania., ale zgadzam się, że pisząc obiektowo łatwiej cały projekt "ogarnąć".

Link do komentarza
Udostępnij na innych stronach

Chcesz używać printf/scanf w programie pisanym obiektowo ? ok...
No a czemu nie? Czy od tego architektura stanie się mniej obiektowa?
Oczywistym jest, że gdyby wszytko było takie samo, to nie byłoby żadnej różnicy w czasie działania.
No nie wiem, czy takie oczywiste. Takie oczywistości są z reguły mało oczywiste. Przykład, co jest złego w goto? Drugi przykład, jakie są skutki rzucenia wyjątku w destruktorze? Trzeci przykład, co to znaczy kod obiektowy? Kolejny, co jest szybsze ++i, czy i++? Co jest złego w zmiennych globalnych?

Kwestie wydajności nigdy nie są oczywiste. Teraźniejszy sprzęt komputerowy jest strasznie skomplikowany. Sam pipeline dekodowania instrukcji w procesorach x86/64 to jest materiał na książkę. Zwłaszcza, że mamy dwóch producentów, którzy cały czas rozwijają tą technologię.

Przykład, przechowujemy ten sam obraz w formie nie skompresowanej i skompresowanej jpeg'iem (z rozsądną jakością, oba obrazy są wciąż zbliżone) na dysku twardym. Który plik wyświetlimy szybciej?

Rozwiązania obiektowe cierpią szczególnie z tytułu komunikacji z pamięcią. Mamy kolekcję obiektów różnorodnych klas. Chcemy w pętli foreach wywołać metodę foo. Mamy gwarantowane trzy cache miss'y dla każdego obiektu w kolekcji na samym tylko wywołaniu funkcji.

Rozwiązania strukturalne mają tendencję do nadużywania if'ów i switchy. Prowadzi to powstawania rozgałęzień w kodzie, które uniemożliwiają poprawne działanie mechanizmu przewidywania. Mamy coś co nazywa się branch prediction miss. W takiej sytuacji procesor musi się "zatrzymać", tj. skasować wyniki wszystkich wykonanych wprzód operacji i rozpocząć nowe obliczenia. W tym podejściu uzyskanie wywołania "foo" w pętli foreach na kolekcji, wymaga użycia enum'a i switch'a. W pętli sprawdzamy typ obiektu i wywołujemy odpowiednie foo.

Kiedyś z kolegą sprawdziliśmy ile musi być klas aby podejście obiektowe było szybsze. Wtedy nam wyszło kilkanaście, ale to jest uzależnione od procesora, pamięci, płyty głównej, rozmiarów samej kolekcji (15 obiektów 15 klas, to nie to samo co 1500 obiektów 15 klas) i pewnie jeszcze wielu innych czynników. Pamiętajmy jednak, że mowa o samym wywołaniu funkcji, które często bywa marginalne w porównaniu z wykonaniem.

Link do komentarza
Udostępnij na innych stronach

Grub jest bardzo dobry. Jak się zrobi system w standardzie multiboot, to od razu ustawia deskryptory i protected mode.

Ja tak robię mój skromny "system" i śmiga.

Btw. Kernel Linuxa jest pisany w C obiektowo (robione są ręcznie tablice funkcji wirtualnych)

Link do komentarza
Udostępnij na innych stronach

Jako że koderki za młodu trochę liznąłem, to pozwolę sobie napisać to i owo. Osobiście nie zgodzę się że assembler jest jakimś mega trudnym językiem. Trudny w opanowaniu jest sam hardware. Podstawy podstaw na C64 opanowałem w miesiąc (tryby adresowania i tym podobne historie), potem już tylko kwestia ogarnięcia co gdzie "siedzi". Potem była Amiga i Motorolka 68k. Pisanie czegokolwiek pod MC68k to była poezja. Nie miałem nigdy ambicji do zostania koderem, więc pisałem głównie użytki na własne potrzeby. W sumie można by było zrobić to samo w AMOSie czy innym BASICu. Jak zanabyłem pierwszego pc to oczywiście pierwszą rzeczą jaką sobie zorganizowałem to był kompilator assemblera. Poddałem się. Takiej rzeźby jaka jest na pc to chyba jakiś chory sen paranoika. Kilka trybów pracy procesora, w każdym dzieją się rzeczy których ja nie mogłem pojąć (a może po prostu mi się nie chciało). Nawet był kiedyś w CDA kurs assemblera (chyba po to pradzieje były). Podstawą assemblera jest doskonała znajomość architektury komputera. Sam język jest szybki bo grzebie bezpośrednio w sprzęcie. C musi się "tłumaczyć" ze swoich instrukcji na zera i jedynki które zakuma procesor. Właśnie z powodu kombinacji w architekturze pc i chęci zachowania kompatybilności wstecznej assembler pc jest skomplikowany. A i sam x86 do najprostszych nie należy. Od groma instrukcji, rejestrów, trybów pracy proca jest chyba 3 czy 4 - koszmarr. Ale jak ktoś ambitny jest to czemu nie. Mi się assembler najbardziej przydał z czasów Commodore 64, bo miałem potem kilka razy programować procesor 6502 w jakichś sterownikach standalone.

Jeżeli chodzi o programowanie na pc, to bym proponował zacząć od podstawy podstaw czyli Pascala (FPC jest chyba darmowy). Jak autor wątku opanuje Pascala to potem można się brać za C(++). Zresztą na studiach programowaliśmy na kartce papieru operując diagramami N/S i też się dało. Dlaczego nie polecam C++ na początek? Bo to straszna kobyła i łatwo się do niej zniechęcić. Jak się opanuje pętle w Pascalu to już można śmiało robić proste gierki. Ja na informatyce w liceum zrobiłem arkanoida w trybie tekstowym - nie starczyło czasu przed maturą żeby to "ubrać" w grafikę. Tylko niech się nikt nie rzuca na Turbo Pascala by Borland. To już jest taki staroć że albo nie działa wcale pod windą, albo wywala takie krzaki że osiwieć idzie. Na początek warto zapoznać się z zasadami umieszczania zwykłego tekstu na ekranie, potem pętle, tablice a na koniec funkcje. Nie trzeba wkuwać całego Pascala na "blachę" bo nie o to chodzi. Wystarczy go znać na tyle, aby rozwiązywać zadany problem na poziomie algorytmu. Potem to już tylko kwestia implementacji (nie zależnie od języka).

Jeżeli chodzi o assemblera na pc to z tego co wiem Mortal Kombat, MK2 i MK3 były napisane właśnie w assemblerze. Poza tym i kilkoma demami nie "zderzyłem" się z assemblerem na pc.

Link do komentarza
Udostępnij na innych stronach

@stingray

IMO Pascal jest stratą czasu.

To język, który jest już praktycznie martwy.

A C++ nie jest aż tak trudny, kwestia chęci do nauki (bo jak ktoś to robi, bo musi, to nie ma sensu).

No i - są bardzo dobre środowiska programistyczne, np. MS Visual C++ (mimo, że M$ nie lubię, to to im się udało), niestety, jeśli chodzi o wersje Express, to ta najnowsza, będzie umozliwiała programowanie pod Metro.

A na linuxa jest Code::Blocks (na linuxa też) - co prawda IMO nie dorównuje płatnym wersjom Visual, ale w końcu jest darmowe.

Jest też oczywiście mnóstwo innych świetnych edytorów kodu i kompilatorów (z edytorów polecę Notepad++, nie tylko do C++ zresztą, wiele języków obsługuje).

Link do komentarza
Udostępnij na innych stronach

@tomsto - martwy jak martwy, ale to dobry początek aby nauczyć się myśleć algorytmami. Przyznam, że ja się od C odbiłem. Chyba dlatego, że już mi wtedy programowanie nie było potrzebne, a w liceum i na studiach katowali nas właśnie Pascalem. Nie wiem jak to teraz wygląda. Co do środowisk programistycznych, to jestem zdecydowanie przeciwny. Mnie już te wszystkie dot nety i inne badziewia tak osłabiają. W pracy używam właśnie softu napisanego w javie i działającego na .Net + Yellow od Apple. Na Quadzie działa to tak sobie niestety, a innego rozwiązania nie ma.

Link do komentarza
Udostępnij na innych stronach

Gość
Temat jest zablokowany i nie można w nim pisać.


  • Kto przegląda   0 użytkowników

    • Brak zalogowanych użytkowników przeglądających tę stronę.
×
×
  • Utwórz nowe...