WY SZA SZKO A INFORMATYKI STOSOWANEJ I ZARZ DZANIA

Transkrypt

1 WY SZA SZKO A INFORMATYKI STOSOWANEJ I ZARZ DZANIA Marcin Czopik nr. albumu 8806 Piotr Rzeszotarski nr. albumu 9930 gr. ID06SK1 Projekt z Programowania Niskopoziomowego Prosta maszyna wirtualna JVM pracuj ca na STRC51 wyk adowca : mgr in. Aleksander Pruszkowski

2 Maszyna wirtualna 1 (ang. virtual machine, VM) to ogólna nazwa dla programów tworz cych rodowisko uruchomieniowe dla innych programów. Maszyna wirtualna kontroluje wszystkie odwo ania uruchamianego programu bezpo rednio do sprz tu lub systemu operacyjnego i zapewnia ich obs ug. Dzi ki temu program uruchomiony na maszynie wirtualnej "my li", e dzia a na rzeczywistym sprz cie, podczas gdy w istocie pracuje na sprz cie wirtualnym, "udawanym" przez odpowiednie oprogramowanie (maszyn wirtualn ). Wykonywanym programem mo e by zarówno pojedyncza aplikacja jak i ca y system operacyjny lub nawet kolejna maszyna wirtualna. S one zupe nie odizolowane przez maszyn wirtualn od maszyny fizycznej, w odró nieniu od klasycznego systemu operacyjnego, który tylko zarz dza uruchamianiem aplikacji na maszynie fizycznej. Maszyny wirtualne to m.in.: interpretery, szczególnie interpretery kodu bajtowego kompilatory JIT emulatory rzeczywi cie istniej cego sprz tu, np. emulatory konsol Ró nice mi dzy poszczególnymi typami takich maszyn s p ynne. Na przyk ad wirtualna maszyna Javy jest powszechnie znana jako samodzielny interpreter, ale poniewa istnia y komputery, które potrafi y wykonywa programy w kodzie bajtowym Javy bezpo rednio, mo na j tak e traktowa jako emulator tych maszyn. Maszyny wirtualne pozwalaj uruchamia programy napisane dla innych architektur bez adnych zmian lub tylko z niewielkimi modyfikacjami (parawirtualizacja). Daje to du niezale no od fizycznego sprz tu, cho kosztem dodatkowej warstwy abstrakcji, która wi e si z pewnymi niedogodno ciami: oprogramowanie wirtualizuj ce samo wymaga cz ci czasu procesora i pami ci operacyjnej, zwi ksza tak e stopie komplikacji uk adu, a wi c i ryzyko b du. Poniewa jednak wydajno wspó czesnych komputerów ci gle ro nie, a osobne warstwy u atwiaj znajdowanie b dów, coraz cz ciej jest to cena, jak warto zap aci za dodatkowe mo liwo ci. Podobne motywy sta y za odej ciem w informatyce od asemblera w stron j zyków wysokiego poziomu (C, programowania obiektowego). Maszyny wirtualne s u ywane do ró nych celów: do uruchamiania istniej cych aplikacji i systemów operacyjnych w innych rodowiskach ni pierwotne dla zapewnienia uniwersalnego rodowiska uruchomieniowego do bezpiecznego rozdzielania zasobów du ych maszyn (mainframe, superkomputery) do uruchamiania jednocze nie ró nych systemów operacyjnych na jednym komputerze do uruchamiania na jednym komputerze programowych klastrów do uzyskania pe nej kontroli nad systemem operacyjnym, np. podczas analizowania jego pracy do optymalizacji pracy programów, poprzez kontrol ich rodowiska dzia ania i procesu translacji kodu Poszczególne korzy ci mog wyst powa cznie, na przyk ad uruchamianie wielu wirtualnych maszyn na du ym komputerze odbywa si pod cis kontrol stanu ich dzia ania. Wirtualna maszyna Javy (ang. Java Virtual Machine, w skrócie JVM) to zale ny od platformy system uruchomieniowy dla programów. Standardowo s u y programom napisanym w j zyku Java, ale mo na go u ywa tak e jako rodowisko uruchomieniowe tak e dla innych j zyków, np. Jython to implementacja Pythona w a nie na JVM. Programy napisane w tym j zyku s niezale ne od platformy dzi ki temu, e uruchamiane s 1http://pl.wikipedia.org/wiki/Maszyna_wirtualna

