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 » Questions » Question de haut niveau (42 réponse(s))

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

Billy Charvet

Ecrit le: Vendredi 10 septembre 2004 à 16:24

Envoyer un message privé à Billy Charvet

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

Quelqu'un peut-il me dire les modifications précises apportées par les
patchs des outils GNU dans TIGCC et surtout LEUR BUT.

C'est surtout pour supprimer les floats IEEE 754 et les remplacer par le BCD SMAP II
si je ne m'abuse...

Mais est-ce que ça concerne la compilation aussi...?
Bon, j'ai compilé un gcc en cross Linux->m68k-coff.

J'ai sorti quelques listings as, et c'est zarb... j'ai bien l'impression
(mais je demande confirmation) qu'il n'est pas possible de configurer
gcc pour 68000 premier du nom, et que le patch sert en partie à adapter
gcc pour qu'il n'utilise que les instructions 68k.

Est-ce le cas ? Sinon, on a pas grand'chose à faire pour exploiter d'autres langages
comme C++ et Fortran 77 sur nos TI, seulement en faisant une croix sur le BCD SMAP II...
Pour ma part je serais bien tenté, pour Pyrix, de ne pas utiliser le SMAP II.

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°1 Marquer comme non lu.

ZogStriP

Ecrit le: Vendredi 10 septembre 2004 à 18:40

Membre: Disciple

Messages: 106

Membre n°363

Inscrit le 14 juillet 2004

Dsl, je ne peux pas répondre à ta question, mais c'était juste pour dire que même moi qui suit programmeur (sous windows) et qui est considéré par un extra-terrestre par mes amis lorsque je parle prog, alors là, je te decernes le PRIX D'OR DU TEXTE OU L'ON NE COMPREND PAS PLUS DE 2 MOTS PAR PHRASES !

./Post n°2 Marquer comme non lu.

LionelA

Ecrit le: Vendredi 10 septembre 2004 à 19:31

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Mais non, c'est très compréhensible (à moins que je n'y comprenne rien

), c'est juste que la majorité des programmeurs ne connaissent pas la réponse parce qu'ils n'ont pas développé TIGCC, d'où le sous-titre du topic

Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

./Post n°3 Marquer comme non lu.

verytourist

Ecrit le: Vendredi 10 septembre 2004 à 20:28

Membre: Titan

Messages: 973

Membre n°26

Inscrit le 02 février 2004

Je te rassure, c'est très compréhensible par rapport à d'autres postes

-Edité le Vendredi 10 septembre 2004 à 20:29 par verytourist-

./Post n°4 Marquer comme non lu.

geogeo

Ecrit le: Vendredi 10 septembre 2004 à 21:00

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Euh Billy, tu veux avoir une compilation pure 68000 sans tenir compte des spécificités des TI68K?

Pourquoi ne regardes-tu pas la doc dans history? Y a peut être déjà des infos.

Ensuite remplacer les floats IEEE 754, c'est une très très bonne idée.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°5 Marquer comme non lu.

LionelA

Ecrit le: Vendredi 10 septembre 2004 à 21:09

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

je crois que c'est justement le contraire, il veut utiliser les floats IEEE a la place du SMAP II BCD.
Les floats SMAP sont utilisés par tigcc car en fait ils sont déja supportés par AMS et qu'il n'était pas nécéssaire de rajouter du code.
Je ne m'y connais pas trop, alors j'espère pas que ça soit trop faux

./Post n°6 Marquer comme non lu.

geogeo

Ecrit le: Vendredi 10 septembre 2004 à 21:13

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

lol euh oui, j'ai encore dit une bêtise. #rougir#

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°7 Marquer comme non lu.

GoldenCrystal

Ecrit le: Vendredi 10 septembre 2004 à 23:00

Envoyer un message privé à GoldenCrystal

Membre: Vétéran

Messages: 89

Membre n°18

Inscrit le 01 février 2004

BC > t'as essayé de spécifier le target m68000 explicitement en lançant gcc ?

Kupo !

./Post n°8 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 11 septembre 2004 à 02:23

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Billy Charvet :
Quelqu'un peut-il me dire les modifications précises apportées par les
patchs des outils GNU dans TIGCC et surtout LEUR BUT.

