TiJava ou J2ME 4 68k - Page 2

freka a écrit :
Alors, que j'y mette mon grain de sable, je suis peu etre a la masse, mais aux dernières nouvelles J2ME n'est autre que du code java adapté en ce qui concerne les classe pour l'embarqué et les ressources faibles, ET pour ce faire, le code n'est pas compilé en byte-code, mais directement en langage machine, et paf! Le seul probleme c'est la place en memeoire, la memoire ti est vraiment trop petite, et je ne vois pas l'intéret de faire un programme qui fera plusieurs ko de plus qu'en C. De toute facon la structure objet est bien trop lourde pour une ti.

Je dit pas que tu a tord freka, mais sa me fait penser a se qu'on disait a propos d'émuler une GB sur TI....

De tte pq on pourrait pas compiler du java en 68k ? au pire on pourrait passer par une conversion du source java en C puis a passer a la moulinette GCC !
(On peut bien le faire avec des sources pascal apres tt)

D'ailleur a mon avis faire une conversion
src java -> src C

est plus facile que

ByteCode -> Asm68k

godzil a écrit :
Je dit pas que tu a tord freka, mais sa me fait penser a se qu'on disait a propos d'émuler une GB sur TI....

De tte pq on pourrait pas compiler du java en 68k ? au pire on pourrait passer par une conversion du source java en C puis a passer a la moulinette GCC !
(On peut bien le faire avec des sources pascal apres tt)

D'ailleur a mon avis faire une conversion
src java -> src C

est plus facile que

ByteCode -> Asm68k

+ Simple, mmm pas sur ... mais surement


Par contre faire su J2ME --> TIGCC --> ASM, ca me plait moyen car a chaque fois on perd un peu de perf. Par contre transformer le bytecode n'est pas impossible, et faisable ds un temps raisonnable. Mais il faut des betes du bytecode java d'un cote et des betes du 68k de l'autre ( tigcc team ? ).
Toutefois, s'il s'avere que faire bytecode -> 68k est trop complexe, on peut tjs faire Java -> C, mais la ca va etre chiant car il va falloir faire des malloc a partir du gc, et gerer les pointeurs.

Alors:
* Je vois que même freka, qui est un fan du Java, dit que ton projet est infaisable.
* Je t'ai déjà dit: il y a déjà un compilateur Java->langage machine: GCJ. Bonne chance pour le porter. Nous (l'équipe de TIGCC), on a vraiment d'autres choses à faire.

Le pbm du byte code, c que sion regarde de plus pret, c en fait comme un programme compilé, le byte code, etant l'equivalent de ton programme compilé sur ta ti (mal exprimé), mais en gros la jvm n'est qu'un émulateur (un peu comme vti) emulant un processeur...

Si tu veux "convertir" le bytecode en asm68k, tu va rencontrer exactement les meme pbm que si tu cherchez a convertir le code d'un jeu de GB en asm68k.... (cf le topic de l'emu GB de boogerman) A mon avis faire un compilo prenant an source du "java" et compilant directement en natif 68k, est plus facile que java bytecode->"68k Bytecode"

Kevin Kofler a écrit :
Alors:
* Je vois que même freka, qui est un fan du Java, dit que ton projet est infaisable.
* Je t'ai déjà dit: il y a déjà un compilateur Java->langage machine: GCJ. Bonne chance pour le porter. Nous (l'équipe de TIGCC), on a vraiment d'autres choses à faire.

Merci pour ton soutien
Mais je vais m'inspirer + de wabavm car gcj je crois est fais que pour j2se ...

yora, regarde du coté du supprt de java pour GCC3, sa pourrait ptet t'aider..

godzil
a écrit : Si tu veux "convertir" le bytecode en asm68k, tu va rencontrer exactement les meme pbm que si tu cherchez a convertir le code d'un jeu de GB en asm68k.... (cf le topic de l'emu GB de boogerman) A mon avis faire un compilo prenant an source du "java" et compilant directement en natif 68k, est plus facile que java bytecode->"68k Bytecode"

Non, le bytecode du Java sépare correctement code et données, donc on peut le compiler en code natif. (GCJ peut compiler des fichiers .class en code natif.)

YoraSAkitori
a écrit : Mais je vais m'inspirer + de wabavm car gcj je crois est fais que pour j2se ...

Mais WabaVM est une machine virtuelle, pas un compilateur natif.

godzil
a écrit : yora, regarde du coté du supprt de java pour GCC3, sa pourrait ptet t'aider..

Ben, GCJ = support de Java de GCC 3.

Finalement ce GCJ est interessant
Reste a voir comment implementer J2ME

Bon je vais essayer de moins blablater sur ce sujet et faire des choses effectives

Si tu veux porter GCJ, commence par le patch TIGCC. (GCJ utilise le backend de GCC.)

aRf, pkoi porter cela alors que ca ne va pas marcher correctement ??? (puis pour l'utilisation qu'on en aurait ..)

Kevin Kofler a écrit :
Si tu veux porter GCJ, commence par le patch TIGCC. (GCJ utilise le backend de GCC.)

Ooops
Excuse moi je ne t'ai pas suivi
Qd tu dis , patch TIGCC que veut tu dire par la ?

nEUrOne
a écrit : aRf, pkoi porter cela alors que ca ne va pas marcher correctement ??? (puis pour l'utilisation qu'on en aurait ..)

