Archiwum kategorii: atari st

Lua + gemlib.

Wysłany by

Jak się spodziewałem utworzenie własnej biblioteki w C dla Lua jest bardzo proste. Póki co moja „biblioteka” to ambitna funkcja v_pline() z gemlib rysująca polilinię, z dowolnej (ile się zmieści) ilości danych przekazywanych przez stos Lua. Nauczka nr 1: nie używać malloc() z libstd PureC (wywala się), tylko Malloc() z tos.h.

Cała filozofia, to utworzenie modułu np. gemlib.c, w którym będą zdefiniowane funkcje z biblioteki w C, w tym przykładzie jest aż jedna: vpline() o definicji jak niżej:

static int vpline(lua_State *L) {
/* narysuj polilinię */
}

potem:


static const luaL_Reg gemlib[] = {
{"v_pline", vpline},
{NULL, NULL}};

LUAMOD_API int luaopen_gemlib (lua_State *L) {
luaL_newlib(L, gemlib);
return 1;
}

i dodanie: LUAMOD_API int (luaopen_gemlib) (lua_State *L); np do lualib.h oraz
{„gem”, luaopen_gemlib} do loadedlibs[] w linit.c, żeby interpreter go zarejestrował, bo moduł jest statycznie linkowany więc nie trzeba go ładować.

Wybiorę co najciekawsze funkcje GEM/VDI/AES i zobaczymy co z tego wyjdzie. Proceduralne tworzenie grafiki ze skryptu Lua może być całkiem zabawne ;).

Mam sporo przemyśleń i wątpliwości czy obsługa GUI z Lua jest do zrobienia, ale w tym cała frajda ;).

Gemlib.

Wysłany by

Szkoda, że tak niewiele dobrej dokumentacji się zachowało (albo ja nie wiem gdzie szukać). Znalazłem GEM’s Programmers Reference z Abacus Software i Professional GEM, i tu jest sporo fajnych artykułów. I jeszcze to na początek i ten wątek na Atari Forum jest bardzo ciekawy. Ok, znalazłem jeszcze to. Chyba wystarczy ;).gemlib
No i API Gemlib jest chyba dość spójne, bo dla prostych przykładów można bez problemów linkować z GEM.LIB (w wersji 0.43.6) zamiast PCGEMLIB.LIB z PURE C.

gemlib_st

Zaczynam powoli zmieniać zdanie na temat ST…

Lua-5.3.0 dla Atari ST (PureC).

Wysłany by

No i wyszła wersja Lua-5.3.0. Binarka dla Atari ST tutaj. A gdyby ktoś chciał poeksperymentować wrzucam mój kompletny katalog PURE_C, wraz ze katalogiem lua530 i paroma koniecznymi nagłówkami. A w katalogu src znajduje się plik projektu lua.prj (i lamerski patch ze zmianami względem oryginalnych źródeł, już zaaplikowany). purec_lua530Jak widać powyżej, działa w Aranym. Aby skompilować, ładujemy plik lua.prj w menu Project -> Select, a potem Project -> Make all. W pliku lua.prj trzeba ustawić właściwy katalog w którym utworzona zostanie binarka (u mnie g:\build\lua\lua53.prg). lua530

Lua-5.3.0-rc4 dla Atari ST.

Wysłany by

No i udało się skompilować w PureC 😉 Binarka, gdyby ktoś chciał się pobawić (148KB), tutaj.

lua530rc4

Lua530rc4 jest nawet trochę szybsze od 503 z 2006 roku.

iterator_closure_generator5Interpreter zdaje się działać na miarę możliwości platformy, powyżej ST spotyka iteratory, generatory i domknięcia 😉

f2c

Dla większych serii danych i dużych ilości obliczeń w Lua 5.3.0 różnica GCC vs PureC nie jest już tak duża: jeśli policzymy 30 elementów nieszczęsnego Fibonacciego, 30 razy w pętli, to czas wykonania dla binarki skompilowanej GCC wynosi: 1591x5ms=7,955s a dla PureC 1495x5ms=7,475s. Różnica 6.7%. W 5.2.3 2186x5ms=10,930s. 46% vs 6.7% robi różnicę ;). Dla małych skryptów różnica oczywiście da się we znaki, a 3x większy rozmiar binarki na wolniejszych dyskach da sporą różnicę czasu wykonania.

Niewiarygodne jest to, że da się taki projekt w 2015 skompilować w PureC, który ma 22 lata :]

I jeszcze jeden przykład, tym razem OOP w Lua:

OO_luaJasne, proste i przejrzyste, a możliwości implementacji OOP „po swojemu” ogromne (brak narzuconego modelu obiektowego).

Gulam, yet another shell for TOS.

Wysłany by

