Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation C » Orienté objet avec TIGCC (113 réponse(s))

./POST DE DEPART (post n°0) Marquer comme non lu.

Jfg

Ecrit le: Vendredi 30 juin 2006 à 22:18

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

"the original implementation of C++ consisted of a preprocessor that translated the C++ syntax into C source code."
source

Ca serait possible que quelqu'un trouve et inclus un tel preprocesseur à TIGCC?

Kill Mario

./Post n°1 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 1er juillet 2006 à 00:24

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Ce serait carrément dingue, les préprocesseurs en question processaient un "C++" très antique, le C++ actuel n'est plus traîtable de la sorte, à moins de générer du code C totalement illisible. Si tu veux du C++, porte g++. Mais quelle que soit la solution envisagée, aucune ne résout le problème fondamental que les classes C++ sont un gaspillage de place. Regarde ce que donne Moka: un Hello World de 15 KO! #roll#

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°2 Marquer comme non lu.

Onur

Ecrit le: Samedi 1er juillet 2006 à 00:36

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

Apres ... Hello World = 15Ko n'implique pas Mario = 150 Mo ... faudrait voir si la taille du code produit en fonction de la grosseur du programme n'est pas linéaire mais plutot affine.

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°3 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 1er juillet 2006 à 00:44

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Et ça change quoi? Même si le Mario fait 64 KO au lieu de 49 KO, c'est inacceptable. Et si ce sont 65 KO, c'est totalement inacceptable vu que ça ne compile même plus.

./Post n°4 Marquer comme non lu.

Jfg

Ecrit le: Samedi 1er juillet 2006 à 00:50

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

1/ le hello world fait 15ko parcequ'il utilise des classes énormes et inadaptées à la prog TI.
2/ je ne veux pas du C++ complet, mais d'un préprocesseur capable de gérer les bases de l'OO.

Kill Mario

./Post n°5 Marquer comme non lu.

Onur

Ecrit le: Samedi 1er juillet 2006 à 00:58

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

Tout dépend où on se situe pour faire concession au niveau de la taille.
Si le OO va te permettre de simplifier grandement la tache pour faire ton truc et que tu es pret à sacrifier 10% en taille, c'est toi qui vois...

On peut gerer > 65Ko, si le "compilateur" "C++ to C" genere des dll

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°6 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 1er juillet 2006 à 06:53

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Onur :
Tout dépend où on se situe pour faire concession au niveau de la taille.
Si le OO va te permettre de simplifier grandement la tache pour faire ton truc et que tu es pret à sacrifier 10% en taille, c'est toi qui vois...

On peut gerer > 65Ko, si le "compilateur" "C++ to C" genere des dll

Les DLLs sur TI, c'est nul, surtout vu le bordel que c'est avec la protection anti-exécution des HW >=2.

./Post n°7 Marquer comme non lu.

Sasume

Ecrit le: Dimanche 2 juillet 2006 à 16:43

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

jf> Tu peux jeter un coup d'oeil là-dessus, je ne sais pas ce que ça vaut : http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html

./Post n°8 Marquer comme non lu.

Sasume

Ecrit le: Dimanche 2 juillet 2006 à 16:53

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Regarde ça aussi, ça peut être utilisable : http://users.pandora.be/stes/compiler.html

./Post n°9 Marquer comme non lu.

Vertyos

Ecrit le: Lundi 3 juillet 2006 à 12:05

Membre

Messages: 165

Membre n°172

Inscrit le 30 mars 2004

Kevin Kofler :
Et ça change quoi? Même si le Mario fait 64 KO au lieu de 49 KO, c'est inacceptable. Et si ce sont 65 KO, c'est totalement inacceptable vu que ça ne compile même plus.

Moi j'en connais beaucoup qui se fichent totalement d'avoir un Mario qui fait 64Ko au lieu de 49Ko, tant qu'il est aussi bien et qu'il tourne quasiment aussi vite... Une fois encore, ce n'*est* pas inacceptable, *tu trouves* ça inacceptable (curieux qu'après tant d'années tu ne saches toujours pas faire la différence

)

Membre de [ yAronet ]

(et de [ 3l33t ] aussi, mais chut, coté obscur toussa...)

./Post n°10 Marquer comme non lu.

Quésoft

Ecrit le: Mercredi 11 octobre 2006 à 22:14

Membre: Habitué

Messages: 56

Membre n°90

Inscrit le 08 mars 2004

Kevin Kofler :Regarde ce que donne Moka: un Hello World de 15 KO! #roll#

Désolé de remonter le sujet, mais un Hello World prend 15Ko que lorsqu'il est fenêtré. 15 Ko, inclu le runtime de l'environnement graphique (codé en Moka). C'est beaucoup (beaucoup trop diront certains) - alors l'utilité d'un API graphique est contestable, mais ce n'est pas outrageant pour les fonctionnalités du Gestionnaire graphique.

