AS, il en est où ? - Page 8

Non, pas forcement C++, mais un langage au moins orienté objet... Et quand on a un certain niveau (comme PpHd), bah c'est pas "LA MORT" comme tu dis

oué, après tout...
PpHd> tu étais sérieux ?

sur PC, il y a quoi d'autres comme langages orientés objet ?
(je suis pas trop connaisseur dans ce truc là : la prof nd'algo nous a parlé d'un truc sorti en 1968, qui aurait été le premier... mais sans plus )

Arrêtez avec vos langages orientés objet!
Cf. http://tigcc.ticalc.org/doc/faq.html#5.

Bon, pour en revenir au sujet, c'est a dire à AS, parlons du mode Kernel. J'ai pas tout compris aux nouveaux trucs qu'il y a dans PreOS, donc, je ne ferais le mode kernel que si quelqu'un (PpHd?) écrit une doc claire et détaillée sur le format du mode kernel. (plus claire que celle qui est dans DoorsOSd de préférence)
vala

/me supplie PpHd d'aider Nitro !!!!!!!!!!

/me attend le mode Kernel avec impatience !!! (pr pouvoir utiliser les libs en ASM... vu que je code en ASM que pour ça ou presque)

Primo, KK, arrete un peu de le prendre pour Dieu supreme devant l'eternel
Secundo, ca sera un VRAI language oriente objet (ie pas du C++), avec heritage multiple, un fichier par classe, des assertions, etc (Si je le fais) et beaucoup de contraintes (par exemple, pas de fonctions, seulement des methodes).
Tertio, le truc tout pourri de doorsosd est assez explicite, une fois compris.

Tu n'as qu'a utiliser le code de object.cc dans PreOS 0.50. je vais pas le copier, il est trop long.

[edit]Edité par PpHd le 28-01-2002 à 19:19:09[/edit]

pas de fonctions ?
heu... ça va qd même être dur : tout le monde a l'habitude d'en utiliser... même si énormément de choses sont gérables par objets !

Pas forcement. Tu creer une classe program, puis tes variables globales, puis tes methodes a l'interieur de ta classe sont comme des fonctions. A autre chose, seules les methodes seront de domaine public.

houla
ben... vivement que j'attaque l'orientation objet... demain en cours... histoire de comprendre tout ça.

L'héritage multiple existe aussi en C++. Et plus de contraintes veut dire du code encore moins efficace, notamment si les contraintes obligent à utiliser de l'orienté objet.
Ça me surprend énormément de la part d'un fan de l'optimisation maximale de parler de code orienté objet, qui est le contraire exact de l'optimisation (du moins dans la famille de la programmation procédurale).

Kevin, l'idée ici n'est pas de produire du code optimal, pour ça il y a l'asm. En t'écoutant on a l'impression que tu ne connais pas le plaisir que c'est de programmer en orienté objet ?

squale92 : Je m'occupe de la mise à jour de ta doc
Pour rédiger le reste, il suffit que tu remplaces byte par char, word par short, et long par ...

PpHd : bon courage ...........

Bon, rapidement pour ceux qui veulent essayer CC pour voir ce que ça donne, c'est ICI.
Ca marche avec la derniere version de AS, qui se trouve ICI.

Je rappelle que c'est du C K&R, et on peut utiliser les ROM CALLs (rajoutez-les dans ams_c avec un offset négatif, comme avec l'exemple pour ST_helpMsg).
Pas de préprocesseur pour l'instant, donc ni #include ni #define, mais le reste marche.
CC n'est pas encore adapté pour SIDE, il faut faire la compilation et l'assemblage à la main. Les fichiers d'entrée et de sorties ont des noms fixés: csrc -> asmsrc

Amusez-vous bien les alpha-testers

Kernel required (desolé)
[edit]Edité par Nitro le 28-01-2002 à 22:42:17[/edit]

bah je vais essayer ça demain matin pdt le sport, ça tombe bien je me suis niké le dos et jepeut rien faire

>L'héritage multiple existe aussi en C++.
Mais oui. As-tu essaye de t'en servir ?
C'est tres mal foutu

> Et plus de contraintes veut dire du code encore moins efficace, notamment si les contraintes obligent à utiliser de l'orienté objet.
Et alors ? C'est pas le but d'un language oriente objet, non ?
Surtout que derriere un s.x = 2
Doit etre genere un code style :
move.w x_off(a0),d0
lea base(a0,d0.w),a1
move.w #2,(a1)
Puisque x peut etre redirige.

