Logiciel : Adobe libère sa machine virtuelle ActionScript 3
Posté par Laurent J (page perso, ). Modéré le 07 novembre 2006.
Adobe et Mozilla vont donc travailler ensemble sur cette machine virtuelle, afin de profiter chacun d'une implémentation complète et performante des futures versions d'Ecmascript (en particulier Ecmascript 2 édition 4), ce qui est l'objectif du projet Tamarin de Mozilla.
Concrètement, le projet Tamarin permettra d'avoir des performances accrues sur l'exécution des scripts javascript dans les pages web, dans les extensions, dans les applications XUL, et donc dans le futur Firefox 3.
![[en]](../images/en.png)
Communiqué de presse (259 hits)![[fr]](../images/fr.png)
Article sur sur xulfr.org (661 hits)-
L'annonce de Franck Heicker, Directeur Exécutif de la fondation Mozilla (176 hits)
-
Projet Tamarin (388 hits)
> Lire la dépêche (60 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #772230.
Run by 
Cette page a été générée par Templeet en 0.0811s (dont 0.0072 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Rectificatif
D'après http://www.mozilla.org/projects/tamarin/ et http://www.adobe.com/aboutadobe/pressroom/pressreleases/2006(...) c'est plutôt la version 4 de ECMAScript qui ets implémentée dans Tamarin, version à l'origine de AS 3 (soit flash 9) et Javascript 2, version encore à l'état de brouillon mais presque finie.
En tout cas c'est une bonne nouvelle pour la standardisation du langage Javascript et j'espère que le projet sera repris par les autres navigateurs libre comme konqueror.
Et, encore une note positive (j'ai perdu la source par contre), cette machine virtuelle est disponible pour les 64 bits ce qui voudrait donc dire qu'il y à de grandes chances de voir un flash 9 pour 64 bits
[^]Re: Rectificatif
Arf, encore oublié, et perdu la source.
Malgré le fait que Adobe ait libéré (http://blogs.adobe.com/penguin.swf/2006/11/open_source_actio(...) 135000 lignes de code, ils n'ont pas libéré leur soft java qui génère le bytecode pour actionscript (pas bytecode pour javascript 2, ni de JIT pour mozilla donc il me semble)
[^]Re: Rectificatif
Pourtant, http://lxr.mozilla.org/mozilla/source/js/tamarin/codegen/ ressemble furieusement à de la génération de code machine, donc d'un système JIT ;-)
Je pige pas par contre ton histoire de soft Java ... Y a pas de java dans flash...
Et puis je ne vois pas l'interet d'une machine virtuelle si elle ne génère pas du bytecode....
[^]Re: Rectificatif
ah je crois comprendre : dans un flash, le code actionscript est déjà sous forme de bytecode, bytecode généré par les outils de dev flash ?
Et il n'y aurait pas alors de parser javascript/générateur de bytecode dans ce qu'ils ont filé ?
C'est probable en effet (je suis pas encore aller tout voir...)
Cependant, spidermonkey sait parser du JS, et comme on a les sources de la machine virtuel, c'est assez "relativement" "aisé" alors de générer du byte code :
parser (spidermonkey) -> génération de bytecode (générateur à développer ?) -> execution du byte code (la machine virtuelle d'adobe)
[^]Re: Rectificatif
Il y mtasc qui est présenté comme un compilateur pour ActionSCript2 mais je sais pas si ça répond à la problématique :
http://www.framasoft.net/article3536.html
http://www.mtasc.org/
[^]Re: Rectificatif
Il y a surtout haXe qui est le successeur de mtasc, qui permet la compilation d'un langage dédié (ressemblant à ECMAScript, mais avec typage strict, inférence de types...) vers Javascript ou SWF.
http://haxe.org/
[^]Re: Rectificatif
Bon, j'ai retrouvé ma source, je vais dire moins de bêtises :
http://www.kaourantin.net/2006/11/spidermonkeys-relative-tam(...)
Ce monsieur est ingénieur chez Adobe et travaille sur le flash player, il me semble qu'il travaille main dans la main avec le développeur principal de flash pour linux.
Il y aura donc un JIT pour mozilla.
Par contre :
Il y a bien du code java pour générer du bytecode ecmascript, code utilisé dans la plate-forme flex (et sûrement dans Flash pour créer les .swf).
D'après ce que j'ai compris ils ont libéré du code qu'ils ont écrit il y a peu pour leur garbage collector (ramasse-miettes), ce qui amène un gros gain de performances rien que pour leur player. On peut donc imaginer la même chose pour mozilla, ce qui ne présage que de bonnes choses :-)
[^]Re: Rectificatif
En gros, si j'ai bien compris, le principe, c'est ça :
ECMAScript --> Bytecode pour Tamarin (compilé) --> execution sur le processeur
Pour l'instant, sur Firefox, on a :
ECMAScript --> interprétation par SpiderMonkey --> exécution
La compilation est presque tout le temps beaucoup plus efficace que l'interprétation.
Avec Tamarin, les 2 fonctions principales qui accélèrent sont le JIT (compilatio à la volée) et le ramasse-miette (gestion/récupération de la mémoire à la volée).
Ce qui n'a pa été libéré, c'est la partie :
ECMAScript --> Bytecode pour Tamarin
Donc, le futur boulot, c'est de mettre Tamarin dans SpiderMonkey pour que SpiderMonkey compile pour Tamarin.
En gros, c'est :
ECMAScript --> SpiderMonkey --> Bytecode Tamarin --> exécution
Pour les puristes (ceux qui aiment la purée ;) ), la page Tamarin indique qu'en fait Tamarin sera DANS SpiderMonkey, c'est à dire que c'est le même bidule qui interprète/compile/exécute l'ECMAScript.
Et au final, ils sont pas fous chez Adobe, ils gardent leur avantage concurrentiel, c'est-à-dire l'outil qui génère le code Tamarin depuis des bibliothèques (optimisées) de gestion audio/video.
xmpp:ofaurax@jabber.fr
[^]Re: Rectificatif
c'est-à-dire l'outil qui génère le code Tamarin depuis des bibliothèques (optimisées) de gestion audio/video.
Pardon ? Tu ne crois pas que le moteur de rendu du lecteur Flash est écrit en ActionScript quand même ?
[^]Re: Rectificatif
T'as raison.
Je connais pas assez bien Flash.
Mais alors là, je comprends pas pourquoi ils ont par libéré leur compilateur d'ECMAScript vers Tamarin.
Ça leur permettait d'ouvrir complètement la chaîne de compilation et de proposer une valeur ajoutée en fournissant des bibliothèques audio/video/pdf/etc.
Je sais, on s'en fout, on a SpiderMonkey, mais bon...
xmpp:ofaurax@jabber.fr
[^]Re: Rectificatif
Mais alors là, je comprends pas pourquoi ils ont par libéré leur compilateur d'ECMAScript vers Tamarin.
Timic Uro (le chef de proj. Flash chez Adobe) l'explique : parce qu'il n'est de toutes façons pas utilisable pour FF :
* Il est en java (donc déjà, ça le fait pas)
* Son architecture ne permet pas de gérer l'instruction eval() (donc impossible de le rendre totalement compatible avec le standard ECMAScript 4).
Si je comprend bien le but est maintenant d'écrire le compilateur Ecmascript ... en Ecmascript !
Ref. http://www.kaourantin.net/2006/11/spidermonkeys-relative-tam(...)
[+] [^]ils n'ont pas libéré ...
Perl, Python, Parrot ... sont totalement libérés depuis longtemps eux!
[^]Re: ils n'ont pas libéré ...
ECMAScript est totalement libre... la preuve on en a fait javascript, implémenté dans firefox (et surement konqueror)
[^]Re: ils n'ont pas libéré ...
ECMAScript est totalement libre... la preuve on en a fait javascript
Euh non c'est l'inverse, ECMAScript est le descendant normalisé du JavaScript créé par Netscape et de JScript, sa variante microsoftienne.
[^]Autre rectificatif
Chez mozilla, ils prévoient plutôt d'implémenter Tamarin dans Firefox 4 et non pas 3.
Cf http://www.mozilla.org/projects/tamarin/faq.html#when
et http://www.hecker.org/mozilla/adobe-mozilla-and-tamarin