La vérité, c'est qu'un programme Moka comme celui là prend 1327 octets:

import moka.lang.System;
public class Hello {
public static void main () {
System.println("Bonjour le monde !");
System.read();
}
}

Il y a aussi moyen de descendre à peu près 400K en désactivant les features OO avec NoInstanciation (mais en conservant les classes et le polymorphisme des méthodes).

Pour revenir à l'orienté objet, mettons qu'un runtime de 1K, c'est pas la fin du monde ... surtout que Moka pourrait être optimizé encore d'avantage.

./Post n°11 Marquer comme non lu.

Quésoft

Ecrit le: Mercredi 11 octobre 2006 à 22:19

Membre: Habitué

Messages: 56

Membre n°90

Inscrit le 08 mars 2004

Je suis tout à fait d'accord avec Vertyos: l'important c'est que ça fasse la job (temps de réponse acceptable, etc.), ensuite, c'est la facilité de maintenance et finalement, c'est l'élégance. Le tight, c'est beau, mais selon moi, quand on se met à jetter aux poubelles l'élégance pour optimiser d'avantage, c'est rendu trop loin.

./Post n°12 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 12 octobre 2006 à 07:38

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Quésoft :
La vérité, c'est qu'un programme Moka comme celui là prend 1327 octets:

import moka.lang.System;
public class Hello {
public static void main () {
System.println("Bonjour le monde !");
System.read();
}
}

L'équivalent TIGCC:

#include <tigcclib.h>

void _main(void)
{
puts("Bonjour le monde !\n");
ngetchx();
}

prend 411 octets (taille on-calc, avec SAVE_SCREEN activé et le SET_FILE_IN_USE_BIT automatique à cause de l'utilisation de ngetchx).
EDIT: 407 avec OPTIMIZE_ROM_CALLS.

Quésoft :
Je suis tout à fait d'accord avec Vertyos: l'important c'est que ça fasse la job (temps de réponse acceptable, etc.), ensuite, c'est la facilité de maintenance et finalement, c'est l'élégance. Le tight, c'est beau, mais selon moi, quand on se met à jetter aux poubelles l'élégance pour optimiser d'avantage, c'est rendu trop loin.

Je pense qu'on est à peu près d'accord là-dessus (J'ai horreur du code illisible de Lionel Debroux juste pour économiser 10 octets ou quelques cycles, genre du "C" où une ligne sur 2 est de l'ASM inline!), le problème est que nos définitions de "élégance" ne correspondent pas.

Et sinon, pour moi, la taille du code produit est quand-même importante. À la limite, on n'est pas à 10 octets près, mais Moka dépasse les bornes (enfin, en non graphique ça a l'air quand-même plus potable). Il faut voir ce qu'on gagne et ce qu'on perd dans le tradeoff. Je ne considère pas l'OO comme une fonctionnalité pour laquelle il vaille le coup sacrifier des KO sur une calculatrice.

Quant à l'environnement graphique, ne vaudrait-il pas mieux wrapper l'API existante de AMS? Il y a des fonctions pour dialogues, menu, fenêtres et affichage graphique dans AMS. Un wrapper OO simple pour les dialogues AMS ne prendrait probablement pas 15 KO.
-Edité le Jeudi 12 octobre 2006 à 07:39 par Kevin Kofler-

./Post n°13 Marquer comme non lu.

Quésoft

Ecrit le: Jeudi 12 octobre 2006 à 15:14

Membre: Habitué

Messages: 56

Membre n°90

Inscrit le 08 mars 2004

Kevin Kofler :
L'équivalent TIGCC:

#include <tigcclib.h>

void _main(void)
{
puts("Bonjour le monde !\n");
ngetchx();
}

