30

J'ai pensé à faire un bench sur 100 000 000 instructions, oui grin Au fait, c'était bien sur ta calc, pas VTI ?

Mais que signifie le 4(1/0)* alors, s'il ne peut arriver puisqu'on aura toujours l'extension.

31

1. oui, oui.
2. Je ne sais pas.

32

Et merde, j'ai fait des tests avec $10000 * $80 * 10 additions pour chaque cas, même temps à la seconde près (et j'ai déroulé un minimum mes boucles pour pas trop passer de temps dans les dbf). Merde alors ! Elle veut dire quoi la doc ?!?

33

PpHd (./31) :
2. Je ne sais pas.


34

Oui, question réthorique, je vais tout de même pas mailer Motorola grin

35

À ma connaissance, addq.l ou addq.w pour un registre d'adresses reviennent exactement au même (taille, vitesse, résultats), du moins d'après toutes les tables de cycles que je connais. Et si en plus PpHd dit qu'il a mesuré…
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

36

Je me souviens que quand on faisait des tests pour bencher genlib les résultats oncalc étaient parfois un peu différents de données fournies dans la doc de Motorola.
Et ils étaient même différents selon que la calc était HW1 ou HW2 (je ne parle pas du fait que les HW2 avaient une horloge à 12 MHz, hein)
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

37

Sasume (./36) :
Je me souviens que quand on faisait des tests pour bencher genlib les résultats oncalc étaient parfois un peu différents de données fournies dans la doc de Motorola.
Et ils étaient même différents selon que la calc était HW1 ou HW2 (je ne parle pas du fait que les HW2 avaient une horloge à 12 MHz, hein)

Yes, sir!

38

Eh merde, j'avais presque trouvé un moyen pour avoir mon copyright dans la moitié des fonctions de PedroM cry grin

39

Désolé mourn

40

Pas grave. ^^

J'ai trouvé l'optimisation suivante, dans pas mal de fonctions sûrement :
movea.l (sp)+,a1
movea.l (sp),a0 / move.w (sp),d0 ;ici on récupère les deux octets perdus au début
[fonction]
jmp (a1)

on gagne 8 cycles avec le jmp par rapport au rts, au moins 4 avec la lecture du premier argument sans offset, ça coute sûrement moins que le movea du début.

Mais bon, j'imagine pas la merde pour gagner si peu grin

41

Moi j'ai une optimisation extrême: Tu remplaces toutes tes fonctions par "rts", puis tu optimise par réduction / code similaires, ce qui te donne un programme principal simple: "rts". Et ensuite tu appliques cette optimisation à tout le système, donc tu n'as plus qu'un seul programme ("rts"), et tous les autres sont des liens symboliques vers celui là.
Plus aucun cycle gâche, puisque le code ne fait plus rien ! oui
(Désolé grin)

Sinon l'optimisation que tu proposes là me semble typiquement adaptée à l'application dans un compilateur, beaucoup moins pour de l'assembleur écrit à la main.
M'étonnerait que quiconque daigne prendre le temps d'appliquer ça partout. grin
(Et c'est pas forcément "si peu", mais bon, si jamais cette optimisation devait être significative, il existe une(des) optimisation(s) d'ordre supérieur nettement plus intéressante(s))
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

42

Je pense aussi ^^

43

Folco (./40) :
on gagne 8 cycles avec le jmp par rapport au rts, au moins 4 avec la lecture du premier argument sans offset, ça coute sûrement moins que le movea du début.

Désolé, movea.l (%sp)+,%an coûte exactement 12 cycles, et tes "au moins 4" cycles sont exactement 4 cycles, donc au final tu n'as rien économisé, juste rendu ton code illisible.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

44

LOL Folco, courage, tu vas en trouver une d'optim utile grin

45

Tout ça c'était des idées en l'air sans même avoir le nez dans le source, ça devrait pas être impossible si je m'y mettais sérieusement grin

46

Tiens, je viens de voir ça en faisant un transfert GCC4TI -> VTI, il fait taper à PedroM 'name()'
Et PedroM, après avoir écrit tout ce que dit le programme sur stdout, rajoute une ligne avec '000000'

J'imagine qu'il calcule name x (), l'expression dans la parenthèse étant initialisée à 0. J'ai parfois eu des comportements un peu plus bizarres, où il me sortait une valeur non nulle (genre 4.000000).

Bref, rien de grave docteur, mais ça serait peut-être bien de faire une différence entre abc(1+2), avec abc qui est une expr, et abc qui est un programme. Quitte à devoir spécifier explicitement abc * (1+2) si abc est un programme.

