Moka - Page 1

Bonjour.

Je suis nouveau sur ce forum et c'est tout récemment, grâce au site www.ti-fr.com, que j'ai pris connaissance de son existance. Veuillez donc excuser mon ignorance de ses us et coutumes.

Moka est un convertisseur de code Java en code C. En fait, il cré un projet TIGCC directement compilable. On peu voir le sdk de Moka (ou mdk) comme un précompilateur C complexe.

Bien que certaines sommités du C sont septiques envers l’émergence des langages orientés objet pour calculatrice en général et Moka en particulier, je crois que ce SDK peut simplifier la vie à beaucoup de programmeurs.

La documentation de Moka n'est disponible qu'en anglais, mais je suis disposé à répondre à vos interrogations dans la langue de votre choix (anglais – ou français si possible).

Vos suggestions et commentaires seront toujours les bienvenues et les contributions de packages ou de classes seront toutes étudiées avec attention.

Il faut dire que ton programme est très interessant que je n'ai pas plus résister à mettre une news sur http://www.tigen.org
En tout cas c'est vraiment complet.

Merci, je viens de découvrir le site et j'ai d'ailleurs ajouté un commentaire ...

dommage que je code pas en java, je ne pourrais donc pas tester ça.
Est-ce que le code obtenu est efficace ?

Tout dépend de ce que l’on entend par efficace.

Si l’on parle de vitesse, oui. Bien sûr un programme en pure C ou en assembleur optimisé à la main et avec une foule de hacks audacieux sera plus rapide, mais Moka produit des programmes assez rapides. Les structures de contrôles sont identiques à celle du C. En fait, c’est plutôt l’envoi d’un message à un objet qui est un peu plus lent qu’un appel de fonction en C – en termes un peu plus techniques, cela correspond à déréférencer un pointeur vers un pointeur vers une fonction avant de faire l’appel.

Si l’on parle de la taille des exécutables, ou d’efficience taille/vitesse, Moka perd un peu au change. En effet, les mécanismes d’optimisation ne sont pas encore à leur mieux – mais sont déjà assez compétents - et, la vitesse étant la préoccupation principale lors de la conception de l’API, l’optimisation de la taille a passé en deuxième.

Les programmes graphiques tendent à être gros. L’environnement graphique proposé par Moka offre de nouvelles possibilités par rapport à celui natif, mais il est vrai que c’est assez cher payé pour pouvoir programmer avec un API semblable à l’AWT.

Un point intéressant pour les programmeurs qui connaissent le C et qui voudraient développer de nouveaux packages ou de nouvelles classes pour Moka, est que le langage offre une totale interopérabilité avec le C. On peut donc programmer des méthodes en C dans une classe Moka.

En bref, Moka est efficace. Efficient, ça dépend des besoins – et des opinions. Je dirais qu’un programme qui n’utilise pas le GEM (l’environnement graphique de Moka) est assez efficient. Et qu'un programme à fenêtres multiples qui utilise le GEM est assez facile à programmer.

A tu prévu des interfaces avec GTC ? (gtc est le compilateur C oncalc de Pollux)

Quesoft> Comment Moka se débrouille-t-il sans garbage collection ? Le prog s'arrête violemment quand il est à court de mémoire ? Le programmeur est censé libérer la mémoire ? Il y a le gros garbage-collector qui se met en marche et freeze la calc pendant 2 secondes ? (comme sur HP )