>Ça me surprend énormément de la part d'un fan de l'optimisation maximale de parler de code orienté objet, qui est le contraire exact de l'optimisation (du moins dans la famille de la programmation procédurale).
Mais ca supportera l'assembleur inline

Nitro> vivement ce week-end, que je puisse tester ça !!!

PpHd, que penses-tu d'un assembleur structuré orienté objet ? Ca ferait taire les HPistes avec leur MASD (assembleur avec des structures de controle) une bonne fois pour toute

PpHd> en gros, si on vuet un code pas optimisé, on utilise l'objet... et si on veut un code optimisé, l'ASM, c'est ça ?

Bof les HPist ont de bonnent années devant eux....

arf...
HP vs TI, l'écrat se réduit, non ?

PpHd, l'assembleur inline n'est pas une excuse pour un langage totalement inefficace! Sinon, allez, on va tous programmer en TI-BASIC. Si c'est trop inefficace, on utilise des codes Exec. C'est le résultat direct de ce genre d'attitude, et c'est vraiment très idiot à mon avis. Je suis absolument contre l'orienté objet. Surtout s'il faut générer 3 lignes au lieu d'une seule, sous le prétexte de pouvoir "rediriger" des membres d'une classe/structure! Je ne comprends pas comment cette idée puisse plaire à quelqu'un qui a la réputation d'être un "dieu de l'optimisation". Moi, je suis entièrement d'accord avec Zeljko: OOP sur calculatrice -> poubelle. Mais je suis même contre l'OOP en général.

>Moi, je suis entièrement d'accord avec Zeljko: OOP sur calculatrice -> poubelle

Tu déformes les propos de Zeljko, il a dit C++ sur calculatrice -> poubelle... il ne faut pas confondre C++ et OOP.

>Mais je suis même contre l'OOP en général

Donc j'avais raison, tu fais partie de ceux qui n'ont pas compris l'interet de l'OOP.

Mais ne laissons pas le topic partir en débats inutiles, puisque tout le monde voit bien que j'ai raison (). Et revenons au sujet.

PpHd et les autres: il n'y aura pas de mode kernel tant qu'il n'y a pas une doc claire et détaillée du format du stub. ProgFormat.txt c'est bien gentil, mais comme dirait Xavier "Sorry this file is not very well explained yet". Alors quels sont les formats des labels à detecter pour les mettre dans le stub, quels sont les différents flags, comment on les active, etc... j'ai pas l'intention de lire 36 docs et code sources pour trouver tout ça.
[edit]Edité par Nitro le 29-01-2002 à 19:35:28[/edit]

Pour ceux qui auraient par hasard pensé à essayer CC, et qui auraient rencontré des problème de plantage, vérifiez bien que AS et CC sont toujours archivés (ces programmes s'autodétruisent lorsqu'ils sont lancés en RAM )

>>Moi, je suis entièrement d'accord avec Zeljko: OOP sur calculatrice -> poubelle
>Tu déformes les propos de Zeljko, il a dit C++ sur calculatrice -> poubelle... il ne faut pas confondre C++ et OOP.

Parce que le langage que veut PpHd est plus efficace que le C++??? Les 3 lignes de code généré qu'il a postées disent exactement le contraire (que c'est encore moins efficace que le C++).

>Pour ceux qui auraient par hasard pensé à essayer CC, et qui auraient rencontré des problème de plantage, vérifiez bien que AS et CC sont toujours archivés (ces programmes s'autodétruisent lorsqu'ils sont lancés en RAM )

J'ai remarqué.
La compression ExePack, ça te dit quelque chose? La dernière version compresse aussi les programmes pour kernel. Et ça évite ce genre de problèmes.

>PpHd et les autres: il n'y aura pas de mode kernel tant qu'il n'y a pas une doc claire et détaillée du format du stub.
Desole mais c'est relativement bien detaille. Pourquoi tu repompes pas le code de prgm.cc ?

>KK:Parce que le langage que veut PpHd est plus efficace que le C++??? Les 3 lignes de code généré qu'il a postées disent exactement le contraire (que c'est encore moins efficace que le C++).
Ca n'a pas pour but d'etre efficace mais d'etre 100% oriente objet.
Un language oriente objet n'a pas pour finalite d'etre performant. Il existe d'autres languages pour. Il a pour but d'etre abstrait.

