Zgromadzenie Actionariuszy by Yosh 2009-02-23 22:19:35
Kolega Paweł "Yosh" Różański może zostać uznany za odkrycie
konkrusu "Napisze se". O ile bowiem reszta autorów, którzy zajęli
czołowe miejsca w konkursie była znana z tego, że działa na rzecz
Atari, to Yosh nie był dotychczas rozpoznawany jako autor
atarowskiego oprogramowania. Ale właśnie o to chodzi w takich
konkursach, żeby ujawniały się kolejne talenty, żebyśmy odkrywali
nowych ludzi, którzy chcą się poświęcić intelektualnej rozrywce,
jaką jest tworzenie programów na nasz 8-bitowy komputerek.
Jego gra Bump mimo słabego opakowania (brak kolorowej grafiki), została doceniona za oryginalność i bardzo wysoki poziom trudności. Zajęła wysokie, 4 miejsce w konkursie "Napisze se" oraz 9 miejsce na najlepszą grę na Atari w ogóle (KazKompo 2008). To naprawdę sukces, biorąc pod uwagę brak doświadczenia w programowaniu naszego Ataraka.
.png)
.png)
Program został napisany w języku "Action!", do którego spróbowania zamiast Basica Yosh zachęcał mnie już na KWAS-ie, który odbył się w tym roku we Wrocławiu. Jeszcze mnie nie namówił, ale jest na dobrej drodze :). Aby wzmóc siłę jego argumentów, poprosiłem go o napisanie elaboratu, w którym czarno na białym wyłożyłby miłośnikom Basica (takim jak ja), dlaczego "Action!" jest dobry, a może nawet lepszy do programowania, jaką daje przewagę, jakie ma zalety i wady. Z czasem może uda się zwiększyć popularność tego (ponoć) dobrego języka programowania i nie będzie tak jak w zeszłym roku, że na ponad 40 gier tylko 3 były napisane w "Action!".
Yosh dał się na tą niewdzięczną pracę namówić i dlatego mogę dziś oficjalnie zaprosić na internetowe Zgromadzenie Actionariuszy czyli osób zainteresowanych programowaniem w "Action!". Dzisiejszy odcinek argumentacji na rzecz tego języka dotyczy arytmetyki. Pojawieniu się kolejnych odcinków sprzyjałoby zainteresowanie tematem ze strony czytelników. Jeżeli więc macie pytania, uwagi, prośby w zakresie tego, co powinno być poruszone w takiej serii o programowaniu w "Action!" - właśnie nadszedł dobry czas, żeby je ujawnić i zmusić Yosha do napisania kolejnych odcinków :).
A teraz oddaję głos Yosh-owi:
Arytmetyka ośmiobitowego Atari
Widząc tak szeroki oddzew na konkurs "Napisze se" postanowiłem zwrócić uwagę na bardzo istotną kwestię, jaką jest model obliczeń wykorzystywany przez dany język programowania. Jako pierwszy zostanie przedstawiony przykład ilustrujący różnice w realizacji operacji arytmetycznych między interpreterem i kompilatorem języka "Turbo Basic XL" (zwany dalej TBXL), a kompilatorem języka "Action!".
Rozpatrzmy następujący program w języku Turbo Basic XL:
Komórka 20 jest zwiększana przez system w czasie przerwania VBL czyli co 1/50 sekundy (w systemie PAL). Powyższy program wykonywał więc będzie się przez około 2 sekundy, a zmienna A zliczy nam liczbę przebiegów pętli w tym czasie. Uruchamiamy poprzez interpreter "Turbo Basic-a XL":
Wynik dość mizerny, około 12 razy na ramkę. Przykład nie wydaje mi się zbyt naiwny - każdy program to przecież obliczenia i przepływ sterowania.... Wytoczymy teraz ciężkie działo, czyli kompilator języka "Turbo Basic XL". Po skompilowaniu i zlinkowaniu ponownie uruchamiamy nasz program:
Ponad 4 razy szybszy, nieźle. Zapiszmy ten sam przykład w języku "Action!":
Wynik? 37551 obrotów pętli... Funkcja PEEK i procedura POKE należą do standardowej biblioteki - przyjaznej dla przesiadających się z Basic-a. "Action!" udostępnia także bezpośredni dostęp do pamięci poprzez przypisania adresów zmiennym, czyli:
Pierwsza linijka "nazywa" bajt pod adresem 20, kod staje się czytelniejszy i szybszy (brak narzutu wywolywania funkcji PEEK). Pętla w tak zapisanym programie wykona się 50778 razy.
Jeżeli kod w języku "TBXL" został skompilowany, to skąd się bierze aż taka różnica? Język "Atari Basic" (i jego młodszy, ulepszony brat "Turbo Basic XL") posiada tylko jeden typ liczb: liczby zmiennoprzecinkowe. Oczywiście 6502 nie wspiera ich natywnie, obliczenia na nich realizowane są przez zniesławiony pakiet FP. Należy mieć na uwadze, że są one używane wszędzie. Dla przykładu, część ludzi lubi mroczny design swojego edytora ekranowego Basic i pierwsze co robią po zapaleniu się READY to zmieniają kolory poprzez:
Jest to naprawdę niski poziom, odwołujemy się bezpośrednio do adresów w pamięci naszego mikrokomputera. "Bezpośrednio", jeżeli nie liczymy między innymi czterech zaokrągleń... a skoro komputer zaokrągla, to ten sam efekt uzyskamy na przykład poprzez:
Czas wykonania jest praktycznie identyczny z racji wykonania tych samych operacji. W instrukcjach POKE i PEEK płacimy także za test poprawności przekazywanej liczby, na przykład POKE 80000, 10 zwróci ładny błąd numer 3 (liczba z poza dozwolonego zakresu). Nie jest to wada Basic-a. Jest to przecież Beginner's All-purpose Symbolic Instruction Code. Jego celem jest przede wszystkim zapoznanie człowieka z maszyną. Pamiętam swoje początki... Pieczołowicie sprawdzałem w podstawówce zadania z matematyki nie mając pojęcia, że bajt to 8 bitów. Dla początkującego z mikrokomputerem Basicowe uproszczenia na pewno były pomocne - liczby rzeczywiste nie tworzyły dodatkowych barier w zapoznaniu się z programowaniem.
Przejdźmy do innych przykładów niż obliczenia. Dźwięk narastający można modelować poprzez:
Co jest o wiele bardziej naturalne, niż sztuczne pętle opóźniające z krokiem co 1. Jednakże gry przez wiele lat powstawały bez liczb zmiennoprzecinkowych (na przykład "Doom" - niewiele szczegółów grafiki i 386DX (nie posiadający kooprocesora) wystarczał...)
Jeżeli nie chcemy inwestować sił w poznanie nowego języka ("Action!"), polecam "Atari Basic":
Oczywiście uruchomiony poprzez standardowy interpreter:
daje wiadomy wynik, niższy niż "Turbo Basic XL". Na szczęście firma Special Sofware Systems stworzyła "MMG Basic Compiler" dla programów w Atari Basic. Potrafi on skompilować kod z zachowaniem liczb zmiennoprzecinkowych i w tym przykładzie daje nam 803 przebiegi pętli - dużo mniej niż kodu wygenerowanego przez kompilator "Turbo Basica XL", ale potrafi także wymusić liczby całkowite. Pętla w tak skompilowanym programie wykona się 6375 razy, ponad dwa razy szybciej niż kod kompilowany TBXL.
Problem liczb zmiennoprzecinkowych próbował także obejść autor "Advan Basic". W tym dialekcie A oznacza zmienną zmiennoprzecinkową, a A% całkowitą. Czas wykonania zbliżony do kompilowanego "Turbo Basica XL". Mam nadzieję, że zachęciłem do eksperymentów z kompilatorami. Jak zawsze, odpowiem na wszystkie pytania (nie żebym znał na wszystkie odpowiedź, ale z przyjemnością poszukam i posprawdzam). Więc, jeżeli ktoś marzy o szybkiej gierce w "Action!" - zapraszam do dyskusji i dociekań.
Jego gra Bump mimo słabego opakowania (brak kolorowej grafiki), została doceniona za oryginalność i bardzo wysoki poziom trudności. Zajęła wysokie, 4 miejsce w konkursie "Napisze se" oraz 9 miejsce na najlepszą grę na Atari w ogóle (KazKompo 2008). To naprawdę sukces, biorąc pod uwagę brak doświadczenia w programowaniu naszego Ataraka.
Bump zajął wysokie miejsca w głosowaniach
graczy
Program został napisany w języku "Action!", do którego spróbowania zamiast Basica Yosh zachęcał mnie już na KWAS-ie, który odbył się w tym roku we Wrocławiu. Jeszcze mnie nie namówił, ale jest na dobrej drodze :). Aby wzmóc siłę jego argumentów, poprosiłem go o napisanie elaboratu, w którym czarno na białym wyłożyłby miłośnikom Basica (takim jak ja), dlaczego "Action!" jest dobry, a może nawet lepszy do programowania, jaką daje przewagę, jakie ma zalety i wady. Z czasem może uda się zwiększyć popularność tego (ponoć) dobrego języka programowania i nie będzie tak jak w zeszłym roku, że na ponad 40 gier tylko 3 były napisane w "Action!".
Yosh dał się na tą niewdzięczną pracę namówić i dlatego mogę dziś oficjalnie zaprosić na internetowe Zgromadzenie Actionariuszy czyli osób zainteresowanych programowaniem w "Action!". Dzisiejszy odcinek argumentacji na rzecz tego języka dotyczy arytmetyki. Pojawieniu się kolejnych odcinków sprzyjałoby zainteresowanie tematem ze strony czytelników. Jeżeli więc macie pytania, uwagi, prośby w zakresie tego, co powinno być poruszone w takiej serii o programowaniu w "Action!" - właśnie nadszedł dobry czas, żeby je ujawnić i zmusić Yosha do napisania kolejnych odcinków :).
Paweł "Yosh" Różański
A teraz oddaję głos Yosh-owi:
Arytmetyka ośmiobitowego Atari
Widząc tak szeroki oddzew na konkurs "Napisze se" postanowiłem zwrócić uwagę na bardzo istotną kwestię, jaką jest model obliczeń wykorzystywany przez dany język programowania. Jako pierwszy zostanie przedstawiony przykład ilustrujący różnice w realizacji operacji arytmetycznych między interpreterem i kompilatorem języka "Turbo Basic XL" (zwany dalej TBXL), a kompilatorem języka "Action!".
Rozpatrzmy następujący program w języku Turbo Basic XL:
10 POKE 20,0
20 A=0:WHILE PEEK(20)<100:A=A+1:WEND
30 ? AKomórka 20 jest zwiększana przez system w czasie przerwania VBL czyli co 1/50 sekundy (w systemie PAL). Powyższy program wykonywał więc będzie się przez około 2 sekundy, a zmienna A zliczy nam liczbę przebiegów pętli w tym czasie. Uruchamiamy poprzez interpreter "Turbo Basic-a XL":
RUN
642Wynik dość mizerny, około 12 razy na ramkę. Przykład nie wydaje mi się zbyt naiwny - każdy program to przecież obliczenia i przepływ sterowania.... Wytoczymy teraz ciężkie działo, czyli kompilator języka "Turbo Basic XL". Po skompilowaniu i zlinkowaniu ponownie uruchamiamy nasz program:
Load from what file?
WH.COM
2866Ponad 4 razy szybszy, nieźle. Zapiszmy ten sam przykład w języku "Action!":
PROC MAIN()
CARD A
POKE (20,0)
A=0
WHILE PEEK(20)<100
DO
A=A+1
OD
PRINTF("%U%E",A)
RETURNWynik? 37551 obrotów pętli... Funkcja PEEK i procedura POKE należą do standardowej biblioteki - przyjaznej dla przesiadających się z Basic-a. "Action!" udostępnia także bezpośredni dostęp do pamięci poprzez przypisania adresów zmiennym, czyli:
BYTE RT = 20
PROC MAIN()
CARD A
RT=0
A=0
WHILE RT<100
DO
A=A+1
OD
PRINTF("%U%E",A)
RETURNPierwsza linijka "nazywa" bajt pod adresem 20, kod staje się czytelniejszy i szybszy (brak narzutu wywolywania funkcji PEEK). Pętla w tak zapisanym programie wykona się 50778 razy.
Jeżeli kod w języku "TBXL" został skompilowany, to skąd się bierze aż taka różnica? Język "Atari Basic" (i jego młodszy, ulepszony brat "Turbo Basic XL") posiada tylko jeden typ liczb: liczby zmiennoprzecinkowe. Oczywiście 6502 nie wspiera ich natywnie, obliczenia na nich realizowane są przez zniesławiony pakiet FP. Należy mieć na uwadze, że są one używane wszędzie. Dla przykładu, część ludzi lubi mroczny design swojego edytora ekranowego Basic i pierwsze co robią po zapaleniu się READY to zmieniają kolory poprzez:
POKE 710,0
POKE 709,12Jest to naprawdę niski poziom, odwołujemy się bezpośrednio do adresów w pamięci naszego mikrokomputera. "Bezpośrednio", jeżeli nie liczymy między innymi czterech zaokrągleń... a skoro komputer zaokrągla, to ten sam efekt uzyskamy na przykład poprzez:
POKE 709.56, 0.312
POKE 709.43, 11.712Czas wykonania jest praktycznie identyczny z racji wykonania tych samych operacji. W instrukcjach POKE i PEEK płacimy także za test poprawności przekazywanej liczby, na przykład POKE 80000, 10 zwróci ładny błąd numer 3 (liczba z poza dozwolonego zakresu). Nie jest to wada Basic-a. Jest to przecież Beginner's All-purpose Symbolic Instruction Code. Jego celem jest przede wszystkim zapoznanie człowieka z maszyną. Pamiętam swoje początki... Pieczołowicie sprawdzałem w podstawówce zadania z matematyki nie mając pojęcia, że bajt to 8 bitów. Dla początkującego z mikrokomputerem Basicowe uproszczenia na pewno były pomocne - liczby rzeczywiste nie tworzyły dodatkowych barier w zapoznaniu się z programowaniem.
Przejdźmy do innych przykładów niż obliczenia. Dźwięk narastający można modelować poprzez:
10 FOR I=0 TO 15 STEP 0.1: SOUND 1,10,10,I:NEXT
ICo jest o wiele bardziej naturalne, niż sztuczne pętle opóźniające z krokiem co 1. Jednakże gry przez wiele lat powstawały bez liczb zmiennoprzecinkowych (na przykład "Doom" - niewiele szczegółów grafiki i 386DX (nie posiadający kooprocesora) wystarczał...)
Jeżeli nie chcemy inwestować sił w poznanie nowego języka ("Action!"), polecam "Atari Basic":
10 POKE 20,0
20 A=0
30 A=A+1:IF PEEK(20)<100 THEN 30
40 ? AOczywiście uruchomiony poprzez standardowy interpreter:
RUN
217daje wiadomy wynik, niższy niż "Turbo Basic XL". Na szczęście firma Special Sofware Systems stworzyła "MMG Basic Compiler" dla programów w Atari Basic. Potrafi on skompilować kod z zachowaniem liczb zmiennoprzecinkowych i w tym przykładzie daje nam 803 przebiegi pętli - dużo mniej niż kodu wygenerowanego przez kompilator "Turbo Basica XL", ale potrafi także wymusić liczby całkowite. Pętla w tak skompilowanym programie wykona się 6375 razy, ponad dwa razy szybciej niż kod kompilowany TBXL.
Problem liczb zmiennoprzecinkowych próbował także obejść autor "Advan Basic". W tym dialekcie A oznacza zmienną zmiennoprzecinkową, a A% całkowitą. Czas wykonania zbliżony do kompilowanego "Turbo Basica XL". Mam nadzieję, że zachęciłem do eksperymentów z kompilatorami. Jak zawsze, odpowiem na wszystkie pytania (nie żebym znał na wszystkie odpowiedź, ale z przyjemnością poszukam i posprawdzam). Więc, jeżeli ktoś marzy o szybkiej gierce w "Action!" - zapraszam do dyskusji i dociekań.
Kaz 2009-02-23 23:36:04
Na Forum Atarum tez cos bylo o Action!:
http://atarionline.pl/forum/comments.php?DiscussionID=31&page=1#Item_0
i Basicu/Action:
http://atarionline.pl/forum/comments.php?DiscussionID=33&page=1#Item_0
Tdc 2009-02-23 23:57:09
Fajny art !;)
Action! jest zdecydowanie rewelacyjny do gier i jego zaletą jest wydajność, którą można zwiększać jeśli się wie jak. Pamiętam że w redakcji Atari Magazynu Draco mnie przekonywał, że jest jakiś przykład w TBXL, że jest on szybszy niż Action! Ale nie pokazał mi go - może teraz powie o czym była mowa.
Dodatkowo w Action! jest więcej dostępnej pamięci niż w TBXL. W każdym razie z mojego doświadczenia wynika, że Action! najlepszy i najwygodniejszy jest w małych prostych programach, czyli np. we wspomnianym konkursie. Jeśli kod ma np. 20 kb to zaczynają się kłopoty jeśli pozostało jeszcze wiele do napisania, jednak podobne kłopoty ma zapewne i TBXL.
Odnośnie zniesławionego FP to ma on swoje zalety, np. dokładność obliczeń. Na innych komputerach 8bit obliczenia są dużo mniej dokładne (dziś na PC też tak bywa) i o ile się orientuję to są też wolniejsze.
Jednak największą zaletą Action! jest np. to że różnie napisane programy mogą działać z różną prędkością - wiele tu zależy od programisty. To jest cecha języka C/C++ w którym również np. tę samą prostą pętle da się napisać na wiele sposobów i każda będzie miała różne czasy wykonania (włącznie z tymi hiperszybkimi).
Dlatego o ile ktoś wie jak pisać kod w Action! to może się on stać naprawdę bardzo wydajnym, dlatego zachęcam do zainteresowania się tym językiem oraz do eksperymentowania, bo jak ostatnio przekonywałem Mikera, wydajność przeciętnego programu napisanego w Action! można zwykle zwiększyć nawet ponad 100 razy! (właśnie mnie to czeka w programie nad którym siedzieliśmy z Mikerem kilka miesięcy temu).
Również na ile czas pozwoli chętnie wspomogę wraz z Yoshim osoby chcące się nauczyć Action!, a naprawdę warto!
Tdc 2009-02-24 00:07:37
ps. wcale bym się nie zdziwił gdyby okazało się że ukazany tu przykład pętli w Action! nie dałoby się napisać szybciej ;) Może nie będzie to duża różnica, ale można sprawdzić wszelkie możliwe formy pętli oraz innych wynalazków dostępnych w Action! Sam jestem ciekaw co z tego wyniknie!
Kaz 2009-02-24 00:38:43
No to panowie musicie sie postarac zachecic niedowiarkow takich jak ja konkretami: prosze mi udowodnic na konkretnych przykladach programow, ze namecze sie mniej i gra bedzie lepsza jak zamiast TBXL uzyje Action! :)
tdc 2009-02-24 00:55:07
he, he prowokujesz nas ;)
Zostało to już wykazane przez Yoshiego w tym tekście, nie trzeba się wiele namęczyć aby program był szybszy tylko dlatego, że jest w Action! Pisząc w Action! mamy podobną wygodę programowania co w Basic (jeśli chodzi o składnię itp.) a nie jest tak odrzucająca jak dla niektórych asembler. Natomiast w Action! mamy też rewelacyjny edytor, który zwiększa tę wygodę, co ciekawe umożliwia on otwarcie dwóch "okienek" co umożliwia np. edytowanie dwóch programów/plików albo np. przeglądanie zawartości dyskietki przy równoczesnym pisaniu programu ;)
Zapewne wiele dobrego da się powiedzieć, ale w moim pojęciu to są wystarczające argumenty;)
ptb 2009-02-24 01:09:29
W assemblerze jest troche szybciej:
-- WAIT.ASM --------------------
opt %10101
org $9000
rtclock equ 20
a equ $d0
lda #0
sta a
sta a+1
sta a+2
sta rtclock
lda #100
loop inc a
bne *+4
inc a+1
bne *+4
inc a+2
cmp rtclock
bne loop
ldy a
ldx a+1
lda a+2
brk
---------------------------
Prosty kod w QA po wyjsciu (brk) na dole w rejestrach A,X,Y
mamy wynik dodawania u mnie na Atari800 pod Linuksem
wychodzi 021ABF czyli 137919. Ale Action! tez jest niezly! :)
Kaz 2009-02-24 01:41:05
Tdc - oczywiscie, ze prowokuje, bo samo gadanie, ze "Action fajny jest" nikogo nie przekona nas, poczatkujacych i przyzwyczajonych do TBXL do zmiany uzywanego jezyka. Trzeba wlasnie porownac, najlepiej na przykladach i wykazac wszystkie przewagi/zalety.
Ptb - dzieki, fajne, ze konkretny przyklad w Basicu czy Action mozemy sobie zobaczyc takze w assemblerze.
xxl 2009-02-24 01:49:33
a w semblerze z80 pod zxemulator na malym atari:
ld hl,zegar
ld a,0
ld (hl),a
ld b,a
ld c,b
ld a,100
loop inc bc
cp (hl)
jr nc,loop
wychodzi 15424 czyli 5x szybciej od kompilowanego turbo basica?
tdc 2009-02-24 02:22:15
Ptb pokazał właśnie, że zarówno C/C++ na pecetach jak i Action! na Atari nigdy nie dorównają asemblerowi (z pewnymi wyjątkami w Action!). Jednak różnica w przypadku Action! vs pozostałe języki jest tak przytłaczająca, że nie ma się nad czym zastanawiać ;)
Dlatego nic nie stoi na przeszkodzie aby najistotniejsze algorytmy robić w asm w programach Action! Tak jak się robi na nowszych sprzętach z C/C++. Zakłaada się że takiego kodu w asm jest bardzo mało ~10%.
xxl: :D :D
Przy okazji jak się patrzy na asm u ptb i u xxla to widać od razu czym się różni asm RISC od CISC. 6502 było takie trochę RISCowe czyli programy są dłuższe ale znacznie szybsze.
tdc 2009-02-24 02:27:09
Kaz: to trudne porównanie, bo porównując np. program wykreślający coś plot/drawto to jednak niewiele da się powiedzieć, dlatego, że takie rzeczy da się w Action! napisać inaczej tak aby były dużo szybsze. Stąd w mojej ocenie to rozległy temat i trudny.
Ja byłbym odległy od porównywania składni języków Action! i Basic, bo wykazałoby się że np. w którymś języku program jest krótszy o np. 10 znaków, ale co z tego ? Skoro w moim ujęciu takie porównywanie listingów nie ma sensu. Co nam da 10 znaków skoro program działa o niebo szybciej ? W mojej ocenie najważniejsza tu jest szybkość i w mojej ocenie na tym należy się zatrzymać. Inna sprawa że jestem za jak najdokładniejszym opisaniem programowania w Action! i pewnie będę miał w tym swój udział;)
monsoft 2009-02-24 07:06:42
Bardzo fajny artykul.
Tak mi sie na marginesie przypoina, ze o ile dobrze pamietam to gra "Problem Jasia" byla wlasnie napisana w Action!
Yosh 2009-02-24 07:54:34
Jest to oczywiste, że assembler jest szybszy - sam Action! wykonuje ZERO optymalizacji np.
a = 0
b = 0
a on
LDA #0
STA ...
LDA #0
STA ...
czasami też robi
STA $3000
LDA $3000
CMP ...
dla
x = 123
if (x ....
Jest jedno przebiegowy - czyli szybki i tępy :) chłopaki nie zrobili nawet podstawowych optymalizacji "pamietam co mam w rejestrach" i "pamietam od ktorej instrukcji mam znaczniki procesora"
Ale nie chciałem już straszyć assemblerem ;P
xxl 2009-02-24 09:02:51
uczcie Action! na przykladzie, wybierzcie jakas maksymalnie prosta gre i w odcinkach na strone, przy okazji tlumaczac jak mozna robic optymalizacje itp. tetrisa/odwracanke/snejka cokolwiek.
larek 2009-02-24 09:07:36
Pamiętam, jak dawno, dawno temu chciałem nauczyć się Action! Próbowałem coś tworzyć, ale jakoś nic z tego nie wyszło. Nie potrafiłem się przestawić z prostego zapisu w TBXL (AB) na dziwny Action! Basic pozwalał skakać po liniach programu bez ograniczeń, Action! z tymi swoimi procedurami praktycznie tego nie udostępniał - nie potrafiłem tego obejść :) Edytor mimo, że pełnoekranowy, też jakoś nie spodobał mi się. W Basicu, żeby zapisać program wystarczyło napisać CSAVE i już. W Action! nie było to takie intuicyjne. I te brzęczyki, które w opcjach monitora Action! mnie denerwowały... ;)
Ciągle kusi mnie powrót do Action! i spróbowanie go ponownie, ale z drugiej strony, skoro mam się uczyć czegoś nowego, to dlaczego nie... asemblera? Może gdyby powstał cykl lekcji o Action! to kto wie... :)
pps 2009-02-24 09:58:24
Jeszcze jeden argument za Action!:
dla ludzików klepiących na codzień w "dzisiejszych" językach średniego i wysokiego poziomu (np. C/C++/Java/Pascal/Python itd.) dużo łatwiej jest podejść do języka z podobnym stylem programowania niż do linijkowca-Basica.
A na koniec pytanko: jak do kodu w Action! wstrzyknąć procedurkę w asemblerze?
zilq 2009-02-24 10:15:21
heh... ACTION! faktycznie, jak na swoje czasy, był językiem wyjątkowym (na małym Atari) Pełno ekranowy edytor, zabudowany kompilator, dwa okna...
Wszystko fajnie, tylko szkoda, że "czasami" daje się we znaki niedopracowanie środowiska programistycznego :(
Przykłady
- brak zapamiętania nazwy edytowanego pliku w poszczególnych oknach, co przy nieostrożnym użytkowaniu, prowadzić może do "utraty" pliku
- niepamiętanie ustawień edytora (Compilator->Option) Reset kasuje te opcje :( (do zniesienia :P)
- źle wskazywane błędy kompilacji (kod programu) - chyba najbardziej upierdliwy bug
i jeszcze kilka innych bugów które utrudniają korzystanie z języka Action!
Po za tym, język wart poznania, choćby ze względu na łatwość "przesiadki" na inne języki. Uczy pisać w sposób elegancki i strukturalny. No i co najważniejsze, jest szybki.
ptb 2009-02-24 10:19:14
W takim razie jeszcze przyklad ze mozna troche
bardziej zoptymalizowac program:
--- WAIT2.ASM ------------------
opt %10101
org $9000
rtclock equ 20
a equ $d0
lda #0
sta a
tax
tay
sta rtclock
lda #100
loop iny
bne *+3
inx
bne *+4
inc a
cmp rtclock
bne loop
lda a
brk
-------------------------------
I teraz dostajemy 028E9C, czyli 167580 :) Tak na marginesie
to ostatnio patrzylem tez na kompilator CC65 i moze on byc
tez dobra alternatywa. Oczywiscie wiem, ze dziala tylko na
PC. Zaleta jest jednak taka ze mozna pisac duze gry
nie martwiac sie ze zabraknie nam pamieci. Pamietam
jak pisalem na Atari w QA trzeba bylo dzielic projekt na male
czesci i pozniej kompilowac do pamieci po kawalku lub ladowac
w czasie kompilacji.
ptb 2009-02-24 15:03:20
To jeszcze dodatkowo program w cc65 :)
--- counter.c ---------------------------
#include
#include
#include
#define rtclock 20
int main (void)
{
register unsigned int a=0;
POKE(rtclock,0);
do {
a=a+1;
} while ( PEEK(rtclock) < 50 );
printf ("%un",a);
return 0;
}
-------------------------------
Tutaj sprawdzamy tylko sekunde (<50) bo nastepuje przepelnienie
int, ale jak damy long to juz bedzie troche nieuczciwie dla porownania z Action!. Wiec po uruchomianiu dostajemy 43146
czyli razy dwa i mamy 86292. Ale tutaj byly uzyte oczywiscie optymalizacje cc65. Dokladnie skompilowalem to tak
cc65 -Oi -Or -Os -Cl -t atari counter.c
ptb 2009-02-24 15:14:07
To co napisalem:
cc65 -Oi -Or -Os -Cl -t atari counter.c
to skompiluje nam tylko do pliku counter.s, czyli assemblera.
Mozna sobie nawet zobaczyc jak program wyglada
w assemblerze, ale jak chcemy do pliku wykonywalnego,
to wtedy
cl65 -Oi -Or -Os -Cl -t atari counter.c
tdc 2009-02-24 16:46:46
monsoft: tak. Duet Gizmo i Jakub bardzo sobie cenili Action! A o ile ja pamiętam to była to jedena z niewielu gier w Action! która była w 15 tr. graficznym.
Yosh 2009-02-24 18:37:45
@pps: Wstrzykiwanie kodu assmblerowego.... cóż... Action! to język siłowy np...
DO
A=A+1
[ $8D 710 ]
OD
czyli ni z gruchy ni z pietruchy nagle STA 710, nie ważne co tam w akumulatorze było (a że 'akurat' tam była liczba zapisywana do A, to mamy pulsujące tło)
można sobie to uładnić, całość będzie wyglądać tak
BYTE RT = 20
DEFINE STA = "$8D"
PROC MAIN()
CARD A
RT=0
A=0
WHILE RT<100
DO
A=A+1
[ STA 710 ]
OD
PRINTF("%U%E",A)
RETURN
o DEFINE napewno w przyszłym odcinku :)
Można też nie pisać kodu w Action! i cała procedure wydłubać w [ ]
@ptb:
cc65 też fajny i także umożliwia zapis "ładny" tzn:
#define RTCLOCK (*((unsigned char*)20))
int main (void)
{
register unsigned int a=0;
RTCLOCK = 0;
do {
a=a+1;
} while ( RTCLOCK < 50 );
printf ("%un",a);
return 0;
}
choć jest to kwestia gustu :)
Na szczęście Action i C to prawie to samo :P.
ptb 2009-02-24 19:29:26
Osobiście to akurat bardziej by mnie ciekawiło zrobienie
rekompilacji Action!, tak aby można z niego korzystać na PC.
To jest całkiem ciekawy pomysł, chodzi o cos takiego jak tutaj:
http://www.pagetable.com/?p=35
http://www.pagetable.com/?p=48
Ale tylko samego kompilatora Action!
Fajnie bo nie piszemy od zera kodu tylko wykorzystujemy aktualne
implementacje. Aktualnie nie mam duzo czasu, ale już wcześniej
o tym myślałem :)
golem14 2009-02-24 20:06:19
xxl: "uczcie Action! na przykladzie, wybierzcie jakas maksymalnie prosta gre i w odcinkach na strone".
Jak najbardziej mnie się to podoba! Nawet mam pomysł na grę, którą kiedyś napisałem w Basicu ale wszelki duch po niej zaginął. Gra jest "relaksówką szkolną" którą się robi na kartce papieru, ale z czasem zliczanie wyników robi się zbyt meczące (i mylące).
Ponadto można by zrobić "Conway's Life" lub "Dylematy Więźnia" dwie gry edukacyjne wymagające sporych obliczeń. Dla chętnych mam własne źródła w Microsoft Basicu - pewnie można je łatwo przerobić na TBXL i potem porównać szybkość z Actionem.
sikor 2009-02-24 20:32:26
Bardzo ładny artykuł, aczkolwiek nieobiektywny. Dlaczego tak uważam?
1. Język ACTION! jest typowym przykładem języka kompilowanego, któremu znacznie bliżej do kodu maszynowego niż dowolnemu językowi interpretowanemu, jakim jest Basic w każdej postaci (z wyjątkiem bodajże GFA Basica dla ST i PC). Przy takim porównaniu żaden żaden interpretowany język nie ma szans.
2. Kompilacja (i linkowanie) BASICA nadal nie tworzy pełnoprawnego języka kompilowanego - niestety, stokenizowany kod po kompilacji nie tworzy czystego kodu. Oczywiście, znacznie go przyspiesza (podstawiając od razu pewne adresy), ale nadal przy wielu czynnościach część rzeczy jest wyliczana na bieżąco.
3. Jak już porównywać, to poproszę jeszcze o porównanie z innymi językami dla Atari, aby było sprawiedliwie. Na przykład Deep Blue C czy KYAN Pascal. O ile przypuszczam, że KP będzie wolniejszy niż ACTION!, o tyle DBC już nie jest takie pewne.
4. Kod TB XL można nieznacznie przyspieszyć, używając cyfr od 0 do 3 ze znakiem %. W podanym przykłądzie bez kompilacji przyrost będzie niewielki, ale zawsze...
A teraz co nieco o ACTION!: tak z tego co wiem, to wspaniały język i chętnie bym się go nauczył, jednak może mi zbraknąć samozaparcia. Przykładowy kurs od A do Z to by było tu, z odpowiedziami na forum, zadaniami dla uczących się... Jakiś PacMan?
Aha, i przypominam, że (prawie) każdy kod da się zoptymalizować...
Old 2009-02-24 21:13:37
@ptb — ja bym wolał TBXL w tej roli. Jest coś takiego: interpreter TBXL pod Win (TurboTari się nazywa), ale projekt nie został dokończony.
Kaz 2009-02-24 21:15:07
A ja pozwole sobie dalej byc "na nie", ale wcale nie z powodow o ktorych Sikor pisze. Bo akurat mnie zadne tam "uczciwe" porownania jezykow nie interesuja, a wrecz przeciwnie - uwazam, ze kazdy jezyk powinien pokazywac wszystkie nieuczciwe przewagi nad innymi, jesli je ma :)
Dla mnie liczy sie przede wszystkim holdowanie mojemu lenistwu czyli jezyk powinien byc wygodny w uzyciu, nie powinien miec rzucajacych sie w oczy bledow i miec sporo wsparcia w literaturze i przykladach.
Niestety, ale w swietle obiegowych, moze i nieprawdziwych, opinii Action nie jest ani wygodny ani pozbawiony powaznych bledow. Chcialbym wiec wiecej poczytac o Action wlasnie od strony praktycznej, na przykladach - jakie ma zalety, a jak obchodzic wady.
Adam Mowny 2009-02-24 21:31:44
A czy ktoś słyszał/używa języka QUICK i może chociaż krótko opisać ? A może zapisać powyższą pętlę testową i podać wynik?
http://cgi.ebay.pl/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MEWAX
:IT&item=230323826722
Yosh 2009-02-24 21:58:58
Zanim ustosunkuje się do innych wypowiedzi
- O językach nie mówi się, że są kompilowane, interpretowane, wywoływane na maszynie wirtualnej.... no chyba że jest to skrót myślowy do "istnieje interpreter dla danego języka", "istnieje kompilator dla danego języka" - więc Kaz jest dużo bliżej prawdy - liczy się także środowisko i wszystko wokół
Język Action!, język polski, język angielski i język C... to tylko rozpisane gramatyki (mniej lub bardziej formalne).. (żonę mam po filologi - więc jest to nasz 'wspólny' konik :P:P)
- Dobór języków wynika (fakt faktem, umkneło mi to w artykule - postaram się o tym pamiętać na przyszłość (o metodologi) dzieki sikor) z zastanych języków w konkursie "napisz se" (dlatego wnikałem w Advan Basic), chciałem także pokazać BrainFuck - ale tam porównanie liczby to jej odejmowanie co 1 - zbyt skrajny przypadek :)
I z tego, że na kolejnych przykładach pokaże, że dzięki rozsądnej bibliotece rozruchowej, nie jest on trudniejszy od TBX (jak ktoś nie robi nagminnie GOTO :P) a ma kilka fajnych przekmin :P
- %0 %1 %2 %3 w TB to głównie oszczędność miejsca.... liczba zmiennoprzecinkowa + stałoprzecinkowa -> rzut %0 na zmiennoprzecinkową przed sumą, przez interpreter różnica jest pomijalna 642 vs 643... ..
Chciałem głównie uczulić, na tą zmiennoprzecinkowość - cześć gier z "napisz se" zyskały by na miodności gdyby je puścić właśnie przez ten MMG
BASIC to Java tamtych czasów :) Imponuje mi... jest w nim TRAP, coś czego ani w C ani w Action! nie uświadczysz... dopiero C++ czy java ma podobne mechanizmy (throw/catch)
Czy sprawdzanie zakresów tablicy (!)
10 DIM A(1)
20 A(10) = 7
RUN
ERROR 9 DIM AT LINE 20
Miód! (też w javie jest :P) , czy LOCATE poza ekran.
Ale, jeżeli kod jest w miarę prosty da się go wklepać w Action! bez straty większej ilości włosów.
Action! tak jak C to jazda bez trzymanki - tablica + indeks za duży ? chcesz - masz :) łatwo wywalić swój kod, łatwo napisać sobie po edytorze. W BASIC, właściwie tylko używanie POKE jak popadnie może coś rozwalić...
I to jest też to o czym zapomniałem - Action! napewno nadaję się dla projektów które straszą przez POKE w Basicu :)
Nie bijcie :) chciałem dobrze.... :)
sikor 2009-02-24 22:29:16
@Yosh: Nie bijcie :) chciałem dobrze.... :)
Jak napisałem - ciekawy artykuł, ale napisany w taki sposób, że pokazuje tylko zalety Action! w stosunku do Basica na podstawie jednego przykładu. Jak napisałem - ciekawy język, ale - jak wspomniał KAZ - przydało by się więcej przykładów.
Języki kompilowane/interpretowane - jak najbardziej masz rację, skrót myślowy. Ale spotykany (i stosowany, co więcej) - w praktyce. Jedno ale - czasem konstrukcja języka wymusza pewne mechanizmy... I niestety tak jest z Basiciem. Jak napisałem - chętnie bym popatrzył na wyniki i w innych językch.
Pytanie za 10 punktów: jaki wynik będzie w LOGO...? Chyba trzeba odszukać gdzieś binarkę ;)
NIe ma się co obrażać... Czekamy na więcej artykułów, a nie tyklko obietnice o artkach... I opartych na przykładach. Każdy język ma swoje zalety i swoje wady. Co więcej: często jeden język jest wykorzystywany do pisania w innym. Przy wielu efektach w assemblerze do dem wykorzystywano... Atari Basic - mimo swej powolności pozwalał w łatwy sposób przeliczać pewne rzeczy bez potrzeby pisania skomplikowanego kodu w assemblerze... Pewnie (była) grupa Slight czy inne to poświadczą ;)
Na zakończenie - poprosimy o krótki kurs (a raczej długi kurs w krótkich odcinkach) z Action!. Koniecznie na przykłądach ;)
Monsoft 2009-02-24 22:45:07
Adam: http://www.classiccmp.org/dunfield/atarixl/atari8b.txt szukaj hasla "Quick (disk)"
golem14 2009-02-24 22:51:14
Upubliczniam, może kogoś zainspiruje:
http://wklej.org/hash/361a86bf35/
Scalak 2009-02-25 00:30:38
dla mnie szybkość zdecydowanie przemawia za Action! Assembler kusi, ale jakoś nie mogę znaleźć przystępnego kursu dla totalnych nemo. Aby wyrobić sobie zdanie na temat Action! prosiłbym o kilka nazw gier napisanych w tym języku które ukazują power Action! Z góry dziękuję.
larek 2009-02-25 09:08:16
Atarimania podaje: http://tiny.pl/bm87
Z tego, co wiem, to Problem Jasia i The Warsaw Tetris są napisane w Action!
Prawdę mówiąc, to jakoś mocy Action! w tych grach (no może oprócz Problemu Jasia) nie widać...
xxl 2009-02-25 09:11:10
muzyka do scorpions 2.0 napisana jest w action! i zlinkowana z gra.
Cosi 2009-02-25 09:37:09
@sikor: Odpowiedź na pytanie za 10 punktów: wynik jest koszmarny :/
Zrobiłem dwie wersje testu - rekurencyjną i nierekurencyjną.
Wersja pierwsza:
TO TEST
MAKE "A :A+1
IF (.EXAMINE 20)<100 [TEST]
END
TO START
MAKE "A 0
.DEPOSIT 20 0
TEST
PR :A
END
Wersja druga:
TO TEST2
MAKE "A 0
.DEPOSIT 20 0
REPEAT 5000 [MAKE "A :A+1 IF (.EXAMINE 20)>100 [STOP]]
END
Wyniki:
1) 47
2) 66
czyli tragiczne, ale...
c.d.n.
Cosi 2009-02-25 09:48:02
Porównywać pod tym względem Logo z cc65 czy Action! to tak jak z tym buldogiem z kawału, który wystartował w wyścigu chartów. Podobnie można by porównywać C i PHP :-)
Spośród języków na małe Atari Logo jest chyba językiem najwyższego poziomu - obok Lispu. Interpreter tworzy własną "maszynę wirtualną", prawdopodobnie z własnym stosem i z dynamicznym zarządzaniem pamięcią. Język zakłada rekurencyjne rozwiązywanie problemów i, między innymi dlatego, brak w nim klasycznych pętli typu DO ... WHILE. Takie podejście pozwala programować bardzo "wysoko", ale odbywa się to kosztem wydajności. I tak byłem zdziwiony, że procedura potrafi się rekurencyjne wywołać 10000 razy i dalej działa ;-)
Ograniczenia Atari Logo to są de facto ograniczenia Atari. Oczywiście można je obejść, grzebiąc nieco w bebechach - mam taki zamysł - ale w dalszym ciągu będzie to potwornie powolna maszyna wirtualna...
Scalak 2009-02-25 11:04:13
dzięki za te dwa tytuły a może są jakieś demka w Action! ???, bo w Tetrisie to mało tego powera... w Problemie Jasia już coś (aczkolwiek małego) się rusza, ten (chyba duch) pasek w czołówce nieco powera ujawnia.
Kaz 2009-02-25 11:34:42
Mozna szukac wsrod programow Husaka:
http://tiny.pl/bm6l
Ale w wywiadzie wyszlo, ze to Gizmo uzywal Action!:
http://tiny.pl/bm6n
wiec wypada sprawdzic te gry:
http://tiny.pl/bm6k
Yosh 2009-02-25 12:04:16
@Cosi: 10000 się wywoła bo prawdopodobnie LOGO implementuje optymalizacje wywołań ogonowych http://en.wikipedia.org/wiki/Tail_call
Tak myślę, ze raczej zrobię przykład 'dużo się dzieje', bo jak pokaże tekstowke to "W TBXL tez się da!" :). Chyba trochę to spłynie w pisanie gier jako takich - mam nadzieje, ze porady z pod lady przydadzą się także w innych językach ...
Kaz 2009-02-25 12:11:12
I bardzo dobry pomysl! Podejrzewam, ze pisanie gier jest najwiekszym wyzwaniem dla programisty, wiec jak przekonywac, to na przykladach z "grubej rury" :)
ptb 2009-02-25 12:20:59
To ja podaje kilka innych przykladow, ze Action! jest dość szybki:
http://www.cyberroach.com/analog/an16/action.htm
Z 16 numeru Analogu jest prosty przykład z sitem i pokazana
jest od razu translacja Action! na kod maszynowy. Jako bardziej
graficzny przykład to można wziąć
http://www.umich.edu/~archive/atari/8bit/Unverified/Cislib_b/pulse.act
W Analogu zadaje sie ze byly specjalne kolumny o Action!.
A tak podsumowując to Yosh dobra robota i wydaje mi się ze
jeśli ktoś myśli o programowaniu na Atari i nawet jeśli
zna assembler to Action! jest b. dobra alternatywa.
Nie mówiąc już jeśli zna tylko BASIC, a jeśli to kogoś
nie interesuje to zawsze moze po prostu nie czytac zamiast
pisać niepotrzebne komentarze :)
sikor 2009-02-25 12:44:09
@COSI: wynik i tak jest lepszy, niż się spodziewałem. Ale tak samo jest z porównaniem Basica i ACTION!, więc pytanie było czysto teoretyczne... W takim razie jeszcze test KP i DBC i będziemy mieli jakiś większy pogląd. Dzięki za test ;)
sikor 2009-02-25 12:46:24
A pro po kompilacji BASICA: kiedyś kompilowałem mój programik na real 16KB compo z atari Basica (nie pamiętam, czy MMG Basic Compilerem czy tym drugim, w każdym razie nie kompilatorem Turbo Basica) i nie dało się grać... Program był za szybki, więc fakt-faktem: czasem kompilacja duuużo zmienia ;)
Cosi 2009-02-25 13:12:50
@Yosh: Faktycznie, o tym nie pomyślałem. Jeżeli tak, to stos może być całkowicie odciążony i - teoretycznie - powinno się dać zrobić dowolne zagnieżdżenie.
Tak w ogóle to marzy mi się reverse-engineering Atari Logo, bo wielu rzeczy nie udało mi się rozgryźć "empirycznie", np. lokalizacji kodu interpretera - a to by była przydatna wiadomość przy pisaniu wstawek w kodzie maszynowym, bo Logo blokuje nadpisywanie swojego obszaru (całkiem rozsądnie zresztą). Można natomiast nadpisać DL - i to jest pole do popisu :) - tylko że w te klocki jestem za cienki niestety...
Cosi 2009-02-25 13:21:33
@sikor: DBC jest cholernie wolne - pamiętam, jak się przez krótki czas nim bawiłem i oczywiście zacząłem od programu liczącego silnie. Wydajność tragiczna, można powiedzieć, że DBC przynosi wstyd swoim braciom ;-P
W każdym razie bez porównania z cc65, ale to chyba oczywiste.
urborg 2009-02-26 12:04:30
Wpisałem ten programik w TB uruchomiłem i dziwna rzecz. Uzyskałem wynik zaledwie 499. Uruchamiałem na emulatorze. Nie wiem czemu mam o tyle niższy wynik.
Sam potem jednak zacząłem główkować i wymyśliłem że program da się przyśpieszyć poprzez wyłaczenie Antica na czas obliczeń.
10 POKE 559,0:POKE 20,0
20 A=0:WHILE PEEK(20)<100:A=A+1:WEND
30 POKE 559,250:? A
WYNIK: 729
potem pomyślałem o tym co pisał Sikor, czyli zamiana stałej na stałą TB, 1 na %1, 0 na %0 itd. W zasadzie zysk da jedynie zmiana 1 bo to się odbywa w pętli czyli jest wykonywane wielokrotnie.
10 POKE 559,0:POKE 20,%0
20 A=%0:WHILE PEEK(20)<100:A=A+%1:WEND
30 POKE 559,250:? A
No i proszę jest minimalna poprawa. WYNIK: 731
Ale da się jeszcze całość trochę uprościć. Można uprościć warunek zakończenia pętli zmieniając sposób zlicznia. Liczymy od 156, a po osiągnięciu 100 otrzymamy w komórce wartość 0. :)
10 POKE 559,0:POKE 20,156
20 A=0:WHILE PEEK(20):A=A+%1:WEND
30 POKE 559,250:? A
WYNIK 833
urborg 2009-02-26 12:08:01
No już wszystko jasne :) Miałem gorsze wyniki bo w emulatorze nie zauważyłem że mam włączone NTSC. Po włączeniu PAL wynik dla ostatniego programiku to 995.
Cosi 2009-02-26 13:32:56
A Logo po wyłączeniu ANTIC'a: 99 :D
Kaz 2009-02-26 14:42:20
Mnie liczenie akademickich przykladow w egipskich ciemnosciach nie przekonuje :).
sikor 2009-02-26 22:01:11
@Urborg: po kompilacji wersja bez % wskazuje mi 6876
wersja z %: 6856
Dziwne, czyli wersja krótsza działa nieco wolniej ;)
mono 2009-02-27 00:01:06
@Yosh: Te wywołania noszą też nazwę rekurencji prawostronnej.
Świetny artykuł! Kiedyś chciałem się nauczyć Action! i nawet zaopatrzyłem się w cartridge i książkę, ale zdarzyło się, że wcześniej poznałem assembler :) A do prostych przeliczeń BASIC najczęściej wystarczał, no i na chęciach się skończyło.
rudla 2010-03-01 22:43:35
In Atalan, following code counts to 145302.
[code]
timer@20:byte
count:0..2'000'000
inc:macro( x ) =
x = x + 1
"Counting 2 seconds..."
count = 0
timer = 0
until timer = 100
inc count
"Counted to [count]."
[/code]
Na Forum Atarum tez cos bylo o Action!:
http://atarionline.pl/forum/comments.php?DiscussionID=31&page=1#Item_0
i Basicu/Action:
http://atarionline.pl/forum/comments.php?DiscussionID=33&page=1#Item_0
Tdc 2009-02-23 23:57:09
Fajny art !;)
Action! jest zdecydowanie rewelacyjny do gier i jego zaletą jest wydajność, którą można zwiększać jeśli się wie jak. Pamiętam że w redakcji Atari Magazynu Draco mnie przekonywał, że jest jakiś przykład w TBXL, że jest on szybszy niż Action! Ale nie pokazał mi go - może teraz powie o czym była mowa.
Dodatkowo w Action! jest więcej dostępnej pamięci niż w TBXL. W każdym razie z mojego doświadczenia wynika, że Action! najlepszy i najwygodniejszy jest w małych prostych programach, czyli np. we wspomnianym konkursie. Jeśli kod ma np. 20 kb to zaczynają się kłopoty jeśli pozostało jeszcze wiele do napisania, jednak podobne kłopoty ma zapewne i TBXL.
Odnośnie zniesławionego FP to ma on swoje zalety, np. dokładność obliczeń. Na innych komputerach 8bit obliczenia są dużo mniej dokładne (dziś na PC też tak bywa) i o ile się orientuję to są też wolniejsze.
Jednak największą zaletą Action! jest np. to że różnie napisane programy mogą działać z różną prędkością - wiele tu zależy od programisty. To jest cecha języka C/C++ w którym również np. tę samą prostą pętle da się napisać na wiele sposobów i każda będzie miała różne czasy wykonania (włącznie z tymi hiperszybkimi).
Dlatego o ile ktoś wie jak pisać kod w Action! to może się on stać naprawdę bardzo wydajnym, dlatego zachęcam do zainteresowania się tym językiem oraz do eksperymentowania, bo jak ostatnio przekonywałem Mikera, wydajność przeciętnego programu napisanego w Action! można zwykle zwiększyć nawet ponad 100 razy! (właśnie mnie to czeka w programie nad którym siedzieliśmy z Mikerem kilka miesięcy temu).
Również na ile czas pozwoli chętnie wspomogę wraz z Yoshim osoby chcące się nauczyć Action!, a naprawdę warto!
Tdc 2009-02-24 00:07:37
ps. wcale bym się nie zdziwił gdyby okazało się że ukazany tu przykład pętli w Action! nie dałoby się napisać szybciej ;) Może nie będzie to duża różnica, ale można sprawdzić wszelkie możliwe formy pętli oraz innych wynalazków dostępnych w Action! Sam jestem ciekaw co z tego wyniknie!
Kaz 2009-02-24 00:38:43
No to panowie musicie sie postarac zachecic niedowiarkow takich jak ja konkretami: prosze mi udowodnic na konkretnych przykladach programow, ze namecze sie mniej i gra bedzie lepsza jak zamiast TBXL uzyje Action! :)
tdc 2009-02-24 00:55:07
he, he prowokujesz nas ;)
Zostało to już wykazane przez Yoshiego w tym tekście, nie trzeba się wiele namęczyć aby program był szybszy tylko dlatego, że jest w Action! Pisząc w Action! mamy podobną wygodę programowania co w Basic (jeśli chodzi o składnię itp.) a nie jest tak odrzucająca jak dla niektórych asembler. Natomiast w Action! mamy też rewelacyjny edytor, który zwiększa tę wygodę, co ciekawe umożliwia on otwarcie dwóch "okienek" co umożliwia np. edytowanie dwóch programów/plików albo np. przeglądanie zawartości dyskietki przy równoczesnym pisaniu programu ;)
Zapewne wiele dobrego da się powiedzieć, ale w moim pojęciu to są wystarczające argumenty;)
ptb 2009-02-24 01:09:29
W assemblerze jest troche szybciej:
-- WAIT.ASM --------------------
opt %10101
org $9000
rtclock equ 20
a equ $d0
lda #0
sta a
sta a+1
sta a+2
sta rtclock
lda #100
loop inc a
bne *+4
inc a+1
bne *+4
inc a+2
cmp rtclock
bne loop
ldy a
ldx a+1
lda a+2
brk
---------------------------
Prosty kod w QA po wyjsciu (brk) na dole w rejestrach A,X,Y
mamy wynik dodawania u mnie na Atari800 pod Linuksem
wychodzi 021ABF czyli 137919. Ale Action! tez jest niezly! :)
Kaz 2009-02-24 01:41:05
Tdc - oczywiscie, ze prowokuje, bo samo gadanie, ze "Action fajny jest" nikogo nie przekona nas, poczatkujacych i przyzwyczajonych do TBXL do zmiany uzywanego jezyka. Trzeba wlasnie porownac, najlepiej na przykladach i wykazac wszystkie przewagi/zalety.
Ptb - dzieki, fajne, ze konkretny przyklad w Basicu czy Action mozemy sobie zobaczyc takze w assemblerze.
xxl 2009-02-24 01:49:33
a w semblerze z80 pod zxemulator na malym atari:
ld hl,zegar
ld a,0
ld (hl),a
ld b,a
ld c,b
ld a,100
loop inc bc
cp (hl)
jr nc,loop
wychodzi 15424 czyli 5x szybciej od kompilowanego turbo basica?
tdc 2009-02-24 02:22:15
Ptb pokazał właśnie, że zarówno C/C++ na pecetach jak i Action! na Atari nigdy nie dorównają asemblerowi (z pewnymi wyjątkami w Action!). Jednak różnica w przypadku Action! vs pozostałe języki jest tak przytłaczająca, że nie ma się nad czym zastanawiać ;)
Dlatego nic nie stoi na przeszkodzie aby najistotniejsze algorytmy robić w asm w programach Action! Tak jak się robi na nowszych sprzętach z C/C++. Zakłaada się że takiego kodu w asm jest bardzo mało ~10%.
xxl: :D :D
Przy okazji jak się patrzy na asm u ptb i u xxla to widać od razu czym się różni asm RISC od CISC. 6502 było takie trochę RISCowe czyli programy są dłuższe ale znacznie szybsze.
tdc 2009-02-24 02:27:09
Kaz: to trudne porównanie, bo porównując np. program wykreślający coś plot/drawto to jednak niewiele da się powiedzieć, dlatego, że takie rzeczy da się w Action! napisać inaczej tak aby były dużo szybsze. Stąd w mojej ocenie to rozległy temat i trudny.
Ja byłbym odległy od porównywania składni języków Action! i Basic, bo wykazałoby się że np. w którymś języku program jest krótszy o np. 10 znaków, ale co z tego ? Skoro w moim ujęciu takie porównywanie listingów nie ma sensu. Co nam da 10 znaków skoro program działa o niebo szybciej ? W mojej ocenie najważniejsza tu jest szybkość i w mojej ocenie na tym należy się zatrzymać. Inna sprawa że jestem za jak najdokładniejszym opisaniem programowania w Action! i pewnie będę miał w tym swój udział;)
monsoft 2009-02-24 07:06:42
Bardzo fajny artykul.
Tak mi sie na marginesie przypoina, ze o ile dobrze pamietam to gra "Problem Jasia" byla wlasnie napisana w Action!
Yosh 2009-02-24 07:54:34
Jest to oczywiste, że assembler jest szybszy - sam Action! wykonuje ZERO optymalizacji np.
a = 0
b = 0
a on
LDA #0
STA ...
LDA #0
STA ...
czasami też robi
STA $3000
LDA $3000
CMP ...
dla
x = 123
if (x ....
Jest jedno przebiegowy - czyli szybki i tępy :) chłopaki nie zrobili nawet podstawowych optymalizacji "pamietam co mam w rejestrach" i "pamietam od ktorej instrukcji mam znaczniki procesora"
Ale nie chciałem już straszyć assemblerem ;P
xxl 2009-02-24 09:02:51
uczcie Action! na przykladzie, wybierzcie jakas maksymalnie prosta gre i w odcinkach na strone, przy okazji tlumaczac jak mozna robic optymalizacje itp. tetrisa/odwracanke/snejka cokolwiek.
larek 2009-02-24 09:07:36
Pamiętam, jak dawno, dawno temu chciałem nauczyć się Action! Próbowałem coś tworzyć, ale jakoś nic z tego nie wyszło. Nie potrafiłem się przestawić z prostego zapisu w TBXL (AB) na dziwny Action! Basic pozwalał skakać po liniach programu bez ograniczeń, Action! z tymi swoimi procedurami praktycznie tego nie udostępniał - nie potrafiłem tego obejść :) Edytor mimo, że pełnoekranowy, też jakoś nie spodobał mi się. W Basicu, żeby zapisać program wystarczyło napisać CSAVE i już. W Action! nie było to takie intuicyjne. I te brzęczyki, które w opcjach monitora Action! mnie denerwowały... ;)
Ciągle kusi mnie powrót do Action! i spróbowanie go ponownie, ale z drugiej strony, skoro mam się uczyć czegoś nowego, to dlaczego nie... asemblera? Może gdyby powstał cykl lekcji o Action! to kto wie... :)
pps 2009-02-24 09:58:24
Jeszcze jeden argument za Action!:
dla ludzików klepiących na codzień w "dzisiejszych" językach średniego i wysokiego poziomu (np. C/C++/Java/Pascal/Python itd.) dużo łatwiej jest podejść do języka z podobnym stylem programowania niż do linijkowca-Basica.
A na koniec pytanko: jak do kodu w Action! wstrzyknąć procedurkę w asemblerze?
zilq 2009-02-24 10:15:21
heh... ACTION! faktycznie, jak na swoje czasy, był językiem wyjątkowym (na małym Atari) Pełno ekranowy edytor, zabudowany kompilator, dwa okna...
Wszystko fajnie, tylko szkoda, że "czasami" daje się we znaki niedopracowanie środowiska programistycznego :(
Przykłady
- brak zapamiętania nazwy edytowanego pliku w poszczególnych oknach, co przy nieostrożnym użytkowaniu, prowadzić może do "utraty" pliku
- niepamiętanie ustawień edytora (Compilator->Option) Reset kasuje te opcje :( (do zniesienia :P)
- źle wskazywane błędy kompilacji (kod programu) - chyba najbardziej upierdliwy bug
i jeszcze kilka innych bugów które utrudniają korzystanie z języka Action!
Po za tym, język wart poznania, choćby ze względu na łatwość "przesiadki" na inne języki. Uczy pisać w sposób elegancki i strukturalny. No i co najważniejsze, jest szybki.
ptb 2009-02-24 10:19:14
W takim razie jeszcze przyklad ze mozna troche
bardziej zoptymalizowac program:
--- WAIT2.ASM ------------------
opt %10101
org $9000
rtclock equ 20
a equ $d0
lda #0
sta a
tax
tay
sta rtclock
lda #100
loop iny
bne *+3
inx
bne *+4
inc a
cmp rtclock
bne loop
lda a
brk
-------------------------------
I teraz dostajemy 028E9C, czyli 167580 :) Tak na marginesie
to ostatnio patrzylem tez na kompilator CC65 i moze on byc
tez dobra alternatywa. Oczywiscie wiem, ze dziala tylko na
PC. Zaleta jest jednak taka ze mozna pisac duze gry
nie martwiac sie ze zabraknie nam pamieci. Pamietam
jak pisalem na Atari w QA trzeba bylo dzielic projekt na male
czesci i pozniej kompilowac do pamieci po kawalku lub ladowac
w czasie kompilacji.
ptb 2009-02-24 15:03:20
To jeszcze dodatkowo program w cc65 :)
--- counter.c ---------------------------
#include
#include
#include
#define rtclock 20
int main (void)
{
register unsigned int a=0;
POKE(rtclock,0);
do {
a=a+1;
} while ( PEEK(rtclock) < 50 );
printf ("%un",a);
return 0;
}
-------------------------------
Tutaj sprawdzamy tylko sekunde (<50) bo nastepuje przepelnienie
int, ale jak damy long to juz bedzie troche nieuczciwie dla porownania z Action!. Wiec po uruchomianiu dostajemy 43146
czyli razy dwa i mamy 86292. Ale tutaj byly uzyte oczywiscie optymalizacje cc65. Dokladnie skompilowalem to tak
cc65 -Oi -Or -Os -Cl -t atari counter.c
ptb 2009-02-24 15:14:07
To co napisalem:
cc65 -Oi -Or -Os -Cl -t atari counter.c
to skompiluje nam tylko do pliku counter.s, czyli assemblera.
Mozna sobie nawet zobaczyc jak program wyglada
w assemblerze, ale jak chcemy do pliku wykonywalnego,
to wtedy
cl65 -Oi -Or -Os -Cl -t atari counter.c
tdc 2009-02-24 16:46:46
monsoft: tak. Duet Gizmo i Jakub bardzo sobie cenili Action! A o ile ja pamiętam to była to jedena z niewielu gier w Action! która była w 15 tr. graficznym.
Yosh 2009-02-24 18:37:45
@pps: Wstrzykiwanie kodu assmblerowego.... cóż... Action! to język siłowy np...
DO
A=A+1
[ $8D 710 ]
OD
czyli ni z gruchy ni z pietruchy nagle STA 710, nie ważne co tam w akumulatorze było (a że 'akurat' tam była liczba zapisywana do A, to mamy pulsujące tło)
można sobie to uładnić, całość będzie wyglądać tak
BYTE RT = 20
DEFINE STA = "$8D"
PROC MAIN()
CARD A
RT=0
A=0
WHILE RT<100
DO
A=A+1
[ STA 710 ]
OD
PRINTF("%U%E",A)
RETURN
o DEFINE napewno w przyszłym odcinku :)
Można też nie pisać kodu w Action! i cała procedure wydłubać w [ ]
@ptb:
cc65 też fajny i także umożliwia zapis "ładny" tzn:
#define RTCLOCK (*((unsigned char*)20))
int main (void)
{
register unsigned int a=0;
RTCLOCK = 0;
do {
a=a+1;
} while ( RTCLOCK < 50 );
printf ("%un",a);
return 0;
}
choć jest to kwestia gustu :)
Na szczęście Action i C to prawie to samo :P.
ptb 2009-02-24 19:29:26
Osobiście to akurat bardziej by mnie ciekawiło zrobienie
rekompilacji Action!, tak aby można z niego korzystać na PC.
To jest całkiem ciekawy pomysł, chodzi o cos takiego jak tutaj:
http://www.pagetable.com/?p=35
http://www.pagetable.com/?p=48
Ale tylko samego kompilatora Action!
Fajnie bo nie piszemy od zera kodu tylko wykorzystujemy aktualne
implementacje. Aktualnie nie mam duzo czasu, ale już wcześniej
o tym myślałem :)
golem14 2009-02-24 20:06:19
xxl: "uczcie Action! na przykladzie, wybierzcie jakas maksymalnie prosta gre i w odcinkach na strone".
Jak najbardziej mnie się to podoba! Nawet mam pomysł na grę, którą kiedyś napisałem w Basicu ale wszelki duch po niej zaginął. Gra jest "relaksówką szkolną" którą się robi na kartce papieru, ale z czasem zliczanie wyników robi się zbyt meczące (i mylące).
Ponadto można by zrobić "Conway's Life" lub "Dylematy Więźnia" dwie gry edukacyjne wymagające sporych obliczeń. Dla chętnych mam własne źródła w Microsoft Basicu - pewnie można je łatwo przerobić na TBXL i potem porównać szybkość z Actionem.
sikor 2009-02-24 20:32:26
Bardzo ładny artykuł, aczkolwiek nieobiektywny. Dlaczego tak uważam?
1. Język ACTION! jest typowym przykładem języka kompilowanego, któremu znacznie bliżej do kodu maszynowego niż dowolnemu językowi interpretowanemu, jakim jest Basic w każdej postaci (z wyjątkiem bodajże GFA Basica dla ST i PC
2. Kompilacja (i linkowanie) BASICA nadal nie tworzy pełnoprawnego języka kompilowanego - niestety, stokenizowany kod po kompilacji nie tworzy czystego kodu. Oczywiście, znacznie go przyspiesza (podstawiając od razu pewne adresy), ale nadal przy wielu czynnościach część rzeczy jest wyliczana na bieżąco.
3. Jak już porównywać, to poproszę jeszcze o porównanie z innymi językami dla Atari, aby było sprawiedliwie. Na przykład Deep Blue C czy KYAN Pascal. O ile przypuszczam, że KP będzie wolniejszy niż ACTION!, o tyle DBC już nie jest takie pewne.
4. Kod TB XL można nieznacznie przyspieszyć, używając cyfr od 0 do 3 ze znakiem %. W podanym przykłądzie bez kompilacji przyrost będzie niewielki, ale zawsze...
A teraz co nieco o ACTION!: tak z tego co wiem, to wspaniały język i chętnie bym się go nauczył, jednak może mi zbraknąć samozaparcia. Przykładowy kurs od A do Z to by było tu, z odpowiedziami na forum, zadaniami dla uczących się... Jakiś PacMan?
Aha, i przypominam, że (prawie) każdy kod da się zoptymalizować...
Old 2009-02-24 21:13:37
@ptb — ja bym wolał TBXL w tej roli. Jest coś takiego: interpreter TBXL pod Win (TurboTari się nazywa), ale projekt nie został dokończony.
Kaz 2009-02-24 21:15:07
A ja pozwole sobie dalej byc "na nie", ale wcale nie z powodow o ktorych Sikor pisze. Bo akurat mnie zadne tam "uczciwe" porownania jezykow nie interesuja, a wrecz przeciwnie - uwazam, ze kazdy jezyk powinien pokazywac wszystkie nieuczciwe przewagi nad innymi, jesli je ma :)
Dla mnie liczy sie przede wszystkim holdowanie mojemu lenistwu czyli jezyk powinien byc wygodny w uzyciu, nie powinien miec rzucajacych sie w oczy bledow i miec sporo wsparcia w literaturze i przykladach.
Niestety, ale w swietle obiegowych, moze i nieprawdziwych, opinii Action nie jest ani wygodny ani pozbawiony powaznych bledow. Chcialbym wiec wiecej poczytac o Action wlasnie od strony praktycznej, na przykladach - jakie ma zalety, a jak obchodzic wady.
Adam Mowny 2009-02-24 21:31:44
A czy ktoś słyszał/używa języka QUICK i może chociaż krótko opisać ? A może zapisać powyższą pętlę testową i podać wynik?
http://cgi.ebay.pl/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MEWAX
:IT&item=230323826722
Yosh 2009-02-24 21:58:58
Zanim ustosunkuje się do innych wypowiedzi
- O językach nie mówi się, że są kompilowane, interpretowane, wywoływane na maszynie wirtualnej.... no chyba że jest to skrót myślowy do "istnieje interpreter dla danego języka", "istnieje kompilator dla danego języka" - więc Kaz jest dużo bliżej prawdy - liczy się także środowisko i wszystko wokół
Język Action!, język polski, język angielski i język C... to tylko rozpisane gramatyki (mniej lub bardziej formalne).. (żonę mam po filologi - więc jest to nasz 'wspólny' konik :P:P)
- Dobór języków wynika (fakt faktem, umkneło mi to w artykule - postaram się o tym pamiętać na przyszłość (o metodologi) dzieki sikor) z zastanych języków w konkursie "napisz se" (dlatego wnikałem w Advan Basic), chciałem także pokazać BrainFuck - ale tam porównanie liczby to jej odejmowanie co 1 - zbyt skrajny przypadek :)
I z tego, że na kolejnych przykładach pokaże, że dzięki rozsądnej bibliotece rozruchowej, nie jest on trudniejszy od TBX (jak ktoś nie robi nagminnie GOTO :P) a ma kilka fajnych przekmin :P
- %0 %1 %2 %3 w TB to głównie oszczędność miejsca.... liczba zmiennoprzecinkowa + stałoprzecinkowa -> rzut %0 na zmiennoprzecinkową przed sumą, przez interpreter różnica jest pomijalna 642 vs 643... ..
Chciałem głównie uczulić, na tą zmiennoprzecinkowość - cześć gier z "napisz se" zyskały by na miodności gdyby je puścić właśnie przez ten MMG
BASIC to Java tamtych czasów :) Imponuje mi... jest w nim TRAP, coś czego ani w C ani w Action! nie uświadczysz... dopiero C++ czy java ma podobne mechanizmy (throw/catch)
Czy sprawdzanie zakresów tablicy (!)
10 DIM A(1)
20 A(10) = 7
RUN
ERROR 9 DIM AT LINE 20
Miód! (też w javie jest :P) , czy LOCATE poza ekran.
Ale, jeżeli kod jest w miarę prosty da się go wklepać w Action! bez straty większej ilości włosów.
Action! tak jak C to jazda bez trzymanki - tablica + indeks za duży ? chcesz - masz :) łatwo wywalić swój kod, łatwo napisać sobie po edytorze. W BASIC, właściwie tylko używanie POKE jak popadnie może coś rozwalić...
I to jest też to o czym zapomniałem - Action! napewno nadaję się dla projektów które straszą przez POKE w Basicu :)
Nie bijcie :) chciałem dobrze.... :)
sikor 2009-02-24 22:29:16
@Yosh: Nie bijcie :) chciałem dobrze.... :)
Jak napisałem - ciekawy artykuł, ale napisany w taki sposób, że pokazuje tylko zalety Action! w stosunku do Basica na podstawie jednego przykładu. Jak napisałem - ciekawy język, ale - jak wspomniał KAZ - przydało by się więcej przykładów.
Języki kompilowane/interpretowane - jak najbardziej masz rację, skrót myślowy. Ale spotykany (i stosowany, co więcej) - w praktyce. Jedno ale - czasem konstrukcja języka wymusza pewne mechanizmy... I niestety tak jest z Basiciem. Jak napisałem - chętnie bym popatrzył na wyniki i w innych językch.
Pytanie za 10 punktów: jaki wynik będzie w LOGO...? Chyba trzeba odszukać gdzieś binarkę ;)
NIe ma się co obrażać... Czekamy na więcej artykułów, a nie tyklko obietnice o artkach... I opartych na przykładach. Każdy język ma swoje zalety i swoje wady. Co więcej: często jeden język jest wykorzystywany do pisania w innym. Przy wielu efektach w assemblerze do dem wykorzystywano... Atari Basic - mimo swej powolności pozwalał w łatwy sposób przeliczać pewne rzeczy bez potrzeby pisania skomplikowanego kodu w assemblerze... Pewnie (była) grupa Slight czy inne to poświadczą ;)
Na zakończenie - poprosimy o krótki kurs (a raczej długi kurs w krótkich odcinkach) z Action!. Koniecznie na przykłądach ;)
Monsoft 2009-02-24 22:45:07
Adam: http://www.classiccmp.org/dunfield/atarixl/atari8b.txt szukaj hasla "Quick (disk)"
golem14 2009-02-24 22:51:14
Upubliczniam, może kogoś zainspiruje:
http://wklej.org/hash/361a86bf35/
Scalak 2009-02-25 00:30:38
dla mnie szybkość zdecydowanie przemawia za Action! Assembler kusi, ale jakoś nie mogę znaleźć przystępnego kursu dla totalnych nemo. Aby wyrobić sobie zdanie na temat Action! prosiłbym o kilka nazw gier napisanych w tym języku które ukazują power Action! Z góry dziękuję.
larek 2009-02-25 09:08:16
Atarimania podaje: http://tiny.pl/bm87
Z tego, co wiem, to Problem Jasia i The Warsaw Tetris są napisane w Action!
Prawdę mówiąc, to jakoś mocy Action! w tych grach (no może oprócz Problemu Jasia) nie widać...
xxl 2009-02-25 09:11:10
muzyka do scorpions 2.0 napisana jest w action! i zlinkowana z gra.
Cosi 2009-02-25 09:37:09
@sikor: Odpowiedź na pytanie za 10 punktów: wynik jest koszmarny :/
Zrobiłem dwie wersje testu - rekurencyjną i nierekurencyjną.
Wersja pierwsza:
TO TEST
MAKE "A :A+1
IF (.EXAMINE 20)<100 [TEST]
END
TO START
MAKE "A 0
.DEPOSIT 20 0
TEST
PR :A
END
Wersja druga:
TO TEST2
MAKE "A 0
.DEPOSIT 20 0
REPEAT 5000 [MAKE "A :A+1 IF (.EXAMINE 20)>100 [STOP]]
END
Wyniki:
1) 47
2) 66
czyli tragiczne, ale...
c.d.n.
Cosi 2009-02-25 09:48:02
Porównywać pod tym względem Logo z cc65 czy Action! to tak jak z tym buldogiem z kawału, który wystartował w wyścigu chartów. Podobnie można by porównywać C i PHP :-)
Spośród języków na małe Atari Logo jest chyba językiem najwyższego poziomu - obok Lispu. Interpreter tworzy własną "maszynę wirtualną", prawdopodobnie z własnym stosem i z dynamicznym zarządzaniem pamięcią. Język zakłada rekurencyjne rozwiązywanie problemów i, między innymi dlatego, brak w nim klasycznych pętli typu DO ... WHILE. Takie podejście pozwala programować bardzo "wysoko", ale odbywa się to kosztem wydajności. I tak byłem zdziwiony, że procedura potrafi się rekurencyjne wywołać 10000 razy i dalej działa ;-)
Ograniczenia Atari Logo to są de facto ograniczenia Atari. Oczywiście można je obejść, grzebiąc nieco w bebechach - mam taki zamysł - ale w dalszym ciągu będzie to potwornie powolna maszyna wirtualna...
Scalak 2009-02-25 11:04:13
dzięki za te dwa tytuły a może są jakieś demka w Action! ???, bo w Tetrisie to mało tego powera... w Problemie Jasia już coś (aczkolwiek małego) się rusza, ten (chyba duch) pasek w czołówce nieco powera ujawnia.
Kaz 2009-02-25 11:34:42
Mozna szukac wsrod programow Husaka:
http://tiny.pl/bm6l
Ale w wywiadzie wyszlo, ze to Gizmo uzywal Action!:
http://tiny.pl/bm6n
wiec wypada sprawdzic te gry:
http://tiny.pl/bm6k
Yosh 2009-02-25 12:04:16
@Cosi: 10000 się wywoła bo prawdopodobnie LOGO implementuje optymalizacje wywołań ogonowych http://en.wikipedia.org/wiki/Tail_call
Tak myślę, ze raczej zrobię przykład 'dużo się dzieje', bo jak pokaże tekstowke to "W TBXL tez się da!" :). Chyba trochę to spłynie w pisanie gier jako takich - mam nadzieje, ze porady z pod lady przydadzą się także w innych językach ...
Kaz 2009-02-25 12:11:12
I bardzo dobry pomysl! Podejrzewam, ze pisanie gier jest najwiekszym wyzwaniem dla programisty, wiec jak przekonywac, to na przykladach z "grubej rury" :)
ptb 2009-02-25 12:20:59
To ja podaje kilka innych przykladow, ze Action! jest dość szybki:
http://www.cyberroach.com/analog/an16/action.htm
Z 16 numeru Analogu jest prosty przykład z sitem i pokazana
jest od razu translacja Action! na kod maszynowy. Jako bardziej
graficzny przykład to można wziąć
http://www.umich.edu/~archive/atari/8bit/Unverified/Cislib_b/pulse.act
W Analogu zadaje sie ze byly specjalne kolumny o Action!.
A tak podsumowując to Yosh dobra robota i wydaje mi się ze
jeśli ktoś myśli o programowaniu na Atari i nawet jeśli
zna assembler to Action! jest b. dobra alternatywa.
Nie mówiąc już jeśli zna tylko BASIC, a jeśli to kogoś
nie interesuje to zawsze moze po prostu nie czytac zamiast
pisać niepotrzebne komentarze :)
sikor 2009-02-25 12:44:09
@COSI: wynik i tak jest lepszy, niż się spodziewałem. Ale tak samo jest z porównaniem Basica i ACTION!, więc pytanie było czysto teoretyczne... W takim razie jeszcze test KP i DBC i będziemy mieli jakiś większy pogląd. Dzięki za test ;)
sikor 2009-02-25 12:46:24
A pro po kompilacji BASICA: kiedyś kompilowałem mój programik na real 16KB compo z atari Basica (nie pamiętam, czy MMG Basic Compilerem czy tym drugim, w każdym razie nie kompilatorem Turbo Basica) i nie dało się grać... Program był za szybki, więc fakt-faktem: czasem kompilacja duuużo zmienia ;)
Cosi 2009-02-25 13:12:50
@Yosh: Faktycznie, o tym nie pomyślałem. Jeżeli tak, to stos może być całkowicie odciążony i - teoretycznie - powinno się dać zrobić dowolne zagnieżdżenie.
Tak w ogóle to marzy mi się reverse-engineering Atari Logo, bo wielu rzeczy nie udało mi się rozgryźć "empirycznie", np. lokalizacji kodu interpretera - a to by była przydatna wiadomość przy pisaniu wstawek w kodzie maszynowym, bo Logo blokuje nadpisywanie swojego obszaru (całkiem rozsądnie zresztą). Można natomiast nadpisać DL - i to jest pole do popisu :) - tylko że w te klocki jestem za cienki niestety...
Cosi 2009-02-25 13:21:33
@sikor: DBC jest cholernie wolne - pamiętam, jak się przez krótki czas nim bawiłem i oczywiście zacząłem od programu liczącego silnie. Wydajność tragiczna, można powiedzieć, że DBC przynosi wstyd swoim braciom ;-P
W każdym razie bez porównania z cc65, ale to chyba oczywiste.
urborg 2009-02-26 12:04:30
Wpisałem ten programik w TB uruchomiłem i dziwna rzecz. Uzyskałem wynik zaledwie 499. Uruchamiałem na emulatorze. Nie wiem czemu mam o tyle niższy wynik.
Sam potem jednak zacząłem główkować i wymyśliłem że program da się przyśpieszyć poprzez wyłaczenie Antica na czas obliczeń.
10 POKE 559,0:POKE 20,0
20 A=0:WHILE PEEK(20)<100:A=A+1:WEND
30 POKE 559,250:? A
WYNIK: 729
potem pomyślałem o tym co pisał Sikor, czyli zamiana stałej na stałą TB, 1 na %1, 0 na %0 itd. W zasadzie zysk da jedynie zmiana 1 bo to się odbywa w pętli czyli jest wykonywane wielokrotnie.
10 POKE 559,0:POKE 20,%0
20 A=%0:WHILE PEEK(20)<100:A=A+%1:WEND
30 POKE 559,250:? A
No i proszę jest minimalna poprawa. WYNIK: 731
Ale da się jeszcze całość trochę uprościć. Można uprościć warunek zakończenia pętli zmieniając sposób zlicznia. Liczymy od 156, a po osiągnięciu 100 otrzymamy w komórce wartość 0. :)
10 POKE 559,0:POKE 20,156
20 A=0:WHILE PEEK(20):A=A+%1:WEND
30 POKE 559,250:? A
WYNIK 833
urborg 2009-02-26 12:08:01
No już wszystko jasne :) Miałem gorsze wyniki bo w emulatorze nie zauważyłem że mam włączone NTSC. Po włączeniu PAL wynik dla ostatniego programiku to 995.
Cosi 2009-02-26 13:32:56
A Logo po wyłączeniu ANTIC'a: 99 :D
Kaz 2009-02-26 14:42:20
Mnie liczenie akademickich przykladow w egipskich ciemnosciach nie przekonuje :).
sikor 2009-02-26 22:01:11
@Urborg: po kompilacji wersja bez % wskazuje mi 6876
wersja z %: 6856
Dziwne, czyli wersja krótsza działa nieco wolniej ;)
mono 2009-02-27 00:01:06
@Yosh: Te wywołania noszą też nazwę rekurencji prawostronnej.
Świetny artykuł! Kiedyś chciałem się nauczyć Action! i nawet zaopatrzyłem się w cartridge i książkę, ale zdarzyło się, że wcześniej poznałem assembler :) A do prostych przeliczeń BASIC najczęściej wystarczał, no i na chęciach się skończyło.
rudla 2010-03-01 22:43:35
In Atalan, following code counts to 145302.
[code]
timer@20:byte
count:0..2'000'000
inc:macro( x ) =
x = x + 1
"Counting 2 seconds..."
count = 0
timer = 0
until timer = 100
inc count
"Counted to [count]."
[/code]