Logicielsmoto.com
http://www.logicielsmoto.com/phpBB/

Oh la belle bleue!
http://www.logicielsmoto.com/phpBB/viewtopic.php?f=10&t=418
Page 2 sur 3

Auteur:  gilles [ 18 Juil 2011, 16:37 ]
Sujet du message: 

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

Auteur:  PulkoMandy [ 23 Juil 2011, 09:19 ]
Sujet du message: 

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

Auteur:  Samuel Devulder [ 23 Juil 2011, 12:33 ]
Sujet du message: 

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:

Auteur:  gilles [ 23 Juil 2011, 13:29 ]
Sujet du message: 

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?

Auteur:  PulkoMandy [ 23 Juil 2011, 13:32 ]
Sujet du message: 

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

Auteur:  gilles [ 23 Juil 2011, 13:45 ]
Sujet du message: 

par là il me semble :
http://pulko.mandy.pagesperso-orange.fr/exodecrplus.asm

Auteur:  PulkoMandy [ 23 Juil 2011, 13:49 ]
Sujet du message: 

ah oui tiens :)

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

Auteur:  gilles [ 23 Juil 2011, 13:57 ]
Sujet du message: 

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

Auteur:  Samuel Devulder [ 23 Juil 2011, 14:51 ]
Sujet du message: 

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.

Auteur:  PulkoMandy [ 23 Juil 2011, 14:57 ]
Sujet du message: 

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

Auteur:  Samuel Devulder [ 23 Juil 2011, 15:00 ]
Sujet du message: 

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.

Auteur:  PulkoMandy [ 23 Juil 2011, 15:04 ]
Sujet du message: 

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

Auteur:  CloudStrife [ 23 Juil 2011, 18:15 ]
Sujet du message: 

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

Auteur:  gilles [ 23 Juil 2011, 22:32 ]
Sujet du message: 

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.

Auteur:  Samuel Devulder [ 23 Juil 2011, 22:46 ]
Sujet du message: 

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.

Page 2 sur 3 Heures au format UTC + 1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/