GCC 4.2 disponible
Vincent Rivière
Je viens de terminer un portage de GCC 4.2 et des binutils 2.17 pour Atari
ST.
Le tout est disponible ici :
http://vincent.riviere.free.fr/soft/m68k-atari-mint/
Les binaires pour Cygwin sont fournis, permettant de cross-compiler des
programmes ST depuis Windows.
Vincent Rivière
vincent...@freesbee.fr
DOCs croustibat
revenir a GCC sur Atari. En plus, il est possible de generer des symboles au
format DRI, super.
Yvan Doyeux
"Vincent Rivière" <vincent...@freesbee.fr> wrote in message
news:46882a36$0$27148$426a...@news.free.fr...
OL
(jamais reussi à faire le port! j'y ai pourtant passé du temps!). Petite
question le strip fonctionne maintenant?
Bon je vais me tester cela sous peu et puis ca peut cracher du V4e aussi!
Merci vraiement parceque c'est du sacré boulot.
Olivier
Francois LE COAT
Bravo vraiment pour ce travail exemplaire.
Vincent Rivière a écrit :
> Bonjour à vous, amis de l'Atari ST !
>
> Je viens de terminer un portage de GCC 4.2 et des binutils 2.17 pour Atari
> ST.
> Le tout est disponible ici :
> http://vincent.riviere.free.fr/soft/m68k-atari-mint/
>
> Les binaires pour Cygwin sont fournis, permettant de cross-compiler des
> programmes ST depuis Windows.
La fabrication d'un cross-compilateur GCC 4.2 est la première étape
pour concevoir le compilateur natif m68k, qui est construit à partir
des mêmes sources à l'aide du cross-compilateur x86. Reste ensuite la
2ème phase du compilateur natif et le test de l'intégrité.
Est-ce que vous envisagez une cible m68k-atari-mint native ? Je suis
en effet intéressé par un tel outils dans le but de poursuivre le
développement des mes applications ATARI.
Quelles sont vos intentions ?
Merci.
--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/
Philippe Reverdy
"Vincent Rivière" <vincent...@freesbee.fr> a écrit dans le message de
news: 46882a36$0$27148$426a...@news.free.fr...
Vincent Rivière
Oui, le C++ marche bien !
Les templates, les exceptions, la STL...
J'ai même écrit des tests unitaires avec la librairie CppUnit, ça marche
comme il faut !
Eveidemment, ca ne veut pas dire qu'il ne reste pas des bugs.
> Et les binutils
> (jamais reussi à faire le port! j'y ai pourtant passé du temps!). Petite
> question le strip fonctionne maintenant?
Ca a l'air de fonctionner. Attention, il ne faut pas avoir linké avec
--traditional-format, sinon on obtient "File format not recognized".
> Bon je vais me tester cela sous peu et puis ca peut cracher du V4e aussi!
Oui, les versions récentes de binutils gèrent le Coldfire :
$ m68k-atari-mint-as.exe --target-help
...
Architecture variants are: 68000 | 68010 | 68020 | 68030 | 68040 | 68060
| cpu32 | isaa | isaaplus | isab | cfv4 | cfv4e
Processor variants are: 68000 | 68ec000 | 68hc000 | 68hc001 | 68008 |
68302 | 68306 | 68307 | 68322 | 68356 | 68010 | 68020 | 68k | 68ec020 |
68030 | 68ec030 | 68040 | 68ec040 | 68060 | 68ec060 | cpu32 | 68330 |
68331 | 68332 | 68333 | 68334 | 68336 | 68340 | 68341 | 68349 | 68360 |
5200 | 5202 | 5204 | 5206 | 5206e | 5207 | 5208 | 5211 | 5212 | 5213 |
5214 | 5216 | 521x | 5232 | 5233 | 5234 | 5235 | 523x | 5249 | 5250 |
5270 | 5271 | 5272 | 5274 | 5275 | 5280 | 5281 | 5282 | 528x | 5307 |
5327 | 5328 | 5329 | 532x | 5372 | 5373 | 537x | 5407 | 5470 | 5471 |
5472 | 5473 | 5474 | 5475 | 547x | 5480 | 5481 | 5482 | 5483 | 5484 |
5485 | 548x
Quant à GCC... hum... je sais pas.
Vincent
Vincent Rivière
> pour concevoir le compilateur natif m68k, qui est construit à partir
> des mêmes sources à l'aide du cross-compilateur x86. Reste ensuite la
> 2ème phase du compilateur natif et le test de l'intégrité.
>
> Est-ce que vous envisagez une cible m68k-atari-mint native ? Je suis
> en effet intéressé par un tel outils dans le but de poursuivre le
> développement des mes applications ATARI.
>
> Quelles sont vos intentions ?
Mes intentions sont claires : je veux pouvoir écrire des programmes pour
mon vieil STe, en C++ et en assembleur, tout en développant sous Windows.
Le but étant simplement de bricoler, en tirant parti du code optimisé
généré par GCC. Pourquoi pas des démos écrites en C++ :-)
Par contre ne je vois pas l'intérêt de développer directement sur Atari
(je parle du ST) même si c'était techniquement possible. De nos jours il
est bien plus confortable de travailler avec un PC récent sous Windows
ou Linux.
Mais je ne connais pas les nouveaux systèmes compatibles Atari, peut
être sont-ils assez puissants pour faire tourner GCC correctement ? Dans
ce cas, un compilateur natif serait intéressant. Etant donné que les
patchs sont au point pour construire un cross-compilateur, ils devraient
permettre aussi de compiler un compilateur natif ? Reste à savoir si
la MiNTLib est suffisante pour compiler les binutils et GCC.
J'essaierai peut-être de compiler un compilateur natif, histoire de
savoir jusqu'où ça fonctionne, mais je ne compte pas le supporter
activement. Par contre, je suis prêt à soutenir celui qui se lancera
dans l'aventure !
Vincent
OL
> > Ooah p..! Et il y a même le C++ (testé un peu ???)
>
> Oui, le C++ marche bien !
> Les templates, les exceptions, la STL...
> J'ai même écrit des tests unitaires avec la librairie CppUnit, ça marche
> comme il faut !
> Eveidemment, ca ne veut pas dire qu'il ne reste pas des bugs.
Yep!
>
> > Et les binutils
>
> > (jamais reussi à faire le port! j'y ai pourtant passé du temps!). Petite
> > question le strip fonctionne maintenant?
>
> Ca a l'air de fonctionner. Attention, il ne faut pas avoir linké avec
> --traditional-format, sinon on obtient "File format not recognized".
A priori normal et bien mieux que ma version!
>
> > Bon je vais me tester cela sous peu et puis ca peut cracher du V4e aussi!
>
> Oui, les versions récentes de binutils gèrent le Coldfire :
>
> $ m68k-atari-mint-as.exe --target-help
> ...
> Architecture variants are: 68000 | 68010 | 68020 | 68030 | 68040 | 68060
> | cpu32 | isaa | isaaplus | isab | cfv4 | cfv4e
> Processor variants are: 68000 | 68ec000 | 68hc000 | 68hc001 | 68008 |
> 68302 | 68306 | 68307 | 68322 | 68356 | 68010 | 68020 | 68k | 68ec020 |
> 68030 | 68ec030 | 68040 | 68ec040 | 68060 | 68ec060 | cpu32 | 68330 |
> 68331 | 68332 | 68333 | 68334 | 68336 | 68340 | 68341 | 68349 | 68360 |
> 5200 | 5202 | 5204 | 5206 | 5206e | 5207 | 5208 | 5211 | 5212 | 5213 |
> 5214 | 5216 | 521x | 5232 | 5233 | 5234 | 5235 | 523x | 5249 | 5250 |
> 5270 | 5271 | 5272 | 5274 | 5275 | 5280 | 5281 | 5282 | 528x | 5307 |
> 5327 | 5328 | 5329 | 532x | 5372 | 5373 | 537x | 5407 | 5470 | 5471 |
> 5472 | 5473 | 5474 | 5475 | 547x | 5480 | 5481 | 5482 | 5483 | 5484 |
> 5485 | 548x
>
> Quant à GCC... hum... je sais pas.
En fait la réponse est oui je l'ai compilé pour cela, parceque les
autres versions le code généré ce n'était pas trop cela et le V4e
fallait oublier, je confirme cette version permet de compiler pour
coldfire sans trop de soucis majeurs, le code généré est fonctionnel.
Pour une version Atari se serait bien, j'utilise beaucoup gcc sous
Aranym, c'est largement suffisant, utiliser le cross compilo n'est pas
un gros soucis, mais faut passer a tout bout de champs d'une appli à
une autre. Je le ferais bien mais je ne sais pas comment faire, peut
etre le plus simple c'est sous Mint lui meme avec tous les outils,
mais déjà que c'est super long et pénible sur un PC sous Linux alors
sous Mint avec peut être des outils qui ne vont pas et le temps de
compil que cela doit necessiter, cela doit être assez épique et
franchement pénible.
Olivier
Francois LE COAT
Merci pour cette réponse.
Vincent Rivière a écrit :
>> La fabrication d'un cross-compilateur GCC 4.2 est la première étape
>> pour concevoir le compilateur natif m68k, qui est construit à partir
>> des mêmes sources à l'aide du cross-compilateur x86. Reste ensuite la
>> 2ème phase du compilateur natif et le test de l'intégrité.
>>
>> Est-ce que vous envisagez une cible m68k-atari-mint native ? Je suis
>> en effet intéressé par un tel outils dans le but de poursuivre le
>> développement des mes applications ATARI.
>>
>> Quelles sont vos intentions ?
>
> Mes intentions sont claires : je veux pouvoir écrire des programmes pour
> mon vieil STe, en C++ et en assembleur, tout en développant sous Windows.
J'ai moi un Hadès 60, c'est à dire une machine ATARI clone qui possède
les possibilités d'un ATARI TT, mais dont le processeur est un 68060 à
60MHz avec 40Mo de RAM. Par comparaison un STe est un 68000 à 8MHz avec
1Mo de RAM, avec des possibilités graphiques limitées (16 couleurs),
alors que le GEM (OS) permet beaucoup plus. Il est en particulier
impossible d'espérer utiliser MiNT sur une STe. Il y a une carte
graphique PCI dans mon Hadès 60. Il ne faut pas espérer faire grand
choses avec un STe aujourd'hui, surtout avec un système de développement
GCC, qui est bien moins adapté qu'un PURE C (Borland) ou le GFA Basic
<http://www.bright.net/~gfabasic/html/gfa_apps.htm> qui se renouvelle.
Il existe aussi, pour les machines encore utilisées des Falcon 30
c.à.d. un 68030 à 16 MHz avec 14Mo de RAM, mais équipées de cartes
accélératrices à base de 68060 à 100 MHz, qui ont les caractéristiques
d'un Falcon 60.
Le Falcon 30 a fait l'objet du développement d'une machine virtuelle,
qui s'appelle ARAnyM : ATARI Running on Any Machine, qui bénéficie des
ressources, via une machine/OS hôtes moderne (Intel, PPC, Cell sous
Linux, Windows, Mac OS X ...) ici <http://aranym.org/>
> Le but étant simplement de bricoler, en tirant parti du code optimisé
> généré par GCC. Pourquoi pas des démos écrites en C++ :-)
C'est pas la peine d'y penser avec le STe. Pour le C++ encore moins.
Il faut pour cela un 68060, un émulateur, ou encore mieux ARAnyM.
> Par contre ne je vois pas l'intérêt de développer directement sur Atari
> (je parle du ST) même si c'était techniquement possible. De nos jours il
> est bien plus confortable de travailler avec un PC récent sous Windows
> ou Linux.
C'est sûr que développer sur une machine ATARI aujourd'hui n'est pas
très confortable. Mais ce qui importe n'est pas les difficultés que
peuvent rencontrer les développeurs, mais surtout la qualité des
développements produits, surtout quand il s'agit d'applications ATARI.
Par exemple, peu importe que mon application ATARI mette une heure
à se compiler, comme c'est le cas par exemple avec POV-Ray, si la
personne qui utilise ce logiciel ressent la qualité d'un outil
performant, comme c'est le cas avec GCC 4.2. L'important aussi est
que le binaire généré soit correct, ce que je n'ai jamais constaté
avec les cross-tools, mais uniquement avec des outils natifs.
> Mais je ne connais pas les nouveaux systèmes compatibles Atari, peut
> être sont-ils assez puissants pour faire tourner GCC correctement ? Dans
> ce cas, un compilateur natif serait intéressant. Etant donné que les
> patchs sont au point pour construire un cross-compilateur, ils devraient
> permettre aussi de compiler un compilateur natif ? Reste à savoir si la
> MiNTLib est suffisante pour compiler les binutils et GCC.
Je l'espère ... J'utilise actuellement GCC 3.3.6 que l'on trouve à
<http://the.zorro.free.fr/misc.html>
> J'essaierai peut-être de compiler un compilateur natif, histoire de
> savoir jusqu'où ça fonctionne, mais je ne compte pas le supporter
> activement. Par contre, je suis prêt à soutenir celui qui se lancera
> dans l'aventure !
Il n'y a personne pour vous faire concurrence de ce point de vue.
Il existe un cross-compilateur sous Mac OS X, avec lequel j'ai une
petite expérience décevante à cause du binaire ATARI généré.
<http://www.xn--donz-epa.ch/atari/articles/cross-compiler/>
Bonne chance pour la suite !
Francois LE COAT
Merci pour cette réponse.
Vincent Rivière a écrit :
>> La fabrication d'un cross-compilateur GCC 4.2 est la première étape
>> pour concevoir le compilateur natif m68k, qui est construit à partir
>> des mêmes sources à l'aide du cross-compilateur x86. Reste ensuitela
>> 2ème phase du compilateur natif et le test de l'intégrité.
>>
>> Est-ce que vous envisagez une cible m68k-atari-mint native ? Je suis
>> en effet intéressé par un tel outils dans le but de poursuivre le
>> développement des mes applications ATARI.
>>
>> Quelles sont vos intentions ?
>
> Mes intentions sont claires : je veux pouvoir écrire des programmes pour
> mon vieil STe, en C++ et en assembleur, tout en développant sous Windows.
J'ai moi un Hadès 60, c'est à dire une machine ATARI clone qui possède
les possibilités d'un ATARI TT, mais dont le processeur est un 68060 à
60MHz avec 40Mo de RAM. Par comparaison un STe est un 68000 à 8MHz avec
1Mo de RAM, avec des possibilités graphiques limitées (16 couleurs),
alors que le GEM (OS) permet beaucoup plus. Il est en particulier
impossible d'espérer utiliser MiNT sur une STe. Il y a une carte
graphique PCI dans mon Hadès 60. Il ne faut pas espérer faire grand
choses avec un STe aujourd'hui, surtout avec un système de développement
GCC, qui est bien moins adapté qu'un PURE C (Borland) ou le GFA Basic
<http://www.bright.net/~gfabasic/html/gfa_apps.htm> qui se renouvelle.
Il existe aussi, pour les machines encore utilisées des Falcon 30
c.à.d. un 68030 à 16 MHz avec 14Mo de RAM, mais équipées de cartes
accélératrices à base de 68060 à 100 MHz, qui ont les caractéristiques
d'un Falcon 60.
Le Falcon 30 a fait l'objet du développement d'une machine virtuelle,
qui s'appelle ARAnyM : ATARI Running on Any Machine, qui bénéficie des
ressources, via une machine/OS hôtes moderne (Intel, PPC, Cell sous
Linux, Windows, Mac OS X ...) ici <http://aranym.org/>
> Le but étant simplement de bricoler, en tirant parti du code optimisé
> généré par GCC. Pourquoi pas des démos écrites en C++ :-)
C'est pas la peine d'y penser avec le STe. Pour le C++ encore moins.
Il faut pour cela un 68060, un émulateur, ou encore mieux ARAnyM.
> Par contre ne je vois pas l'intérêt de développer directement surAtari
> (je parle du ST) même si c'était techniquement possible. De nos jours il
> est bien plus confortable de travailler avec un PC récent sous Windows
> ou Linux.
C'est sûr que développer sur une machine ATARI aujourd'hui n'est pas
très confortable. Mais ce qui importe n'est pas les difficultés que
peuvent rencontrer les développeurs, mais surtout la qualité des
développements produits, surtout quand il s'agit d'applications ATARI.
Par exemple, peu importe que mon application ATARI mette une heure
à se compiler, comme c'est le cas par exemple avec POV-Ray, si la
personne qui utilise ce logiciel ressent la qualité d'un outil
performant, comme c'est le cas avec GCC 4.2. L'important aussi est
que le binaire généré soit correct, ce que je n'ai jamais constaté
avec les cross-tools, mais uniquement avec des outils natifs.
> Mais je ne connais pas les nouveaux systèmes compatibles Atari, peut
> être sont-ils assez puissants pour faire tourner GCC correctement ? Dans
> ce cas, un compilateur natif serait intéressant. Etant donné que les
> patchs sont au point pour construire un cross-compilateur, ils devraient
> permettre aussi de compiler un compilateur natif ? Reste à savoir si la
> MiNTLib est suffisante pour compiler les binutils et GCC.
Je l'espère ... J'utilise actuellement GCC 3.3.6 que l'on trouve à
<http://the.zorro.free.fr/misc.html>
> J'essaierai peut-être de compiler un compilateur natif, histoire de
> savoir jusqu'où ça fonctionne, mais je ne compte pas le supporter
> activement. Par contre, je suis prêt à soutenir celui qui se lancera
> dans l'aventure !
Il n'y a personne pour vous faire concurrence de ce point de vue.
Il existe un cross-compilateur sous Mac OS X, avec lequel j'ai une
petite expérience décevante à cause du binaire ATARI généré.
<http://www.xn--donz-epa.ch/atari/articles/cross-compiler/>
Bonne chance pour la suite !
--
Mickael Pointier
> mon vieil STe, en C++ et en assembleur, tout en développant sous Windows.
> Le but étant simplement de bricoler, en tirant parti du code optimisé
> généré par GCC. Pourquoi pas des démos écrites en C++ :-)
Pour l'assembleur, inline, dans des sources séparés, la syntaxe est
utilisable ou bien c'est la syntaxe GCC standard (c'est à dire horrible
quand on est habitué à des trucs style Assemle, GenST ou Turbo Assembleur) ?
Ca m'intéresse aussi :)
Dbug
Vincent Rivière
> utilisable ou bien c'est la syntaxe GCC standard (c'est à dire horrible
> quand on est habitué à des trucs style Assemle, GenST ou Turbo Assembleur) ?
C'est la syntaxe "GCC standard"... mais qui est devenue utilisable au
fil des temps !
Plus précisément, il s'agit de la syntaxe "gas".
Toute la documentation se trouve ici :
http://sourceware.org/binutils/docs-2.17/as/
Les premières versions de gas ne comprenaient que la syntaxe MIT, qui
est vraiment horrible, avec des trucs du genre :
movew #9,%sp@-
Mais depuis un certain temps déjà, gas comprend aussi la syntaxe
Motorola que nous connaissons bien. De plus, il s'est enrichi avec des
directives de compilation de plus en plus complètes, comme .rept, .dc.b
et autres... Il est recommandé de préfixer les registres avec un
caractère % pour éviter les conflits entre les noms de registres et les
noms de labels, mais ce n'est pas obligatoire.
Un exemple de programme :
* A simple TOS program : hw.s
pea msg
move.w #9,-(sp)
trap #1 | Cconws()
addq.w #6,sp
move.w #8,-(sp)
trap #1 | Cnecin()
addq.w #2,sp
clr.w -(sp)
trap #1 | Pterm0()
msg: .ascii "Hello !\r\n\0"
Franchement, même si ce n'est pas exactement du GenST, ça n'en est pas
très loin !
Pour assembler :
$ m68k-atari-mint-as hw.s -o hw.o
$ m68k-atari-mint-ld hw.o -o hw.tos
On peut utiliser deux variantes lors de l'appel du linker :
Pour voir les labels dans MonST :
$ m68k-atari-mint-ld hw.o -o hw.tos --traditional-format
Pour ne générer aucune information de debug :
$ m68k-atari-mint-ld hw.o -o hw.tos -s
Qui a dit que ce n'était pas utilisable ?
Vincent
Jean-François Lemaire
On Wednesday 4 July 2007 11:34, OL wrote:
> Pour une version Atari se serait bien, j'utilise beaucoup gcc sous
> Aranym, c'est largement suffisant, utiliser le cross compilo n'est pas
> un gros soucis, mais faut passer a tout bout de champs d'une appli à
> une autre. Je le ferais bien mais je ne sais pas comment faire, peut
> etre le plus simple c'est sous Mint lui meme avec tous les outils,
> mais déjà que c'est super long et pénible sur un PC sous Linux alors
> sous Mint avec peut être des outils qui ne vont pas et le temps de
> compil que cela doit necessiter, cela doit être assez épique et
> franchement pénible.
On m'a dit que Odd Skancke travaillerait sur le portage de GCC 4.x.x
pour FreeMiNT.
JFL
--
Jean-François Lemaire
Vincent Rivière
> impossible d'espérer utiliser MiNT sur une STe.
J'ai utilisé MiNT (1.12 ?) sur ST pendant un certain temps, avec une
partition Minix et des noms longs. J'ai même utilisé le bureau
multitâche, dont j'ai oublié le nom (MultiTOS ?). Et une fois, j'ai même
lu un CD avec un lecteur SCSI. Ce n'était pas un modèle de rapidité,
mais ça fonctionnait.
> Il ne faut pas espérer faire grand
> choses avec un STe aujourd'hui, surtout avec un système de développement
> GCC, qui est bien moins adapté qu'un PURE C (Borland) ou le GFA Basic
> <http://www.bright.net/~gfabasic/html/gfa_apps.htm> qui se renouvelle.
Dans une optique "développement embarqué", le ST est une excellente
target, car c'est une machine raisonnablement puissante qui est bien
connue. Mais évidemment il est hors de question de se servir du ST comme
environnement de développement !
> Le Falcon 30 a fait l'objet du développement d'une machine virtuelle,
> qui s'appelle ARAnyM : ATARI Running on Any Machine, qui bénéficie des
> ressources, via une machine/OS hôtes moderne (Intel, PPC, Cell sous
> Linux, Windows, Mac OS X ...) ici <http://aranym.org/>
Merci beaucoup pour cette information, je ne connaissais pas ARAnyM, ça
a l'air vraiment super. Il me tarde de l'essayer.
>> Le but étant simplement de bricoler, en tirant parti du code optimisé
>> généré par GCC. Pourquoi pas des démos écrites en C++ :-)
>
> C'est pas la peine d'y penser avec le STe. Pour le C++ encore moins.
> Il faut pour cela un 68060, un émulateur, ou encore mieux ARAnyM.
Je me répète, je souhaite utiliser le ST comme machine cible et non
comme environnement de développement.
> L'important aussi est
> que le binaire généré soit correct, ce que je n'ai jamais constaté
> avec les cross-tools, mais uniquement avec des outils natifs.
Il n'y a aucune raison que les cross-tools génèrent du code moins
correct que les outils natifs. Si on compilait Pure C sous Windows ou
Linux, il génèrerait les mêmes binaires que la version Atari !
Quant au code généré par gcc et gas, s'il n'est pas correct, à nous de
l'améliorer. C'est à ça que servent les logiciels libres.
> Je l'espère ... J'utilise actuellement GCC 3.3.6 que l'on trouve à
>
> <http://the.zorro.free.fr/misc.html>
Merci pour ce lien.
Je vous invite à essayer de compiler vos projets avec mes binaires de
GCC 4.2 pour Cygwin, afin de juger de la qualité du code généré. Votre
retour d'expérience pourra servir à améliorer le cross-compilateur -
ainsi que le futur compilateur natif.
Vincent Rivière
vincent...@freesbee.fr
Francois LE COAT
Vincent Rivière a écrit :
>> Il est en particulier
>> impossible d'espérer utiliser MiNT sur une STe.
>
> J'ai utilisé MiNT (1.12 ?) sur ST pendant un certain temps, avec une
> partition Minix et des noms longs. J'ai même utilisé le bureau
> multitâche, dont j'ai oublié le nom (MultiTOS ?). Et une fois, j'ai même
> lu un CD avec un lecteur SCSI. Ce n'était pas un modèle de rapidité,
> mais ça fonctionnait.
Je l'ai aussi utilisé sur mon Falcon 30 en 1993, car MultiTOS était
fourni avec la machine. C'est à vous dégouter définitivement :-( Le
succès de Magic sur ces machines vient de là, car Magic est plus
léger, plus rapide, plus simple. Dès que l'on a une machine plus
rapide en revanche, MiNT exprime toutes ses possibilités, en étant
lui même bien plus léger que Linux68k, par exemple.
>> Il ne faut pas espérer faire grand
>> choses avec un STe aujourd'hui, surtout avec un système de développement
>> GCC, qui est bien moins adapté qu'un PURE C (Borland) ou le GFA Basic
>> <http://www.bright.net/~gfabasic/html/gfa_apps.htm> qui se renouvelle.
>
> Dans une optique "développement embarqué", le ST est une excellente
> target, car c'est une machine raisonnablement puissante qui est bien
> connue. Mais évidemment il est hors de question de se servir du ST comme
> environnement de développement !
N'importe quel assistant numérique ou portable est plus intéressant.
>> Le Falcon 30 a fait l'objet du développement d'une machine virtuelle,
>> qui s'appelle ARAnyM : ATARI Running on Any Machine, qui bénéficie des
>> ressources, via une machine/OS hôtes moderne (Intel, PPC, Cell sous
>> Linux, Windows, Mac OS X ...) ici <http://aranym.org/>
>
> Merci beaucoup pour cette information, je ne connaissais pas ARAnyM, ça
> a l'air vraiment super. Il me tarde de l'essayer.
Son développement est actif. J'y contribue depuis environ 10 ans.
>>> Le but étant simplement de bricoler, en tirant parti du code optimisé
>>> généré par GCC. Pourquoi pas des démos écrites en C++ :-)
>>
>> C'est pas la peine d'y penser avec le STe. Pour le C++ encore moins.
>> Il faut pour cela un 68060, un émulateur, ou encore mieux ARAnyM.
>
> Je me répète, je souhaite utiliser le ST comme machine cible et non
> comme environnement de développement.
L'outil utilisé est beaucoup trop lourd pour la cible choisie. C'est
ce que je veux dire. GCC produit un code qui n'est pas trop compact ni
rapide. Lorsque je construit mon propre logiciel à l'intention de ces
machines là, je n'utilise pas GCC mais PURE C qui est bien mieux.
La version de mon soft Eurêka 2.12 destinée aux anciennes configurations
est construite avec PURE C <http://eureka.atari.org/eurklite.zip>
Si vous avez l'occasion de me confirmer son fonctionnement sur votre
machine STe, je serais intéressé par vos commentaires. C'est un exemple
de soft actuel qui est supposé fonctionner sur les premières machines
ATARI, et qui donne vraiment envie d'avoir accès à plus de ressources.
>> L'important aussi est
>> que le binaire généré soit correct, ce que je n'ai jamais constaté
>> avec les cross-tools, mais uniquement avec des outils natifs.
>
> Il n'y a aucune raison que les cross-tools génèrent du code moins
> correct que les outils natifs.
C'est ce que je constate en compilant des softs avec des cross-tools.
> Si on compilait Pure C sous Windows ou
> Linux, il génèrerait les mêmes binaires que la version Atari !
En théorie. On ne parle pas que du compilateur, mais aussi de tout
le système de développement, librairies comprises. Si tout était
pour le mieux dans le meilleur des mondes (!) un cross-compilateur
donnerait le même résultat qu'un compilateur natif.
Le problème est qu'il est impossible de tester le produit d'un cross-
compilateur sur la machine même qui a servi à compiler. Que souvent,
lorsque l'on a recours à un cross-compilateur, c'est qu'on ne possède
pas la cible.
Travailler sérieusement au portage et à la vérification de
l'intégrité du compilateur GCC est un travail à plein temps de 3 ans.
Lorsqu'en plus on s'intéresse à une cible 68k, les possibilités de
débuggage ne sont pas nombreuses, car le parc de machines disponibles
est faible, et les utilisateurs rares.
C'est pourquoi ARAnyM est entrain de devenir une plateforme de
maintien de la version 68k de Linux, faute de machines disponibles.
ARAnyM a été choisi pour cela pour son degré d'achèvement, et sa
qualité de réalisation.
Si le but est de réaliser des softs par cross-compilation, le test
a avantage à être réalisé à l'aide d'ARAnyM, car c'est portable.
> Quant au code généré par gcc et gas, s'il n'est pas correct, à nous de
> l'améliorer. C'est à ça que servent les logiciels libres.
Le facteur limitant est le temps dont on dispose, et les moyens.
>> Je l'espère ... J'utilise actuellement GCC 3.3.6 que l'on trouve à
>>
>> <http://the.zorro.free.fr/misc.html>
>
> Merci pour ce lien.
Ma machine de développements est un Hadès 60 depuis 1996. Il n'y a
pas de système hardware équivalent qui a pu le remplacer depuis.
GCC 3.3.6 aurait avantage a être remplacé par GCC 4.2 s'il était
disponible en natif 68k, ce qui ne tient qu'à vous de réaliser :-)
> Je vous invite à essayer de compiler vos projets avec mes binaires de
> GCC 4.2 pour Cygwin, afin de juger de la qualité du code généré. Votre
> retour d'expérience pourra servir à améliorer le cross-compilateur -
> ainsi que le futur compilateur natif.
Je développe mes softs ATARI sur machines ATARI (ou clones) ce qui
m'a permis jusque là de proposer des applications qui marchent. Le
développement de mes applications ATARI m'occupe suffisamment pour
que je ne me préoccupe pas en plus de maintenir les outils de devels.
Je m'occupe déjà depuis longtemps déjà d'émulateurs ATARI STonX puis
TOSBox, et plus récemment d'ARAnyM. Le nombre des machines ATARI se
réduit comme peau de chagrin, et les ATARIstes aussi.
Le développement libre, je connais bien.
L'étape à franchir pour réaliser un compilateur natif 68k à partir du
cross-compilateur x86 que vous avez réalisé, n'est pas insurmontable.
Vous aurez beaucoup d'ATARIstes comme moi qui seront intéressés.
Je vous encourage à poursuivre sur la voie que vous avez ouvert !
Bonne chance.
Pierre TON-THAT
> Je développe mes softs ATARI sur machines ATARI (ou clones) ce qui
> m'a permis jusque là de proposer des applications qui marchent. Le
> développement de mes applications ATARI m'occupe suffisamment pour
> que je ne me préoccupe pas en plus de maintenir les outils de devels.
Le même programme depuis 20 ans, de moins en moins mis à jour, surtout
pour des broutilles, et décliné en différentes versions de compilation.
L'application n'est, de plus, pas réputée pour être user-friendly.
Message à Monsieur Rivière : ne vous laissez pas embobiner par le troll
de service, qui, s'il n'a pas le temps de "maintenir des outils de dev",
a énormément de temps "d'écrire des posts sur ce forum", au point de
noyer ses bétises dans les archives de google groups.
Bien à vous, et bravo pour votre release.
++
OL
> Bonjour Vincent,
>
> Vincent Rivière a écrit :
>
> >> Il est en particulier
> >> impossible d'espérer utiliser MiNT sur une STe.
>
> > J'ai utilisé MiNT (1.12 ?) sur ST pendant un certain temps, avec une
> > partition Minix et des noms longs. J'ai même utilisé le bureau
> > multitâche, dont j'ai oublié le nom (MultiTOS ?). Et une fois, j'ai même
> > lu un CD avec un lecteur SCSI. Ce n'était pas un modèle de rapidité,
> > mais ça fonctionnait.
>
> Je l'ai aussi utilisé sur mon Falcon 30 en 1993, car MultiTOS était
> fourni avec la machine. C'est à vous dégouter définitivement :-( Le
> succès de Magic sur ces machines vient de là, car Magic est plus
> léger, plus rapide, plus simple. Dès que l'on a une machine plus
> rapide en revanche, MiNT exprime toutes ses possibilités, en étant
> lui même bien plus léger que Linux68k, par exemple.
Bon on va reprendre une fois de plus.
Il y a Mint d'un coté, c'est en gros la couche gemdos, le multitache
et il y a multitos de l'autre qui est une couche AES.
L'erreur généralement commise parcequ'il y a eu amalgame à sa sortie,
c'est de dire que Mint est lent, mais en fait Mint + Multitos était
lent il est vrai et buggué par dessus le marché, un truc pas fini de
la Corps, mais c'est bien être ingrat envers Mint qui en fait n'est
pas le fautif, car le fautif c'est bien multitos et en fait tout le
monde a vite fait de le laisser de coté soit pour Magic soit pour Mint
+ Naes. Il est vrai que Magic est sans doute un peu plus light en
besoin mémoire que Mint + AES car en partie les deux parties sont
mieux intégrées. Aujourd'hui en vitesse avec un AES du moment que ce
soit Mint ou Magic en vitesse c'est a peu près pareil.
L'autre affirmation que tu n'as pas fait, mais qui est souvent faite
par d'autres c'est de dire que le système monotache est plus rapide
que le multitache, c'est vrai que c'est tentant de dire cela et
théoriquement c'est vrai (mais de tellement peu), si bien que je peux
dire que les systèmes actuels multitache (Mint compris) que l'on
trouve sont sensiblement plus réactifs (et donc d'impression plus
rapide) que monotos que l'on trouve dans sur un ST, un TT ou un falcon
de base, c'est simplement plus optimisé et pensé, par contre ca
necessite plus de mémoire et tenter de faire fonctionner Mint + AES
avec 1Mo ca doit être proche de l'impossible.
Olivier
Mickael Pointier
> >>> généré par GCC. Pourquoi pas des démos écrites en C++ :-)
> >>
> >> C'est pas la peine d'y penser avec le STe. Pour le C++ encore moins.
> >> Il faut pour cela un 68060, un émulateur, ou encore mieux ARAnyM.
> >
> > Je me répète, je souhaite utiliser le ST comme machine cible et non
> > comme environnement de développement.
>
> L'outil utilisé est beaucoup trop lourd pour la cible choisie. C'est
> ce que je veux dire. GCC produit un code qui n'est pas trop compact ni
> rapide. Lorsque je construit mon propre logiciel à l'intention de ces
> machines là, je n'utilise pas GCC mais PURE C qui est bien mieux.
>
> La version de mon soft Eurêka 2.12 destinée aux anciennes configurations
> est construite avec PURE C <http://eureka.atari.org/eurklite.zip>
Il n'y à aucune raison pour que GCC ne puisse pas produire du meilleur code
que Pure C, et il est évident (pour moi) qu'avoir un bon GCC capable de
générer du bon code 68000 qui tourne bien sur un ST, est un objectif
parfaitement réalisable.
Pure C n'est plus maintenu, et comme son nom l'indique ne génère que du C,
donc un bon compilateur C++ serait le bienvenu pour faire des progs sur ST
et compatibles.
> >> L'important aussi est
> >> que le binaire généré soit correct, ce que je n'ai jamais constaté
> >> avec les cross-tools, mais uniquement avec des outils natifs.
> >
> > Il n'y a aucune raison que les cross-tools génèrent du code moins
> > correct que les outils natifs.
>
> C'est ce que je constate en compilant des softs avec des cross-tools.
Bein tu n'as pas testé tous les environment de développement croisé de
l'univers non plus. Tu n'imagine pas que les programmeurs PS3 codent sur une
PS3 non plus ?
> > Si on compilait Pure C sous Windows ou
> > Linux, il génèrerait les mêmes binaires que la version Atari !
>
> En théorie. On ne parle pas que du compilateur, mais aussi de tout
> le système de développement, librairies comprises. Si tout était
> pour le mieux dans le meilleur des mondes (!) un cross-compilateur
> donnerait le même résultat qu'un compilateur natif.
C'est généralement le cas, et en général même le compilateur croisé tournant
sur une machine autremement plus puissante que la cible, peut se permettre
d'effectuer des optimisation qu'un compilateur natif ne serait pas à même de
faire. Exemple bête et con, les compilateurs croisés pour les vieux micros à
base de 6502 ou Z80.
Oui tu peux compiler un hello world sur un Amstrad CPC, je doute que ce soit
aussi efficace que de compiler le même hello world sur un PC.
> Le problème est qu'il est impossible de tester le produit d'un cross-
> compilateur sur la machine même qui a servi à compiler.
Bien sur que si, les émulateurs ne sont pas là pour rien. Et le fait de
vérifier qu'un code tourne sur une machine donnée, n'est pas une façon
viable et scientifique de prouver qu'un code tourne de façon conforme à ce
qu'il était sensé faire. C'est juste de l'empirisme.
Dbug - utilisateur de compilateurs croisés since 1994 -
Francois LE COAT
Mickael Pointier a écrit :
>>>>> Le but étant simplement de bricoler, en tirant parti du code optimisé
>>>>> généré par GCC. Pourquoi pas des démos écrites en C++ :-)
>>>> C'est pas la peine d'y penser avec le STe. Pour le C++ encore moins.
>>>> Il faut pour cela un 68060, un émulateur, ou encore mieux ARAnyM.
>>> Je me répète, je souhaite utiliser le ST comme machine cible et non
>>> comme environnement de développement.
>> L'outil utilisé est beaucoup trop lourd pour la cible choisie. C'est
>> ce que je veux dire. GCC produit un code qui n'est pas trop compact ni
>> rapide. Lorsque je construit mon propre logiciel à l'intention de ces
>> machines là, je n'utilise pas GCC mais PURE C qui est bien mieux.
>>
>> La version de mon soft Eurêka 2.12 destinée aux anciennes configurations
>> est construite avec PURE C <http://eureka.atari.org/eurklite.zip>
>
> Il n'y à aucune raison pour que GCC ne puisse pas produire du meilleur code
> que Pure C,
Et pourtant c'est le cas.
> et il est évident (pour moi) qu'avoir un bon GCC capable de
> générer du bon code 68000 qui tourne bien sur un ST, est un objectif
> parfaitement réalisable.
Tu t'y colles ?
> Pure C n'est plus maintenu,
En même temps les ST sont les mêmes depuis 20 ans. C'est gênant que
PURE C n'évolue pas avec les machines les plus récentes. Mais si
c'est pour compiler pour un 520ST, pourquoi prendre GCC 4.2. PURE C
est toujours aussi convenable pour les machines d'il y a 20 ans !
> et comme son nom l'indique ne génère que du C,
À part alourdir le code, pour un STe le C++ n'apporte rien.
> donc un bon compilateur C++ serait le bienvenu pour faire des progs sur ST
> et compatibles.
On parle du STe de Vincent. Je ne suis pas opposé au C++. Je dis que
s'il s'agit de développer pour une machine qui date d'il y a 20 ans,
c'est idiot. Autant utiliser des outils adaptés à ces vielles archis,
et leurs contraintes d'autrefois. Je ne parle pas des machines
ATARI actuelles, bien évidemment.
>>>> L'important aussi est
>>>> que le binaire généré soit correct, ce que je n'ai jamais constaté
>>>> avec les cross-tools, mais uniquement avec des outils natifs.
>>> Il n'y a aucune raison que les cross-tools génèrent du code moins
>>> correct que les outils natifs.
>> C'est ce que je constate en compilant des softs avec des cross-tools.
>
> Bein tu n'as pas testé tous les environment de développement croisé de
> l'univers non plus. Tu n'imagine pas que les programmeurs PS3 codent sur une
> PS3 non plus ?
Je n'ai pas prétendu connaître tous les cross-compilateurs, comme tu
sembles le prétendre. Je dis simplement que le cross-compilateur 68k
est mauvais. Des cross-compilateurs, il en existe autant que des
compilateurs. Ils sont tous différents. Celui du 68k est mauvais.
Je l'ai testé.
>>> Si on compilait Pure C sous Windows ou
>>> Linux, il génèrerait les mêmes binaires que la version Atari !
>> En théorie. On ne parle pas que du compilateur, mais aussi de tout
>> le système de développement, librairies comprises. Si tout était
>> pour le mieux dans le meilleur des mondes (!) un cross-compilateur
>> donnerait le même résultat qu'un compilateur natif.
>
> C'est généralement le cas, et en général même le compilateur croisé tournant
> sur une machine autremement plus puissante que la cible, peut se permettre
> d'effectuer des optimisation qu'un compilateur natif ne serait pas à même de
> faire. Exemple bête et con, les compilateurs croisés pour les vieux micros à
> base de 6502 ou Z80.
Je parle en particulier du 68k.
D'ailleurs, ce que tu dis n'est pas seulement vrai que pour les
cross-compilateurs. Il vaut toujours mieux avoir pour développer
une machine possédant plus de ressources que les machines pour
lesquelles on développe. Avec un compilateur natif aussi !
En compilant POV-Ray sur mon Hadès 60, j'arrive aux limites de
ses ressources, alors que le binaire lui même convient à un Falcon.
> Oui tu peux compiler un hello world sur un Amstrad CPC, je doute que ce soit
> aussi efficace que de compiler le même hello world sur un PC.
C'est un problème. Mais je ne vois pas le rapport avec la discussion.
À part le fait que les outils de devels produisent toujours des
binaires plus gros. On peut le constater en comparant un PURE C et
un GCC, ou alors des binaires produits par des sources C et C++,
par exemple "Hello world!" en C et C++, ça n'est pas pareil !
>> Le problème est qu'il est impossible de tester le produit d'un cross-
>> compilateur sur la machine même qui a servi à compiler.
>
> Bien sur que si, les émulateurs ne sont pas là pour rien. Et le fait de
> vérifier qu'un code tourne sur une machine donnée, n'est pas une façon
> viable et scientifique de prouver qu'un code tourne de façon conforme à ce
> qu'il était sensé faire. C'est juste de l'empirisme.
J'aurais du dire :
Le problème est qu'il est impossible de tester le produit d'un cross-
compilateur *nativement* sur la machine même qui a servi à compiler.
et tu aurais compris ... Ne fais pas exprès de comprendre de travers.
Surtout que si tu regardes un peu plus loin dans le post j'en parle,
à propos d'ARAnyM.
Et puis ... L'informatique n'est pas une science ... Ça n'est qu'un
outil au service des scientifiques ... Entre autre. On peut parler
de sciences et technologies de *l'information* pas de l'informatique.
ATARIstiquement,
BARANGER Emmanuel
>> Linux, Windows, Mac OS X ...) ici <http://aranym.org/>
>
> Merci beaucoup pour cette information, je ne connaissais pas ARAnyM, ça
> a l'air vraiment super. Il me tarde de l'essayer.
>
petit tour ici : http://helijah.free.fr/Pack_3D pourrait surement te
donner envie d'en savoir beaucoup plus ;)
Amicalement
--
BARANGER Emmanuel
http://helijah.free.fr
http://helijah.free.fr/Pack_3D
http://helijah.free.fr/flightgear/flightgear.htm
http://helijah.free.fr/flightgear/H4-Hercules.htm
http://helijah.free.fr/flightgear/hangar.htm
OL
>
> Je n'ai pas prétendu connaître tous les cross-compilateurs, comme tu
> sembles le prétendre. Je dis simplement que le cross-compilateur 68k
> est mauvais. Des cross-compilateurs, il en existe autant que des
> compilateurs. Ils sont tous différents. Celui du 68k est mauvais.
> Je l'ai testé.
Ton cas n'est pas unique Francois, la plupart des programmeurs
Francais sur notre machine que je connais (je les connais presque
tous!) et qui font du C, aujourd'hui cross compil et personne pour
dire que cela ne marche pas ou que c'est mauvais. Le plus réfractaire
de tous (si je ne parle pas de toi) c'est moi je crois, parceque
passer d'un environnment à l'autre à tout bout de champs ca me gonfle
et qu'utiliser les éditeurs sous Linux généralement me pose des soucis
de table ascii et retour fin de ligne, ca fait des mélanges pas
possible et si je dois compiler aussi bien en GCC qu'en PureC ce
dernier n'aime pas la plaisanterie. Bref si je peux tout faire sous
Atari je le fais, mais cela n'a pas grand chose à voir avec ce que
fait GCC, j'ai personnellement moi aussi fait le port de GCC 4.2 et
reutilisé les binutils de Mark (parceque j'ai bien été incapable de
faire ce port car bonjour le travail sans parler des bugs) et
franchement j'ai rien à redire, tout ce que j'ai compilé avec
fonctionne au poil (MyAES, Tiny (Mint mais je le met à part, il n'est
pas totalement pret pour le 4.2 et j'ai du patcher pas mal pour
corriger certains bugs)), corrolairement j'ai du compiler de
librairies comme ma vieille "libm" dont je ne me separerais pour rien
au monde, que j'ai du patcher aussi car le 4.2 n'en voulait pas (c'est
comme cela il est vachement strict par rapport aux versions plus
vieilles et c'est tant mieux), ca marche au poil même en V4e c'est
dire.
Enfin j'ai effectivement à un moment mis en cause GCC 4.2 cross
compilo, car un de mes softs marchait bizarrement, mais j'ai cherché
pour comprendre et là j'ai trouvé quoi? Un bug bien maison, bien moche
qui n'aurait jamais du marcher et qui marchait très bien avec GCC
ancienne version, je me suis rendu compte que je sauvais un pointeur
qui correspondait à une variable locale utilisé en dehors de la dite
fonction, je dis pas les dégats possibles. Alors si tu as l'exemple
contraire envoi le moi, cela m'intéresse, jusque là je n'ai trouvé que
des bugs dont j'étais le responsable, pas été capable de mettre en
défaut le cross compilateur, même si parfois ce n'est pas l'envi qui
m'a manqué de trouver une solution de facilité en accusant le cross
compilo. Mais a ce que je sache tu utilises de manière bien
particulière GCC avec l'option -mshort et peut etre ton problème est
là, j'ai abandonné cette option il y a bien longtemps et que tu as
voulu utiliser de vieilles libs déjà toutes compilées, le soucis est
peut etre de ce coté. Option aujourd'hui en cours d'obsolescence tu es
bien le seul encore à l'utiliser à ma connaissance.
Alors peut etre que celui que tu as utilisé n'est pas au point c'est
possible, mais je ne pense pas qu'il faille faire des généralités.
Olivier
Vincent Rivière
> petit tour ici : http://helijah.free.fr/Pack_3D pourrait surement te
> donner envie d'en savoir beaucoup plus ;)
Bonjour.
J'ai installé le Pack 3D, c'est vraiment excellent !
ARAnyM et tous ces logiciels réunis dans un seul pack super simple à
installer sous Windows... C'est vraiment ce qu'il faut pour découvrir
les systèmes Atari modernes.
Voilà tout un monde que je ne connais pas (pour l'instant)...
Je vais pouvoir rattraper mon retard !
Encore merci.
Vincent
Vincent Rivière
Je viens de mettre en ligne une nouvelle version de la MiNTLib.
Dans la version initiale, les fonctions memcpy retournaient une valeur
invalide.
J'en profite pour vous informer d'un point important. J'ai configuré GCC
4.2 pour qu'il se comporte comme Linux/m68k lors des appels de fonctions.
- Si une fonction renvoie un pointeur, celui-ci est retourné dans a0.
- Si elle renvoie un autre type, la valeur est retournée dans d0 comme
d'habitude.
Cela peut poser problème : lors de l'appel d'une fonction, le
compilateur doit connaitre le type de retour pour aller chercher la
valeur dans le bon registre. Dans la pratique, avant d'appeler une telle
fonction, il faut impérativement déclarer son prototype (comme cela
devrait toujours être le cas). Malheureusement, le C n'oblige pas à
déclarer les prototypes, et beaucoup de code existant exploite cette
"particularité". C'est pourquoi les développeurs Linux ont décidé que
lorsqu'une fonction renvoie un pointeur, il est renvoyé dans a0 (puisque
c'est la nouvelle norme) ET dans d0 (pour éviter de faire planter les
appelants qui ne déclarent pas les prototypes).
Dans la pratique, ce nouveau réglage devrait être relativement
transparent, sauf dans un cas précis : lorsqu'on écrit *en langage
assembleur* une fonction qui retourne un pointeur, il faut bien faire
attention à retourner la valeur dans a0 et d0.
Dans la MiNTLib, seule la fonction memcpy (et dérivées) est dans ce cas,
et fatalement elle était buggée dans ma version initiale. Mais comme on
utilise rarement la valeur de retour de memcpy, ce bug était passé
inaperçu. C'est à présent corrigé.
--
Vincent Rivière
vincent...@freesbee.fr
Mickael Pointier
code
>> que Pure C,
>Et pourtant c'est le cas.
C'est une constatation, pas une raison.
Techniquement, conceptuellement, rien de s'oppose à ce qu'on puisse faire
mieux qu'un compilateur pondu il y à heuuu on va dire "il y à plus de 15
ans".
>En même temps les ST sont les mêmes depuis 20 ans. C'est gênant que
>PURE C n'évolue pas avec les machines les plus récentes. Mais si
>c'est pour compiler pour un 520ST, pourquoi prendre GCC 4.2. PURE C
>est toujours aussi convenable pour les machines d'il y a 20 ans !
Bein tu prend un programmeur assembleur, il va t'exploser tout ce que tu
peux faire avec Pure C - en taille et en performance -, sans même se
fatiguer, de la main gauche, et en prennant un Ricard en même temps (ou un
jus d'orange si il/elle ne boit pas d'alcool).
Ca veut donc dire qu'on peut faire mieux, vu que la limite théorique de ce
que peux faire un compilateur, c'est d'utiliser l'assembleur comme un dieux.
C'est d'ailleur ce qui se passe sur PC, où il vaut déja avoir un certain
niveau en assembleur pour réussir à faire mieux que les compilateurs de
façon consistante (je parle pas d'optimiser une petite routine simple).
Donc oui, avoir mieux que Pure C sur un Atari ST de 20 ans est extremement
justifiable, vu que ca permet d'obtenir plus d'un hardware qui n'a pas
évolué.
>> et comme son nom l'indique ne génère que du C,
>À part alourdir le code, pour un STe le C++ n'apporte rien.
Forcément si tu ne sais pas programmer en C++, tu peux sortir ce genre de
phrase.
Le C++ est un excellent language en comparaison du C, et se passer de toutes
ces amméliorations est purement rétrograde.
>On parle du STe de Vincent. Je ne suis pas opposé au C++. Je dis que
>s'il s'agit de développer pour une machine qui date d'il y a 20 ans,
>c'est idiot. Autant utiliser des outils adaptés à ces vielles archis,
>et leurs contraintes d'autrefois. Je ne parle pas des machines
>ATARI actuelles, bien évidemment.
Donc je suis un idiot vu que j'utilise un cross compilateur C pour faire mes
programmes Oric.
Je te remercie.
Tu vieux d'ailleur aussi de traiter d'idiot Vincent qui justement à bien
l'intention d'utiliser le C++ sur son STE.
>Je n'ai pas prétendu connaître tous les cross-compilateurs, comme tu
>sembles le prétendre. Je dis simplement que le cross-compilateur 68k
>est mauvais. Des cross-compilateurs, il en existe autant que des
>compilateurs. Ils sont tous différents. Celui du 68k est mauvais.
>Je l'ai testé.
Il n'y à pas UN cross compilateur 68k, il y en à plein.
>D'ailleurs, ce que tu dis n'est pas seulement vrai que pour les
>cross-compilateurs. Il vaut toujours mieux avoir pour développer
>une machine possédant plus de ressources que les machines pour
>lesquelles on développe. Avec un compilateur natif aussi !
<ironie>
Diantre, je n'avais jamais réalisé qu'en ayant une machine plus puissante je
serais plus productif !
</ironie>
>> Oui tu peux compiler un hello world sur un Amstrad CPC, je doute que ce
soit
>> aussi efficace que de compiler le même hello world sur un PC.
>C'est un problème. Mais je ne vois pas le rapport avec la discussion.
>À part le fait que les outils de devels produisent toujours des
>binaires plus gros. On peut le constater en comparant un PURE C et
>un GCC, ou alors des binaires produits par des sources C et C++,
>par exemple "Hello world!" en C et C++, ça n'est pas pareil !
Tu te dit scientifique, alors que tu dérives des règles depuis des tests
empiriques sur des cas spécifiques.
Il y à pas mal d'environnements de développements qui te sortirons
exactelement le même exécutable pour un hello world écrit en C ou en C++.
Les environnements de développements croisés ne génèrenent pas
systématiquement des binaires plus gros.
Arrête de généraliser sur une mauvaise expérience.
Déja avant de gueuler que les exécutables étaient plus gros, as tu désactivé
les fonctions pour inliner le code automatiquement, as tu activé les
paramètres pour merger les constantes, changé les allignements par défaut,
etc...
Ca me fait penser aux gens qui gueulent en disant que leur nouvelle voiture
consomme plus que l'ancienne, alors qu'il ont completement oublié qu'ils
avaient une clim à donf sur l'autoroute, et que maintenant la voiture est
suffisament puissante pour tracter une caravane.
Faut comparer les choses dans des conditions similaires.
Le compilo Oric que j'utilise génère un code catastrophique, mais ca
s'amméliore, petit à petit, par rapport à il y à 4 ans, le code généré est
environ 10% plus compact, et d'autant plus rapide. C'est pas grand chose,
mais ca n'était pas un objectif à la base d'avoir un truc super optimal.
Et si je pouvais avoir le C++ sur l'Oric, et bien je l'utiliserais, parce
que c'est super cool pour structurer un programme.
>J'aurais du dire :
>Le problème est qu'il est impossible de tester le produit d'un cross-
>compilateur *nativement* sur la machine même qui a servi à compiler.
>et tu aurais compris ... Ne fais pas exprès de comprendre de travers.
Non, je ne vois pas ce que ca change, et surtout je ne vois pas l'intéret de
tester nativement ou pas nativement.
>Surtout que si tu regardes un peu plus loin dans le post j'en parle,
>à propos d'ARAnyM.
Oui, heu ca change quoi ?
>Et puis ... L'informatique n'est pas une science ... Ça n'est qu'un
>outil au service des scientifiques ... Entre autre. On peut parler
>de sciences et technologies de *l'information* pas de l'informatique.
On ne parle pas d'informatique au sens large, on parle d'un domaine qui à
été extensivement documenté par Wirth, Knut, je t'en passe et des meilleurs:
La compilation, c'est à dire la transformation d'un programme représenté
sous une certaine forme générablement lisible par un être humain, vers
quelque chose qu'un ordinateur pour exécuter.
La création de compilateurs, arbres de parsings, évaluation d'expression,
lex/flex, yack, bison etc... c'est pas tombé des arbres, c'est issue d'une
réflection poussée par des gens qui ont fait ca à temps plein.
Le fait que ce soit cross compilé ou pas, c'est un problème non existant.
Ce que tu déblatère à propos de tes problèmes de compilation 68k ne fait que
prouve encore une fois que tu aimes parler sur les sujets que tu ne maitrise
pas.
Je ne connais rien aux maths avancées, donc je ne reprendrais jamais sur ce
que tu pourrais écrire dans ce domaine, donc s'il te plait ait la décence de
ne pas sortir d'abérations dans les domaines que d'autres maitrisent.
Dbug