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

• klasy problemow: wymagania sprzetowe, sychnr prologu z otoczeniem, prolog a rt
• runtime? linux/prolog

• Wybór kompilatora prologa (SWI, GNU), analiza jakości działania obu kompilatorów - pod względem zużycia zasobów systemu, stabilności oraz możliwych mechanizmów komunikacji z innymi składnikami systemu.
• Sposób integracji z systemem - np. jako moduł jądra - wysoka wydajność i uproszczona komunikacja między składnikami systemu, duża podatność na awarie, niska portowalność na inne architektury; w przestrzeni użytkownika - większa stabilność kosztem potencjalnie bardziej złożonej komunikacji i mniejszej wydajności, konieczność opracowania rozbudowanej warstwy komunikacyjnej umożliwiającej integrację z systemem
• Analiza alternatywnych środowisk uruchomieniowych - porównanie dostępnych platform bazujących na systemie GNU/Linux z innymi dostępnymi, jak np. NetBSD; należy zwrócić uwagę na wymagania sprzętowe, trudności związane z konfiguracją systemu oraz odtwarzaniem tej konfiguracji w nowych warunkach a także jakość dokumentacji i perspektywy rozwoju danej implementacji. Licencje i dostępność.
• Rozważenie wykorzystania istniejącego już oprogramowania (D-Bus, PolicyKit, HAL) do realizacji zadań związanych z dostępem do sterowników oraz zarządzaniem zdarzeniami. Ewentualnie wykorzystanie pewnych wzorców dostępnych w wymienionych implementacjach.
• Na podstawie powyższych punktów, określenie minimalnych wymagań sprzętowych umożliwiających działanie w czasie rzeczywistym.

• wymagania prologu → SWI/Yap praca na czymś innym niż ix86? ARM?
• minimalne środowisko gnu/linux, ew. netbsd? → spec
• emulacja arm, test dystrybucji linux/netbsd arm-owej na QEmu
• uwaga! pytanie co daje cxprolog i jaki ma footprint, porównując do powyższych?

• opis krosskomp
• inst linux/bsd arm na wirtualizatorze
• testy wydajności prologu http://www.ncc.up.pt/~vsc/Yap/documentation.html#SEC83
• może warto brać pod uwagę jako platformy
  • OpenMoko.org OpenMoko.com
  • Maemo

• spis środowisk + ew. ewalucja: OpenMoko, Android → argumenty
• ew. zasadzki w kompilacji prologu na w.w

• Próba utworzenia wirtualnego środowiska uruchomieniowego emulującego system oparty o procesor z rodziny ARM.

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.

• Analiza wymagań implementacji Prologa:

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.

• Próba cross-kompilacji Prologa na architekturę ARM:

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:

• Przygotowanie środowiska. Należy pobrać archiwa zawierające pakiety binutils, newlib oraz gcc i umieścić w odpowiednio dobranej strukturze katalogów.

