probleme de desassemblage - Page 1

Quand je desassemble j' obtient souvant cette ligne :
link a6,#$FF98

As. refuse de le compiler car ca dépasse 16bit

Que faire ?

a calto, tu tapes -0hFF98>hexTu prends tiens 0hFFFF0068 et tu obt Tu gardes les 4 premiers chiffres, et AS acceptera

C'est TIGCC qui est responsable de ces links à opérande négative. Il pourrait donner la taille des cadres de pile en positif, mais ça revient au même.
AS n'aime pas que ça soit négatif, alors tu es obligé de changer le signe.

Merci.
Il y a quand meme un autre probleme : a la fin du fichier il y a "unlk a6" et arrivé a cette commande, ca plante.

C'est parce que ce que t'a dit Thibaut est complètement faux! La deuxième opérande de link doit toujours être négative. C'est -0x68 qu'il faut mettre.

Thibaut, lis le 68kguide au lieu de dire n'importe quoi.

Je n'ai toujours pas compris l'intéret profond de cette commande d'ailleurs ...

Même si on peut s'en passer, elle est utile. Par exemple, pour "allouer" de la mémoire afin de sauvegarder l'écran: link %a6,#-3840 et tu obtiens dans a7 un pointeur vers 3840 octets. Et en plus de ça, en l'utilisant, tu est sûr que a7 sera correctement restauré.