Z jakiegoś powodu zakodowałem sobie, że binarki kompilowane pod Freemint/Aranym są linkowane z libmint i nie będzie się ich dało uruchomić pod TOS-em, a tak nie jest. Moje eksperymenta generowane przez GCC i PureC działają prawidłowo w „gołym” TOS-ie. Poniżej zdjęcie ekranu z Gulam shell w Mist (STEroids):

Zauważyłem też sporą różnicę czasu wykonania w zależności od „nośnika” na którym znajduje się uruchamiany program. Uruchomienie z dysku GEMDOS w Hatari jest znacznie szybsze od obrazu dysku z driverem AHDI:gulam1Po cichu liczę na to, że po przepisaniu DMA w Mist przez Till’a i przy bezpośrednim dostępie do FAT, będzie tak samo szybko.

Magic.

Wysłany by

I jeszcze jedna ciekawostka od twórców PureC: MagiC.
magicNiestety nie działa w MIST i nie wiadomo czy zadziała, bo developer jest tylko jeden i ma jasno określone priorytety, co jest całkowicie zrozumiałe.

Aktualizacja: Już działa w MIST :).

Lua dla Freemint.

Wysłany by

luaLua jest szybki, mały, dynamicznie typowany i wypasiony. Jest konsola interaktywna, można skompilować skrypt do bytecodu, są „list comprehensions” i sporo tego, co lubię z Pythona… Co ważniejsze: jak widać powyżej, jest szybko. Powiedziałbym nawet że bardzo szybko. Binarka Lua-5.2.3 dla Atari ST (skompilowana GCC-4.6.4) dla zainteresowanych tutaj. Tym razem niestety na Mist w trybie STEroids jest wolniej niż w Hatari (68020). A co dziwniejsze: w ST Mint uruchomienie bytecodu jest wolniejsze od interpretowanego pliku .lua (w Hatari też), a we Freemint w Aranym jest 2x szybsze (czego należałoby się spodziewać). Zwariować można. Nie zmienia to faktu, że Lua jest najszybszym językiem tego rodzaju, z jakim miałem do czynienia.

Update: Poniżej zrzut ekranu z Lua-5.0.2 (link do webarchives) skompilowanego PureC w 2006 przez Thorstena Butschke:
lua_purecJak widać Lua jest sporo szybszy. Może po prostu GCC kiepsko optymalizuje kod, chociaż nie chce mi się w to wierzyć. Z drugiej strony wersja 5.0.2 skompilowana GCC-4.6 działa tak samo szybko jak 5.2.3 i nie daje mi spokoju, że 16-bitowy retro-kompilator daje szybszy kod… Może to kwestia manipulacji 32-bitowymi typami danych w GCC, a może narzut starej wersji Mintlib/stdlib w ST Mint i/lub libgcc, ciężko stwierdzić. Binarka Lua-5.2.3 skompilowana GCC jest w każdym razie w pełni funkcjonalna, a kompilacja w PureC to taki mój eksperyment. Swoją drogą to bardzo fajny kompilator i IDE. Tutaj jest paczka z plikami projektu Lua-5.0.2 dla PureC, więc warto  powalczyć ;).

Update: Udało mi się w PureC 1.1 skompilować Lua-5.0.3:purec_lua503Binarka (wrzucam tutaj) działa w STMint znacznie szybciej niż kompilacje gcc.
lua503W Vbcc Lua-5.2.3 się kompiluje, ale działa nieprawidłowo (złe parsowanie plików i obsługa konsoli interaktywnej, pewnie dałoby się ogarnąć). AHCC odpada na starcie. Niby aktywnie rozwijany (ostatnia wersja z września 2014), ale nie radzi sobie już na etapie dołączania plików nagłówkowych, a komunikaty są mało pomocne w znalezieniu rozwiązania. Próbuje skompilować wersję 5.2.3 w PureC (2 moduły się jeszcze nie budują i niestety jeden z nich wymaga modyfikacji lub przepisania skomplikowanego makra). Fajnie byłoby też skompilować Tinypy. Ogólnie dobra okazja, żeby sobie odświeżyć ANSI C.

Tinypy dla FreeMint.

Wysłany by

Jak widać po ostatnich wpisach eksperymentowałem z Pythonem na FreeMint. Binarka dużego Pythona jest dostępna tutaj i działa bardzo ładnie (patrz poprzedni wpis). Szukałem cały czas małego interpretera (z myślą o Mist) i udało mi się skompilować Tinypy:
tinypy

Binarkę tinypy dla FreeMint wrzuciłem tutaj. Muszę ją jeszcze pod Mist-em przetestować ;).

Update: na ST Mint działa:

pystmint Więc na Mist też zadziała (po cichu liczę, że może w trybie STEroids).