crumpet a écrit 16 commentaires

Avec -Os, c'est mieux en effet, et effectivement, il faudrait regarder avec un "vrai" programme.

Au fait, j'ai fait un petit essai avec une petite fonction qui prend deux entiers et retourne leur somme:

en C:

int function (int a, int b)
{
return a + b;
}


en Java:

public static int function (int a, int b)
{
return a + b;
}


sur x86, je compile avec optimisations (-O3 -fomit-frame-pointer) et j'obtiens:

0: 8b 44 24 08 mov 0x8(%esp),%eax
4: 03 44 24 04 add 0x4(%esp),%eax
8: c3 ret

soit 9 octets (11 octets avec -O2)

Le ByteCode Java est:

0: iload_0
1: iload_1
2: iadd
3: ireturn

soit 4 octets (on mets les deux parametres sur la pile, on les additionne et on retourne le sommet de la pile).

Ici, il y a un rapport environ de 2 en faveur du ByteCode. Bon ce n'est qu'un exemple, et je ne dis pas que c'est toujours comme ca hein.

J'ai essayé avec la fonction factorielle codée recursivement et j'obtiens un rapport presque de 14 avec -O3 (gloups), plus que 3 avec -O0 et presque 2 avec -O2. Je n'ai pas cherché a faire un truc super-optimisé, mais juste un petit programe classique.

Une fois translaté en langage machine, il n'est pas deraisonnable de penser que le ByteCode occupera au moins la taille occupée par un code equivalent écrit en C, donc le fait que ca soit plus compact n'a pas forcement toujours un interet.

J'imagine que le nombre d'unités (les F1) est faible, et que ce n'est pas pour une question de cout qu'il y a juste 750 Ko. Est-ce-que le processeur ne peut addresser que 1 Mo ? Y-a-t'il une autre raison ?

Utiliser le mot "Garbage Collector" a cote du mot "Systeme Embarqué" fait herisser les cheveux de plus d'une personne, surtout si tu precises "Temps-Reel".

Dans certains projets de systemes embarqués il n'y a aucune allocation dynamique ; avantage : pas de 'malloc' qui echoue ; inconvenient : tu sur-dimensionnes ta memoire pour le pire cas.

Mais bon, encore une fois, les contraintes ne sont pas les memes pour tous les systemes embarqués, que ca soit en terme de taille, de fiabilite, etc. Un ABS et une Set-Top-Box sont des systemes embarqués, mais les contraintes ne sont pas du tout les memes.

Je ne connais pas bien le monde de la telephonie mobile mais un autre intervenant semblait dire que ce n'etait pas rare.

Chez le fabricant de STB ou j'ai travaillé, je n'ai pas vu une seule ligne de code en Java non plus, mais une JVM etait ajoutée par dessus la couche drivers.

Par contre dans un autre registre, il y a des JavaCards.

Lisaac, c'est prevu pour tourner sur une JavaCard ?

;-)

Bon, je crois qu'on a dérivé.

Le monde de l'embarqué est tres vaste, et l'echelle est plus importante que le monde du desktop.

J'essayais juste de faire une critique que je pensais constructive, a savoir qu'il y a une part non-negligeable de l'embarqué ou l'utilisation de ByteCode avait un avantage. Je n'ai pas dis qu'il faut abandonner l'assembleur et le C, juste que le ByteCode est utilisé et que le marché potentiel est tres important, surtout en valeur. Je demandais juste si le fait de pouvoir generer du ByteCode etait une fonctionnalité prévue, car cela a certains avantages, comme le fait d'utiliser des bibliotheques partagées ; je n'ai pas dit non plus que c'etait absolument indispensable.

Pour la manipulation des données et d'apres ce que j'ai vu, tout est serialisé sur disque ou en memoire flash, et on recharge la JVM en relisant ces données. Ce n'est certes pas tres eleguant mais ca a le merite d'etre simple ; en plus si la mise-a-jour a lieu durant la nuit ce n'est generalement pas tres genant pour l'utilisateur. C'est juste une histoire de compromis entre diverses choses, en premier le cout, et en dernier l'elegance technique. Triste réalité n'est-ce-pas ?

Désolé pour le doublon.

Cela fait un petit moment qu'il y a une JVM sur les Set-Top-Box de Canal Sat.
J'ai travaillé chez un fabricant fournisseur de STB pour Canal Sat et je te promets qu'il y a une JVM.

Cela fait un petit moment qu'il y a des JVM sur les Set-Top-Box Canal Sat.
J'ai travaillé chez un des fabriquants fournisseurs de STB pour Canal Sat : je te promets qu'il y a une JVM dessus.

Le marché que je décris c'est telephonie mobile (ok il n'y a pas de JVM dans tous les telephones portables) + TV num. Ce ne sont pas des petits marchés. A l'heure actuelle, ce sont deja des millions de machines. Je ne parle pas non plus des autres marchés.

Tous les equipements embarqués n'ont pas les memes contraintes, mais pour certains d'entre eux, le fait de pouvoir mettre a jour l'application sans se preoccuper de la plateforme materielle est clairement un avantage. Ceci est, a mon avis, quelque choses qui va continuer a se developper.

La JVM JamVM (J2SE) annonce un executable (compresse) de 140KB. La JVM MicroJVM (J2ME) annonce une empreinte memoire inferieure a 30 KB.

Le ByteCode est plus compact pour deux raisons:

- la premiere vient de sa conception : en ByteCode Java, si tu mets '0' sur la pile, c'est un seul octet ; sur une machine 32 bits, rien que le nombre tient sur 4 octets ; tout n'est pas comme ca, mais globalement, c'est plus compact

