Pas trop quand même. Sinon ça ne sert plus à rien de chercher à ce comprendre.
Pour te montrer comme être pointilleux quand il n'y a pas d'ambiguïté ne mène nul part.
parce qu'il n'existe pas de logiciel assembleur qui va traduire le bytecode de la JVM en langage machine.
N'importe quelle JVM fait ca c'est son job (Astuce pour Hotspot par exemple). Autrement pour sortir des JVM standards, GCJ est capable de compiler directement vers du natif. Il y a eu un paquets d'autres projets qui ont fait ca.
J'aurais du ne parler uniquement de langage machine car il existe des machine qui décodent directement le bytecode JVM.
Tu arrêtes pas de le ressortir mais on peut faire ca pour n'importe quel bytecode, voir langage si vraiment on s'ennuie. On le fait pas par ce que ca n'a aucun sens. Toutes les tentatives de CPU mangeant du JVML ont été des échecs cuisants.
Je cherche pas à troller je demande réellement qu'elle est la différence dans la démarche d'un coté (bytecode JVM) et de l'autre (jeu d'instructions x86).
Y'en a un qui est du soft et l'autre du hard ca n'a rien de comparable.
Pourquoi cibler la JVM ?
- S'intégrer avec l'existant (compétence, compatibilité, bootstraper avec un eco-systeme déjà prêt)
- Profiter des efforts absolument monstrueux qui ont été fait dessus depuis 15 ans
C'est exactement les mêmes raison qui font actuellement fleurir les langages ciblant JS. Et c'est bien là le changement. L'informatique est arrivée à un point où c'est extrêmement difficile d'être disruptif et de pousser de l'innovation. Et c'est pour ca que c'est "la mode". Sauf cas particulier on a plus vraiment le choix, même pour les mastodontes qui quand ils tentent n'arrivent plus à pousser leurs technos. Ça ne marche que si tu es environnement clos.
[^] # Re: Compilateur
Posté par ckyl . En réponse au journal Nouveau projet OpenSource chez Microsoft: TypeScript. Évalué à 1.
Pour te montrer comme être pointilleux quand il n'y a pas d'ambiguïté ne mène nul part.
N'importe quelle JVM fait ca c'est son job (Astuce pour Hotspot par exemple). Autrement pour sortir des JVM standards, GCJ est capable de compiler directement vers du natif. Il y a eu un paquets d'autres projets qui ont fait ca.
Tu arrêtes pas de le ressortir mais on peut faire ca pour n'importe quel bytecode, voir langage si vraiment on s'ennuie. On le fait pas par ce que ca n'a aucun sens. Toutes les tentatives de CPU mangeant du JVML ont été des échecs cuisants.
Y'en a un qui est du soft et l'autre du hard ca n'a rien de comparable.
Pourquoi cibler la JVM ?
- S'intégrer avec l'existant (compétence, compatibilité, bootstraper avec un eco-systeme déjà prêt)
- Profiter des efforts absolument monstrueux qui ont été fait dessus depuis 15 ans
C'est exactement les mêmes raison qui font actuellement fleurir les langages ciblant JS. Et c'est bien là le changement. L'informatique est arrivée à un point où c'est extrêmement difficile d'être disruptif et de pousser de l'innovation. Et c'est pour ca que c'est "la mode". Sauf cas particulier on a plus vraiment le choix, même pour les mastodontes qui quand ils tentent n'arrivent plus à pousser leurs technos. Ça ne marche que si tu es environnement clos.