A propos du tas, est-ce que :
- tu alloues avec HeapAlloc/HeapFree ou tu as fais des fonctions plus efficaces ? (ce serait vraiment dommage d'utiliser les fonctions horriblement lentes du TIOS)
- ton compilo est capable d'optimiser lorsqu'il constate qu'une variable n'est pas accessible aux fonctions appelantes, pour éviter l'allocation sur le tas et passer par la pile ? (pour faire un peu comme en C++ )

Est-ce qu'il y a des switch pour activer le contrôle de débordement des entiers comme en Java ? (puisque je présume que c pas activé par défaut)

Enfin, est-ce qu'il y a des optimisations globales du genre ajout de "final" si la définition de la fonction n'est pas overridée par des sous-classes ?

Enfin bon, j'ai pas eu le temps de regarder ça de plus près, mais si c pas trop inefficace, ça a l'air prometteur


geogeo> lol, la pub à peine déguisée ^^

vince> ça m'a pas l'air évident à première vue, il faut déjà que le compilo Moka soit prévu pour être léger (au niveau ROM _et_ au niveau RAM), et ensuite il faut que la bibliothèque de classes tienne dans la calc (et ça, c vraiment pas gagné a priori). Peut-être que ce serait possible avec une modif de la bibliothèque de classes ?

Pollux :
Il y a le gros garbage-collector qui se met en marche et freeze la calc pendant 2 secondes ? (comme sur HP )

TIME MEM TIME
=> 0.038 secondes (Hp49G+)

(MEM force un garbage collector)

En tout cas du bon vieux temps de la HP48 c'était vachement lent (> 0.5 sec) J'imagine qu'ils ont optimisé depuis... Et puis est-ce que MEM fait tjs autant de boulot selon qu'il y a effectivement des choses à nettoyer ou pas ? Pas sûr...

Pollux :
En tout cas du bon vieux temps de la HP48 c'était vachement lent (> 0.5 sec) J'imagine qu'ils ont optimisé depuis... Et puis est-ce que MEM fait tjs autant de boulot selon qu'il y a effectivement des choses à nettoyer ou pas ? Pas sûr...

La routine a été optimisée une première fois dans la 49G, puis réécrite partiellement en Arm dans la 49G+.

Et puis la vitesse dépend fortement de plusieurs paramètres :
- combien y a t il d'objets temporaires?
- quelle est leur taille?
- quelle est la hauteur des piles et le nombre de variables locales?
- combien doit on déplacer d'objets?

Ah tiens j'avais pas vu le "+" Tu t'en es acheté une ?

Et pour les paramètres je suis bien d'accord, c pour ça que ton bench n'est pas forcément très adapté...

Bon, alors dans un situation très défavorable et peu fréquente (Mémoire complètement saturée de tous petits objets temporaires) :

MEM
10 1 7500 START NEWOB NEXT
TIME MEM TIME

=> 1.28 sec
(1.44 sec sur 49G)

(NEWOB crée une copie d'un objet dans la zone des objets temporaires)

Tu t'en es acheté une ?

Hippohmu :
Bon, alors dans un situation très défavorable et peu fréquente (Mémoire complètement saturée de tous petits objets temporaires) :

MEM
10 1 7500 START NEWOB NEXT
TIME MEM TIME

=> 1.28 sec (1.44 sec sur 49G)

argl, c qd même vachement long C normal que la 49G+ soit à peine plus rapide que la 49G, si ça a été réécrit en ARM ?

Pollux :
argl, c qd même vachement long

Bof, non.
La boucle qui précède la mesure, et qui sert à remplir la mémoire, est nettement plus longue. (13.87 sec sur g+, 34.29 sec sur g)

C normal que la 49G+ soit à peine plus rapide que la 49G, si ça a été réécrit en ARM ?

- C'est *partiellement* réécrit en Arm
- Amha, dans ce cas de figure, la routine utilise beaucoup de commandes saturn émulées peu efficacement (lecture de 20 bits)
- Il y a encore de la place pour de l'optimisation (nouvelles roms + maintenant on sait programmer en arm )

Hippohmu
:

Pollux :
argl, c qd même vachement long

Bof, non. La boucle qui précède la mesure, et qui sert à remplir la mémoire, est nettement plus longue. (13.87 sec sur g+, 34.29 sec sur g)

500 créations de petits objets par seconde seulement ?
Ca veut dire que la ROM passe 150.000 cycles ARM par objet, c presque digne de TI ça

Combien de temps pour exécuter une boucle .vide. de 7500 pas sur Ti?


Si tu veux je te le réécris en RPL système...

!RPL
!NO CODE
::
 ZINT 10
 7500 #1+_ONE_DO TOTEMPOB LOOP
;

1.27 sec sur g+, 10.60 sec sur g

OK, si l'overhead vient du RPL, ça va... Pour info, la TI prend 5 pour faire 1000 allocations+libérations, soit 200 allocations par seconde. Si avec une fréquence 7.5x plus élevée et un processeur qui fait bien plus de choses en un cycle, la HP n'arrivait pas à faire mieux que 2.5x plus vite que la TI, c'est qu'il y avait vraiment un pb qq part et que les ingés de chez HP étaient "encore meilleurs" que ceux de TI... Et encore, là, 25x plus vite, c'est relativement moyen vu la fréquence du processeur (ça veut dire que si TI compilait pour ARM, ça tournerait grosso modo aussi vite)

(petit bench avec des allocations de 5 octets)

Sur hp49g : ~ 1900 allocations par seconde
Sur hp49g+ : ~ 16600 allocations par seconde

=>

Bah, c même pas 25x plus rapide, c 16x plus rapide... Ce qui veut dire qu'à fréquence égale, une HP va seulement 2x plus vite qu'une TI (et pourtant, la TI n'a pas un bus 32 bits, et n'est capable de faire une lecture que tous les 4 cycles)

200 allocations par seconde.

~ 16600 allocations par seconde

c même pas 25x plus rapide, c 16x plus rapide...

T'aurais pas oublié un zéro?

oups, je croyais que la TI en faisant 1000

Bon, OK, c 80x plus rapide, ça devient plus raisonnable... Ce qui n'empêche pas qu'on pourrait faire largement mieux dans le cas de gros consommateurs de petites allocations (typiquement, Java, Basic, ou plus généralement n'importe quel langage avec une gestion mémoire de haut niveau) avec un heap réimplémenté.

Y a un émulateur de 49G+ dispo ? Et un compilo ARM ?

-- non rien --

Rah la la qu'il est difficile

80 * plus d'allocations pour une fréquence 7.5 * plus élevée, sachant que c'est une puce bien plus puissante mais qui émule du code d'un vieux microprocesseur venu de la planète mars, moi ça me fait doucement planer...

avec un heap réimplémenté.

Au fait, répétons le encore une fois :
- ce n'est pas du C
- ce n'est pas un Heap comme en C
- ce n'est pas du C

gros consommateurs de petites allocations (typiquement, Java, Basic, ou plus généralement n'importe quel langage avec une gestion mémoire de haut niveau)

C'est le cas du RPL.

Y a un émulateur de 49G+ dispo ?

Non!

Et un compilo ARM ?

Un compilo *orienté Hp49g+*, non. (pas encore)

Y a un émulateur de 49G+ dispo ?

Non!


Et un compilo ARM ?
Un compilo *orienté Hp49g+*, non. (pas encore)

ah bah si, c'est ce que je voulais dire au ./22 mais j'ai eu un doute...

Hippohmu :
Rah la la qu'il est difficile
80 * plus d'allocations pour une fréquence 7.5 * plus élevée, sachant que c'est une puce bien plus puissante mais qui émule du code d'un vieux microprocesseur venu de la planète mars, moi ça me fait doucement planer...

Etant donné que c 10x plus rapide que le code de la 49G alors que le reste du RPL tourne grosso modo à la même vitesse, je pense que cette partie-là a été recodée en ARM (et tant mieux, d'ailleurs)

avec un heap réimplémenté.

Au fait, répétons le encore une fois :
- ce n'est pas du C
- ce n'est pas un Heap comme en C - ce n'est pas du C

Oui. Mais pour faire un heap "comme en C", c'est loin d'être la meilleure solution (à moins qu'il y ait une autre API plus efficace)

gros consommateurs de petites allocations (typiquement, Java, Basic, ou plus généralement n'importe quel langage avec une gestion mémoire de haut niveau)

C'est le cas du RPL.

Alors, "peut mieux faire"

Y a un émulateur de 49G+ dispo ?

Non!

Ouin

Et un compilo ARM ?

Un compilo *orienté Hp49g+*, non. (pas encore)

(oui c ce que je voulais dire)
Ouin

Note pour en autres vince :
http://alpage.ath.cx/hptute/arm.htm
Le site (en pleine construction bien sûr) est pour hp49g+, mais il donne des tutos pour l'arm et surtout des outils de développement pour PC.

je fais confiance à HPSB et Xorxar (HPEARL)

Pollux :
Etant donné que c 10x plus rapide que le code de la 49G alors que le reste du RPL tourne grosso modo à la même vitesse, je pense que cette partie-là a été recodée en ARM (et tant mieux, d'ailleurs)

- En partie seulement
- Et de toute façon les temps d'exécution les unes par rapport aux autres des commandes du saturn émulé sont très différentes de ce que c'était sur le saturn original. Du coup, l'accélération que procure l'arm change beaucoup selon la nature de la routine...

Oui. Mais pour faire un heap "comme en C", c'est loin d'être la meilleure solution (à moins qu'il y ait une autre API plus efficace)

(confused) Qu'est ce qui est loin d'être la meilleure solution?

Il n'y a pas de Heap "comme en C" sur Hp.

Alors, "peut mieux faire"

C'est très, très bien comme ça #satisfait#

Ouin

Il y en a un en construction, mais il n'est sans doute pas près de voir le jour.

Hippohmu
:

Pollux :
Etant donné que c 10x plus rapide que le code de la 49G alors que le reste du RPL tourne grosso modo à la même vitesse, je pense que cette partie-là a été recodée en ARM (et tant mieux, d'ailleurs)

- En partie seulement - Et de toute façon les temps d'exécution les unes par rapport aux autres des commandes du saturn émulé sont très différentes de ce que c'était sur le saturn original. Du coup, l'accélération que procure l'arm change beaucoup selon la nature de la routine...

Je pense qd même qu'une partie très significative du heap a été reprogrammée...

Oui. Mais pour faire un heap "comme en C", c'est loin d'être la meilleure solution (à moins qu'il y ait une autre API plus efficace)

(confused) Qu'est ce qui est loin d'être la meilleure solution?
Il n'y a pas de Heap "comme en C" sur Hp.

Si tu veux faire un heap "comme en C", ces routines-là sont utilisables (quitte à remplacer free() par un nop) mais pas efficaces.

Alors, "peut mieux faire"

C'est très, très bien comme ça #satisfait#

Ouin

Il y en a un en construction, mais il n'est sans doute pas près de voir le jour.

D'ému ou de SDK ?

Pollux
: Je pense qd même qu'une partie très significative du heap a été reprogrammée...

#ter# : Ce n'est pas un Heap !!!

Et certes, une partie est reprogrammée, mais ça n'empêche pas que le code arm natif doit se conformer aux structures de données du saturn : champs de 20 bits, adresses en quartets et indifféremment paires ou impaires.

Si tu veux faire un heap "comme en C", ces routines-là sont utilisables (quitte à remplacer free() par un nop) mais pas efficaces.

(still a bit confused) C'est lesquelles, "ces routines là"?

On ne peut pas faire de Heap "à la C" à partir des routines mémoires de la rom. (en première approximation, du moins).

#si#

D'ému ou de SDK ?

Emu.

Et Jean Yves Avenard semblait intéressé sur comp.sys.hp48, ce qui laisse à croire que Hp n'a pas fait d'ému pour eux.