Projekt zakończony
Konrad Rybacki, konrad.rybacki@wp.pl
Embedded Prolog Runtime (EPR) – Running Prolog on Embedded Platforms, programming Prolog-C Interfaces, evaluation, refinment, testing, improvement; C and Prolog Programming is required
Wykorzystano: Pakiet QEMU, wersja 0.9.1_2, system uruchomieniowy (host) FreeBSD 7.0, procesor klasy i686. Uruchomienie dystrybucji ARM systemu NetBSD nie powiodło się. Emulator albo zupełnie odmawia współpracy, nie rozpoznając właściwie obrazu jądra, albo sygnalizuje błędy w uruchamianym kodzie. Należy dokładnie sprawdzić wsparcie dla architektury opartej o ARM w tym systemie w konfrontacji z możliwościami QEMU. Niestety, brak jest dokumentacji opisującej bezpośrednio przykłady uruchomienia NetBSD na tym symulatorze.
Próba uruchomienia systemu Linux na wspomnianym emulatorze, zgodnie z opisem http://www.aurel32.net/info/debian_arm_qemu.php zakończyła się połowicznym sukcesem. System wprawdzie uruchamia się, ale przy próbie zapisu na dysk dochodzi do błędu segmentacji. Najprawdopodobniej jest to spowodowane jakimiś zależnościami FreeBSD - QEMU. Niestety, nie miałem możliwości przetestowania QEMU na innym systemie - do zrobienia w najbliższym czasie.
W związku z wymienionymi wcześniej problemami, trudno podejmować próby oceny wymagań dostępnych środowisk. SWI Prolog posiada wygodną w użyciu bibliotekę, pozwalającą w pewnym stopniu analizować zużycie zasobów http://gollem.science.uva.nl/SWI-Prolog/Manual/profile.html. Niestety, nie udało mi się znaleźć odpowiednika dla YAP, bez czego właściwie trudno o wykonanie sensownych porównań. Do wykorzystania zestaw testów sprawdzających wydajność Prologa: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/prolog/code/bench/0.html. Interesująca może być również strona: http://www.david-reitter.com/compling/prolog/compare.html.
W ramach próby wykorzystałem toolchain arm-elf-linux. Niestety, kompilator sygnalizuje błędy w kodzie (zarówno w przypadku YAP jak i SWI) - może być to spowodowane niezgodnością wersji. Należy przetestować inne dostępne wersje oraz, po rozwiązaniu problemów zasygnalizowanych powyżej (QEMU), sprawdzić, czy możliwa będzie kompilacja w natywnym środowisku.
Kompilacja CxProlog nie powiodła się zarówno przy środowisku docelowym arm-linux jak i FreeBSD. Brak skryptów umożliwiających konfigurację budowy tego oprogramowania prawdopodobnie poważnie utrudni możliwość jego uruchomienia w systemie innym niż GNU/Linux.
Kross-kompilacja:
http://free-electrons.com/community/demos/qemu-arm-directfb Samo wydanie nie odpowiada dokładnie oczekiwaniom ale zawiera zestaw skryptów oraz opis pozwalający na budowę własnej dystrybucji - co wobec problemów ze znalezieniem jakiejkolwiej innej, działającej, może być dobrym rozwiązaniem.
Platformy warte rozważenia w dalszej części projektu, to: Android, OpenMoko (Neo1973) oraz płyta ewaluacyjna Versatile PB.
Brak wsparcia ze strony dostępnych wirtualizatorów.
Wsparcie dla środowiska Linuksa: http://www.vollmann.ch/en/colibri/info.html, http://wiki.toradex.com/index.php?title=Linux. Niestety są to rozwiązania komercyjne.
http://rybacki.rootnode.net/debian.pdf
http://wiki.debian.org/Embedded_Debian
Jako platformy uruchomieniowej wydałoby się zasadne użycie systemu GNU/Linux wyposażonego w pakiety: D-Bus, PolicyKit oraz Hal. Pakiety te umożliwiają realizację zagadnień takich jak: komunikacja międzyprocesowa, zarządzanie uprawnieniami oraz interakcja z warstwą sprzętową. Dzięki wysokiemu poziomowi abstrakcji oraz łatwej konfigurowalności mogłby by stanowić wystarczające środowisko - teoretycznie, możliwe do przeniesienia na inne platformy.
Środowisko to pozwala na imitację częściowo natywnej kompilacji oprogramowania oraz kompilację skrośną. Wykorzystywany jest emulator QEMU dla architektury ARMEL.
SDK maemo pozwala na stworzenie środowiska uruchomieniowego na bazie architektury x86 opartej o system GNU/Linux. Nie jest to emulacja, lecz kompilacja i użycie natywnego dla tej architektury kodu ale z użyciem elemetów dostępnych tylko dla maemo:
http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html#development
Takie rozwiązanie znacznie zwiększa wygodę testowania i obsługi aplikacji, jednocześnie nie ograniczając możliwości uruchomienia w środowisku emulatora (QEMU).
Ostatecznie, do dalszych prac, zostały uwzględnione trzy różne rozwiązania sprzętowe oparte o procesor architektury arm/armel. Dwa z nich to klasyczne urządzenia typu smartphone/pda, natomiast w przypadku trzecim jest to płyta ewaluacyjna o szerokim zakresie zastosowań. Właściwości tych urządzeń zostaną rozpatrzone w poniższych punktach:
Jest to telefon pracujący w standardzie GSM , wyposażony w zestaw funkcji pozwalających zaliczyć go do klasy urządzeń smartphone. W finalnej wersji (aktualnie jest to sprzęt będący obiektem ciągłego rozwoju) mają się znaleźć:
Oprogramowanie na tę architekturę powstaje w środowisku OpenMoko, które zostanie opisane w dalszych akapitach.
Platforma ta może być emulowana przez wirtualizator QEMU, jednak wsparcie dla niej jest ciągle w fazie rozwoju (konieczności modyfikacji źródeł QEMU na podstawie odpowiedniego repozytorium).
Jest to seria urządzeń o funkcjonalności zbliżonej do klasycznych rozwiązań typu PDA (wbrew błędnie powielanym opiniom, urządzenia te nie posiadają funkcji telefonu). Najnowszym modelem z tej serii jest N810:
Platforma rozwojowa - maemo.
Architektura ta jest wspierana (częściowo) przez wirtualizator QEMU.
Platforma ta, spośród wybranych, zawiera najszerszy zestaw komponentów - jest to rozwiązanie przeznaczone do w pełni profesjonalnych zastosowań. Istnieje wiele odmian tego urządzenia; jako przykład może zostać przedstawiona płyta:
Platforma wspierana przez wirtualizator QEMU.
Jest to projekt w stu procentach społecznościowy, a zatem i otwarty/niezależny (GPL). Dystrybucja ta powstaje w oparciu o platformę http://oe.linuxtogo.org/.
Struktura zawartego oprogramowania została przedstawiona na poniższym schemacie:
Środowisko to powstało w oparciu o dystrybucję linuksa Debian. Ciekawą własnością SDK należącego do tego środowiska jest możliwość stworzenia platformy uruchomieniowej na bazie architektury x86 z wykorzystaniem kompilacji skrośnej oraz częsciowej tylko emulacji (QEMU). To rozwiązanie jest możliwe dzięki zastosowaniu pakietu http://www.scratchbox.org/:
http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html#development
Struktura oprogramowania została przedstawiona poniżej:
Środowisko bazuje na klasycznych rozwiązaniach: warto tu szczególną uwagę zwrócić na wykorzystanie takich pakietów, jak D-Bus oraz HAL (szczególnie interesujące w kontekście sterowania/obsługi zdarzeń). Szczególnie cenna może być również wirtualizacja systemu plików (GnomeVFS), umożliwiająca wykorzystanie wielu dostępnych źródeł danych; narzędzia do obsługi XML; G-Conf (globalne zarządzanie danymi konfiguracyjnymi).
Nie jest to właściwie pełne środowisko jak w przypadkach wyżej opisanych a raczej wydanie samego systemu możliwe do uruchomienia na wybranych paltformach sprzętowych. Szczególnym przypadkiem zastosowania tej dystrybucji, może być wspominana wcześniej płyta ewaluacyjna Versatile PB.
Z faktem, iż nie jest to w pełni funkcjonalne środowisko wiąże się konieczność samodzielnego wyposażenia go w odpowiednie oprogramowanie. Problem ten częściowo da się rozwiązać przez wykorzystanie dostępnych wraz z dystrybucją pakietów i/lub kompilacji skrośnej/w środowisku wirtualizatora. Sytuacja taka daje jednak niewątpliwą korzyść w postaci możliwości niemal dowolnej ingerencji w ostateczny kształt rozwiązania.
Przykład uruchomienia tej dystrybucji na wirtualizatorze, został przedstawiony tutaj: http://www.aurel32.net/info/debian_arm_qemu.php.
Kwestię przenaszalności, w rozważanym tutaj przypadku, można sprowadzić do problemu, czy na danej architekturze da się uruchomić system GNU/Linux. Ewentualne ograniczenia mogą wynikać z wyboru dodatkowego oprogramowania. Zastosowanie popularnych rozwiązań, wymienionych wcześniej (HAL, D-Bus, GnomeVFS, PolicyKit, itd.) daje możliwość oddzielenia warstwy sprzętowej/systemowej od samego środowiska uruchomieniowego prologu. W praktyce oznacza to, że np. migracja między wymienionymi tu platformami będzie ograniczała się najwyżej do instalacji i/lub odpowiedniej konfiguracji wymaganego oprogramowania.
Kompilację przeprowadzono w środowisku: http://www.aurel32.net/info/debian_arm_qemu.php uruchomionym na wirtualizatorze QEMU. Komputer, na którym uruchomiono wirtualizator wyposażony był w procesor Core 2 Duo T5500, 2GB pamięci RAM, system operacyjny FreeBSD. Kompilacja Yap zajęła w sumie ok. 40 min. W przypadku SWI, proces ten przeciągnął się nieomal do 3 godzin.
Po uruchomieniu (zajmowanej pamięci rzeczywistej): 2968kB.
Po uruchomieniu (zajmowanej pamięci rzeczywistej): 3328kB.
Nie udało się dokładnie zbadać zapotrzebowania na czas procesora w przypadku wymienionych kompilatorów, jednak, zauważono, w środowisku wirtualizatora wyraźnie mniejszą responsywność kompilatora SWI.
Do sprawdzenia:
