30

godzil
a écrit : Sinon meme si tu dit que avec J2ME, on cherche pas a faire du tt objet, java reste un language a tres (tres) forte consonance objet...


Merci de me le rappeller grin

31

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

avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

32

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 ?gni ).
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.

33

Alors:
* Je vois que même freka, qui est un fan du Java, dit que ton projet est infaisable. grin
* Je t'ai déjà dit: il y a déjà un compilateur Java->langage machine: GCJ. Bonne chance pour le porter. grin Nous (l'équipe de TIGCC), on a vraiment d'autres choses à faire.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

34

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"
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

35

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


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

36

yora, regarde du coté du supprt de java pour GCC3, sa pourrait ptet t'aider..
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

37

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. smile
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

38

Finalement ce GCJ est interessant smile
Reste a voir comment implementer J2ME smile

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

39

Si tu veux porter GCJ, commence par le patch TIGCC. smile (GCJ utilise le backend de GCC.)
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

40

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

41

Kevin Kofler a écrit :
Si tu veux porter GCJ, commence par le patch TIGCC. smile (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 ?

42

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.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

43

Oki grin
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.

44

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.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

45

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

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

46

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 smile
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 ... smile
Yora...>pkoi tu veux faire ca au fait ?


Lol la ligue anti-TiGCj ( qui a dit que je manque d'imagination pour le nom ? gni )
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.

47

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

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

48

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

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 !

49

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

50

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! wink

51

top

52

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.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

53

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.