[Toulouse-pm] Re: [ppm] YAPC::Europe::2003 (3) (fwd)

[Michel Rodriguez]

La discussion sur Parrot se poursuit...

Si ca vous interesse pas, faites me le savoir.

Michel Rodriguez
Perl & XML
http://www.xmltwig.com

---------- Forwarded message ----------
Date: Tue, 29 Jul 2003 22:56:51 +0200
From: Jerome Quelin <jquelin at mongueurs.net>
To: stef at payrard.net, Paris.pm <paris-pm-list at pm.org>
Subject: Re: [ppm] YAPC::Europe::2003 (3)

Stéphane Payrard wrote:
>      PIR: Parrot Intermediate Representation Language. C'est un
>            assembleur à base de registres typés qui gère aussi
>            les espaces de noms. Les registres sont de types:
>            entiers, numériques, chaînes et PMC, pour Perl Magic
>            Cookie. PIR propose un nombre illimitée de registre
>            appelés registres symboliques.

Il y a d'autres différences entre PIR et PASM :
 - affectations plus "simples"
	PASM: add I0, I1, I2
	PIR:  $I0 = $I1 + $I2

 - gestion d'unités de compilation permettant de réutiliser des labels
(dits locaux à l'inverse de labels globaux)

 - conditions plus faciles à écrires
	PASM: lt I0, I1, FOOBAR
	PIR:  if $I0 < $I1 goto FOOBAR

 - utilisation de variables nommées
	.local int foo
	foo = 2 +3

 - pareil pour des constantes
	.const string HELLO
	HELLO = "hello, world!\n"

 - il y en a certainement d'autres


>            IMMC (Intermediate Code Compiler for Parrot, maitenant

Vous avez rectifié de vous-mêmes : IMCC


>            une passe de Parrot) transcrit ça en PASM en passant
>            de la fiction du nombre illimité de registres à la
>            "réalité" de nombre effectif de registre faisant
>            l'allocation avec un algorithme à base de couleurs qui
>            représentent les registres réels.

Je croyais qu'il s'agissait d'affecter un score à chacune des variables,
et de libérer les registres contenant les variables ayant le score le
plus faible en les stockant dans une PerlArray se trouvant dans P31.
Les variables ayant une brève durée de vie ou se trouvant dans une
boucle verront leur score augmenter.


>      PASM:
[...]
>                                         Mais maitenant que IMCC
>           est opérationnel, il n'y a aucune raison de travailler
>           à ce niveau.

Tsk, tsk... Le fun, stef, le fun ! :o)
D'autre part, si tu veux réellement apprécier imcc, il faut auparavant
en avoir bavé avec pasm. Et puis cela te donne une bonne connaissance
de Parrot, ce qui est pas mal non plus.


> Plus que de calcul d'adresses en soi avec les contraintes
> d'alignement que cela suposse, il s'agit surtout d'optimisations
> pour le DOD et le GC qui n'ont pas encore l'imprimatur de Dan.
> DOD et GC acronymes de Garbage Gollection et Dead Object
> Detection. Pour les pros du GC, la distinction (que je n'ai pas
> comprise) n'est pas celle entre les deux passes "mark" et "sweep"

Je crois que le DOD consiste à tout marquer comme dead, et ensuite
suivre les "root objects" et ce vers quoi ils pointent en marquant
alive l'objet correspondant, puis à virer tout ce qui est encore dead.

Le GC serait un simple scan pour rechercher les morceaux de mémoire non
encore rendus au système. Par exemple, si j'ai une variable chaîne
faisant 1000 caractères de long et que je lui affecte une nouvelle
valeur de 100 caractères, il y a 900 octets à récupérer.

Ceci dit, je ne suis pas un pro de tout ça, et il faut prendre ce que je
dis dans ce domaine avec précautions. Voire même ne pas le lire :-)

Je ne sais pas où en est la discussion, car le DOD _serait_ incompatible
(selon Leo) avec la notion de "timely destruction", cad la destruction
des objets en temps voulu (typiquement à la sortie d'un bloc lexical).


> >     Leo expose ensuite quelques uns des différents run cores
> >     disponibles dans Parrot. Si j'ai bien compris, les run cores
> > sont les coeur d'exécution de Parrot, mais comme ils n'étaient pas
> > sûr de savoir quel mécanisme serait le plus efficace, ils ont
> > développé plusieurs run cores : Fast Core, Goto Core, Slow Core, et
> > des combinaisons. Leo montre le Fast Core avec du code C :
> > while(PC) {
> >             PC = ((INTERP->op_func_table)[*PC])(PC,INTERP);
> >         }
> >     Je crois que la majeure partie de la salle est restée
> > dubitative face à ça...
>
> Je suis largué sur ce coup là.

Si je comprends bien :
 INTERP est l'interpréteur Parrot courant
 INTERP->op_func_table est un tableau de pointeurs de fonctions
 PC est l'opcode courant
 (INTERP->op_func_table)[*PC] est donc la fonction permettant d'exécuter
l'opcode courant
 ((INTERP->op_func_table)[*PC])(PC,INTERP) est donc un appel à cette
fonction avec l'opcode courant et l'interpréteur courant. Par
convention, les fonctions implémentant les opcodes renvoient le
prochain opcode à être exécuté
 on recommence tant qu'on a un opcode

Les autres solutions m'ont semblé plus touchy à comprendre.


> A propos du JIT et comme indiqué sur un des slides de Dan par un
> TLA (Three Letter Acronym) que j'ai oublié : ce n'est pas
> vraiment du JIT (Just In Time) puisque la génération du code
> natif est faite avant l'exécution.

Je crois qu'il a parlé de WAT, soit Way Ahead Time.


> En tout cas, c'est la première fois (je crois) que Dan rencontre Leo
> et on a tous constaté Leo existe réellement.

En plus il est super sympa. Il veut même modifier le système de
commentaire de imcc pour que je puisse rajouter un neuvième langage à
mon programme polyglotte ! :-)


Jérôme
-- 
jquelin at mongueurs.net

-
Paris Perl Mongueu(r|se)s  => http://paris.mongueurs.net/mail.html