1. cd [binutils-build]
2. [binutils-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
3. make all install
4. export PATH=„$PATH:[toolchain-prefix]/bin”
5. cd [gcc-build]
6. [gcc-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib –enable-languages=„c,c" --with-newlib --with-headers=[newlib-source]/newlib/libc/include - make all-gcc install-gcc - cd [newlib-build] - [newlib-source]/configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib - make all install - cd [gcc-build] - make all install - cd [gdb-build] - [gdb-source]/configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib - make all install * Jeżeli ma się odbyć pełny proces kompilacji, to należy również wyposażyć się w pliki nagłówkowe oraz wymagane biblioteki z przyszłego środowiska uruchomieniowego. * Kompilacja oprogramowania odbywa się zgodnie z np. następującymi regułami: - rozpakowanie archiwum, wejście do katalogu, w którym odbywa się kompilacja - [sciezka_do_zrodel]/configure --target=arm-elf --host=i386-unknown-freebsd CC=[toolchain-prefix]/bin/arm-elf-gcc CPP=[toolchain-prefix]/bin/arm-elf-cpp RANLIB=[toolchain-prefix]/bin/arm-elf-ranlib CPPFLAGS="-I[sciezka_do_naglowkow]" LDFLAGS="-L[sciezka_do_bibliotek] --prefix=[prefiks] - użycie CPPFLAGS i LDFLAGS jest w pewnych warunkach opcjonalne * YAP przechodzi taki proces pomyślnie do momentu linkowania. Niestety, ze względu na ciągłe trudności ze znalezieniem właściwego środowiska, brak odpowiednich bibliotek umożliwiających końcowe zbudowanie pakietu. * W przypadku SWI problemem jest brak odpowiednich plików nagłówkowych - należy to rozwiązać tak samo jak problem powyższy. * Udało się znaleźć ciekawe wydanie systemu linuks uruchamialne na wirtualizatorze qemu: 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. * Platforma Neo1973 wymagana do uruchomienia dystrybucji OpenMoko nie jest oficjalnie wspierana przez Qemu. Wsparcie dla tej architektury jest aktualnie przedmiotem aktywnego rozwoju - instnieje możliwość wyposażenia Qemu w taką funkcjonalność, ale nie jest to rozwiązanie w pełni stabilne i przewidywalne. ===== 08.04.15 ===== Platformy warte rozważenia w dalszej części projektu, to: Android, OpenMoko (Neo1973) oraz płyta ewaluacyjna Versatile PB. === Android === == Zalety == * Stabilny rozwój architektury. * Dobry zestaw narzędzi pozwalających na tworzenie oprogramowania. * Dobrej jakości dokumentacja. == Wady == * Ograniczenia licencyjne (Google zastrzega sobie pewne zasadnicze [[http://en.wikipedia.org/wiki/Android_%28mobile_phone_platform%29 prawa]] co do projektu) * Częściowo zamknięty kod * Ograniczenie dostępności pewnych funkcji hardware'u dla oprogramowania. * Duży koszt ew. urządzenia. === OpenMoko === == Zalety == * Całkowita otwartość kodu. * Jasna koncepcja rozwoju. * Dostępność wirtualizatora (w najbliższej przyszłości, p. wyżej) == Wady == * Aktualnie brak dobrego środowiska do emulacji platformy. * Duży koszt ew. urządzenia. === Versatile PB === http://www.arm.com/products/DevTools/VPB926EJ-S.html == Zalety == * Jest to architektura o względnie uniwersalnym charakterze. * Obecna od dłuższego czasu na rynku - dobra dostępność oprogramowania. * Możliwość rozbudowy o dodatkowe komponenty. == Wady == * Przeciętnej jakości dokumentacja. ==== Próba instalacji systemu GNU/Linux (Debian) na wirtalizatorze ==== Emulowana platforma to płyta ewaluacyjna Versatile PB. Instalacja odbyła się zgodnie z intrukcjami podanymi na stronie: http://www.aurel32.net/info/debian_arm_qemu.php. Jedyna modyfikacja polegała na dodaniu flagi „clock=pit” do parametrów jądra. Po instalacji systemu oraz pakietów make, gcc, g, g77 oraz libc6 odbyła się próba kompilacji i uruchomienia kompilatora Yap (wersja 5.1.2). Próba ta zakończyła się sukcesem. Jedyną niezbędną modyfikacją, było usunięcie flag odpowiadających za obsługę wyjątków zmiennoprzecinkowych z pliku config.h. Skrypt konfiguracyjny prawdopodobnie niewłaściwie rozpoznał dostępną w systemie implementację wyjątków.

Próba kompilacji kompilatora SWI niestety nie powiodła się. Proces kompilacji w tym wypadku konsumował olbrzymie ilości zasobów i z powodu długiego czasu trwania został przerwany.

:pl:miw:gjn-mixdes2006-final.pdf