prend 411 octets (taille on-calc, avec SAVE_SCREEN activé et le SET_FILE_IN_USE_BIT automatique à cause de l'utilisation de ngetchx).
EDIT: 407 avec OPTIMIZE_ROM_CALLS.

Cet équivalent, en Moka, prennait 441 octets avec TIGCC 0.95 (peut être que les 40 octets viennent d'optimisations introduites dans la version 0.96, je ne l'ai pas recompilé):

import moka.lang.No_Instanciation;
import moka.lang.No_SaveScreen;
import moka.lang.No_GhostSpace;
import moka.lang.System;
public class Hello implements No_Instanciation, No_GhostSpace, No_SaveScreen {
public static void main () {
  System.println("Bonjour le monde !");
  System.read();
  }
}

On peut se demander à quoi sert Moka sans OO, c'est vrai, mais ça démontre que malgré le peu de maturité de Moka, c'est un préprocesseur flexible. Je ne me souviens plus pourquoi, mais j'avais du réimplanter le save screen dans Moka. Cela doit compter pour une part des 1000 octets d'overhead.

Kevin Kofler :
Je pense qu'on est à peu près d'accord là-dessus (J'ai horreur du code illisible de Lionel Debroux juste pour économiser 10 octets ou quelques cycles, genre du "C" où une ligne sur 2 est de l'ASM inline!), le problème est que nos définitions de "élégance" ne correspondent pas.

En plus, je présume que ces optimisations sont plus ou moins portables entre les versions d'AMS. Lorsqu'il faut modifier son programme à chaque release de TIGCC ou parce qu'une nouvelle version de l'AMS est sortie, c'est vrai que ça n'a pas de bon sens.

Je ne suis pas sûr que nos définitions de l'élégance soient si différentes. Je suis un traditionnaliste qui croit au vieux dicton voulant que l'élégance, c'est lorsqu'il ne reste plus rien à enlever, plutôt que lorsqu'il ne reste plus rien à ajouter. Par contre, c'est plus le code et l'algo que j'évalue que le rapport taille/vitesse. Aussi, il faut faire la distinction entre un programme utilitaire d'au plus quelques pages de code et une grosse application développé par un grand nombre de personne. Dans le premier cas, c'est plus facile de faire dans l'artistique.

Kevin Kofler :
Et sinon, pour moi, la taille du code produit est quand-même importante. À la limite, on n'est pas à 10 octets près, mais Moka dépasse les bornes (enfin, en non graphique ça a l'air quand-même plus potable). Il faut voir ce qu'on gagne et ce qu'on perd dans le tradeoff. Je ne considère pas l'OO comme une fonctionnalité pour laquelle il vaille le coup sacrifier des KO sur une calculatrice.

Sur TI, je suis d'accord que la taille est très importante. Avoir privilégié la vitesse d'exécution avant la taille dans la programmation de l'API et du préprocesseur a été une erreur selon moi. Au moins, l'overhead en temps d'exécution est minimal.

Moka, avec son modèle OO et son API actuels est potable selon moi. Par contre, un refactoring pourrait donner un pré-processeur vraiment optimisé et un nouvel API pourrait privilégier la taille.

Kevin Kofler :
Quant à l'environnement graphique, ne vaudrait-il pas mieux wrapper l'API existante de AMS? Il y a des fonctions pour dialogues, menu, fenêtres et affichage graphique dans AMS. Un wrapper OO simple pour les dialogues AMS ne prendrait probablement pas 15 KO.

J'ai pensé le faire après avoir releasé Moka, mais les dialogues AMS sont plus limités (on ne peut pas 'switcher' entre des fenêtres superposées (si ma mémoire est bonne) et il n'y a pas de curseur. Cependant, il est vrai que ce serait moins gourmand en mémoire. L'API du GEM, par contre, est très semblable au AWT de Java, alors il reste intéressant à des fins éducatives.
-Edité le Jeudi 12 octobre 2006 à 16:51 par Quésoft-

./Post n°14 Marquer comme non lu.

Quésoft

Ecrit le: Lundi 16 octobre 2006 à 18:02

Membre: Habitué

Messages: 56

Membre n°90

Inscrit le 08 mars 2004

Je pense travailler sur un nouveau préprocesseur vraiment minimaliste qui serait compatible avec toutes les compilateurs supportant l'Ansi C (incluant TIGCC). Cela ressemblerait à Moka, mais il n'y aurait pas d'API dans un premier temps, et ce ne serais qu'un outil pour définir des classes et être en mesure de les instancier, un peu comme Objective C (mais je vois une syntaxe plus proche du java). Je ne sais pas si des gens d'ici serait intéressé à en discuter.

Un programme pourrait ressembler à ça (pc):

public class Toto {
  public void test() {
    printf("Hello!");
  }
}

int main() {
  Toto t = new Toto();

  t.test();

  delete t;
}

./Post n°15 Marquer comme non lu.

Onur

Ecrit le: Lundi 16 octobre 2006 à 18:39

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

une sorte de compilateur minijava -> c ?
moi je trouve ca intéressant.

Si tu le portes sur TI, une lib de base avec un tilemap engine permettrait de faire de pures jeu en dérivant une classe sprite par exemple.

je vois bien le truc où on définit une classe pour les méchant en dérivant de Ennemy, une classe pour le bonhomme qu'on controle en dérivant de ControlablePlayer etc.. avec des méthodes qui gèrent les collisions et écrits en assembleur de manière optimisé.

Là, le rapport (plutot la multiplication) facilité_de_programmation * qualité_du_jeu serait énorme.

