AMS 2.07 - Page 3

On retrouve ce code raté un peu partout parce que c'est une macro. C'est la macro qui permet de déréférencer une variable HSYM (TI préfère l'in-liner plutôt que d'utiliser la ROM Call DerefSym()).

J'ai essayé de recréer cette macro avec TI Flash Studio, mais j'ai pas tout à fait réussi. J'ai même obtenu quelque chose de pire. #define HIWORD(l) ((unsigned short) ((unsigned long) (l) >> 16)) void main(void) {       char* HandleTable[2000];      HSYM hs = 0; // pour TI Flash Studio, HSYM est défini par typdef HSYM unsigned long;      SYM_ENTRY* sym_ptr;      sym_ptr = (SYM_ENTRY*)(HandleTable[(short)hs] + (long)HIWORD(hs));           //pour éviter que TIFS enlève les lignes au-dessus :      sym_ptr->hVal = 0;  //hVal est l'handle pour TIFS }

Et voilà ce qu'on obtient : _main:      link     a6,#-8012      movem.l     d3/a2,-8(a6)                ;char* HandleTable[2000];                ;HSYM hs = 0;      moveq     #0,d3                ;SYM_ENTRY* sym_ptr;                ;sym_ptr = (SYM_ENTRY*)(HandleTable[(short)hs] + (long)HIWORD(hs));      move.w     d3,d0      lsl.w     #2,d0      clr.w     d3      swap     d3      swap     d3      clr.w     d3      swap     d3      movea.w     d0,a1      lea      -7880(a1),a1      add.l     -128(a6,a1.l),d3      movea.l     d3,a1      movea.l     a1,a2                ;sym_ptr->hVal = 0;      move.w     #0,12(a2)      .ln      8      movem.l     -8(a6),d3/a2      unlk     a6      rts


Et GCC se rate pas là-dessus, lui.

C'est une source maximum par message.

Voilà, tu t'en es rendu compte.

Voilà une source pour faire générer du code comparable à GCC:

#define USE_TI89
#define USE_TI92PLUS
#define USE_V200
#define MIN_AMS 100
#define NO_EXIT_SUPPORT
#include <tigcclib.h>

#define HIWORD(l) ((unsigned short) ((unsigned long) (l) >> 16))

register unsigned long hs asm("d0")

void _main(void)
{ 
    char* HandleTable[2000];
    SYM_ENTRY* sym_ptr;
    sym_ptr = (SYM_ENTRY*)(HandleTable[(short)hs] + (long)HIWORD(hs));
    sym_ptr->handle = 0;
}

Et voilà ce que donne GCC 3.1:

_main:
#APP
#NO_APP
	link.w %a6,#-8000
	move.w %d0,%d1
	ext.l %d1
	lsl.l #2,%d1
	lea (%a6,%d1.l),%a0
	move.l %d0,%d1
	clr.w %d1
	swap %d1
	move.l -8000(%a0),%a0
	add.l %d1,%a0
	clr.w 12(%a0)
	unlk %a6
	rts

Il est super le code du TIFS !
J'aime bien le movea.l d3,a1; movea.l a1,a2; move.w #0,12(a2) !
(move.w #0,xxxx = clr.w xxxx) !
Quelles daubes les outils utilisés par TI... S'ils utilisaient GCC, la taille d'AMS serait diminuée de plusieurs dizaines de KO facilement !

Aussi: regardez les bugs du CAS, présents sur toutes les versions d'AMS (1.00/1.01, 1.05, 2.01, 2.03, 2.04, 2.05, 2.07 et donc 2.02):
intégrale formelle (x^20*sin(2x),x,0,pi/4).
et intégrale formelle (40*ln(x)^40,x,1,e).

erf, même avec le peu d'ASM que je connais, je vois des trucs pas terrible pour optimiser (ex : move #0, xxx ).

clr.w d3
11: swap d3
12: swap d3
13: clr.w d3
14: swap d3

quelle merde ce truc !

je c même pas ce que ça fait

inutile de le savoir pour savoir qu'effacer d3, faire 2 swaps (), encore effacer () et refaire un swap est totalement débile

Qu'est-ce qu'un SWAP ?

ca echange la partie haute et basse du registre

pour le CAS à mon avis les bugs y seront tant qu'ils ne changeront pas le processeur, car le code n'a pas été développer par TI, et donc ils ne peuvent pas le corriger eux-même sans payer (enfin je pense), et donc il leur faut une vrai raison pour le mettre à jour.

pour le code foireux, peut-être qu'ils utilisents du qBasic in-line dans leur compilo C

Ximoon
a écrit : pour le CAS à mon avis les bugs y seront tant qu'ils ne changeront pas le processeur, car le code n'a pas été développer par TI, et donc ils ne peuvent pas le corriger eux-même sans payer (enfin je pense), et donc il leur faut une vrai raison pour le mettre à jour.

TI a racheté Soft Warehouse, l'entreprise qui a créé Derive. Ils peuvent donc corriger ce qu'ils veulent là-dedans.

'savait pas...
n'empêche que je pense quand même qu'on peut toujours attendre pour une modification du CAS...

le truc est d'autant plus debile que 2 swap sur d3, ça donne rien et en plus avec des clr.w c encore mieux

et pis 2 effacements sur 16 bits du même registre à la suite, c'est fort qd même !

J'ai signalé ces problèmes au beta-testeur de TI qui vient sur le forum de TIGCC. Il a posté le même code compilé en mode release avec le SDK, qui semble être meilleur que celui de TIGCC (au niveau temps et taille, même s'il y a un triple swap d'un registre et un move.w #0,12(a0)).

Je dis 'semble' car à mon sens, il faut comparer des choses qui sont comparables: il compare une routine sans frame pointer (celle du SDK en mode release) et celle de TIGCC qui a un frame pointer par défaut. Sur une version ancienne de TIGCC (avec TIGCC 0.94 Beta 12), si je mets -fomit-frame-pointer, TIGCC assemble un code de même taille, et un poil plus rapide. Peut-être que cela change un peu sur des versions plus récentes de GCC...

De toute façon si on imagine ça en plein milieu d'un programme avec un DerefSym() vraiment utile, GCC rendrait quelque chose de meilleur que le compilateur de TI.

Soupir.

sourire

flood

étonnant ce topic

Vous pouvez aller voir le topic sur:
http://pub26.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=1647.topic
si ça vous intéresse...

remarquez que les topics de nioubi comme là, parte en couille en peu de temps sur un autre sujet. comme chez nous !