Logicielsmoto.com

La version 0.82 vous attends à la même adresse : http://www.pulsdemos.com/c6809.html.

Le nouveau bug a été corrigé.

Je vais donc laisser C6809 de côté pour l'instant (sauf nouveau bug découvert), et retourner à mes moutons.

c6809, par défaut, sort un fichier "binaire thomson", c'est à dire avec un header:
avec abcd: longueur du bloc et efgh adresse de chargement du bloc.

C'est super pratique ! Surtout qu'on peut mettre plusieurs directives ORG dans le source.

MAIS: c6809 s'obstine à maximiser la tailler des blocs à 128 octets ! (fonction du source: SaveBinChar())

Pourquoi ? Il me semble que rien ne limite la taille des blocs, j'utilise d'habitude des blocs de 65535 octets.

J'ai le droit de demander que tu changes ça ?

merci !!!

... d'autant plus que c'est déjà fait, à l'aide de l'option -bl, dixit le "lisezmoi.txt" :

non, tu n'as pas compris ma requete:

Je voudrais que le fichier de sortie (sans -bl ni -bd) utilise des blocs de 65535 octets max au lieu de 128 octets max. (regarde la fonction dont je parle)

Tu veux donc dire : pouvoir faire un "super" fichier BIN avec autant de blocs de 65535 octets que tu veux?

Ou simplement un fichier BIN, qui créerait un nouveau bloc (de taille quelconque) seulement quand les adresses ne sont pas consécutives?

Parce que la fonction SaveBinChar fait bien appel à la fonction SaveBinBlock, et SaveBinBlock, avec l'option -bl, n'est pas censée créer un nouveau bloc tous les 128 octets si les adresses sont consécutives.

Oui, effectivement, il y a comme un problème : dans le cas d'un binaire linéaire, si les adresses ne sont pas consécutives, il y a une erreur "Binary Not Linear". Donc bug.
(Je sens qu'il va y avoir une version 0.83 :^\)

Courage! En tout cas je trouve super de coder ASM et compiler à la vitesse de la lumière sur les PC modernes. En plus C6809 compte les cycles pour nous. C'est cool pour tester plusieurs implémentations.

Si je n'avais rien à faire (et si j'étais plus jeune), j'aurais bien envie de faire un éditeur ASM thomson avec coloration syntaxique, completion, et debugger etc pour l'IDE eclipse. lol

sam (<== il pas bien lui!!)

Ca, c'est sûr que...


Un truc qui aurait été bien utile pour faire Chinese Stack et Space Project. Et CC90 aussi.


J'y ai pensé. Mais carrément faire un éditeur en C. Avec coloration syntaxique, bien sûr.


Si, ça peut aller

Par contre, j'étais tranquillement en train de coder CC90 en mode fenétré (et oui, c'est la prochaine étape) quand vous vous êtes manifestés à propos de C6809. Et là, je dois avouer que j'ai été pris de court.

J'ai relu le programme, j'en ai eu l'occasion, je l'ai trouvé abominable. C'est vraiment un proto de chez proto. J'ai donc commencé à retravailler dessus, je l'ai découpé en morceau, j'ai fixé les extern, je l'ai splinté, et je suis en train de reconfigurer tout ça, parce qu'il y a des parties qui ne me plaisent pas du tout. Comme quoi, ça n'est pas parce qu'on écrit vite qu'on écrit bien (j'ai presque écrit le programme originel d'une traite, sur plusieurs jours, mais bon).

Je vais continuer à maintenir la version "monobloc", mais ça va m'être épuisant.

Moi la version monobloc ne me déplaisait pas. On a tout sous la main. Mais bon, les gouts et les couleurs... peu importe. L'essentiel c'est que toi et les utilisateurs soient content de ton prog. En plus ca n'est pas si monobloc que cela. Il y a bien pire, par exemple la lib cimg (tiens l'auteur est passé dans le même labo de recherche que moi dans le temps).

sam (un prog moche écrit par un gars motivé sur un coin de table et qui est maintenu et qui fonctionne vaut mieux qu'un prog bien écrit par une équipe de pros mais qui ne marche pas! )

Voilà c'est ça !
En gros que tu modifies
"|| (bin.size == 0x0080)"
par
"|| (bin.size == 0xffff)"

Parce que je vois pas bien l'intérêt de splitter tout en blocs de 128 octets. (mais il y a peut-etre une raison que j'ignore...)

C'est juste une question de place mémoire.

Lorsqu'Assembler sauvegarde la compilation d'un source, il remplit, octet par octet, le buffer de 128 octets (et c'est déjà beaucoup) qui lui est alloué pour l'occasion, en conservant l'adresse d'implantation du bloc et en comptant les octets. Une fois que ce bloc est plein (ou une fois que l'on est au dernier bloc), le programme sauve le header (flag, taille, adresse) puis le bloc de données.

Pour sauver des fichiers binaires "linéaires" par compilation, il y a deux options :
- Soit on a effectivement un buffer de 65535 octets (sur un TO7 sans extension, ça va être difficile à trouver);
- Soit on réserve de la place pour le header de bloc sur le périphérique, on écrit les données, puis on retourne à l'endroit du header de bloc pour ajuster la taille dans le header, pour revenir ensuite à la fin des données et recommencer l'opération. Mais je vois difficilement quelqu'un arriver à ce résultat avec un LEP, par exemple.

Et tu as raison, c'est pourtant le résultat qu'il faudrait obtenir, bien que ce que j'appelle un binaire linéaire, c'est un binaire en un seul bloc (obtenu par SAVEM sous Basic), donc avec des adressages consécutifs du début à la fin.

Nous allons assister à la naissance d'un format hybride de fichier binaire (déjà en vigueur sur le cross-compiler?) qui n'est pas censé exister sur Thomson, qui non seulement autorisera les blocs de plus de 128 octets, mais qui gèrera aussi les changements d'origine

Pour y revenir, tu remarqueras aussi qu'il y a de "longues" pauses entre les blocs lors d'une sauvegarde par blocs de 128 octets, dues au fait que le moteur du LEP s'arrête une fois que le bloc est écrit et redémarre pour écrire le suivant. Ce qui permet sur le Thomson de transférer ces fichiers binaires "non-linéaires" d'une cassette à une disquette et vice-versa. Ce que n'autorisent pas les fichiers binaires "linéaires" de plus de 128 octets, le buffer de transfert alloué par le système étant trop petit.

En fait il y aurait un 3eme choix en ajoutant une passe de plus. Au lieu d'écrire sur le périphérique, Assembleur pourrait ne compter que la taille de la section linéaire, et dans la passe supplémentaire il l'écrirait correctement en connaissant la taille de la section.

Ca serait plus long, mais ca marcherait.

sam.

J'ai opté pour la première option. Après tout, une allocation mémoire de 64 kilooctets, avec les PC d'aujourd'hui...