UWAGA! Tekst dla uűytkowników 80x86 (x>2)

DJGPP - po co to komu?

Wstëp - jak na artykuî przystaîo

Dawno, dawno temu, pewien czîowiek, niesîusznie okreôlany jako red. nacz. magazynu YouBall ^H^H^H^H^H^H^H znaczy sië Fakt Agnus kolega Mirosîaw Baran znany szerszej gawiedzi jako Jubal namówiî mnie na napisanie artykuîu nt. kompilatora C dla MSDOSa - DJGPP. O ile dobrze pamiëtam, chciaî coô polecię swojemu siostrzeďcowi, który posiada PC i zaczyna coô pisaę (kodowaę?). Szczerze mówiâc daîem sië wrobię w to dzieîo ale nie jestem przekonany co z niego wyszîo, chociaű obiecywaîem Jubalowi niski poziom (tak Jubal! Pamiëtasz?) Po dîugich bólach, ciâgle przesuwajâc terminy narodzin oto jest.

Szybkie overview

DJGPP to porting kompilatora GNU C/C++ dla systemu MSDOS. Sîuűy do tworzenia programów w 32 bitowym ôrodowisku na 32 bitowych procesorach Intel, dziaîajâcych w protected mode (czyli z ochronâ pamiëci). Korzystajâc z bezpîatnego serwera DPMI (Dual Protected Mode Interface) moűna uzyskaę do 4GB tzw. flat memory czyli ciâgîej pamiëci bez segmentacji ani stronicowania. Oprócz pamiëci fizycznej mamy do dyspozycji do 256MB swap file'a, czyli dodatkowe 256MB pamiëci (traktowanej na równi z fizycznâ) zrzucanej w locie na dysk twardy. Korzystanie ze swapa odbywa sië automatycznie, bez specjalnych komend alokujâcych pamiëę na swapie czy teű w pamiëci fizycznej - po prostu malloc ();
Dziëki swojej konstrukcji jest to idealne narzëdzie do przenoszenia programów napisanych pod system Unix (wîâcznie z zaimplementowanymi dla kompatybilnoôci, lecz nie dziaîajâcymi niestety funkcjami typowo multitaskingowymi, np. fork ();). Co najwaűniejsze - DJGPP jest caîkowicie bezpîatny (oprócz dosîownie kilku wyjâtków zawartych w bibliotece C++). Caîy projekt zostaî zapoczâtkowany przez niejakiego DJ Delorie, który pozostaje gîównym koordynatorem, ale tworzeniem DJGPP zajmuje sië wielu ludzi z caîego ôwiata.

Kawaîek historii

Zapewne niektórzy wiedzâ - bo juű siedzâ na PC parë latek i liznëli nieco dziwacznej konstrukcji tego komputera, űe kiedy Intel produkowaî tylko 8 bitowe procesorki, a IBM PC znaczyîo IBM PC, a nie klon pewien czîowiek napisaî DOS-a 1.0. Nie byî to gATES (oddúwierny ?) jak niektórzy sâdzâ, ale juű wersja 2.0 (po zakupie licencji od owego tajemniczego programisty) powstaîa w Micro Sofcie (tak sië wówczas to nazywaîo) i dostaîa prefiks "MS". Od tej pory spóîka Intela z Microsoftem zatruwaîa űycie programistom i uűytkownikom komputerów tzw. PC (ja preferujë jednak nazwë IBM lub klon, gdyű PC to w/g mnie nieco szersze pojëcie, Amiga teű PC nie?). Przez lata Microsoft dâűyî do peînej kompatybilnoôci starych aplikacji w nowych wersjach syftemu DOS. I wszystko byîoby piëknie, gdyby Intel nie stworzyî najpierw 16bitówki, a potem wiekopomnego procesora 386. Byî to zaiste wielki krok naprzód - peîny 32 bitowy procesor (myôlë tu o maszynach DX a nie SX - te miaîy obciëtâ szynë pamiëci do 24 bitów). Ale MS nie próbowaî zmieniaę ani systemu, ani aplikacji. I dalej MSDOS pozostawaî single user - single task, mimo niezîych moűliwoôci procesorów serii 386 (o czym moűe ôwiadczyę Linux). Brak multitaskingu nie byî jednak najgorszy - ale fakt, űe maîo kto potrafiî wycisnâę z poczciwego Intela tryb 32 bitowy, a stronicowanie pamiëci w trybie rzeczywistym , w którym tak naprawdë to i386 byîo tylko szybszâ wersjâ 8 bitowych procesorków typu 8008 lub 8086 staîo sië koszmarem wszystkich koderów. Pamiëtam wiele dem chodzâcych w trybie rzeczywistym - byî to okres, kiedy demka na A500 biîy na gîowe pecetyczne demosy nie tylkod designem i muzykâ, ale równieű efektami. Tak dziaîo sië, aű niektórzy koderzy posiedli wiedzë tajemnâ (np. niejaki Tran) i porozdawali swoje 32 bitowe extendery (czyli programiki umoűliwiajâce korzystanie z 32bitowego kodu w protected mode). Jednak uűytkownicy Borlanda (tak C jak i Pascala) mëczyli sië z ograniczeniem pamiëci do 640KB (dziëki kochanemu MSDOSowi), alokowali sobie maksymalnie tablice po 64KB kaűda. Pamiëę powyűej pierwszego megabajta miaîa za to coraz radoôniejsze nazwy - extended, expanded, ale maîo kto potrafiî jâ wykorzystaę. Wspomnë np. o pamiëci expanded - stronicowanie po 16KB. Fajnie nie? Np. przy 4 MB, stron byîo "tylko" 256. Powstaî wiëc projekt stworzenia 32 bitowego ôrodowiska - kompilatora C pod nazwâ DJGPP. Dziëki niemu (jak juű wyűej napisaîem) mamy do dyspozycji caîâ pamiëę bez űadnych segmentów, szybkoôę 32 bitowego kodu (m.in. specyficznych 32 bitowych instrukcji i386 i lepszych) oraz ochronë pamiëci, swap, obsîugë koproca fa fa fa fa. Niestety, jako űe pracuje on pod MSDOSem nie mamy do dyspozycji multitaskingu w odróűnieniu od "oryginalnej" wersji DJGPP czyli GNU C.