>La compression ExePack, ça te dit quelque chose? La dernière version compresse aussi les programmes pour kernel. Et ça évite ce genre de problèmes

Je ne penses pas que les programmeurs aprécient de perdre 45 secondes à chaque compilation. Deja on m'a demandé de mettre une version non compressée de AS (alors que j'utilisais toujours ExePack avant), alors pour CC qui est 3 fois plus gros ce n'est meme pas la peine d'y penser.
L'idéal serait d'avoir un ExePack qui te laisserai le choix du ratio vitesse / taux de compression, en utilisant plusieurs algo différents.

>Desole mais c'est relativement bien detaille. Pourquoi tu repompes pas le code de prgm.cc

Parce que je trouve ça mal fait, ce n'est pas adapté à mon cas (et je ne veux pas d'un AS qui fait 60 Ko), donc je prefere le faire proprement moi meme... enfin bon, tant pis pas de mode kernel.
[edit]Edité par Nitro le 30-01-2002 à 14:08:35[/edit]

File moi les bases de données d'as et je te le tape :
Et franchement ca ne sert qu'a perdre du temps d'utiliser exepack avec des compilateurs.

>PpHd:

>Ca n'a pas pour but d'etre efficace mais d'etre 100% oriente objet.
>Un language oriente objet n'a pas pour finalite d'etre performant. Il existe d'autres languages pour. Il a pour but d'etre abstrait.

Et tu veux donc encore plus aider les programmeurs à être paresseux et à ne pas programmer de manière efficace avec des langages faits pour? L'introduction du C avec TIGCC a déjà fait assez de dégats sur ce point là, il ne faut pas faire encore plus de concessions aux programmeurs paresseux.

>>PpHd et les autres: il n'y aura pas de mode kernel tant qu'il n'y a pas une doc claire et détaillée du format du stub.
>Desole mais c'est relativement bien detaille. Pourquoi tu repompes pas le code de prgm.cc ?

Le minimum qu'il faudra faire, c'est rajouter de manière claire les nouveautés de PreOs et où et comment elles sont stockées. J'en ai besoin si je veux adapter obj2ti à ces nouveautés, et je pense que Nitro en aura besoin lui aussi.

>Et franchement ca ne sert qu'a perdre du temps d'utiliser exepack avec des compilateurs.

Ça sert à:
- réduire la consommation de mémoire permanente, sachant qu'on n'a que 640 KO d'archive (ou 1 MO pour les 2 ou 3 chanceux qui ont un prototype de la V200)
- dans le cas de AS et de CC, éviter que ça plante si le programme est désarchivé
[edit]Edité par Kevin Kofler le 30-01-2002 à 16:13:06[/edit]

>Et tu veux donc encore plus aider les programmeurs à être paresseux et à ne pas programmer de manière efficace avec des langages faits pour?
>L'introduction du C avec TIGCC a déjà fait assez de dégats sur ce point là, il ne faut pas faire encore plus de concessions aux programmeurs
>paresseux.
Bah de toute facon, il y a de grandes chances pour que je ne le fasse pas.

>Le minimum qu'il faudra faire, c'est rajouter de manière claire les nouveautés de PreOs et où et comment elles sont stockées. J'en ai besoin si je
>veux adapter obj2ti à ces nouveautés, et je pense que Nitro en aura besoin lui aussi.
Ok je rajouterais dans Preos une doc plus claire sur le format.

>- réduire la consommation de mémoire permanente, sachant qu'on n'a que 640 KO d'archive (ou 1 MO pour les 2 ou 3 chanceux qui ont un
>prototype de la V200)
Pour un compilateur utilise souvent, c'est une perte de temps dnas le processus de developement.

>- dans le cas de AS et de CC, éviter que ça plante si le programme est désarchivé
Moui.

>Ok je rajouterais dans Preos une doc plus claire sur le format

Aah, on a gagné, bien joué Kevin

Et sérieusement, pourquoi dépendre encore de fichiers que l'on ne trouve que dans DoorsOS alors que c'est totalement dépassé ? Regarde qui est encore tres bien classé dans les downloads de ticalc.org... c'est pas cool.