Szybkość "Action!"... by Kaz 2009-02-27 23:44:12
...o której już trochę tu dyskutowaliśmy, od dawna była przedmiotem
dociekań oraz sporów z wyznawcami programowania w asemblerze oraz
języków interpretowanych. Pozwoliłem sobie zestawić jedną z takich
polemik, która zaczęła się artykułem w "Bajtku", a potem przeniosła
się na łamy "Atari Magazynu". Zamieszani w nią byli Wojciech
Zientara, Konrad "Draco030" Kokoszkiewicz oraz Tomasz
"TDC" Cieślewicz.
Wszystko zaczęło się w "Bajtku" numer 4 z 1988 roku, gdzie Wojciech Zientara przekonywał do używania "Action!", porównując prędkości wykonywania programów z innymi popularnymi językami:
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
Po kilku latach polemikę z tezą o nadzwyczajnej szybkości "Action!" podjął Konrad Kokoszkiewicz w "Atari Magazyn" numer 1/2 z 1994 roku, kończąc cykl artykułów o grafice w języku maszynowym testem porównawczym prędkości wykonywania procedur. Tutaj pomijam sporą część tego artykułu, zainteresowanych odsyłam po nie do "AM", pozostawiłem tylke te fragmenty, które bezpośrednio odnosiły się do porównania z "Action!":
(...)
Na koniec w numerze 5 z 1994 roku polemikę podjął Tomasz Cieślewicz, starając się oprócz niewątpliwych zalet asemblera i wad "Action!" pokazać też zalety tego ostatniego i niedogodności posługiwania się językiem maszynowym:
Mamy więc materiał do przemyśleń i porównać i do podjęcia decyzji, czy pakować się w ten dziwny język C-podobny...
Wszystko zaczęło się w "Bajtku" numer 4 z 1988 roku, gdzie Wojciech Zientara przekonywał do używania "Action!", porównując prędkości wykonywania programów z innymi popularnymi językami:
Po kilku latach polemikę z tezą o nadzwyczajnej szybkości "Action!" podjął Konrad Kokoszkiewicz w "Atari Magazyn" numer 1/2 z 1994 roku, kończąc cykl artykułów o grafice w języku maszynowym testem porównawczym prędkości wykonywania procedur. Tutaj pomijam sporą część tego artykułu, zainteresowanych odsyłam po nie do "AM", pozostawiłem tylke te fragmenty, które bezpośrednio odnosiły się do porównania z "Action!":
(...)
Na koniec w numerze 5 z 1994 roku polemikę podjął Tomasz Cieślewicz, starając się oprócz niewątpliwych zalet asemblera i wad "Action!" pokazać też zalety tego ostatniego i niedogodności posługiwania się językiem maszynowym:
Mamy więc materiał do przemyśleń i porównać i do podjęcia decyzji, czy pakować się w ten dziwny język C-podobny...
Yosh 2009-02-28 00:15:11
Korzystając z okazji - dziękuje wszystkim którzy przeczytali moje wypoćki a zwłaszcza komentującym. Jest mi bardzo miło, że przez kilka dni mogłem żyć tym co kocham :) czyli językami programowania :>
Cieszy mnie, że artykuły powyżej nie oddają 'piękna wyrazu' :) to pewnie rzecz gustu... no ale obaczycie :)
tdc 2009-02-28 00:24:44
Muszę napisać tu sprostowanie do tego tekstu (bo wreszcie mam okazję): Ten mój artykuł, niestety jest tym czego się najbardziej w życiu wstydzę, gdyż opublikowano tekst, pod którym bym się nigdy nie podpisał, a jednak trafił do druku i niestety jest pod nim moje nazwisko... :(
Zacznę od początku, moja rola w Atari Magazynie była właśnie taka, że zajmowałem się pośrednio programowaniem (ogólnie pojętym), ale przede wszystkim miałem tam promować Action! jako jedyna osoba znająca temat w redakcji itp. Powstało wiele tekstów, które opisywały różne ciekawostki związane z tym językiem (niektóre fakty do dziś chyba nie zostały nigdzie opublikowane), ale niewiele z nich faktycznie trafiło do druku (tylko te najmniejsze objętościowo). Część z tych materiałów ostatnio odnalazłem i niebawem będą opublikowane, w każdym razie po latach ja już nawet zapomniałem i ich istnieniu!
W praktyce okazało się, że pierwszy opublikowany taki bardziej interesujący tekst o Action! to właśnie ten. Miał on na celu nie tyle polemikę (co zresztą było tematem przewodnim tego numeru AM), lecz właśnie zainteresowanie czytelników tym językiem oraz ukazanie go od zupełnie innej strony (niż w dotychczasowych publikacjach).
Niestety, artykuł ten był dość długi i sekretarz redakcji (nie bardzo znający się na temacie (bo był głównie od ST)) tekst skrócił no i niestety w niektórych miejscach zmienił jego sens (co mnie najbardziej boli). Nie mogę mu mieć tego za złe bo pewnie robił coś szybko przed drukiem i na dodatek nie wiele z tego rozumiał.
Problem w tym, że stratą dla czytelników było wiele ciekawych faktów, które z tego tekstu zostały usunięte. Przykładowo pamiętam, że miały się pojawić informacje odnośnie tego o ile instrukcja POKE jest szybsza w Action! od tej samej w Atari Basicu. Niestety ta i inne informacje zostały usunięte. Myślę, że ów sekretarz uznał je za podejrzane (były zbyt dobre), a skoro się nie znał to chciał po prostu chronić renomę pisma.
Drugą sprawą jest podsumowanie – które mnie najbardziej boli, gdyż zmieniony został całkowicie sens tego tekstu (w oryginale był chyba dłuższy i zawierał inną treść). Ja tego tekstu nie miałem okazji oglądać przed drukiem, a nawet nie wiedziałem, że ten tekst trafił do nowego numeru. Gdy się o tym przekonałem mając w ręce nowy numer to było już za późno (a KMK był na mnie zły – choć nie wiem dlaczego (!) bo przecież współpracowaliśmy ze sobą od lat; zarzekał się że w Basicu coś tam można zrobić lepiej).
W końcu pod takim podsumowaniem bym się nigdy nie podpisał... ale wyszło jak wyszło... Było jeszcze kilka innych treści, które zostały z tekstu usunięte, ale to są najistotniejsze. Sekretarz redakcji zrobił mi wielką krzywdę, ale nie mam mu tego za złe – zakładam, że nie zrobił tego umyślnie.
Zresztą mam zgrane te dyskietki i można opublikować ten tekst w takiej formie w jakiej trafił do redakcji, można będzie wtedy sobie porównać czym się te teksty różnią.
Kaz 2009-02-28 00:38:27
Tomku, wiele tekstow mozna swego czasu bylo napisac lepiej, ale pamietajmy, ze to bylo lata temu! Bez powszechnego internetu, szybkiego dostepu do zrodel, etc. Jezeli chodzi o redakcje tekstu bez zgody czy wiedzy autora, to pamietam, ze to byla czasem plaga tych wszystkich amatorskich gazet. Czaem tekst "poprawiali" ludzie, ktorzy sie nie znali na temacie poruszanym w artykule. O ile pamietam, mnie tez jakies przeinaczenia moich artkow spotkaly w "STEfanie" :).
A jezeli chodzi o powtorke tekstu, ale w pelnej postaci - jestem jak najbardziej za. Z tego co wiem wiekszosc pism atarowskich upadala "nagle" i zostawalo po nich wiele tekstow do numerow, ktore sie juz nigdy potem nie ukazaly. To tez moze byc kopalnia ciekawych artykulow. Na atarionline.pl zawsze dla takcih historycznych artefaktow jest miejsce!
dEnter 2009-02-28 09:20:14
Ależ niezaprzeczalny urok ma ten wpis! Dzięki!
A przy okazji... Kaz, czy nie pora aby zrobić redesign strony? Takie "blogowanie" sporych artów nie jest przyjazne dla oka. Może dodać także trochę klimatu tych pięknych i jedynych w swoim rodzaju pism Atarowskich? Wiem, to kosztuje sporo czasu, jednak przy wysokiej stronie merytorycznej, warto teraz pomyśleć o formie.
Co do samego Action! to wciągnąłem go na listę języków do poznania. Świetny lobbing :-)
marok 2009-02-28 12:49:37
Przepraszam, ale zastanawia mnie w jaki sposób mierzono długość działania procedur w poszczególnych językach programowania uzyskując tak dokładne wyniki (co do cykla procesora). Pewnego rozwiązania się domyślam, ale pozostaje wątpliwość czy zastosowana metoda jest z tą moją hipotezą torżsama.
Odpowiedź znają na pewno (o ile jeszcze to pamiętają) autorzy dwóch pierwszych artykułów (pan Zientara i KMK). Możliwe, że metoda mierzenia długości trwania procedur została przez pana Zientarę gdzieś opisana w jego publikacjach, ale o tym nic mi nie wiadomo.
Dla jasności sprawy może swoje hipotetyczne rozwiązanie tego zadania pokrótce opiszę. Na wstępie zlicza się liczbę cykli w ramce specjalnym programem (będzie nam i później potrzebny). Specyfika jego polega na tym, że przewidziany on jest do wykonywania od początku ramki, a początek ma w pętli (nie jest to wszak warunek niezbędny), której nie opuszcza już do końca, oraz że mierzy on liczbę przebiegów swoich zrealizowanych pętli do momentu wywołania przerwania (czyli do swojego końca). Z momentem przerwania w dodatkowym kodzie obsługującym przerwanie stwierdza się zapisany na stosie adres powrotny do wewnątrz pętli zliczającej cykle. W ten sposób uzyskuje się precyzyjniejszą wartość szukanej liczby cykli procesora dostępnych dla programu w ramce (liczymy je na podstawie uzyskanego wyniku pełnych przebiegów pętli oraz długości samej pętli w ramkach, jak i tej części pętli, która wykonała się tylko w części). Założenie jednak jest takie, że procedura przerwania VBLANK (przerwanie ramki) realizuje się zawsze w tej samej liczbie cykli (czego nie jestem pewien, iż oryginalna, systemowa zapewnia, przy dodajmy włączonym znaczniku I procesora blokującym przerwania maskowalne i zapewniającym przy okazji krótszy przebieg samej systemowej procedury obsługi przerwania VBLANK) oraz że sam mierzony program wykonuje się zawsze w identycznej liczbie cykli (uwaga ogólna, bo w przypadku tych konkretnych programów wydaje się, że ten warunek jest spełniany).
Mimo przyjęcia iż warunek tego założenia zostanie dotrzymany, uzyskany szacunek liczby wolnych cykli w ramce będzie i tak "zaokrąglony" do kilku cykli, bowiem instrukcja procesora poprzedzająca tą wskazaną adresem na stosie przerwania pętli jest z zasady kilkucyklowa, a więc przerwanie może się zgłosić w każdym cyklu w trakcie jej wykonywania.
Aby to nieprecyzyjne liczenie zamienić na w miarę pewną liczbę wydaje mi się możliwe jest zastosowanie pewnych opóźnień liczonych w pojedyńczych cyklach poprzez dodatkowe instrukcje wykonywane tylko jeden raz, które poprzedzą zasadniczą pętlę zliczającą. Dopiero wówczas poprzez porównanie wyników w kilku wersjach (dla różnych opóźnień) możliwe jest ustalenie szukanej precyzyjnej wartości. To jednak tylko teoria, nie wiem czy słuszna.
Gdy więc uzyskamy liczbę wolnych cykli na ramkę dostępną programowi (tą liczbę na pewno możemy odszukać w różnych opracowaniach), możemy podjąć się mierzenia czasu konkretnego programu będącego jakąś procedurą. Teraz więc odpalamy sam program od początku ramki zapamiętując wcześniej wskazania zegara systemowego (który aktualizuje się co przerwanie VBLANK), a po nim umieszczamy ten sam opisany na wstępie program liczący cykle w pętli. Umieszczamy go po to, aby obliczyć liczbę cykli do wypełnienia pełnej ramki od chwili skończenia wykonywania się mierzonego programu. Po tej operacji możemy już starać się szacować liczbę cykli zajętych procesorowi na wykonanie programu. Od pełnej liczby cykli wolnych w ramce wymnożonej przez liczbę ramek, których działanie programu obejmowało, odjąc należy tą obliczoną liczbę cykli, która pozostała z ostatniej nie w pełni zajętej przez działanie programu ramki.
Kaz 2009-02-28 13:59:08
dEnter - chetnie przyjme kazda darmowa pomoc przy "redesignie strony". Maile z deklaracja konkretnej pomocy wiadomo gdzie slac - na moj email.
dEnter 2009-03-01 22:00:16
Kaz - niestety w tej sferze jestem wyłącznie konsumentem. "Zdolności", a dokładnie ich brak, nie rokują nadziei.
marok 2009-03-02 10:15:10
W poprzednim wpisie pod tematem wypowiedziałem się zupełnie nie do rzeczy. Przepraszam za brak wystarczającej staranności w czytaniu ze zrozumieniem. Tłumaczyć się mogę tylko tym, że sformułowanie "liczba taktów" oraz stosunkowo duże wielkości liczb umieszczone w spłupku pod nim, przywiodły mi na myśl proste skojarzenie z cyklami procesora. Dodatkowo temat liczenia cykli procesora niedawno trochę przemyśliwałem. A wystarczyło tylko trochę uważniej spojrzeć w zamieszczone wydruki listingów omawianych programów testowych, albo lepiej nieco tylko logiczniej pomyśleć, a cała rzecz z nietrafionym komentarzem nie miałaby miejsca. Jeszcze raz przepraszam, postaram się na przyszłość staranniej przechodzić z czytania do komentowania poszczególnych notek na stronie.
xxl 2009-03-02 11:12:31
te artki to maja raczej wartosc historyczna... jeszcze najbardziej rzeczowy byl pierwszy, programy byly napisane wlasiwie tak samo... no jakies pojecie o szybkosci dawaly. w drugim artku zaczela sie optymalizacja ale tylko basica i assemblera i porownywanie do nieoptymalizowanego action, i jeszcze stwierdzenie ze action jest be bo jakas gra napisana w action sie komus nie podoba :-) heh no i trzeci artek z optymalizacja action ale wersja hardcore:-) nie... to byla pyskowka a nie rzeczowe artykuly. czekam na prawdziwe artki o Action!
jell 2009-03-02 15:05:29
niestety ale pan Wojtek sie tylko samodzielnie osmieszyl piszac o "kompilowanym" deep blue c, podczas gdy to srodowisko interpretuje kod posredni (podobnie jak atari basic stokenizowany kod) a nie natywny kod 6502.
ze tez nie wspomne o konstrukcjach tam uzytych (sm+j, podczas gdy mozna bylo i zmienna tymczasowa zainicjowac wartoscia sm przed petla, po czym inkrementowac ja rownolegle do inkrementacji j ;) :P
jell 2009-03-02 15:07:29
btw. tekst pana Wojtka tylko potwierdza stara teze, ze dobrze spreparowany test, potrafi potwierdzic dowolna byzydure ;)
Kaz 2009-03-03 04:23:00
Jellonek - nie wiem, jaka teze Zientary atakujesz jako bzdure? Napisal, ze Action! jest najszybszym z porownywanych jezykow, w niektorych przypadkach rownie szybki co maszynowy. O to chodzi? Czy nie jest to prawda?
Druga sprawa - Deep Blue C ma kompilator:
http://www.atariarchives.org/APX/showdocs.php?cat=20166
wiec na chlopski rozum da sie skompilowac program w tym jezyku :). Nigdzie Zientara nie pisal o "kompilowanym Deep Blue C", a za to napisal, ze z jezykow kompilowanych wybral C (ogolnie jezyk C) do testow.
Kaz 2009-03-03 04:25:04
Jak atakowac Zientare to za konkretne bledy. Tak mi sie przypomina, ze Cosi pisal cos swego czasu o masie bledow w opisie Deep Blue C w ksiazce Zientary "Jezyki Atari XL/XE cz.2". Cosi - moglbys cos wiecej na ten temat?
jell 2009-03-03 09:44:47
kaz: spod twojego linka: "THE COMPILER
Once entered, the C program must be translated into a special code (called
object code) before it can be executed. The program that does this translation
is called the Deep Blue C Compiler."
tak jak juz pisalem - deep blue c tworzy kod posredni, ktory po uruchomieniu jest interpretowany DOKLADNIE jak basicowy kod stokenizowany.
generalnie zientara za dobrym koderem nie byl. czczony jest u nas, bo... byl pierwszym ktory cos powaznego druknal (znaczy sie komentarze do zrodel os, dosa, basica itp.)
Kaz 2009-03-03 12:30:06
A to sie zgadza, ze Zientara byl uwazany "za pierwszego Atarowca Polski" ze wzgledu na popularnosc klanu Atari w Bajtku i paru ksiazek SOETO. I pewnie masz racje, ze koderem byl mocno srednim, a i okazalo sie po latach, ze sentyment do Atari niewielki.
Mimo wszystko moim zdaniem Zientarze szacunek sie nalezy, bo nikt inny tyle nie nadrukowal i nie napisal o Atari - w owych czasach, czasach ledwie czytelnych kserokopii i fatalnie tlumaczonych pirackich opisow gier, bylo to jak woda na pustyni dla spragnionego. :)
Co do kompilatora - to wyjasnij mi na czym polega problem: program zostaje skompilowany czy po prostu nie powinien sie nazywac kompilatorem? :)
Kaz 2009-03-04 01:23:49
Tak przy okazji pytania, ktore na forum zadal adiblol o CC65, pojawil sie tez link do strony Cas-a (Carstena Strotmanna). Zapomnialem wczesniej o tym, ale tam sa fajne przyklady programow w Action! (oczywiscie nie tylko):
http://atariwiki.strotmann.de/xwiki/bin/view/Code/ACTION
jell 2009-03-04 19:38:11
jest kompilowany do kodu posredniego (tak, jak wpisujesz program w basicu, po wprowadzeniu kazdej linii, jest ona "tokenizowana" i w tej postaci zapisywana w pamieci, do czasu wykonania jej, po czym te tokeny sa interpretowane)
czyli to innego rodzaju kompilacja, niz masz w action, czy kompilatorze turbo beja, gdzie do natywnego kodu procesora kompilowany jest program.
to, ze panu Wojtkowi szacun sie nalezy - nie przecze. zrobil poprostu wiele.
co do Carstena - sporo fajnych rzeczy ma od dawna (w tym jedno z lepszych miejsc z kodem forthowym pod malucha). goraco polecam przyjrzec sie calosci jego wiki...
tdc 2009-03-09 03:39:59
xxl: Nie oceniaj tamtej sytuacji tak pochopnie, bo ja z KMK współpracowałem od kilku lat bez najmniejszych problemów, odwiedzaliśmy się w domach, robiliśmy różne testy oraz wiele dyskutowaliśmy na przeróżne tematy. Dlatego skoro nie było żadnych problemów to ja chcąc robić „pyskówkę” musiałbym być jakiś dobrze rąbnięty.
xxl 2009-03-10 08:51:10
obydwaj 'naciagaliscie fakty' ;-) nie mowie ze to zle, gdyby dluzej pociagnac ten cykl to mozna by sie bylo czegos nauczyc, w ogole idea dobrego i zlego gliny przy pisaniu arkow na zmiane nie jest wcale taka glupia ;-) z przyjemnoscia bym poczytal, pod warunkiem ze to do czegos prowadzi, te dwa artki wyzej nie prowadzily - moze wlasnie dlatego ze byly tylko dwa? nie wiem. tak czy owak, o Action! chcialbym jeszcze poczytac.
Kaz 2009-03-10 10:20:37
xxl - na pewno poczytasz wiecej, wierz mi :)
tdc 2009-03-13 09:56:04
xxl: Właśnie zwróciłeś tu uwagę na istotny temat, ja właśnie chciałem napisać tekst, jako osoba wychowana w duchu "Sondy". Czyli zdrowa polemika (bez zbędnych emocji), która do czegoś prowadzi. Jednak nie udało mi się to (nie do końca z mojej winy), a inna sprawa, że w końcu wtedy smarkacz byłem i pewnie nie miałem szans się równać z polemiką jak w Sondzie!
Następne części miały być i kto wie ile by ich powstało. W każdym razie właśnie wtedy pismo zostało zamknięte i do dzisiejszego dnia chyba nic się w tej materii nie działo...
danos 2011-02-24 08:49:16
Kaz:
Wiem, że wątek jest już dość stary, ale chciałbym dorzucić moje 3 grosze o Deep Blue C.
Informacje o DBC są w Atariki: http://atariki.krap.pl/index.php/Deep_Blue_C. Z kolei Atari 8-bit Faq stanowi, że Deep Blue C kompiluje do kodu Intel 8080, który jest następnie wykonywany przez interpretator/maszynę wirtualną 8080 [http://www.faqs.org/faqs/atari-8-bit/faq/]. Czyli technika podobna do dzisiejszej JAVA.
We własnym teście praktycznym byłem rozczarowany szybkością tak "skompilowanych" programów w C - porównywałem do Atari Basica i Kyan Pascala.
Korzystając z okazji - dziękuje wszystkim którzy przeczytali moje wypoćki a zwłaszcza komentującym. Jest mi bardzo miło, że przez kilka dni mogłem żyć tym co kocham :) czyli językami programowania :>
Cieszy mnie, że artykuły powyżej nie oddają 'piękna wyrazu' :) to pewnie rzecz gustu... no ale obaczycie :)
tdc 2009-02-28 00:24:44
Muszę napisać tu sprostowanie do tego tekstu (bo wreszcie mam okazję): Ten mój artykuł, niestety jest tym czego się najbardziej w życiu wstydzę, gdyż opublikowano tekst, pod którym bym się nigdy nie podpisał, a jednak trafił do druku i niestety jest pod nim moje nazwisko... :(
Zacznę od początku, moja rola w Atari Magazynie była właśnie taka, że zajmowałem się pośrednio programowaniem (ogólnie pojętym), ale przede wszystkim miałem tam promować Action! jako jedyna osoba znająca temat w redakcji itp. Powstało wiele tekstów, które opisywały różne ciekawostki związane z tym językiem (niektóre fakty do dziś chyba nie zostały nigdzie opublikowane), ale niewiele z nich faktycznie trafiło do druku (tylko te najmniejsze objętościowo). Część z tych materiałów ostatnio odnalazłem i niebawem będą opublikowane, w każdym razie po latach ja już nawet zapomniałem i ich istnieniu!
W praktyce okazało się, że pierwszy opublikowany taki bardziej interesujący tekst o Action! to właśnie ten. Miał on na celu nie tyle polemikę (co zresztą było tematem przewodnim tego numeru AM), lecz właśnie zainteresowanie czytelników tym językiem oraz ukazanie go od zupełnie innej strony (niż w dotychczasowych publikacjach).
Niestety, artykuł ten był dość długi i sekretarz redakcji (nie bardzo znający się na temacie (bo był głównie od ST)) tekst skrócił no i niestety w niektórych miejscach zmienił jego sens (co mnie najbardziej boli). Nie mogę mu mieć tego za złe bo pewnie robił coś szybko przed drukiem i na dodatek nie wiele z tego rozumiał.
Problem w tym, że stratą dla czytelników było wiele ciekawych faktów, które z tego tekstu zostały usunięte. Przykładowo pamiętam, że miały się pojawić informacje odnośnie tego o ile instrukcja POKE jest szybsza w Action! od tej samej w Atari Basicu. Niestety ta i inne informacje zostały usunięte. Myślę, że ów sekretarz uznał je za podejrzane (były zbyt dobre), a skoro się nie znał to chciał po prostu chronić renomę pisma.
Drugą sprawą jest podsumowanie – które mnie najbardziej boli, gdyż zmieniony został całkowicie sens tego tekstu (w oryginale był chyba dłuższy i zawierał inną treść). Ja tego tekstu nie miałem okazji oglądać przed drukiem, a nawet nie wiedziałem, że ten tekst trafił do nowego numeru. Gdy się o tym przekonałem mając w ręce nowy numer to było już za późno (a KMK był na mnie zły – choć nie wiem dlaczego (!) bo przecież współpracowaliśmy ze sobą od lat; zarzekał się że w Basicu coś tam można zrobić lepiej).
W końcu pod takim podsumowaniem bym się nigdy nie podpisał... ale wyszło jak wyszło... Było jeszcze kilka innych treści, które zostały z tekstu usunięte, ale to są najistotniejsze. Sekretarz redakcji zrobił mi wielką krzywdę, ale nie mam mu tego za złe – zakładam, że nie zrobił tego umyślnie.
Zresztą mam zgrane te dyskietki i można opublikować ten tekst w takiej formie w jakiej trafił do redakcji, można będzie wtedy sobie porównać czym się te teksty różnią.
Kaz 2009-02-28 00:38:27
Tomku, wiele tekstow mozna swego czasu bylo napisac lepiej, ale pamietajmy, ze to bylo lata temu! Bez powszechnego internetu, szybkiego dostepu do zrodel, etc. Jezeli chodzi o redakcje tekstu bez zgody czy wiedzy autora, to pamietam, ze to byla czasem plaga tych wszystkich amatorskich gazet. Czaem tekst "poprawiali" ludzie, ktorzy sie nie znali na temacie poruszanym w artykule. O ile pamietam, mnie tez jakies przeinaczenia moich artkow spotkaly w "STEfanie" :).
A jezeli chodzi o powtorke tekstu, ale w pelnej postaci - jestem jak najbardziej za. Z tego co wiem wiekszosc pism atarowskich upadala "nagle" i zostawalo po nich wiele tekstow do numerow, ktore sie juz nigdy potem nie ukazaly. To tez moze byc kopalnia ciekawych artykulow. Na atarionline.pl zawsze dla takcih historycznych artefaktow jest miejsce!
dEnter 2009-02-28 09:20:14
Ależ niezaprzeczalny urok ma ten wpis! Dzięki!
A przy okazji... Kaz, czy nie pora aby zrobić redesign strony? Takie "blogowanie" sporych artów nie jest przyjazne dla oka. Może dodać także trochę klimatu tych pięknych i jedynych w swoim rodzaju pism Atarowskich? Wiem, to kosztuje sporo czasu, jednak przy wysokiej stronie merytorycznej, warto teraz pomyśleć o formie.
Co do samego Action! to wciągnąłem go na listę języków do poznania. Świetny lobbing :-)
marok 2009-02-28 12:49:37
Przepraszam, ale zastanawia mnie w jaki sposób mierzono długość działania procedur w poszczególnych językach programowania uzyskując tak dokładne wyniki (co do cykla procesora). Pewnego rozwiązania się domyślam, ale pozostaje wątpliwość czy zastosowana metoda jest z tą moją hipotezą torżsama.
Odpowiedź znają na pewno (o ile jeszcze to pamiętają) autorzy dwóch pierwszych artykułów (pan Zientara i KMK). Możliwe, że metoda mierzenia długości trwania procedur została przez pana Zientarę gdzieś opisana w jego publikacjach, ale o tym nic mi nie wiadomo.
Dla jasności sprawy może swoje hipotetyczne rozwiązanie tego zadania pokrótce opiszę. Na wstępie zlicza się liczbę cykli w ramce specjalnym programem (będzie nam i później potrzebny). Specyfika jego polega na tym, że przewidziany on jest do wykonywania od początku ramki, a początek ma w pętli (nie jest to wszak warunek niezbędny), której nie opuszcza już do końca, oraz że mierzy on liczbę przebiegów swoich zrealizowanych pętli do momentu wywołania przerwania (czyli do swojego końca). Z momentem przerwania w dodatkowym kodzie obsługującym przerwanie stwierdza się zapisany na stosie adres powrotny do wewnątrz pętli zliczającej cykle. W ten sposób uzyskuje się precyzyjniejszą wartość szukanej liczby cykli procesora dostępnych dla programu w ramce (liczymy je na podstawie uzyskanego wyniku pełnych przebiegów pętli oraz długości samej pętli w ramkach, jak i tej części pętli, która wykonała się tylko w części). Założenie jednak jest takie, że procedura przerwania VBLANK (przerwanie ramki) realizuje się zawsze w tej samej liczbie cykli (czego nie jestem pewien, iż oryginalna, systemowa zapewnia, przy dodajmy włączonym znaczniku I procesora blokującym przerwania maskowalne i zapewniającym przy okazji krótszy przebieg samej systemowej procedury obsługi przerwania VBLANK) oraz że sam mierzony program wykonuje się zawsze w identycznej liczbie cykli (uwaga ogólna, bo w przypadku tych konkretnych programów wydaje się, że ten warunek jest spełniany).
Mimo przyjęcia iż warunek tego założenia zostanie dotrzymany, uzyskany szacunek liczby wolnych cykli w ramce będzie i tak "zaokrąglony" do kilku cykli, bowiem instrukcja procesora poprzedzająca tą wskazaną adresem na stosie przerwania pętli jest z zasady kilkucyklowa, a więc przerwanie może się zgłosić w każdym cyklu w trakcie jej wykonywania.
Aby to nieprecyzyjne liczenie zamienić na w miarę pewną liczbę wydaje mi się możliwe jest zastosowanie pewnych opóźnień liczonych w pojedyńczych cyklach poprzez dodatkowe instrukcje wykonywane tylko jeden raz, które poprzedzą zasadniczą pętlę zliczającą. Dopiero wówczas poprzez porównanie wyników w kilku wersjach (dla różnych opóźnień) możliwe jest ustalenie szukanej precyzyjnej wartości. To jednak tylko teoria, nie wiem czy słuszna.
Gdy więc uzyskamy liczbę wolnych cykli na ramkę dostępną programowi (tą liczbę na pewno możemy odszukać w różnych opracowaniach), możemy podjąć się mierzenia czasu konkretnego programu będącego jakąś procedurą. Teraz więc odpalamy sam program od początku ramki zapamiętując wcześniej wskazania zegara systemowego (który aktualizuje się co przerwanie VBLANK), a po nim umieszczamy ten sam opisany na wstępie program liczący cykle w pętli. Umieszczamy go po to, aby obliczyć liczbę cykli do wypełnienia pełnej ramki od chwili skończenia wykonywania się mierzonego programu. Po tej operacji możemy już starać się szacować liczbę cykli zajętych procesorowi na wykonanie programu. Od pełnej liczby cykli wolnych w ramce wymnożonej przez liczbę ramek, których działanie programu obejmowało, odjąc należy tą obliczoną liczbę cykli, która pozostała z ostatniej nie w pełni zajętej przez działanie programu ramki.
Kaz 2009-02-28 13:59:08
dEnter - chetnie przyjme kazda darmowa pomoc przy "redesignie strony". Maile z deklaracja konkretnej pomocy wiadomo gdzie slac - na moj email.
dEnter 2009-03-01 22:00:16
Kaz - niestety w tej sferze jestem wyłącznie konsumentem. "Zdolności", a dokładnie ich brak, nie rokują nadziei.
marok 2009-03-02 10:15:10
W poprzednim wpisie pod tematem wypowiedziałem się zupełnie nie do rzeczy. Przepraszam za brak wystarczającej staranności w czytaniu ze zrozumieniem. Tłumaczyć się mogę tylko tym, że sformułowanie "liczba taktów" oraz stosunkowo duże wielkości liczb umieszczone w spłupku pod nim, przywiodły mi na myśl proste skojarzenie z cyklami procesora. Dodatkowo temat liczenia cykli procesora niedawno trochę przemyśliwałem. A wystarczyło tylko trochę uważniej spojrzeć w zamieszczone wydruki listingów omawianych programów testowych, albo lepiej nieco tylko logiczniej pomyśleć, a cała rzecz z nietrafionym komentarzem nie miałaby miejsca. Jeszcze raz przepraszam, postaram się na przyszłość staranniej przechodzić z czytania do komentowania poszczególnych notek na stronie.
xxl 2009-03-02 11:12:31
te artki to maja raczej wartosc historyczna... jeszcze najbardziej rzeczowy byl pierwszy, programy byly napisane wlasiwie tak samo... no jakies pojecie o szybkosci dawaly. w drugim artku zaczela sie optymalizacja ale tylko basica i assemblera i porownywanie do nieoptymalizowanego action, i jeszcze stwierdzenie ze action jest be bo jakas gra napisana w action sie komus nie podoba :-) heh no i trzeci artek z optymalizacja action ale wersja hardcore:-) nie... to byla pyskowka a nie rzeczowe artykuly. czekam na prawdziwe artki o Action!
jell 2009-03-02 15:05:29
niestety ale pan Wojtek sie tylko samodzielnie osmieszyl piszac o "kompilowanym" deep blue c, podczas gdy to srodowisko interpretuje kod posredni (podobnie jak atari basic stokenizowany kod) a nie natywny kod 6502.
ze tez nie wspomne o konstrukcjach tam uzytych (sm+j, podczas gdy mozna bylo i zmienna tymczasowa zainicjowac wartoscia sm przed petla, po czym inkrementowac ja rownolegle do inkrementacji j ;) :P
jell 2009-03-02 15:07:29
btw. tekst pana Wojtka tylko potwierdza stara teze, ze dobrze spreparowany test, potrafi potwierdzic dowolna byzydure ;)
Kaz 2009-03-03 04:23:00
Jellonek - nie wiem, jaka teze Zientary atakujesz jako bzdure? Napisal, ze Action! jest najszybszym z porownywanych jezykow, w niektorych przypadkach rownie szybki co maszynowy. O to chodzi? Czy nie jest to prawda?
Druga sprawa - Deep Blue C ma kompilator:
http://www.atariarchives.org/APX/showdocs.php?cat=20166
wiec na chlopski rozum da sie skompilowac program w tym jezyku :). Nigdzie Zientara nie pisal o "kompilowanym Deep Blue C", a za to napisal, ze z jezykow kompilowanych wybral C (ogolnie jezyk C) do testow.
Kaz 2009-03-03 04:25:04
Jak atakowac Zientare to za konkretne bledy. Tak mi sie przypomina, ze Cosi pisal cos swego czasu o masie bledow w opisie Deep Blue C w ksiazce Zientary "Jezyki Atari XL/XE cz.2". Cosi - moglbys cos wiecej na ten temat?
jell 2009-03-03 09:44:47
kaz: spod twojego linka: "THE COMPILER
Once entered, the C program must be translated into a special code (called
object code) before it can be executed. The program that does this translation
is called the Deep Blue C Compiler."
tak jak juz pisalem - deep blue c tworzy kod posredni, ktory po uruchomieniu jest interpretowany DOKLADNIE jak basicowy kod stokenizowany.
generalnie zientara za dobrym koderem nie byl. czczony jest u nas, bo... byl pierwszym ktory cos powaznego druknal (znaczy sie komentarze do zrodel os, dosa, basica itp.)
Kaz 2009-03-03 12:30:06
A to sie zgadza, ze Zientara byl uwazany "za pierwszego Atarowca Polski" ze wzgledu na popularnosc klanu Atari w Bajtku i paru ksiazek SOETO. I pewnie masz racje, ze koderem byl mocno srednim, a i okazalo sie po latach, ze sentyment do Atari niewielki.
Mimo wszystko moim zdaniem Zientarze szacunek sie nalezy, bo nikt inny tyle nie nadrukowal i nie napisal o Atari - w owych czasach, czasach ledwie czytelnych kserokopii i fatalnie tlumaczonych pirackich opisow gier, bylo to jak woda na pustyni dla spragnionego. :)
Co do kompilatora - to wyjasnij mi na czym polega problem: program zostaje skompilowany czy po prostu nie powinien sie nazywac kompilatorem? :)
Kaz 2009-03-04 01:23:49
Tak przy okazji pytania, ktore na forum zadal adiblol o CC65, pojawil sie tez link do strony Cas-a (Carstena Strotmanna). Zapomnialem wczesniej o tym, ale tam sa fajne przyklady programow w Action! (oczywiscie nie tylko):
http://atariwiki.strotmann.de/xwiki/bin/view/Code/ACTION
jell 2009-03-04 19:38:11
jest kompilowany do kodu posredniego (tak, jak wpisujesz program w basicu, po wprowadzeniu kazdej linii, jest ona "tokenizowana" i w tej postaci zapisywana w pamieci, do czasu wykonania jej, po czym te tokeny sa interpretowane)
czyli to innego rodzaju kompilacja, niz masz w action, czy kompilatorze turbo beja, gdzie do natywnego kodu procesora kompilowany jest program.
to, ze panu Wojtkowi szacun sie nalezy - nie przecze. zrobil poprostu wiele.
co do Carstena - sporo fajnych rzeczy ma od dawna (w tym jedno z lepszych miejsc z kodem forthowym pod malucha). goraco polecam przyjrzec sie calosci jego wiki...
tdc 2009-03-09 03:39:59
xxl: Nie oceniaj tamtej sytuacji tak pochopnie, bo ja z KMK współpracowałem od kilku lat bez najmniejszych problemów, odwiedzaliśmy się w domach, robiliśmy różne testy oraz wiele dyskutowaliśmy na przeróżne tematy. Dlatego skoro nie było żadnych problemów to ja chcąc robić „pyskówkę” musiałbym być jakiś dobrze rąbnięty.
xxl 2009-03-10 08:51:10
obydwaj 'naciagaliscie fakty' ;-) nie mowie ze to zle, gdyby dluzej pociagnac ten cykl to mozna by sie bylo czegos nauczyc, w ogole idea dobrego i zlego gliny przy pisaniu arkow na zmiane nie jest wcale taka glupia ;-) z przyjemnoscia bym poczytal, pod warunkiem ze to do czegos prowadzi, te dwa artki wyzej nie prowadzily - moze wlasnie dlatego ze byly tylko dwa? nie wiem. tak czy owak, o Action! chcialbym jeszcze poczytac.
Kaz 2009-03-10 10:20:37
xxl - na pewno poczytasz wiecej, wierz mi :)
tdc 2009-03-13 09:56:04
xxl: Właśnie zwróciłeś tu uwagę na istotny temat, ja właśnie chciałem napisać tekst, jako osoba wychowana w duchu "Sondy". Czyli zdrowa polemika (bez zbędnych emocji), która do czegoś prowadzi. Jednak nie udało mi się to (nie do końca z mojej winy), a inna sprawa, że w końcu wtedy smarkacz byłem i pewnie nie miałem szans się równać z polemiką jak w Sondzie!
Następne części miały być i kto wie ile by ich powstało. W każdym razie właśnie wtedy pismo zostało zamknięte i do dzisiejszego dnia chyba nic się w tej materii nie działo...
danos 2011-02-24 08:49:16
Kaz:
Wiem, że wątek jest już dość stary, ale chciałbym dorzucić moje 3 grosze o Deep Blue C.
Informacje o DBC są w Atariki: http://atariki.krap.pl/index.php/Deep_Blue_C. Z kolei Atari 8-bit Faq stanowi, że Deep Blue C kompiluje do kodu Intel 8080, który jest następnie wykonywany przez interpretator/maszynę wirtualną 8080 [http://www.faqs.org/faqs/atari-8-bit/faq/]. Czyli technika podobna do dzisiejszej JAVA.
We własnym teście praktycznym byłem rozczarowany szybkością tak "skompilowanych" programów w C - porównywałem do Atari Basica i Kyan Pascala.