Design de projet - Page 3

^^

de toute façon, mon code est parfait car kernel-based
(ça me fait penser que je m'étais amusé à faire un code qui se lancer en mode kernel quand il y en avait un, et en mode nostub sinon )

Fedora serait la solution ? pourtant fedora est en mode kernel, tirez en vos conclusions...
Martial : franchement, je pense que la "conception", le mieux pour la faire, c'est de la faire en s'obligeant à ne pas toucher au pc (crayon, papier et basta)

Tu peux surtout definir des etapes à ton projet qui permettent de tester ton soft en plusieures parties.

On pourrait par exemple considérer que tu respectes le format gnu des fichiers assemblés et donc les assembler avec ton programme et les linker avec le linker gnu, et vis versa!
Faut que tu puisses voir le resultats en plusieurs fois et pas juste à la fin
Ensuite l'astuce consiste aussi a faire qqc de simple qui supporte pas tout a debut pui d'y revenir pour ajouer les fonctions de moindre importance.

Utilise le linker GNU (ou celui de TIGCC), c'est mal parti pour un assembleur en assembleur on-calc.

Folco (./60) :
Bon, appel général ! Qui veut pouvoir avoir (ou non) du code dans les headers ? Quelles bonnes raisos invoquez-vous ?

Oué des fonctions (en C hein) qui sont déclaré comme static inline

Kevin Kofler (./70) :
Utilise le linker GNU (ou celui de TIGCC), c'est mal parti pour un assembleur en assembleur on-calc.

C'est possible de récupérer les fichiers *.o et ensuite les parser pour sortir des fichiers unix et enfin utiliser le linker gnu. Bon après c'est sur que c'est plus pratique dans l'autre sens

(je répondrais peut-être plus précisément à tes posts précédents un autre jour, là je n'ai pas le temps).
Sinon je ne suis pas pour différencier code et headers, je ne pense pas que ça apporte tellement d'avantages (ni pour toi ni pour les développeurs qui utiliseront ton assembleur).

Mais il y a un petit détail auquel je n'avais pas pensé, en fait moi je pensais que tu lirais chaque fichier source en une fois et que tu garderais en mémoire toutes les infos nécessaire concernant les equ, les macros, etc. dans une grande table des symboles de façon à ne pas avoir à relire les fichiers à chaque appel de macro. Mais c'est vrai que sur TI la mémoire est assez limitée, peut-être que ton idée est plus jouable. J'aimerais savoir ce qu'en pense Pollux, il me semble que pour des raisons de faible mémoire GTC assemble une fonction à la fois, pas plus, sinon la table des symboles explose.

Folco (./73) :
Les autres, quepensez vous d'interdire les macros et les equates dans les fichiers sources ? L'avantage est énorme au niveau simplicité, ça permet de n'ouvrir les headers qu'en lecture seule, sans créer de table dynamique, tout ça pour un seul equ au milieu d'un source. Et au passage, ça accélèrerait l'assemblage (code différent pour lire un header ou un source) et réduirait de beaucoup la conso en RAM (je fais déjà tout pour que ce soit minimal).

J'attends vos avis. De mon côté, tout en explosant une pompe à vide sur un toit et en foutant en vrac mes manos cet aprè'm, je pense avoir touvé la solution pour ce que j'ai exposé en vrac hier soir

Si tu veux éviter de faire deux passes séparer headers et code c'est pas forcément la meilleure idée (ne serait-ce que parce que tu voudras déclarer des macros/constantes locales dans un fichier source) : mieux vaut faire comme en C où les equ doivent être définis avant d'être utilisés.

Qu'est-ce que tu entends par "ouvrir en lecture seule" ?

Sasume (./74) :
J'aimerais savoir ce qu'en pense Pollux, il me semble que pour des raisons de faible mémoire GTC assemble une fonction à la fois, pas plus, sinon la table des symboles explose.

C'est pas tellement une question de table des symboles, tout l'arbre syntaxique de la fonction est gardé en mémoire pour pouvoir faire des optimisations donc évidemment on peut pas garder le code de 50 fonctions à la fois en mémoire. Un assembleur n'est pas concerné par ce problème ^^

Folco (./75) :
tu as raison, son avis m'intéresse. Je pense particulièrement au header tios.h. Il est énorme. De touet façon, stocker toutes ses infos dans une table, plus celles éparses ici et là revient à créer un fameux doublon, ej n'en vois pas l'intérêt. Juste pour le parsing ? C'est se permetre de perdre un sacré paquet de mémoire pour quelques milisecondes...

GTC utilise des headers précompilés, pour éviter de devoir passer une éternité à tout parser et à tout stocker. Mais c'est pas nécessaire pour un assembleur : l'assembleur doit juste retenir des macros, il n'a pas à parser de prototypes -- parser un fichier comme tios.h se limite à noter les offsets du nom de l'equ et de son contenu, et zapper jusqu'à la ligne suivante (plus quelques détails comme passer les commentaires, la compilation conditionnelle, etc). Si ton fichier n'est pas compressé tu as seulement besoin de retenir ces offsets puisque tous les fichiers sont mappés en mémoire, ce qui t'amène à 4 octets par symbole (8 octets si tu stockes des pointeurs, c'est sûrement plus efficace). Et après il suffit de les organiser dans un structure efficace genre table de hash ou arbre binaire de recherche

Je suis perdu. Ce topic mélange de la spec, de la conception, du codage, des méthodes, des plans, ...

Folco (./53) :
Je dispose déjà d'un handle où sont écrits tous les pointeurs vers les sources ouverts (PpHd, un fichier ouvert par fopen est locké ? pas vérifié, pataper...)

Oui

Sinon mon opinion:
Je ne vois pas trop l'intéret de pouvoir assembler plusieurs sources séparement. Un include est largement suffisant, et on assemble toujours tout d'un coup.
De toute facon, les programmes resteront très simple on-calc. Faire un vrai linker et un GROS boulot qui tu vas devoir faire (en plus de perdre de la place car il faut pouvoir stocker en RAM les objets + le binaire final.
Bref faire du multi-source, c'est largement plus compliqué.
Il est possible de faire un assembleur une passe, mais c'est largement plus compliqué qu'un deux passe.
Il n'est pas nécessaire, voir déconseillé de différencier le header / source. Peu de langages le font.
Comme tu n'as jamais créé d'assembleur, simplifie, et fait un simple source / deux passes pour le moment.
Ne vise pas la perfection dès le début. Fait un proto.

Je ne vois pas l'avantage. Tu est obbligé de faire une table des symboles en passe 1 valant tous les labels / EQU qui trainent.
(Par contre, tu peux 'optimiser' la table en faisant juste 10 octets par symbole (un pointeur vers la chaine du symbole dans le fichier assemblé / qui finit soit par ':', ' ' ou \n ou '\0', son type, sa valeur 32 bits (addresse ou pour EQU pointeur vers la chaine de remplacement).
Il te faudra aussi une autre table des symboles indéfinies (genre les graphlib@0000, @version, ...).

Ecrit exactement l'algo simple de ton assembleur (dans ce topic). Passe 1 et passe 2.

Folco (./79) :
Ok, je pense que t'as raison, surtout qu'autant j'aime pas le code dans les headers, autant j'ai rien contre l'inclusion des sources.

"inclusion des sources" est juste un autre mot pour "code dans le headers" (sauf qu'en plus le header n'a pas le bon nom de fichier). C'est le même hack obsolète qui ne sert à rien depuis qu'il existe des linkers pour notre plateforme.

PpHd (./80) :
(Par contre, tu peux 'optimiser' la table en faisant juste 10 octets par symbole (un pointeur vers la chaine du symbole dans le fichier assemblé / qui finit soit par ':', ' ' ou \n ou '\0', son type, sa valeur 32 bits (addresse ou pour EQU pointeur vers la chaine de remplacement).

Moi, je propose une table par fichier source ou header (*), 4 octets par symbole. Comment?
* Les 2 premiers octets représentent l'offset depuis le début du fichier où se trouve le label.
* Si c'est un label, les 2 octets qui suivent représentent l'offset du label dans le binaire.
* Le choix de la syntaxe GNU as (et oui ) permet de:
- ne pas préciser le type du symbole: s'il est suivi de ':', c'est un label, s'il est suivi de ',', c'est un equate,
- ne pas préciser la valeur de l'equate, elle se trouve juste après la virgule (je rappelle que la syntaxe est .equ symbole,valeur). Mais on pourrait aussi l'encoder sous forme d'un offset de 2 octets depuis le début du fichier source, à la place de l'offset dans le binaire utilisé pour le label.

(*) Pour gérer les inclusions, on peut faire une métatable avec des pointeurs sur les tables pour les headers inclus.

Folco (./81) :
En fait, j'ai absolument pas la même approche que toi. Je mets à peu près au propre ce que j'ai en tête puis je le poste.

Ne t'inquiète pas, je fonctionne aussi comme ça. Je conçois dans ma tête, puis je code directement, j'écris rarement du pseudocode.

(il a sacrément dévié ce topic, finalement on est revenu sur des discussions très bas niveau assez rapidement ^^)

Histoire de rester dans le sujet, j'ai une petite question :

Qu'utilisez-vous comme outils pour les spécifications et la conception de vos applis ? La réponse m'intéresse surtout dans un cadre "perso" (bien que justement dans le cadre perso on ne prenne pas toujours le temps de faire de la conception et encore moins de la spécification), parcequ'en entreprise je suppose que ça va tourner autour de Word, Visio & co que je trouve assez mal adaptés.

Zephyr (./85) :
En entreprise je suppose que ça va tourner autour de Word, Visio & co que je trouve assez mal adaptés.

pourquoi donc ? (juste par curiosité)

perso j'ai pas d'outil particulier. J'ai pris open office mais ça pourrait être notepad

Flanker (./86) :
pourquoi donc ? (juste par curiosité)

En fait ce n'est pas Word que je trouve mal adapté, c'est le formalisme "texte non structuré". Je suis à peu près sûr qu'on peut trouver (ou faire, si ça n'existe pas) un outil qui permette d'ordonner les idées de façon plus efficace qu'un gros document de 100 pages. Quand j'ai posé la question hier à quelqu'un, on m'a suggéré "un wiki", et effectivement c'est une très bonne idée (et ça se fait visiblement de plus en plus) ; il y a probablement plein d'autres solutions.

Pour Visio par contre, c'est parceque je n'aime pas trop ce logiciel. Il est surpuissant, certes, mais pour avoir utilisé omnigraffle je préfère vraiment un outil très simple qui me permette d'avancer très vite plutôt que Visio et ses 350 boites de dialogues imbriquées par lesquelles il faut passer pour sortir le moindre diagramme :/

(et sinon j'ai espoir que quelqu'un me sorte l'outil miracle qui permettrait par exemple de guider la saisie d'une conception détaillée, mais je n'ai jamais fait ça autrement qu'avec des tableaux Word pas beaux et je ne sais même pas si ce que je cherche existe ^^)

Trac est un outil sympa qui integre Wiki + un mini gestionnaire de projet (timeline & co) et un gestionnaire de sources


Sinon (c'est mac only malheureusement) mais il y a des outils comme OmniPlan ou OmniFocus qui sont pas mal pour la gestion de projets

ouep Trac est pas mal (un peu limité au niveau des formats disponibles dans le Wiki, mais il me semble que ça peut s'arranger facilement)

par contre c'est vrai que je n'avais pas précisé, mais ce sont surtout des outils pour Windows qui m'intéressent ^^ (ou des applis web comme Trac)