47

name() est une fonction qui retourne le float courant (que le programme peut mettre à jour via d0.l)
name est un programme.
abs *(1+2) est une expression

48

Ah ok.

Mais alors comment expliquer ça ?
Les espaces sont importants entre 'as' et '()'
Les "File not found" sont envoyés par as.
:>as ()
File not found: ()
:>as()
File not found: )
4.0000000000000000
:>as
:>as()
000000


Reprenons :
:>as ()
File not found: ()

Normal.
:>as()
File not found: )
4.0000000000000000

4 est bien le code d'erreur pour un fichier non trouvé, mais pourquoi PedroM a-t-il dit à mon programme que ')' est le premier argument de la ligne de commande ?
:>as
:>as()
000000

Maintenant, as() me renvoie juste 000000 et plus 4.00000000000000.
En fait, as() me renvoie 4.00000000000 après que j'ai exécuté 'as ()' et tant que je n'ai pas exécuté 'as', puis il me renvoie 000000. Si je ré-éxécute 'as ()', il me renverra à nouveau 4.000000000.

49

Folco (./48) :
4 est bien le code d'erreur pour un fichier non trouvé, mais pourquoi PedroM a-t-il dit à mon programme que ')' est le premier argument de la ligne de commande ?


Honnêtement ca doit être un bug.

50

Je viens de corriger un bug dans mon programme, un jmp (a0), avec a0 == 0.
On obtient un "Error: unknown error", puis la calc se retrouve dans un état instable (Panic quand on relance un programme).

Comme un jmp/jsr a0 est un bug peut-être plus fréquent que d'autres, j'ai une idée : on pourrait écrire à 0 'jmp Execute0Handler', qui affiche un message d'erreur genre "error: execution at 0x00", puis qui appellerait kernel::exit pour finir proprement.

Il y aurait très peu à modifier : SSP_INIT et CODE_START pourraient être enregistrés en ROM comme des constantes, qu'il suffirait de restaurer à l'exécution d'un SYSTEM_ERROR.

Ca pourrait être bien ou c'est en fait complètement inutile ? Apparemment, la stabilité sous PedroM étant totalement dévolue aux kernel (crash handler spartiate, clean pouvant planter etc...), je suis pas sûr que tu en veuilles grin

51

Oui, on pourrait.
C'est vrai que c'est spartiate sous PedroM en cas de crash...
Un peu trop peut être
D'un autre coté les utilisateurs doivent avoir lu le manuel qui dit qu'en cas de crash, il est recommandé de faire clean, puis reset si cette commande plante smile

52

PpHd (./51) :
Oui, on pourrait.

Tu veux une proposition ?
PpHd (./51) :
D'un autre coté les utilisateurs doivent avoir lu le manuel qui dit qu'en cas de crash, il est recommandé de faire clean, puis reset si cette commande plante

Tout à fait et on est bien d'accord, mais la moindre merde termine en reset sous PedroM (essaye de récupérer un Panic ou un simple "unknown error" avec clean quand t'as eu un fichier ouvert, écrit sur un flot etc...). C'est d'autant plus dommage que PreOS est vraiment performant au niveau de la récupération des crashes.

Ca t'intéresserait d'essayer d'avoir un clean plus performant ?
Folco (./50) :
la stabilité sous PedroM étant totalement dévolue aux kernel

Je voulais dire au programmeur évidemment, le kernel ne faisant pas des masses de ce côté ^^

53

Je peux faire une option d'auto reset en cas de crash embarrassed

54

lol grin

Plus qu'un auto-reset, je verrais plus un auto-clean, désactivé par défaut.
Je te reparlerai de tout ça quand t'auras avancé dans tes réflexions au sujet de la stratégie pour la stabilité. cheeky

55

Juste pour signaler un truc, par exemple dans Memstr.asm :
strcmp:
	move.l	4(a7),a0
	move.l	8(a7),a1

Il y a souvent un peu à gagner (vitesse et taille), surtout pour les romcalls qui prennent pas mal de paramètres, avec un :
movem.l 4(a7),a0-a1
-2 octets

Ou encore :
memmove:
	move.l	4(a7),a0	; Destw
	move.l	8(a7),a1	; Src
	move.l	12(a7),d0	; Len
	beq.s	memend

=>
        movem.l 4(sp),d0/a0-a1
        exg.l   d0,a1
        tst.w   d0
        beq.s   memend