Dans a6 le pointeur plutôt nan? Je connais l'effet, mais il y a toujours moyen de passer outre, et de plus je n'aime vraiment pas passer des variables dans la pile...Surtout un plan entier (quoique, genlib::PUSH_DSCREEN c'est quand même pas mal )... Un bon vieux bss et c'est réglé (bon ceci dit chacun ses préférences hein...)

Pour créer des variables locales, c'est pas très pratique le BSS

mhackgyver:
Mmm...

Il se trouve qu'il n'y a pas 2000 programmes qui possèdent un link a6,#$FF98 dans leur code, or malheureusement Xpand possède exactement la même, en début de code.

Tu sais que tu fais partie de la petite dizaine de personnes possèdant Xpand, lancer un coup de désassembleur dessus je le prends très mal. Et demander de l'aide pour le désassemblage c'est un petit peu gros.
Si Xpand est un projet closed-source, ce n'est pas dû à un oubli dans le zip.
Si je retrouve une ligne de code de Xpand repris dans un autre programme qu'un des miens, je le prendrais encore beaucoup plus mal.

Voilà pourquoi il n'y a pas de déprotection/écriture lourde dans mes programmes. Et sache que le code d'Xpand ne permet de rien faire d'autre que ce qu'il doit faire.

Si je me trompe, toutes mes excuses, mais là ça coincïde un peu trop.

Tiens, en voilà un autre:

void _main(void)
{
char a[0x68];
}

N'importe quel programme qui alloue 0x68 octets de variables locales dans une fonction et qui n'est pas compilé en -fomit-frame-pointer contient ce code. Ce n'est pas une preuve.

ExtendeD :
mhackgyver:
Mmm...

Il se trouve qu'il n'y a pas 2000 programmes qui possèdent un link a6,#$FF98 dans leur code, or malheureusement Xpand possède exactement la même, en début de code.

Tu sais que tu fais partie de la petite dizaine de personnes possèdant Xpand, lancer un coup de désassembleur dessus je le prends très mal. Et demander de l'aide pour le désassemblage c'est un petit peu gros.
Si Xpand est un projet closed-source, ce n'est pas dû à un oubli dans le zip.
Si je retrouve une ligne de code de Xpand repris dans un autre programme qu'un des miens, je le prendrais encore beaucoup plus mal.

Voilà pourquoi il n'y a pas de déprotection/écriture lourde dans mes programmes. Et sache que le code d'Xpand ne permet de rien faire d'autre que ce qu'il doit faire.
Si je me trompe, toutes mes excuses, mais là ça coincïde un peu trop.

TU TE TROMPE ! : j' ai desassembler REMOTE, pour pouvoir creer des macros toutes faite qui permettraient de simplifier des manipulationS sur les calcs d' amis.
Je ne voyais pas du tout comment cela marchait alors je l' ai desassembler.
JE N' AI EN AUCUN CAS DESASSEMBLE XPAND.

Remote Control de Greg Dietsche?
1. Tu peux demander les sources C de Remote à Greg, je pense qu'il te les enverra.
2. Je ne vois pas une seule instruction link dans Remote 1.1 (la version actuelle).

ExtendeD :
Pour créer des variables locales, c'est pas très pratique le BSS

Des variables locales? Une abstraction du compilateur C ça, en assembleur on s'en passe très bien je trouve

Quand tu as fini tes registres, il te faudra bien "spiller" tes résultats intermédiaires quelque part, même en assembleur. Donc tu utilises la pile (ou alors tu utilises des variables globales, mais c'est: 1. sale, 2. gros, 3. lent et 4. non-réentrant (donc catastrophique en cas d'appels récursifs); j'ai vu beaucoup trop de programmeurs assembleur abuser de manière évidente des variables globales ). Et dans certains cas, link peut être pratique pour ça.

si j'ai vraiment besoin de stocke un résultat c'est qu'il est global, et je ne suis pas sûr de tes arguments 3 et 3. Va pour le 4, mais c'est quand même un cas exotique

move.l d7,globalspillvar -> 6 octets + relogement, 20 cycles
move.l d7,localspilloffset(a7) -> 4 octets, 16 cycles

non car j'accède aux données de mon bss ainsi:

...
lea bss_base(),a6
...
move.l d7,offset_(a7)

Finalement je fais la même chose sans utiliser de pile locale, ça évite tous les link/unlink et est donc plus rapide.
Et le lea est plus rapide et moins gros que link+unlink (et je m'arrange pour ne pas toucher à a6 pendant le problème pour ne pas avoir à le refaire)

Tu gaspilles un registre. link aussi, mais link te donne l'avantage de ne pas avoir à restaurer le pointeur de la pile, que tu utilises forcément à un moment où un autre (tous les ROM_CALLs utilisent le passage d'arguments par la pile). Et tu n'es pas obligé d'utiliser link pour tes variables locales (cf. -fomit-frame-pointer), donc l'utilisation de la pile te permet de gagner un registre par rapport à ton abus des BSS.

"ton abus de BSS" lol
Mais c'est plus petit et plus rapide. Et je me débrouille très bien avec un registre en moins. Et si j'ai envie de faire ainsi, et bien je fais ainsi

Au fait, un bel exemple d'usage intensif de la pile est UnInEvHk 3.00.
Si tu arrives à comprendre le fonctionnement de DeleteEventHook et le chemin d'exécution suivi, c'est que tu es fort en assembleur.

Kevin Kofler :
Remote Control de Greg Dietsche?
1. Tu peux demander les sources C de Remote à Greg, je pense qu'il te les enverra.
2. Je ne vois pas une seule instruction link dans Remote 1.1 (la version actuelle).

Faux, la version actuelle est 1.2.

Sur le site de Greg, la version actuelle est 1.1, et idem sur ticalc.org, donc je ne sais pas d'où tu sors ta 1.2. Et je ne pense pas qu'il soit passé de -fomit-frame-pointer à -fno-omit-frame-pointer (ça serait une désoptimisation). Donc désolé, je n'achète pas.

Je t' envoye le fichier, ainsi que sa source et tu verra.

VOICI LE README.TXT :


Title: Remote Control
Version: 1.2
Platform(s): TI-89, TI-92+
Author: Greg Dietsche
Web Site: http://gforce.calc.org
E-Mail: gforce@calc.org
Release Date: 8/24/2002
Size: 461 bytes

*****************
*** Summary ***
*****************
This small program written in C that can take over another calc
(Read: send key presses) without a need for special software on the
other calc. I use it to control vti with my real 89 when making
screen shots...

********************
*** How to Use ***
********************
1. Send remote to your calc.
2. Hook another calc up to your calc with a link cable.
3. run remote on your calc.
4. type stuff and watch it appear on the other calc
5. when you have had your fun, push the ON key to exit.

**************
*** BUGS ***
**************
There is no error checking so you can link to an 89 or 92+,
but be forewarned that funny things can happen because the key
codes on the 92+ are not always the same as on the 89! I recommend linking
a TI-89 to a TI-89 or a TI-92+ to a TI-92+ to avoid those problems.

Sometimes, it will hang when sending alot of keypresses at once such as pressing an
arrow key. If that happens, wait a second or so, and then continue typing.

If you find a bug, please email it to me. Be sure to include instructions
for me so that I can reproduce the bug.

*************************
*** FUTURE FEATURES ***
*************************
NO. :/

********************
*** Contact Me ***
********************
gforce@calc.org
If you have any suggestions or bug reports please email me (I don't bite)
if you do not understand this (documentation) please ask me I will try to
help you out as best as I can. You may also want to visit my webpage at
http://gforce.calc.org first though; I may have posted something
there that could help you!

*************************
*** Program History ***
*************************
Version 1.2
Recomplied to support the V200, as well as the TI-89 and TI-92 Plus
Size: 461 bytes
Released: 08/24/02

Version 1.1
Fixes a bug where the transmission would hang permanently after about
30 key presses. Added an echo so the user can tell what
was typed on the other calc.
Released: 04/17/01
Size: 453 bytes

Version 1.0
Initial Release
Released: 04/17/01
initial release
size: 377 bytes


*****************************************************************************
*** My thanks to the TIGCC team, and the Assembly-89 mailing list. ***
*****************************************************************************

Bon, j'ai regardé ton fichier, et tu es crédible après tout.
Je me demande juste d'où tu as eu ce fichier, vu qu'il n'est même pas sur son site. (Es-tu bêta-testeur de Greg?)

SUR TICALC.ORG : http://www.ticalc.org/archives/files/fileinfo/250/25063.html

Kevin Kofler :
C'est parce que ce que t'a dit Thibaut est complètement faux ! Thibaut, lis le 68kguide au lieu de dire n'importe quoi.

Quelle agressivité... haaaa tu jouis ! tu domines tu aimes ça, hein !

mhackgyver :
SUR TICALC.ORG : http://www.ticalc.org/archives/files/fileinfo/250/25063.html

Arf! Il a mis la nouvelle version sur ticalc.org avec un nom différent, et il n'a pas mis à jour son propre site! Bon, tout s'explique alors.

En tout cas, désolé de ne pas t'avoir cru tout de suite.

Alors Kevin, renseigne-toi avant de raconter n'importe quoi !!!