Sprzët

przynajmniej 386 SX
od 7 do 40 MB wolnego miejsca na dysku (na instalacjë i swap)
przynajmniej 64 KB pamiëci systemowej (tej od 0 do 640 KB) potrzebnâ do uruchomienia serwera DPMI (w przypadku programów innych niű CWSDPMI moűe byę potrzebnych wiëcej)
co najmniej 2.5MB pamiëci extended (przy samym C, jeôli korzystasz z C++ - minimum 4MB do kompilacji wiëkszych programów)
koproc matematyczny (jeôli nie masz - doîâczany jest emulator)
system MS-DOS, okno DOS pod Windows 3.1/3.11, OS/2, Windows 95/DOS 7.0, Novell DOS 7.0, DR-DOS oraz Linux DOS Emu.

To tyle jeôli chodzi o minimalne wymagania. Ja ze swej strony polecam co najmniej 486 DX 33, 8 mega RAM, bardzo szybki twardy i kawaîek wolnego miejsca na twardym (tak z 30 MB), gdyű instalacja minimalna nie jest zbyt sensowna (bez helpów ?). Osobiôcie pracowaîem prawie rok na takiej konfiguracji i uwaűam, űe jest ona wystarczajâca. Aktualnie uűywam P150 ale dalej nie narzekam na zbyt szybkâ kompilacjë. Wynika to z faktu, űe szczególnie liczy sië twardy - przydaje sië jakiô cache dyskowy i mnóstwo pamiëci. I mimo űe mój Caviar jest jednym z najszybszych aktualnie dysków, kompilacja nie przebiega najlepiej. Cóű, wina kompilatora. Procesor jest mniej waűny - chyba 486DX4/100 Mhz to caîkowicie wystarcza. Przydaje sië za to tzw. L2 cache w iloôci np. 512KB i pîyta PCI.

Gdzie to moűna dostaę?

Kraków, Poland: ftp.cyf-kr.edu.pl:      pub/mirror/Simtel.Net/gnu/djgpp
Poznaď, Poland:  ftp.man.poznan.pl:     pub/simtelnet/gnu/djgpp
Warszawa, Poland: ftp.icm.edu.pl:       pub/simtelnet/gnu/djgpp
Stockholm, Sweden: ftp.sunet.se:
London, UK: sunsite.doc.ic.ac.uk
Concord, California, USA: ftp.cdrom.com
California, USA: ftp.digital.com,

a na innych serwerach podobnie.

Ile to pojedzie - czyli osiâgi