Je te fais un IDE (ou j'adapte celui de ETP) pour dessiner facilement les sprites de chaque classe, et voila on a un pur truc.

Mais il faudrait vraiment que tu fasses un vrai compilo, je veux dire par là que le code produit ne doit pas donner d'erreur sur tigcc, que ton compilo doit etre capable de voir les erreurs. En gros tu dois faire les premieres phases de compilation (analyse syntaxique et sémantique) sinon ce n'est pas un compilo, j'appellerais ca plutot un translator.

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°16 Marquer comme non lu.

Quésoft

Ecrit le: Lundi 16 octobre 2006 à 20:43

Membre: Habitué

Messages: 56

Membre n°90

Inscrit le 08 mars 2004

Des bonnes idées, Onur

Ce que je pensait faire était effectivement un 'minijava', mais vraiment mini... Du style C++ lite. Je vois ça comme un plugin pour TIGCC (ou pour un autre compilateur). Par contre, comme proposé, le convertisseur pourrait avoir son propre IDE qui ferait la conversion puis appellerait TIGCC en ligne de commande.

Je ne pense pas fournir un API en premier lieu, mais le préprocesseur fonctionnera out of the box pour TIGCC ou pour GCC sur PC, même si les programmes des utilisateurs ne seront probablement pas portables. Cependant, on peut imaginer développer un API qui assurerait cette portabilité, mais je n'en ferai pas un dans l'immédiat (l'API de Moka a été plus long à faire que le compilateur).

Je vais coder le convertisseur avec GCC, alors ce sera multiplateforme. Maintenant, il faut décider des spécifications du langage...

./Post n°17 Marquer comme non lu.

Quésoft

Ecrit le: Lundi 16 octobre 2006 à 20:49

Membre: Habitué

Messages: 56

Membre n°90

Inscrit le 08 mars 2004

Pour la vérification de syntaxe, je pense traiter la syntaxe java uniquement (ex: s.value = "toto"; Erreur: Assignation illégale. Une instance de String n'a pas d'attribut public 'value'. - ou encore - s.toStrn(); Erreur: Une instance de String n'a pas de méthode publique 'toStrn'.) et laisser le reste au compilateur C (parce que ce sera du C).

./Post n°18 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 16 octobre 2006 à 21:42

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Je ne vois pas trop l'intérêt d'un truc comme ça par rapport à un vrai frontend GCC, par exemple un portage de g++ et/ou GCJ. (Cela dit, je suis contre ce genre de portages aussi, je trouve que la programmation objet n'a rien à faire sur une calculatrice.)

./Post n°19 Marquer comme non lu.

Quésoft

Ecrit le: Lundi 16 octobre 2006 à 22:52

Membre: Habitué

Messages: 56

Membre n°90

Inscrit le 08 mars 2004

Kevin Kofler :
Je ne vois pas trop l'intérêt d'un truc comme ça par rapport à un vrai frontend GCC, par exemple un portage de g++ et/ou GCJ. (Cela dit, je suis contre ce genre de portages aussi, je trouve que la programmation objet n'a rien à faire sur une calculatrice.)

Entre autre, un préprocesseur représente moins de travail et surtout, un simple support des classes sera moins lourd qu'une implémentation du C++ (d'où pourquoi un programme Moka ne pard pas à 5Ko). En plus, ce nouveau préprocesseur, comme je le conçoit, ne produira que de l'ANSI C et ne sera pas dépendant d'un API pour fonctionner (ceci dit, développer un API pour faciliter la prog 68K ne sera pas inintéressant). Ainsi, ce même préprocesseur servira indiscriminament aux programmeurs C sur PC ou sur TI.

J'ai une question technique:

Dans le modèle OO de Moka, les pointeurs vers les fonctions sont gardés avec les attributs de l'objets, donc chaque objet en a une copie. C'est mauvais pour l'empreinte mémoire, mais c'est assez rapide (une déréférenciation au lieu de 2 pour une table séparée).

Pour les interface (qui induisent une gestion des méthodes analogue à celle de l'héritage multiple), j'ai dut employer une autre technique: chaque signature de méthode a un vecteur qui pointe vers les fonctions e.g.

int (**int_count_) (TObject*); //La syntaxe est à vérifier, ça faut un bout que je n'ai pas touché au C

int_count_[reference_de_l_objet->id](reference_de_l_objet)//code d'une invocation

id est un numéro séquentiel identifiant uniquement chaque classe.

Qu'est-ce que l'on devrait utiliser pour notre minijava ? La technique originale de Moka, celle du C++ (l'objet en mémoire garde un pointeur vers une table de pointeurs) ou celle du FMI (celle des interfaces en Moka) ?

Moi, j'irais pour celle du FMI.
-Edité le Lundi 16 octobre 2006 à 23:18 par Quésoft-