C'est ce que je dis aussi, mais il est libre de faire ce qu'il veut.

YoraSAkitori a écrit :
Ooops
Excuse moi je ne t'ai pas suivi Qd tu dis , patch TIGCC que veut tu dire par la ?

Arf, tu veux porter GCJ et tu ne connais même pas le patch TIGCC?!
C'est le patch pour GCC (gcc-3.2-tigcc-1.diff) qu'il y a dans les sources de TIGCC. Ça contient tous les changements qu'on a dus faire à GCC pour TIGCC.

Oki
Je croyais que vs aviez carrement tt remanie. Erreur de ma part.

Au fait c ptet inutile, mais ca m'interesse + ca que de faire le nieme Tetrislike, Mariolike, etc.

Au fait, si tu n'as pas envie d'apprendre en détail le fonctionnement de GCC (y compris les termes et les méthodes de travail de développeurs Unix, style diff, patch, ./configure, ..., ainsi que l'utilisation de MSYS), oublie ton idée de porter GCJ. GCC (et donc aussi GCJ) n'est pas un programme qui se porte comme ça, sans savoir comment il marche.

>je c Kevin, mais je te soutiens ...

Yora...>pkoi tu veux faire ca au fait ?

Kevin Kofler a écrit :
Au fait, si tu n'as pas envie d'apprendre en détail le fonctionnement de GCC (y compris les termes et les méthodes de travail de développeurs Unix, style diff, patch, ./configure, ..., ainsi que l'utilisation de MSYS), oublie ton idée de porter GCJ. GCC (et donc aussi GCJ) n'est pas un programme qui se porte comme ça, sans savoir comment il marche.

Ugh ! Je suis qqun qui met du tps a demarrer, mais ca finit un jour ou l'autre a arriver
J'ai un peu utilise diff & co, mais j'avoue mal connaitre ...
Je mettrais le tps qui faut. Et meme si ca sort jamais ( probable ) j'aurais appris pas mal de chose.

nEUrOne a écrit :
>je c Kevin, mais je te soutiens ...
Yora...>pkoi tu veux faire ca au fait ?

Lol la ligue anti-TiGCj ( qui a dit que je manque d'imagination pour le nom ? )
Je veux faire ca pour :
1) me defouler, un projet ca fait tjs du bien
2) essayer de faire evoluer de 0.0001 % la plate forme ti68k
3) pour les adeptes du java, allergique aux pointeurs et autre malloc.

Donc, en fait, tu comptes faire un truc qui sera enorme et lent pour faire evoluer ...

moi, je compte faire un assembleur en basic ....

Tu es un commercial nEUrOne ... tu traite une hypothèse sans les autres

De tte facon je le ferais pas maintenant, faut d'abord que je rode mon esprit a TIGCC. Vu que j'ai d'autre projet en cours, ca va etre, mmm, reporté !

Tu comptes faire un assembleur en basic ? Tres bonne initiative, ca rulezzz !

PS : Sur ce, bonne nuit !

et il n'entendi pas le ton ironique de son interlocuteur ...

Bon, pour donner quelques elements de repone a un peu tout le monde, comme l'a dit parfaitement Kevin et contrairement a ce qu'a di t Pollux, il n'y a pas de probleme de melange de code et de données, et le probleme qu'il est possible de rencontrer avec d'autre langage, car l'essence meme de java est d'etre un byte cote qui est compilable a la volée ce qui implique de pouvoir le traiter parfaitement sans erreur possible.

De plus il ne faut pas traiter le code source, ca serait un erreur monumentale, mais il faudrait traiter le bytecode deja créé! qui lui est optimisé et pour etre changé en code machine, et meme optimisé tout court, reprendre les sources serait une idiotie! ca serait faire 2 fois le travail!
C'est tres simple de passer d'un byte code a un code compilé, en tout cas, bien plus que de passer d'un source a un autre source!
ca serait faire un compilateur simplifié en quelques sorte!
Mais en partant du principe que c'est possible, il faudrait deja faire le tri entre les fonctions en fonctions utilisables et les classes utilisables et celles trop gourmandes, et j'en passe, et qui est-ce qui serait capable de produire la masse de librairies nécessaires, et code natif correspondant a de nombreuses classe, permettant d'en faire un noyau de code utilisable?
Vive l'utopie!

freka a écrit :
De plus il ne faut pas traiter le code source, ca serait un erreur monumentale, mais il faudrait traiter le bytecode deja créé! qui lui est optimisé et pour etre changé en code machine, et meme optimisé tout court, reprendre les sources serait une idiotie! ca serait faire 2 fois le travail! C'est tres simple de passer d'un byte code a un code compilé, en tout cas, bien plus que de passer d'un source a un autre source!

Je te signale que GCJ peut partir du code source et du bytecode au choix de l'utilisateur (et il peut aussi compiler du code source en bytecode), et que selon ce qui est dit (je n'ai jamais essayé GCJ), il donne en général du code meilleur si on part directement du code source.

Kevin, il me semble bien etonnant d'arriver a un meilleur code en partant du source, il me semble plus logique de partir du byte code d'apres ce que je connais de Java, mais dans le cas que tu presente, le resultat peut dependre de beaucoup de facteurs d'implementation qui selon l'un ou l'autre peuvent en favoriser un.