AROS et Amiga 68000

10 sujets de 1 à 10 (sur un total de 10)

Gilloo
1 février 2012 à 11h27 #10263
Yo, 2012 a déjà un mois de bouffé.

Comme la commande c:info est complètement foireuse sur des partitions dépassant les 2Go, j’ai reluqué du coté d’aros pour voir comment c’est fait.

J’ai copié/renommé le dossier arossupport/include en aros dans le include: de mon compilo C préféré, le SASC6.0.

j’ai ensuite copié le workbench/c/info.c dans un projet,

et lancé la compilation…

J’y suis presque: il faut une arithmétique 64 bits + la correction de quelques notations pourries venant du c++…

Ma question: est-il possible de compiler d’autres trucs aros avec le SAS ?

si oui où est le tuto officiel d’une telle prouesse ?
Ball000
1 février 2012 à 14h23 #157232
La démarche a historiquement (à ma connaissance) toujours été l’inverse pour les développeurs d’AROS :

– ils ont cherché à s’affranchir du SAS qui n’était plus maintenu, et ont donc favorisé gcc et ses évolutions successives (même si la plupart du code de haut niveau passe très bien sous vbcc, il semble qu’au plus près du « métal », le système utilise trop de spécificités de gcc pour qu’un portage sur un autre compilateur puisse être envisagé par un humain normalement constitué). Cela a par contre permis à AROS d’être porté sur une grande partie des machines supportées par gcc lui-même ;

– mais ils ont (à l’origine en tous cas) cherché à modeler l’interface avec gcc pour qu’elle soit la plus facile d’accès aux habitués des environnements SAS : les exemples des RKRM sont en général compilables sans (ou avec très peu de) modifications, et les sources que l’on peut trouver sur Aminet sont en général aussi dociles. Ce point est plutôt favorable à ton projet (par commutativité) ;

– le système de développement (build system) d’AROS a par contre des avantages spécifiques très conséquents : il permet, à partir de sources communes, de créer facilement des bibliothèques partagées dans la plus pure tradition Amiga, mais pour des processeurs aussi variés que ceux que supporte AROS. Il est hébergé sous Linux (ou éventuellement sous AROS, mais on perd beaucoup des avantages de vitesse de compilation et de débogage), ce qui permet l’accès à tous les utilitaires de programmation qui y sont disponibles. Et en particulier, gdb pour le débogage, en association avec la version hébergée d’AROS qui est vue par l’hôte comme un seul gros exécutable. Il est entre autres très facile de compiler pour l’Amiga 68k, comme l’a montré Toni Wilen en compilant une version de PFS compatible avec le Kickstart 1.3, dont il a dit qu’elle n’aurait pas été possible (ou du moins beaucoup plus difficile) sans ce système.

Bon j’ai encore digressé (désolé), mais pour essayer de répondre à ta question plus succinctement : comme ton projet n’a probablement pas de précédent, à mon avis tu ne trouveras pas de documentation. Par contre, je pense que la nécessité des adaptations sera moins importante que ce à quoi on pourrait s’attendre de prime abord.
Gilloo
2 février 2012 à 9h38 #157233
Bon ben ça y est, j’ai mon c:info 3.1 d’Aros qui fonctionne avec les partitions de plus de 2Go… Est ce que cela intéresse du monde ?

Il a fallu que je reprenne toutes les déclarations C++ hors déclarations réglementaires du C du genre

IPTR args[]={(IPTR)toto, (IPTR)titi} ;

en

IPTR args[2] ;

args[0] = (IPTR)toto ;

args[1] = (IPTR)titi ;

Le principal c’est que le code source d’Aros est une petite mine à explorer, même pour les classiques.
krabob
2 février 2012 à 10h14 #157234
Je te thumbe, j te like , je te plussois.

Très bonne idée, et excellente initiative. Je n’ai jamais utilisé le SAS C mais à priori il fait des exécutables plus court ( et mieux compilé ?) que le GCC de geek gadget dispo sur 68k. (ce que j’ai installé chez moi en 68000->68000 pour recompiler mes trucs GPL ). …

D’autre part, il me semble qu’il y a déjà un truc sur classic qui prétends continuer le travail de mise à jour de l’OS3.9 avec les sources d’aros… comment ça s’apelle déjà ?
Ball000
2 février 2012 à 10h15 #157235
Excellent !

