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.
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)
)
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.
:>as () File not found: () :>as() File not found: ) 4.0000000000000000 :>as :>as() 000000
:>as () File not found: ()
:>as() File not found: ) 4.0000000000000000
:>as :>as() 000000
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 ?
PpHd (./51) :
Oui, on pourrait.
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
Folco (./50) :
la stabilité sous PedroM étant totalement dévolue aux kernel
strcmp: move.l 4(a7),a0 move.l 8(a7),a1
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
), et je me rends compte que le programme doit dupliquer le travail pour effacer à coup sûr.
)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), 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.
(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
(ps2 -> quand je parle de SymDel, je parle en fait de SymDel_SymEntry_reg)