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
7. make all-gcc install-gcc
8. cd [newlib-build]
9. [newlib-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
10. make all install
11. cd [gcc-build]
12. make all install
13. cd [gdb-build]
14. [gdb-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
15. 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:

1. rozpakowanie archiwum, wejście do katalogu, w którym odbywa się kompilacja
2. [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]
3. 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.

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