Ceci dit, NativeClient fonctionne déjà sur x86/amd64/arm, ce qui représente une grosse partie des architectures utilisées aujourd'hui. Et puis si ils ont réussi à porter sur 3 architectures, y'a pas de raison que ça ne soit pas portable ailleurs.
D'après ton document, la méthode utilisée par PNaCL pour obtenir cette portabilité est de viser l'intersection des choses supportées par ces trois architectures : que des adresses 32 bits, little-endian, un modèle mémoire ultra-rigide (sequential consistency), etc.
Ça limite donc intrinsèquement sa portabilité : si demain l'architecture Quvz devient populaire et ne respecte pas ses présupposés, elle ne pourra pas utiliser (sans une couche d'émulation) les bitcodes LLVM générés pour PNaCL.
Par ailleurs (mais ce n'est pas lié à ma remarque d'ordre général sur LLVM), le problème de NaCL c'est qu'il y a une interface très large et très lourde entre le processus NativeClient et le browser; elle dépend du fonctionnement de Chrome et n'est donc pas si portable que ça vers les autres browsers. Brendan Eich ne veut pas entendre parler de leur Pepper API et c'est donc un peu mort pour l'intégration dans Mozilla (et ce n'est pas seulement une question politique, le choix technique peut se comprendre, même s'ils pourraient faire des efforts pour essayer de faire changer ces aspects-là; ils ne sont pas intéressés).
[^] # Re: Encore un langage de "haut"-niveau interprété par le navigateur?!
Posté par gasche . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 4.
D'après ton document, la méthode utilisée par PNaCL pour obtenir cette portabilité est de viser l'intersection des choses supportées par ces trois architectures : que des adresses 32 bits, little-endian, un modèle mémoire ultra-rigide (sequential consistency), etc.
Ça limite donc intrinsèquement sa portabilité : si demain l'architecture Quvz devient populaire et ne respecte pas ses présupposés, elle ne pourra pas utiliser (sans une couche d'émulation) les bitcodes LLVM générés pour PNaCL.
Par ailleurs (mais ce n'est pas lié à ma remarque d'ordre général sur LLVM), le problème de NaCL c'est qu'il y a une interface très large et très lourde entre le processus NativeClient et le browser; elle dépend du fonctionnement de Chrome et n'est donc pas si portable que ça vers les autres browsers. Brendan Eich ne veut pas entendre parler de leur Pepper API et c'est donc un peu mort pour l'intégration dans Mozilla (et ce n'est pas seulement une question politique, le choix technique peut se comprendre, même s'ils pourraient faire des efforts pour essayer de faire changer ces aspects-là; ils ne sont pas intéressés).