Logicielsmoto.com

Nous sommes le 14 Oct 2019, 00:11

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 18 messages ]  Aller à la page 1, 2  Suivante
Auteur Message
MessagePosté: 10 Mar 2010, 11:41 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 19:06 
Hors ligne

Inscription: 28 Jan 2007, 14:00
Messages: 33
c6809, par défaut, sort un fichier "binaire thomson", c'est à dire avec un header:
Code:
00 abcd efgh
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 !!!


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 20:52 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
megar a écrit:
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 ?


... d'autant plus que c'est déjà fait, à l'aide de l'option -bl, dixit le "lisezmoi.txt" :
Code:
  -b  type de la sortie (binaire non lineaire par defaut)
      l  binaire lineaire
      d  donnee


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 20:55 
Hors ligne

Inscription: 28 Jan 2007, 14:00
Messages: 33
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)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 20:58 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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?


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 21:15 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 21:35 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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 :^\)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 22:04 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Prehisto a écrit:
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 :lol:

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


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 22:39 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
Courage! En tout cas je trouve super de coder ASM et compiler à la vitesse de la lumière sur les PC modernes.

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

Samuel Devulder a écrit:
En plus C6809 compte les cycles pour nous. C'est cool pour tester plusieurs implémentations.

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

Samuel Devulder a écrit:
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,

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

Samuel Devulder a écrit:
sam (<== il :tourne: pas bien lui!!)

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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 22:48 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Prehisto a écrit:
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! :W )


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Mar 2010, 23:42 
Hors ligne

Inscription: 28 Jan 2007, 14:00
Messages: 33
Prehisto a écrit:
Ou simplement un fichier BIN, qui créerait un nouveau bloc (de taille quelconque) seulement quand les adresses ne sont pas consécutives?


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...)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 13 Mar 2010, 00:12 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
megar a écrit:
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 :)


Dernière édition par Prehisto le 13 Mar 2010, 00:33, édité 3 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 13 Mar 2010, 00:20 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 13 Mar 2010, 13:38 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Prehisto a écrit:
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.


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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 13 Mar 2010, 13:43 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
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.

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


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 18 messages ]  Aller à la page 1, 2  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 4 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com