-2 octets
(ça inverse juste l'utilisation de a0/a1 dans ce cas-là)

56

C'est sympa, mais le gain ne vaut pas le risque corru :
4 octets sur 555.200 octets, ca fait un gain de 0.0007% .
changer en utilisant des movem au lieu des move : risque d'erreur 1% / risque de maintenance: 1%

57

Je m'en doutais. C'est juste que ce n'est pas l'utilisation la plus habituelle de movem qu'on ait quand on lit des arguments, mais par exemple pour Par je m'en sers et ça fait gagner pas mal. C'était juste une idée au passage.

58

Pwet encore.

Tu avais réimplémenté, à ma demande, pedrom::unlink afin que celui-ci efface un fichier même en archive, permettant son effacement même avec une RAM pleine. Merci beaucoup, c'est en effet impossible sans hacker la flash sous AMS.

Le truc, c'est que tant qu'à faire, ne pourrait-on pas rendre unlink plus profitable, afin qu'il sache effacer un fichier en flash ou en RAM ? Là, il ne fait rien si le fichier est en RAM, c'est en peu dommage. En effet, c'est au programme de regarder où est le fichier, et d'appeler pedrom::unlink dans un cas, ou alors SymDel dans l'autre...

Autre pointà noter, pedrom::unlink retourne toujours 0.

Alors ce qui serait faisable à peu de frais, ce serait ça :
- pedrom::unlink appelle EM_delSym (ce qu'il fait actuellement).
- si fichier en flash, EM_delSym appelle EM_abandon et renvoie TRUE en cas de succès (comme SymDel).
- si fichier en RAM, EM_delSym appelle SymDel et renvoie la valeur de SymDel.
- pedrom::unlink retourne la valeur de EM_delSym (au lieu de 0 actuemment).


Voilà, je suis en train de coder ce qui touche à mon switch -force dans par (plus que 2 fonctions à écrire cheeky), et je me rends compte que le programme doit dupliquer le travail pour effacer à coup sûr.
Si tu acceptes cette proposition mais que ça te fait suer de l'implémenter, je veux bien écrire le patch.

Merci d'avance. smile

(ps -> en plus ce qui facilite la tâche, c'est que EM_abandon renvoie FALSE en cas d'échec, alors que sous AMS c'est un void, donc c'est du tout cuit cheeky)
(ps2 -> quand je parle de SymDel, je parle en fait de SymDel_SymEntry_reg)

59

hmmm 'info unlink' me donne ça :
   An exit status of zero indicates success, and a nonzero value
   indicates failure.

pedrom::unlink devrait donc retourner !EM_delSym pour bien faire.

60

Folco (./58) :
Pwet encore.

Tu avais réimplémenté, à ma demande, pedrom::unlink afin que celui-ci efface un fichier même en archive, permettant son effacement même avec une RAM pleine. Merci beaucoup, c'est en effet impossible sans hacker la flash sous AMS.

Le truc, c'est que tant qu'à faire, ne pourrait-on pas rendre unlink plus profitable, afin qu'il sache effacer un fichier en flash ou en RAM ? Là, il ne fait rien si le fichier est en RAM, c'est en peu dommage. En effet, c'est au programme de regarder où est le fichier, et d'appeler pedrom::unlink dans un cas, ou alors SymDel dans l'autre...

Autre pointà noter, pedrom::unlink retourne toujours 0.

Alors ce qui serait faisable à peu de frais, ce serait ça :
- pedrom::unlink appelle EM_delSym (ce qu'il fait actuellement).
- si fichier en flash, EM_delSym appelle EM_abandon et renvoie TRUE en cas de succès (comme SymDel).
- si fichier en RAM, EM_delSym appelle SymDel et renvoie la valeur de SymDel.
- pedrom::unlink retourne la valeur de EM_delSym (au lieu de 0 actuemment).


Voilà, je suis en train de coder ce qui touche à mon switch -force dans par (plus que 2 fonctions à écrire cheeky), et je me rends compte que le programme doit dupliquer le travail pour effacer à coup sûr.
Si tu acceptes cette proposition mais que ça te fait suer de l'implémenter, je veux bien écrire le patch.

Merci d'avance. smile

(ps -> en plus ce qui facilite la tâche, c'est que EM_abandon renvoie FALSE en cas d'échec, alors que sous AMS c'est un void, donc c'est du tout cuit cheeky)
(ps2 -> quand je parle de SymDel, je parle en fait de SymDel_SymEntry_reg)


Mais EM_delSym fonctionne avec les fichiers RAM & FLASH sous PedroM.
Ok pour le code retour, je m'en occupe.