Par simple curiosité… Si tu n’as fait que reprendre les déclarations C++ et que tu n’as rien changé d’autre, quelle taille fait ton exécutable compilé par SAS ? L’exécutable Amiga obtenu par le build-system d’AROS fait 8536 octets (qui pour l’instant, je crois, ne fait par défaut aucune optimisation).

Edit : /me grillé par Krabob à une minute près !

@Krabob :

Il s’agissait d’AFAos (AROS for Amiga) mais il est rendu plus ou moins obsolète par la version pour Amiga d’AROS qui est compilée toutes les nuits et est disponible ici par exemple : amiga-m68k-bootiso.
Gilloo
2 février 2012 à 10h28 #157236
La taille du c:info obtenu par le SASC est de 11ko.

je n’utilise pas d’option d’optimisation.

j’ai aussi inclus les stdio.h stdlib.h, changé __sprintf en sprintf et inclus une bib 64bits (de ma fabrication pour ANAIIS) pour pouvoir utiliser des uint64 au lieu des QUAD. Vu la faible utilisation de sprintf, je pourrais les remplacer par RawDoFmt() et me passer du lib:c.o

Le c:info 3.1 d’origine fait à peine 3ko.
Ball000
2 février 2012 à 11h30 #157237
Tu as vu que le __sprintf() de l’amiga.lib d’AROS, c’est juste ça :

VOID __sprintf(UBYTE *buffer, const UBYTE *format, …)

{

va_list args;

va_start(args, format);

VNewRawDoFmt(format, RAWFMTFUNC_STRING, buffer, args);

va_end(args);

}
Gilloo
3 février 2012 à 9h44 #157238
Le __sprintf à la mode Gillou donne ça:

struct myputstruct

{

UBYTE *buf ;

} ;

static void __asm __saveds myputstr(

register __d0 UBYTE c,

register __a3 struct myputstruct *mps

)

{

*(mps->buf++) = c ;

}

int __sprintf(char *buf, char *fmt, …)

{

struct myputstruct mps ;

mps.buf = buf ;

RawDoFmt(fmt, (&fmt)+1, myputstr, &mps) ;

return (int)strlen(mps.buf) ;

}

le putchar à la mode assembleur me donne la nausée… en C on ne peut pas toucher à A3, mais RawDoFmt permet de faire n’importe quoi avec A3, comme lui donner une structure dont on peut modifier le contenu à sa guise, ce qui est montré et démontré ici (c’est à la limite un scoop, jamais vu ailleurs ni sur les forums ni dans les docs)

Dans info.c, j’ai remplacé Printf() par PutStr() (comme ça, je vire amiga.lib) et remplacé main() par __main()

et l’exécutable pèse 8592 octets depuis.

Ajouté aussi

#define ID_SFS_BE_DISK (0x53465300L) /* SFS */

#define ID_SFS_LE_DISK (0x73667300L) /* sfs */

Mais horreur, il fonctionne en 68030, mais gouroute #3 en 68000… surement un truc pas cadré…

Le vikande sera studieux, vu qu’après je veux faire la version KS1.3
Ball000
3 février 2012 à 16h09 #157239
Joli __sprintf() !

Bizarre quand même ce plantage en 68000 : ce bug ne semble pas connu de la version du build-system sous 68000. On en saura plus quand tu auras trouvé le bug .

Sinon, pour le KS1.3, ce serait peut-être marrant d’essayer de lier brutalement les fonctions de gestion des patterns (et leurs dépendances non présentes sous KS1.3) ? Enfin en même temps, cela ne paraît pas jouable de faire cela pour la localisation…
Gilloo
7 février 2012 à 15h14 #157240
Le plantage était du à un appel à une chaine traduisible à ~0 (-1), certainement une astuce pour pouvoir passer directement la chaine par défaut, astuce qui manque dans la locale 3.1…

J’ai carrément tout réécrit, vu qu’il manque tous les états du disque (busy, no disk…) comme ça j’ai une super version de info compatible 1.3.

Apparemment le info du 3.1 n’est pas localisé.

Pour la gestion des patterns en 1.3, non ça ne peut pas fonctionner.

Le traitement des arguments C est parfois plus simple et suffisant pour une simple commande.

info [device]