3 bezpo rednio w JVM (po konwersji w locie na kod po redni), a nie w rodzimym rodowisku. Mo na je uruchomi na dowolnym komputerze i systemie operacyjnym na które istnieje JVM. Poza tym mo na je uruchamia przez klasyczn kompilacj kodu ród owego do maszynowego, umo liwia to na przyk ad kompilator GCJ z pakietu GCC. Wirtualna maszyna Javy jest dost pna dla wielu platform. Istniej ró ne jej implementacje, zwykle b d ce cz ci ca ego pakietu narz dzi Javy, oraz samodzielne projekty jak na przyk ad Jikes, Kaffe, SableVM czy CACAO, które zazwyczaj dla swojego dzia ania korzystaj z zestawu standardowych bibliotek Javy GNU Classpath. Starsze wersje maszyn wirtualnych mia y problemy z wydajno ci. Dzia o si tak, poniewa maszyny by y interpreterami kodu po redniego j zyka Java. Obecne implementacje maszyn wirtualnych stosuj kompilacj kodu po redniego do kodu maszynowego w trakcie uruchomienia (just-in-time compilation). Dzi ki zastosowaniu tej technologii nowoczesne maszyny wirtualne niewiele ust puj wydajno ci powszechnie u ywanym kompilatorom innych j zyków. Small Device C Compiler (SDCC) 2 jest open source'woym kompilatorem j zyka C dla mikrokontrolerów. Pakiet zawiera równie linker, assembler, symulator (ucsim) oraz debugger. Od marca 2007 roku, SDCC jest jedynym open source'owym kompilatorem j zyka C dla procesorów rodziny Jedyn maszyn wirtualn, która jest w stanie pracowa na procesorze 8051, jak uda o nam si znale jest simple Real-Time-Java ( Jest to ma a wirtualna maszyna Javy specjalnie zaprojektowana, eby dzia a a jako system wbudowany na urz dzeniach wyposa onych w ma ilo pami ci systemowej. W przeciwie stwie do innych implementacji wbudowanych maszyn wirtualnych, maszyna simplertj wymaga od 18 do 24 kb pami ci kodu do dzia ania. Maszyna simplertj mo e dzia a w wi kszo ci 8/16/32 bitowych systemów wbudowanych, które s wyposa one w rozs dn ilo pami ci do przechowywania kodu wirtualnej maszyny, aplikacji Java. Jednak ze wzgl du na to, i jest to podstawowa maszyna, posiada pewne ograniczenia co do kodu, który b dzie na niej wykonywany: 64-bit typy danych (long, double) nie s wspierane. Brak wsparcia dla obiektu java.lang.class. Odwo ania sumboliczne wymagane przez obiekt klasy zostn usuni te podczas fazy linkowania aplikacji Java. Nie wszyskie standardy pakietów s wbudowane. Jako, e simplertj b dzie zazwyczaj uruchamiany na systemach wbudowanych z do ograniczon ilo ci zasobów, zawarte s tylko posttawowe pakiety/klasy. W razie potrzeby mo na doda dodatkowe pakiety. JNI nie jest wspierane, z powodu du ej z o ono ci. SimpleRTJ mo e by idealn platform do wykonywania aplikacji posiadaj cych interfejsy pozwalaj ce na interakcj z cz owiekiem. Przyk adami urz dze, do których mo e zosta wykorzystana s : systemy wbudowane, elektroniczne zabawki, robotyka oraz inne urz dzenia elektroniki konsumenckiej. Istotn rzecz jest, i simplertj nie wymaga do pracy adnego wsparcia od dzia aj cego pod sob np. RTOSa. Kod simplertj podzielony jest na wiele plików, co uniemo liwia bezpo redni kompilacj ca o ci za pomoc SDCC. Jedynym sposobem by aby kompilacja ka dego pliku osobno jako 'object' a nast pnie zlinkowanie ich w ca o. Jednak podczas kompilacji wyst puj b dy dotycz ce 2http://en.wikipedia.org/wiki/Small_Device_C_Compiler

4 rzutowania typów (kompilator ma problem z odró nieniem int od int*). Te same pliki skompilowane za pomoc GCC kompiluj si bez problemu. Mo na by oby oczywi cie wprowadzi modyfikacje w kodzie, jednak by oby ich bardzo du o. Odwo uj c si jednak do dokumentacji simplertj, polecanym kompilatorem jest Tasking 3. Warto w tym momencie zauwa y, e kod dla procesora 8-bitowego (jakim jest 8051) wa y najwi cej. Processor Compiler Code RO data RW data 68HC11 IAR 17K 1K 0.1K H8/300 GNU GCC 19K 2K 0.2K i186 Borland K 2K 0.2K i386 Borland K 2K 0.2K 68K GNU GCC 18K 2K 0.2K 8051 Tasking 35K 1K 0.1K M.CORE GNU GCC 15K 2K 0.2K AT91R40008 (thumb mode) ARM Devel. Suite 12K 2K 0.2K 68HC16 Cosmic 17K 2K 0.2K Niestety, Tasking jest programem komercyjnym i dost pna jest tylko wersja trial, która posiada pewne ograniczenia, równie dotycz ce rozmiaru kodu. Sam simplertj te jest projektem komercyjnym, jednak do celów edukacyjnych i prywatnych dost pna jest wersja ewaluacyjna. Kompilacja tego projektu wymaga zmiany modelu pami ci na 'large'. Jednak z powodu wspomnianych wcze niej ogranicze wersji demonstracyjnej kompilatora, projekt jako ca o nie móg zosta skompilowany. Compiling j_bcode.c cc51 F199: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_bcode.c: line 480: demonstration package limits exceeded wmk: *** action exited with value 2. wmk: j_bcode.src removed. Compiling j_float.c Assembling j_float.src Compiling j_gc.c Assembling j_gc.src asm51 E091: j_gc.src: line 2337: demonstration package limits exceeded wmk: *** action exited with value 1. 3http://

5 Compiling j_lang.c cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 110: function "System_arraycopy": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 123: function "System_freeMemory": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 137: function "System_totalMemory": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 154: function "System_gc": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 154: function "System_gc": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 168: function "System_currentTimeMillis": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 183: function "System_getPropertyLen": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 197: function "System_getProperty0": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 210: function "java_lang_thread_start": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 227: function "java_lang_thread_stop": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 254: function "java_lang_thread_suspend": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 280: function "java_lang_thread_resume": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 296: function "java_lang_thread_yield": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 296: function "java_lang_thread_yield": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 334: function "java_lang_thread_sleep0": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 348: function "java_lang_thread_currentthread": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 363: function "java_lang_throwable_fillinstacktrace": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 363: function "java_lang_throwable_fillinstacktrace": parameter "par" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 401: function "java_lang_throwable_getstacktrace": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 450: function "java_lang_thread_interrupt0": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 473: function "java_lang_thread_setdaemon0": parameter "rv" not used cc51 W068: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 508: function "java_lang_object_wait0": parameter "rv" not used cc51 F199: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_lang.c: line 546: demonstration package limits exceeded wmk: *** action exited with value 2.

6 wmk: j_lang.src removed. Compiling j_mem.c Assembling j_mem.src Compiling j_thread.c cc51 F199: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_thread.c: line 477: demonstration package limits exceeded wmk: *** action exited with value 2. wmk: j_thread.src removed. Compiling j_vars.c Assembling j_vars.src Compiling j_vm.c cc51 F199: c:\documents and settings\cin\pulpit\simplertj-1.4.2\vm-b64k\j_vm.c: line 406: demonstration package limits exceeded wmk: *** action exited with value 2. wmk: j_vm.src removed. W g ównym pliku projektu j_vm.c w 1320 lini kodu: if (f!= NULL) NULL trzeba by o zmodyfikowa na 0, gdy kompilator zapewne inaczej interpretowa NULL. Inne modyfikacje jakie zosta y wprowadzone, to zmiany w pliku javavm.h: #define ENABLE_PRAGMA_PACK true zosta o zmienione na: #define ENABLE_PRAGMA_PACK false oraz: #define _PACKED_ packed zosta o usuni te 'packed'. #define LSB_FIRST false /* set to true for little endian ordering */ zosta o zmienione na true 4 Pragma pack jest to dyrektywa dla kompilatora, która w tym przypadku nie mog a zosta obs u ona, dlatego trzeba by a ustawi warto na false. W przypadku pozostawienia warto ci na true, kompilator ignoruje nieznany pragma pack. 4http://

7 Projektowanie aplikacji java dla systemów wbudowanych mo e by podzielone na kilka kroków: 1. Analiza wymaga Programista musi zadecydowa które cze moga by zaimplementowane w javie, a które trzeba zaprogramowa przy u yciu kodu natywnego. 2. Pisane aplikacji Java Jedynymi ograniczeniami dla programisty s ilo wbudowanej pami ci oraz ograniecznia maszyny przedstawione wcze niej. Przechowalnia mieci jest mo liwa, lecz przechowywanie zbyt du ej ilo ci obiektów mo e powodowa b dy braku pami ci. Jednym z bardzo u ytecznych pakietów dystrybuowanych z simplertj jest javax.events, klasa zdarze pozwalaj ca na obs ug klawiszy, zmian portów, com ow w aplikacjach javy. 3. Optymalizacja procesów klas javy Po zako czeniu pisania aplikacji, kompilator musi przebrn przez proces optymalizacji. Optymalizacja (linkowanie plików klas) jest robione przy pomocy programu ClassLinker (dost pny w pakiecie simplertj). Proces czyta wszystkie klasy zawieraj ce aplikacje, zamieniaj c dowi zania symboliczne na indeksy i generuje plik wyj ciowy. Proces ten upraszcza dzia anie VM i znacznie skraca czas wykonania kodu. 4. Testowanie aplikacji

8 Wnioski ko cowe: Najlepszym j zykiem do pisania aplikacji na 8051 jest Assembler, ewentualnie C. Wszystkie opinie z jakimi si zetkn li my w sieci, jasno mówi y e wykorzystanie Javy, jak i wirtualnych maszyn na tych kontrolerach nie ma wi kszego sensu i mija si z celem, a przede wszystkim z szybko ci dzia ania 5. Najlepszym kontrolerem (stworzonym z my l o wirtualnych maszynach) jest TINI, wyposa ony w odpowiedni ilo zasobów, oraz posiadaj cy juz zintegrowan JVM. Jest on równie kompatybilny wstecz z 8051 ( Napisanie JVM na 8051, które b dzie si kompilowa bez problemu pod SDCC, mo e by doskona ym tematem na prac dyplomow. 5http://forum.mikrokontrolery.net/viewtopic.php?t=149&highlight=java