Názory k článku
Programovací jazyk Forth a zásobníkové procesory (19)

super serial... ikdyz u tohoto dilu by mozna bylo hezke jeste dodat jake jsou rozdily JBC a IL...

btw. netusi nekdo proc si Sun a Microsoft vybrali pro runtime zasobnikove \"procesory\" misto registrovych?

Nejenom Sun a Microsoft, troufam si rict ze registrove VM jsou spise vyjimkou.

Zasobnikova architektura je vyrazne jednodussi jak na implementaci VM, tak predevsim na generovani kodu (odpada zonglovani s registry). Navic pristup do zasobniku je stejne efektivni jako pristup do registru, takze odpada hlavni vyhoda registrovych procesoru (kvuli ktere se tak rozsirily v nevirtualni oblasti).

Hlavní problém s registrovými procesory je v tom, že není jasné, kolik registrů mají obsahovat, zda je jejich instrukční sada ortogonální apod. Také instrukce pro práci s registry musí být delší (bitově), protože v jejich kódu musí být specifikován minimálně zdrojový a cílový registr. Obě tyto nevýhody u zásobníkového kódu odpadají.

Není bez zajímavosti, že bytekód zmíněného Self potřebuje vlastně jen pět instrukcí:
- send
- resend
- pushLiteral
- pop
- returnTop

a pushLiteral by šel taky vypustit :-)

Ahoj Pavle,
a čím se dá - pro zajímavost - pushLiteral nahradit? Přece musí existovat možnost, jak do zásobníku dostat konstantu (a třeba ji potom použít pro výpočty či skok).

Omlouvám se, trochu jsem se nachal unést a opomněl pushSelf, který se nedá nahradit pouhým "send self", protože bychom pak nemohli volat objekty z vrcholu zásobníku.

K těm literálum:

Vtip je v tom, že v Selfu jsou i metody celkem běžné objekty se sloty. Když se začne provádět metoda, tak se ve skutečnosti provádí kód v kontextu aktivačního objektu metody, jehož součástí by mohly být právě sloty pro literály.

Takže bychom měli třeba objekt obj1, jehož sloty by vypadaly takto:
x = 3
y = 4

a v jeho kontextu bychom volali metodu s kódem:
^ x + y + 7

tak by aktivační objekt metody vypadal nějak takhle:
:self* = obj1
literal1 = 7

a vrámci tohoto aktivačního objektu bychom provedli bytekód:
pushSelf
send x
pushSelf
send y
send +
pushSelf
send literal1
send +
returnTop

:self* je rodičovský slot, takže se zprávy x a y delegují na objekt obj1, v jehož kontextu chceme ve skutečnosti kód provádět.

pushSelf vloží na vrchol zásobníku přímo aktivační objekt metody. Kdyby kód metody obsahoval "self", tak se to samozjřejmě přeloží jako:
pushSelf
send self
a ne jen jako pouhé pushSelf. Je to vlasntě explicitní přístup k rodiči.

Je to jen teoretická konstrukce, protože v reálu to Self takhle čistě nedělá a i já ho implementuji zcela jinak. Ale jako demostrace čistoty jeho návrhu je to vynikající.

Aha, to vypadá zajímavě. Je vůbec Self kompilovatelný do nějaké rozumné binární podoby (bytekódu)? U Lispu se například opravdová kompilace nedá provést a Self mi v některých ohledech Lisp dost připomíná (to není výtka, právě naopak :-)))

Self postupuje podobně jako Smalltalk. Tedy, pokud jde o to vzít vygenerovaný bytekód a přenést ho jinam, to jednoduše nejde (netvrdím, že to nejde vůbec). Přenáší se celé snapshoty, což je obdoba smalltalkovské image, kde bytekód binární podobu samozřejmě má.

Bytekód se na cílové platformě překládá do strojového kódu a ukládá do cache. Podobně to dělá Java, která od Selfu technologii HotSpot převzala.

Podobně jako v Lispu lze každý selfovský objekt vyjádřit literálem. Osobně bych Self a Lisp řadil do stejné roviny. Dají se těžko porovnávat, protože oba pracují na zcela jiných čistých základech.

Lisp je syntakticky čistší a více matematicky orientovaný.
Self má syntaktického cukru kolem sebe víc a je (hlavně ve své grafické podobně - ftp://comtalk.net/Self/self.avi) podstatně lidštější.

Prakticky je jedno, z čeho se výsledný bytekód nakonec vygeneruje. Důležitý je základ - objekty jako množiny slotů, delegace. Například moje varianta Selfu se syntakticky vrací blíže k původnímu Smalltalku, aby se dal snadno integrovat do Squeaku, protože překlad provádím přímo do squeakovského bytekódu. Nejedná se tedy o interpret Selfu nad Smalltalkem.

Na zdrojových prakticky nezáleží a jako přirozená podoba Selfu by se mohla brát i jeho grafická reprezentace, což už je světu C/C++, Javy apod. značně vzádlené :-)

Taková volnost u Lispu není. Mimochodem, neobjevily se nějaké pokusy přenést Lisp do grafického prostředí podobného Selfu?

Jediné rozumné prostředí pro LISP jsem viděl v AutoCADu. Ale srovnávat to například se Smalltalkovským Sqeakem to samozřejmě není možné, jedná se o zcela odlišné systémy s jinými cíli.

Ještě pro zájemce přidávám odkazy na obrázky s Javovskými procesory:
http://paginas.fe.up.pt/~ee99043/picojava/java_big.png
http://lci.upf.tche.br/~27905/picojava/picojava2.jpg