Na pewno wiele osób interesuje, jak niekomercyjny program wypada w porównaniu z kombajnami typu Watcom czy tez Borland. Okazuje sië, űe prëdkoôę skompilowanego programu jest co najmniej taka, jak konkurencji. Czësto zdarza sië jednak (przy wîâczonej optymalizacji, a przeîâczników optymalizacji jest duuuuuűo) űe kompilat spod DJGPP jest szybszy. Generalnie - nieúle. Ale jest takűe rysa w tym nieskazitelnym dotâd portrecie - bardzo czësto zdarza sië, űe niektóre programy dziaîajâ wolniej niű 16bitowe aplikacje skompilowane Borlandem. Wynika to z faktu, űe uűywanie funkcji I/O (np. obsîuga dysku) odbywa sië w trybie rzeczywistym (real mode) i program musi sië przeîâczyę z trybu prodected na tryb real, co trwa spory kawaîek czasu. Oprócz tego, űeby DOS potrafiî odczytaę dane naleűy je przenieôę do bufora, który jest zlokalizowany w 1MB pamiëci. Tak wiëc, aby zapisaę dane program musi przenieôę dane (w porcjach po 16KB) do pierwszego megabajta, potem przeîâczyę sië w tryb real, potem uűyę odpowiedniej funkcji BIOSu, a na koniec znów przeîâczyę sië w tryb protected. To niestety powoduje duűe straty prëdkoôci. Dla przykîadu, odczytanie 2MB w DOSie zajmuje 1 sekundë, a spod DJGPP juű 1.2 - 1.5 sekundy. Niby duűo, bo od 20% do 50% róűnicy, ale chyba nikt nie przesyîa wiëcej niű 100 MB (skâd wziâę tyle pamiëci), űeby róűnica byîa odczuwalna. Oczywiôcie liczby sâ przykîadowe, na szybkich pci'owych maszynach róűnica jest nieodczuwalna. Cóű, to juű koniec tego artykuîu. Mam nadziejë, űe udaîo mi sië przybliűyę Wam wspaniaîe narzëdzie, jakim jest DJGPP.

Podsumowanko

Zalety:

szybkoôę kompilatu
32 bitowy kod
praca w trybie chronionym
caîkowita darmocha
îatwoôę przenoszenia programów z UNIXa
setki przeîâczników optymalizacyjnych
optymalizacja pod okreôlony procesor, np. -m486
wiele dobrych bibliotek pod DJGPP (obsîuga .mod, biblioteki graficzne, okienkowe)
ciâgîa pamiëę bez segmentacji
automatycznie tworzony swap file (z CWSDPMI)
dobra dokumentacja

Wady:

strasznie wolna kompilacja (szczególnie z wîâczonymi opcjami optymalizacji)
duűa zajëtoôę dysku
duűa wielkoôę pliku po kompilacji - typowy "Hello World" zajmuje ok. 50 KB jako .exe
kod tylko pod DOS (zero Windowsów)
dziaîa na procesorach 386 i wyűszych - űegnajcie XTki i ATki 286 (a moűe to zaleta ?)
maîa prëdkoôę przy operacjach dyskowych (trudno.. coô za coô)
okropne moim zdaniem rozwiâzanie help'a - program info przypomina nieco "man" znany z UNIXa, ale obsîuga tego programu doprowadza mnie do szaîu, polecam wiëc RHIDE (dla przyzwyczajonych do borlandowskich okienek)
brak edytora - to tylko kompilator, bez ôrodowiska zintegrowanego (jeôli Ci go brak - znów polecam RHIDE)
specyficzna konstrukcja niektórych procedur oraz sposób alokacji pamiëci (a wîaôciwie jej dealokacji - iloôę wolnej pamiëci zwracana przez procedury nie zmienia sië po zwolnieniu bloku pamiëci - okazuje sië űe jest ona co prawda "wolna", ale pozostaje "zarezerwowana" - moűna z niej skorzystaę, ale bez napisania poolera, który by liczyî iloôę alokowanej i dealokowanej pamiëci nie moűna uzyskaę wiarygodnych danych. Chîopaki z listy comp.os.msdos.djgpp twierdzâ, űe to nie bîâd tylko pewna cecha DJGPP. Dzieje sië aby zyskaę szybkoôę, no cóű, kosztem wygody)

Zakoďczenie

No i to tyle. Na zakoďczenie, chciaîbym gorâco polecię ten kompilator wszystkim, którzy korzystajâ z GNU C pod UNIXem, fanów C, tym, którzy nie majâ za co kupię Watcoma, poczâtkujâcym programistom - wspaniaîe biblioteki graficzne pod DJGPP i wszystkim, którzy lubiâ popróbowaę róűnych kompilatorów. Jest to produkt na którym sië nie zawiodîem - np. kocham kiedy DJGPP wychodzi mi z bîëdem, wypisujâc zawartoôę rejestrów i kod bîëdu ale sië, do cholery nie zawiesza. Jest to piëkna sprawa dla maîo doôwiadczonych programistów. Poza tym w koďcu nie problemu z pamiëciâ. Oprócz tego istnieje wiele doskonaîych dodatków - jak np. RHIDE, Allegro (biblioteka graficzna), biblioteki do obsîugi Sound Blastera. Na tyle zaufaîem DJGPP, űe napisaîem pod nim komercyjnâ grë, za którâ juű nawet co nieco udaîo sië dostaę w postaci banknotów Narodowego Banku Polskiego.

LUDO/VD

e-mail: pajonk@ajax.umcs.lublin.pl
homepage: http://ajax.umcs.lublin.pl/~pajonk/ w tym /~pajonk/odjgpp.html

Opracowane na podstawie dokumentu djgppfaq.html (http://www.delorie.com/djgpp/v2faq/faq202s.zip) oraz wîasnych doôwiadczeď z tym kompilatorem zdobytych od marca 1996 roku.