Lis le changelog dans les sources... Il y en a des tonnes.

C'est surtout pour supprimer les floats IEEE 754 et les remplacer par le BCD SMAP II
si je ne m'abuse...

C'est un des nombreux changements, et probablement le plus gros, mais pas le seul.

Mais est-ce que ça concerne la compilation aussi...?
Bon, j'ai compilé un gcc en cross Linux->m68k-coff.

J'ai sorti quelques listings as, et c'est zarb... j'ai bien l'impression
(mais je demande confirmation) qu'il n'est pas possible de configurer
gcc pour 68000 premier du nom, et que le patch sert en partie à adapter
gcc pour qu'il n'utilise que les instructions 68k.

Oui, il te manque ce patch-là:

* config/m68k/m68k-coff.h: (TARGET_CPU_DEFAULT, TARGET_DEFAULT): Define.

diff -Naur gcc-3.3.3.orig/gcc/config/m68k/m68k-coff.h gcc-3.3.3.tigcc7/gcc/config/m68k/m68k-coff.h
--- gcc-3.3.3.orig/gcc/config/m68k/m68k-coff.h  Fri Sep  3 19:10:48 1999
+++ gcc-3.3.3.tigcc7/gcc/config/m68k/m68k-coff.h  Thu Feb 19 21:20:02 2004
@@ -24,8 +24,16 @@
#define  USE_GAS
#endif

+/* Define the appropriate flags for the TI's architecture */
+
+#undef TARGET_CPU_DEFAULT
+#define TARGET_CPU_DEFAULT M68K_CPU_m68000
+
+#undef TARGET_DEFAULT
+#define TARGET_DEFAULT ((TARGET_CPU_DEFAULT >> 4) | MASK_SHORT | MASK_TIOS | MASK_MERGE_SECTIONS)
+
#include "m68k/m68k-none.h"
-#include "m68k/m68kemb.h"
#include "m68k/coff.h"
+#include "m68k/m68k-ti.h"

/* end of m68k-coff.h */

Mais tu peux le faire à la main avec -m68000 aussi.

Est-ce le cas ? Sinon, on a pas grand'chose à faire pour exploiter d'autres langages
comme C++ et Fortran 77 sur nos TI, seulement en faisant une croix sur le BCD SMAP II...

Tu rateras aussi les autres patches, dont certains très importants (par exemple le fait que d2 est call-clobbered sous AMS).

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°9 Marquer comme non lu.

Billy Charvet

Ecrit le: Lundi 13 septembre 2004 à 12:57

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

LionelA > Non, ce que tu as dit était tout à fait exact.

Kevin >

Bon, quand est-ce que je spécifie la cible dans la configuration de GCC ?
Je remplace m68k-coff par m68000-coff, c'est ce que vous voulez dire ?

Le truc, c'est que j'ai besoin d'un GCC qui exporterait du COFF 68000
et qui serait modifié au minimum (voir pas du tout).

