Logicielsmoto.com

Nous sommes le 15 Sep 2019, 21:07

Heures au format UTC + 1 heure




Poster un nouveau sujet Ce sujet est verrouillé, vous ne pouvez pas éditer de messages ou poster d’autres réponses.  [ 32 messages ]  Aller à la page Précédente  1, 2, 3  Suivante
Auteur Message
 Sujet du message:
MessagePosté: 18 Juil 2011, 16:37 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
en fait le test portait sur la compilation du décodeur C.
A priori ce compilo C (mc09) est fiable (il arrive même à se compiler lui même) mais n'optimise pas et la syntaxe est d'un autre age (pur K&R et grosses limitations sur la déclaration).

_________________
http://www.alternative-system.com


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 09:19 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
J'ai essayé de compiler exodecr.c avec gcc-6809. Pas encore vérifié si ça marche, mais le binaire résultant (comprenant en plus un main pour appeler cette fonction fait 928 octets. Pas terrible... :)

http://pulkomandy.lexinfo.fr/to8/exodecr.s

Sur z80 de mémoire on prend à peu près 300 octets.

Je vais voir si au moins ça fonctionne...


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 12:33 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
PulkoMandy a écrit:
J'ai essayé de compiler exodecr.c avec gcc-6809. Pas encore vérifié si ça marche, mais le binaire résultant (comprenant en plus un main pour appeler cette fonction fait 928 octets. Pas terrible... :)

C'est pas surprenant, le compilo C passe son temps à utiliser D (16bits) pour des opérations qui devraient se faire sur B seul. On trouve ainsi
Code:
L7:
   ldd   13,s
   clra   ;andqi(ZERO)
   andb   #15
   cmpd   #0  ;; Nota: ICI il vaudrait mieux subd #0: 20% plus rapide
   bne   L2
là ou
Code:
L7:
        ldb     #15
        andb    14,s
        bne     L2
fait le même boulot en moitié moins de registres, de code et de cycles.

Mon petit doigt me dit qu'on peut faire nettement mieux que les 300 octets du Z80, hein fool? :langue:


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 13:29 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
si la taille de l'int est 16bit ca n'est pas non plus surprenant pour un compilo C.
Tu as utilisé quel compilo en fait? gcc 2.95 ? le dernier gcc 6809 (qui doit etre un 3 ou un 4)? ou bien l'antique mc09 qui est sur ma page?

_________________
http://www.alternative-system.com


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 13:32 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
ça c'est le dernier gcc (4.3.4) avec mes "patchs" pour faire du thomson (pas grand chose à changer finalement, à part les adresses en mémoire).

J'avais aussi fait une version avec mc09 mais je sais plus ou elle est.


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 13:45 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
par là il me semble :
http://pulko.mandy.pagesperso-orange.fr/exodecrplus.asm

_________________
http://www.alternative-system.com


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 13:49 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
ah oui tiens :)

voilà de quoi comparer les deux compilateurs, donc ... :)


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 13:57 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
le compilo semble se planter sur certains labels. Apres correction manuelle on est à 555 octets dont les 128 des 2 tableaux.
Si le code marche ce serait pas mal déjà.
[edit]
les 156 octets du global en fait (le premier tableau est int).

le code en lui meme ferait donc 400octets.

[edit2]
bon, en fait il ne se plante pas mais il manque du code pour les décalages sur 16bits. (soit les labels _00007 et _00009)
et on monte à 599 octets

_________________
http://www.alternative-system.com


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 14:51 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
gilles a écrit:

Le code de GCC est encore optimisable. Par exemple
Code:
   LEAX   0,Y
   LEAX   D,X
peut devenir
Code:
   LEAX   D,Y
De même
Code:
   LDD   #1
   PSHS   D
   LEAX   4,U
   PSHS   X
bénéficirait d'une fusion des PSHS:
Code:
   LDY   #1
   LEAX   4,U
   PSHS   X,Y

Si c'est le même gcc que celui que j'avais testé ici, je me demande ce que donne le code avec -msoft-reg-count=4 ainsi qu'avec -mint8.


Dernière édition par Samuel Devulder le 23 Juil 2011, 14:58, édité 1 fois.

Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 14:57 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
mint8 donnerait du code qui ne marche pas :lol:

Pour les soft regs, j'ai essayé mais le résulat a l'air d'être complètement identique...


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 15:00 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
PulkoMandy a écrit:
mint8 donnerait du code qui ne marche pas :lol:

Il faut probablement remplacer les int par des long pour les trucs vraiment 16bits. Perso je pense qu'un algo devrait utiliser les types dont les tailles sont clairement établie et pas sujet à variantes: int8_t, int16_t, uint8_t, uint16_t, etc. Voir stdint.h.


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 15:04 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 417
Localisation: France
Non mais ce code est prévu pour être compilé en 16 bits. Il utilise des char ou unsigned char pour les trucs 8 bit, et des short int pour les 16 bits. Tout est donc de la faute du compilateur :)


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 18:15 
Hors ligne

Inscription: 27 Juil 2010, 14:46
Messages: 38
Samuel Devulder a écrit:
Le code de GCC est encore optimisable. Par exemple [...]


Yep, quand j'avais regardé, la liste de peephole était pas trop importante, probablement pas mal de boulot de ce côté...
(Et comme l'asm 6809 j'y connais goute...)


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 22:32 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
en meme temps, sur du TO8 (avec ses 256ko) même à 900 octets c'est très acceptable. reste à vérifier si la vitesse est correcte et pas trop pénalisante pour les chargements.

Je vais essayer de faire un test avec le code généré par mc09, meme si le code généré semble moins performant.

_________________
http://www.alternative-system.com


Haut
 Profil  
 
 Sujet du message:
MessagePosté: 23 Juil 2011, 22:46 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1111
Localisation: Brest
gilles a écrit:
en meme temps, sur du TO8 (avec ses 256ko) même à 900 octets c'est très acceptable.
Mon petit doigt me dit qu'on peut faire largement moins de 200octets... mais bon il faut utiliser des op non documentées type "TFR X,A" non supportées par tous les émulateurs...

@CloudStrife: tu devrais essayer l'asm 6809. C'est vraiment un ASM très agréable. Voici une doc officielle: http://www.maddes.net/m6809pm/. Perso j'ai débuté l'asm en tombant sur ce tableau dans un club informatique durant les vacances. La dessus un petit peu de cours asm-thomson dans l'hebdogiciel (voir le sujet dédié ici) et c'est parti mon kiki pour réaliser de zolis progs rapides sur thomson! Si tu connais déjà l'asm d'autres machine, alors la reprise des bases à partir du numéro 156 sera suffisante pour débuter je pense.


Haut
 Profil  
 
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Ce sujet est verrouillé, vous ne pouvez pas éditer de messages ou poster d’autres réponses.  [ 32 messages ]  Aller à la page Précédente  1, 2, 3  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité


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