compilateur - Page 1

Où pourrais-je trouver un compilateur (assembleur) 68k qui tourne sous DOS ou Windows pour convertir des .asm en .89z ?
Merci

télécharge la suite de TIGCC, y'a A68k dedans
mais je laisse Kevin Koffler t'expliquer le reste

merci gususg

Combien de temps va-t-il se passer avant que Kevin ne réponde dans ce topic ?

ça, faut voir, mais il va pas tarder, il passe assez souvent, donc faut l'attirer.

Oups, je ne sais pas comment, mais ce topic doit m'avoir échappé.

Oui, en effet, télécharge TIGCC sur http://tigcc.ticalc.org. C'est là où se trouve la version la plus récente de A68k. Et TIGCC IDE est un excellent environnement de développement pour A68k, comme pour GCC et GNU as.

Autre chose que seul TIGCC t'offrira: la possibilité d'utiliser des libraries statiques en assembleur. L'appel se réduit à un simple bsr! Par exemple: bsr GrayOn. Mais tu n'es pas obligé d'utiliser ça (même si c'est très conseillé - les librairies dynamiques en mode kernel sont obsolètes).

Et tu peux même appliquer la fameuse compression ExePack à tes programmes en assembleur, à condition qu'ils soient en _nostub.
[edit]Edité par Kevin Kofler le 04-12-2001 à 09:50:13[/edit]

arf... obsolètes... pas toutes : Genlib n'est pas obsolète !
Et certaines libs "obsolètes" sont encores bcp utilisées !!!
Cf Ziplib pr les pompes au Lycée sous TxtRider !

"obsolete" n'a pas le meme sens pour lui et pour moi. Et le bsr grayOn ne marchera ps toujours

Ça marche si l'offset est de moins de 32 KO, c'est-à-dire dans la plupart des cas. Et c'est plus rapide et plus court que l'appel des librairies dynamiques pour kernel, qui nécessite un jsr absolu. (Je ne parle pas de lea + jsr (an) - là aussi il te faudra à un moment une adresse absolue en .l là où moi, je peux utiliser une relative en .w.) Et en plus de la lenteur du jsr absolu lui-même, il y a encore un relogement inutile. Le bsr est bien plus pratique.
Et quand l'offset est de 32 KO ou plus, on peut toujours utiliser un jsr absolu, ce qui donnera exactement la même vitesse qu'un appel de librairie dynamique pour kernel. Sauf le temps perdu à rechercher la librairie externe dans la VAT lors du relogement, évidemment.

Et puis je n'utilise pas ma calculatrice pour tricher. Je ne triche pas, moi.
[edit]Edité par Kevin Kofler le 04-12-2001 à 21:16:59[/edit]

nan mais! pfi!

a68k -g -l -t Nom_Du_Fichier.asm
voilà la commande en gros...

kevin> comment ca tu ne triches pas ? t'as pes 'd'aides memoire'?

>Ça marche si l'offset est de moins de 32 KO, c'est-à-dire dans la plupart des cas.
Sauf pour les gros programmes. D'ailleurs je signales que Chrono est impossible a transformer en nostub : il fait 60Ko, et il utiliser GenLib a 99%. Donc a moins de faire des libs dynamiques en nostub (Stupide), c'est impossible.

>Et c'est plus rapide et plus court que l'appel des librairies dynamiques pour kernel, qui nécessite un jsr absolu.
Oui tu as raison : un bsr GrayOn DOIT IMPERATIVEMENT etre le plus rapide possible.
Lol.

> (Je ne parle pas de lea + jsr (an) - là aussi il te faudra à un moment une adresse absolue en .l là où moi, je peux utiliser une relative en .w.)
Oui mais moi je n'ai pas la routine de la fonction dans le programme donc le programme est plus petit, na

>Et quand l'offset est de 32 KO ou plus, on peut toujours utiliser un jsr absolu, ce qui donnera exactement la même vitesse qu'un appel de librairie dynamique pour kernel.
Oui.

>Sauf le temps perdu à rechercher la librairie externe dans la VAT lors du relogement, évidemment.
Houlala ! Meme si ca prenait 10x fois de temps, ca resterait imperceptible !
Tu pourrais reflechir a ton argument quand meme

si chrono peut tenir en nostub, tu mets les gfxs/maps/datas dans un fichier séparé compressé (mon pang en nostub possede un fichier externe de 50Ko de données compressés )

Si malgré ca le code principale continue à faire + de 64Ko, ben ca me ferait mal kan meme !

[edit]Edité par Aghnar le 05-12-2001 à 12:30:15[/edit]

Les gfx/data sont DEJA en fichiers externes !

donc le code pur fait 60Ko !!!!!

Bah putain c la folie ! et en ASM en + !!!!!

C enorme un RPG ki tient sur 60 Ko sans les gfx,mpas, textes, etc !!!!

Surtout qu'il y a genlib pour faire la majorité des fonctions gfx !

ça doit etre codé bourin !

En fait, il y a quelque texte, et quelque images. (Faut pas exagerer non plus).
Mais cela fait tout de meme 50 Ko, a mon avis, de code pur.
C'est pas code bourrin, c'est surtout qu'il y a beaucoup de code (script, ia, dialogue, maps, affichage, demos graphiques, sprites, ombrage, temps, ...)

Et l'alpha est pour quand .... ?

Sais-tu que ttpack supporte les archives à 2 sections? Avec un lanceur PPG adapté, tu peux t'en sortir. Et puis tu peux aussi mettre tes "quelques textes et quelques images" dans un fichier externe...

et les compresser.

il faut quoi comme ressources pour cf ?

beaucoup

oui bcp non je sais pas....
Bon ben tu peux encore gagner 10 ko et mettre tt ça ds un autre fichier
[edit]Edité par liquid le 05-12-2001 à 22:49:29[/edit]

Mais ca me fait du boulot pour rien tout ca. Je prefere depenser mon energie pour des choses plus utiles. Et je maintiens mon opinion : a moins de faire des libs dynamiques en nostub (ce qui est clairement stupide puisque les kernels sont la pour ca), on peut pas le convertir en nostub. Surtout que le BSS fait plus de Ko (Bon ok, je connais HeapAlloc et l'arg n'est pas tres valable).

pkoi ? c pas bien HeapAlloc ?

C'est mieux un BSS.

Tout à fait d'accord.