Est-ce que sous Pyrix (donc en concevant l'OS en tenant compte du GCC en question)
je peux utiliser un GCC non patché ?

Je veux dire par là que l'AMS est l'AMS. S'il utilise son format de floats ça ne me
concerne pas, mais je voudrais savoir si c'est le cas pour tout.
(Ton exemple pour d2, ça peut foirer avec les ROM Calls d'AMS, mais
si je fais Pyrix en prenant ça en compte ça ne pose pas de problème non ?)

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°10 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 14 septembre 2004 à 00:48

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Billy Charvet :
Bon, quand est-ce que je spécifie la cible dans la configuration de GCC ?
Je remplace m68k-coff par m68000-coff, c'est ce que vous voulez dire ?

Non, ce que je veux dire, c'est de passer -m68000 à chaque appel.
Configurer avec m68000-coff, tu peux essayer, mais ça m'étonnerait que ça marche pour changer le TARGET_DEFAULT. Changer les sources est simple et marche en tout cas.

Le truc, c'est que j'ai besoin d'un GCC qui exporterait du COFF 68000
et qui serait modifié au minimum (voir pas du tout).

Et pourquoi, si j'ose demander? Si on modifie GCC, ce n'est pas pour le plaisir de le modifier. #roll#

Est-ce que sous Pyrix (donc en concevant l'OS en tenant compte du GCC en question)
je peux utiliser un GCC non patché ?

En principe oui, mais je ne vois pas trop ce que tu y gagnes.
Des features comme le constant merging ont besoin de patches de GCC par exemple (à moins que tu ne veuilles utiliser le format ELF et le linker GNU; l'implémentation pour le COFF et notre linker a besoin de patches dans GCC et GNU as), et c'est un feature indépendant de l'OS (il dépend juste du linker).

Je veux dire par là que l'AMS est l'AMS. S'il utilise son format de floats ça ne me
concerne pas, mais je voudrais savoir si c'est le cas pour tout.

Je ne vais pas faire ton boulot pour toi. Il y a la liste de tous nos changements dans le changelog, il y a souvent aussi des commentaires expliquant pourquoi on a changé tel et tel truc dans le patch lui-même (dans les lignes rajoutées). À toi de voir lesquels peuvent te servir et lesquels non. Et je pense que tu ferais certainement mieux d'utiliser un sous-ensemble de nos patches que d'utiliser GCC tel quel. GCC tel quel ne gère même pas les chaînes de caractères multilignes (depuis la 3.3) ni les nombres binaires en 0b... (aucune version officielle de GCC ne les gère). En revanche, s'il y a un changement précis que tu ne comprends pas, poste le morceau de patch et/ou l'entrée du changelog (si tu m'en donnes un, je trouverai l'autre) et je te l'explique aussi bien que possible.
-Edité le Mardi 14 septembre 2004 à 00:50 par Kevin Kofler-

./Post n°11 Marquer comme non lu.

Billy Charvet

Ecrit le: Mardi 14 septembre 2004 à 08:41

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

L'intérêt d'un GCC non patché, c'est pas tellement GCC en lui-même, mais plutôt
les autres compilos.

Bon, je verrai bien ce que ça donne....

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°12 Marquer comme non lu.

GoldenCrystal

Ecrit le: Mardi 14 septembre 2004 à 18:10

Membre: Vétéran

Messages: 89

Membre n°18

Inscrit le 01 février 2004

hmm, --with-cpu=m68000 à la configuration ça peut pas marcher sinon ? (pas testé)

les chaînes de caractères multilignes

les nombres binaires en 0b

²
Tu t jamais dit que si ça n'était pas/plus dans gcc c parce que c'était inutile et immonde ?

Kupo !

./Post n°13 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 14 septembre 2004 à 18:49

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Non! Ce n'est pas inutile, Backgammon utilise beaucoup de nombres binaires, par exemple, et tout programme utilisant sérieusement l'assembleur inline utilise les chaînes de caractères multilignes. Et d'ailleurs, il y aura d'autres inversions de patches quand on adoptera GCC 3.4, pour remettre une fois de plus ce qu'ils ont déprécié ou viré (lvalue casts avant tout, TIGCCLIB en a besoin!).

./Post n°14 Marquer comme non lu.

Onur

Ecrit le: Mercredi 15 septembre 2004 à 02:09

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

Billy Charvet :
...mais plutôt
les autres compilos.

Bon, je verrai bien ce que ça donne....

vivement de l'oriente objet!! comme ca y en a plein qui feront des classes toute pretes et on pourra faire des jeux super facilement!!
reste a voir comment supportera la 68k et la TI elle meme... dans la doc de TIGCC c'est ecrit qu'il ont pas pric C++ parce que ca utiliserait trop de memoire.

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

et autres projets à finir avant 2010

./Post n°15 Marquer comme non lu.

Billy Charvet

Ecrit le: Mercredi 15 septembre 2004 à 09:15

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

Perso, je ne suis pas d'accord avec les proportions écrites.
Un prog en C++ n'occupe pas beaucoup plus qu'en C.
(Sauf si on est obsédé de la liaison statique, hein Kevin ?

)

En revanche je trouve que ça fait trop de couches.
Notamment je suis tout à fait contre ces classes toutes prêtes que tout
le monde va utiliser, alors que ça fait mal à la TI...

Donc le C++ n'est pas une priorité. En revanche le Fortran 77, oui,
ainsi que l'Objective-C et l'Ada

(pb: nécessitent des libs statiques... est-ce que
ça va pas poser problème pour les porter...)

Donc le plus rapidement portable est sans doute le Fortran.
(Enfin, on peut aussi essayer le Pascal de gcc-2.95...)

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°16 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 15 septembre 2004 à 13:24

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Billy Charvet :
Perso, je ne suis pas d'accord avec les proportions écrites.
Un prog en C++ n'occupe pas beaucoup plus qu'en C.
(Sauf si on est obsédé de la liaison statique, hein Kevin ?

)

Ben, évidemment qu'un exécutable C++ pour AMS devra être lié statiquement, il n'y a pas de STL C++ dans AMS. Pour Pyrix, c'est une autre histoire. Je t'avertis juste que la GNU libstdc++ a besoin d'une libc complète et d'un grand grade de conformance aux standards de cette libc pour fonctionner. (Elle nécessiterait certainement pas mal de changements pour fonctionner avec TIGCCLIB, par exemple.) Donc prévois de bosser sur ta libc avant même d'essayer de compiler la libstdc++.

(Enfin, on peut aussi essayer le Pascal de gcc-2.95...)

http://www.gnu-pascal.de
La version stable fonctionne avec GCC jusqu'à 3.2.x, la bêta 20040516 aussi avec 3.3.x. (Ils sont en train d'essayer de le faire marcher avec 3.4.x.)
Attention, le runtime de GNU Pascal n'est pas du tout prévu pour le linkage statique et ils refusent de corriger ça: http://www.gnu-pascal.de/crystal/gpc/en/mail9748.html. Et les >200 KO qu'il prend sont peut-être un peu beaucoup pour le mettre en dynamique dans Pyrix...
-Edité le Mercredi 15 septembre 2004 à 13:31 par Kevin Kofler-

./Post n°17 Marquer comme non lu.

Billy Charvet

Ecrit le: Mercredi 15 septembre 2004 à 14:18

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

Dans tous les cas, Pyrix devrait permettre la liaison dynamique
avant que j'y pense.

Mais je pense tout simplifier dans Pyrix.
Par exemple pas de multi-users, on est considéré comme root, dans le groupe
wheel et puis c'est tout. La libc émulera les appels systèmes correspondants,
comme getpid, setuid, etc... et ce ne sera même pas compilé dans le programme.

Je vise comme premier but de permettre un OS avec les 67 appels systèmes
de Linux 0.0.1. Dans Linux, 50 environ étaient vraiment implémentés.
Avec mes astuces je tombe à 37 !
(Rien à voir avec l'AMS côté taille, hein...)

Pour le C++ (et pour tout d'ailleurs) je pensais à alléger de la même
façon. Par exemple, est-il possible de ne pas mettre de libc++ ?
Ou est-ce nécessaire ?
(pour une connerie du genre toutes les classes doivent
hériter d'une classe de base ou qqch comme ça)

Sinon, je mets C++, et pas de STL, les classes devraient être faites
uniquement par l'utilisateur, pour pas prendre trop lourd.
Enfin, le peu nécessaire devrait être mis en dynamique.
Et si ça ne suffit toujours pas, on laisse tomber g++.
Idem pour gpc.

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°18 Marquer comme non lu.

Onur

Ecrit le: Mercredi 15 septembre 2004 à 14:47

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

Billy Charvet :

En revanche le Fortran 77, oui,
ainsi que l'Objective-C et l'Ada

ben j'ai fait ETP-Basic compiler et finalement vu que c'est completement compilé on peut dire que c'est presque de l'Ada.
Le truc c'est que les gens doivent se rehabituer a programmer dans un nouveau langage si ce n'est pas du C++.

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

et autres projets à finir avant 2010

./Post n°19 Marquer comme non lu.

Billy Charvet

Ecrit le: Mercredi 15 septembre 2004 à 15:10

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

Faudra que je jette un coup d'oeil à ton truc.
Ca marche comment ?
Analyse lexical et syntaxique générée avec lex et yacc,
et analyse grammaticale et génération de code à la main ?

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.