- la seconde raison est que les classes s'appuient beaucoup sur la bibliotheque et que tu peux eventuellement mettre a jour une seule classe ; c'est moins evident si tu veux faire ca avec un programme compilé, surtout sans bibliotheque partagée

Un des interets que le ByteCode soit compact est le temps de telechargement de la mise-a-jour. Le programme tient aussi moins de place en memoire.

Ceci dit, je ne vient pas ici pour dire que Java c'est genial pour l'embarque grace a son ByteCode, surtout que je suis plutot C. Je dis juste que c'est dans certains cas, cela a des avantages. Ceci est valable pour tous les langages generant du ByteCode.

Le monde de l'embarqué ce ne sont pas que des microcontrolleurs 8 bits.

Un exemple : en TV num, depuis quelques années, il y a de plus en plus de JVM. En gros, l'OS, les drivers et la JVM sont en C et l'application est en Java. Tout ce petit monde peut etre mis-a-jour via la diffusion satellite.

C'est beaucoup plus simple de mettre a jour l'application par ByteCode car la plateforme materielle est abstraite.

La specification J2ME de Java est destinée au monde de l'embarqué. D'autres existent comme STIP.

Il y a meme des specifications Temps-Reel pour Java ; la plus connue (car officielle) est RTSJ (Real-Time Specification Java).

Je rappelle qu'a l'origine Java a été concu pour l'embarqué uniquement, et que la mise-a-jour par ByteCode était un élément important. Le ByteCode a aussi été concu pour etre plus compact qu'un programme deja compilé.

Ok, merci pour les plugins.

Pour la maintenance, je pensais, par exemple, au fait que dans un projet, les equipes se renouvellent au cours du temps. Un nouvel arrivant doit etre operationnel rapidement pour analyser le programme, le corriger et le faire evoluer. Sans vouloir lancer un troll, le langage Perl n'est pas réputé pour etre facilement maintenable, ceci etant certainement du a sa syntaxe tres consise et le fait qu'"il y a plusieurs facons de le faire".

Un autre aspect est le fait d'apprendre un nouveau langage. Une des raisons pour laquelle Java a aussi bien reussi, c'est que la syntaxe de base est tres proche du C. Un programmeur C qui n'a jamais fait du Java de sa vie comprend rapidement un programme Java ; pas tout le programme bien sur, mais souvent suffisamment pour pouvoir analyser l'algorithme et effectuer une correction. Il y a evidemment d'autres facteurs (Sun poussait et pousse toujours le langage, la richesse de l'environnement) mais cet aspect la est tres important.

Le langage D est vraiment tres bien sur le papier, mieux que C, C++, Java ou C# par exemple ; je precise que je ne lance pas de trolls. Pourquoi ne perce-t-il pas alors ? Peut etre parce qu'il soit sous copyright Digital Mars. Cet aspect "langage non-libre" a été soulevé par un autre intervenant.

Puisque vous dites que vous ciblez l'embarqué, certains equipements necessitent une mise-a-jour logicielle. Il y a clairement un avantage a utiliser un langage produisant du ByteCode pour effectuer ces mises-a-jour (independance par rapport a la plateforme materielle). Je crois que dans Lisaac, il n'y a pas de notion de ByteCode.

Bref, ce que je voulais dire c'est que la reussite ou non de votre projet depend d'un nombre important de facteurs et que la performance par rapport au C n'est pas forcement le plus important. Java s'est trainé une reputation d'escargot pendant des années. Ca s'est bien amélioré mais ca ne l'a pas empéché d'avoir percé.

Vous avez fait un super boulot et semblez tres enthousiastes, mais c'est tres facile de garder la tete dans le guidon. Je voulais juste vous faire part de remarques exterieures qui, je l'espere, sont constructives.

Bibliotheque partagée, ca je vois bien, mais qu'appelez-vous "plugin" ?

Sinon, ne le prennez pas mal, mais j'ai l'impression que vous vous focalisez un peu trop sur les performances par rapport au C. Ce n'est pas un mal en soit, mais il y a d'autres aspects a prendre en compte, comme la maintenance ou la facilité d'apprentissage.

Vu qu'il n'y a pas encore de notion de lib, cela ne peut pas arriver.

Si je peux me permettre, au lieu de creer directement l'executable qui contient a la fois le code du programme et le code de la bibliotheque lissac (garbage collector, etc.), vous pourriez separer en deux parties: d'un coté la bibliotheque lisaac, d'un autre coté la bibliotheque du programme, avec des points d'entrées bien definis.

Vous pourriez ainsi developper des bibliotheques entierement en Lisaac. Avec une petite interface (.h), ces bibliotheques pourraient etre utilisees a la place de bibliotheques existantes ecrites en C.

Jai fait aussi quelques essais avec Lisaac.

Je rajouterais juste que la commande de compilation de gcc est ecrite en dur dans le fichier path.li. Si on veut ajouter on enlever une bibliotheque, on doit regenerer le generateur de code (lisaac). C'est bof bof.

Peut-on utiliser un debogueur pas-a-pas sur le code source (le .li) ? Est-ce-que cette fonctionnalité est prévue dans le futur ?

A propos du code généré, c'est bourré de variables globales. Tot ou tard il va y avoir des collisions.

Je sais que ca fait un peu "je chipote" mais ce sont des problemes qui finiront par ressurgir, surtout si, comme je vous le souhaite, votre projet prend de l'ampleur.