codage des instructions - Page 1

Bonjour, voila j'aimerais savoir différentes choses :
- est ce que quelqu’un connaît un tuto ou une "table" où sont répertoriées toutes les instructions C et leur équivalent en assembleur ?
- et aussi est ce que qqun connaît une table ou tuto où d'un côté on a les instructions assembleur et de l'autre leur équivalent en binaire compilé?
- sinon, j'ai "cru" comprendre que ça marchait comme ça les instructions compilé, les 4 premiers bites de l'octet correspondent a la "commande" et les 4 derniers correspondent à ce sur lequel agit la "commande" précédente .j'ai cru le lire qqpart mais je ne parvient pas a retrouver où... est ce que c'est ça?
- et encore un tout dernier truc, comment on fait pour savoir exactement a partir de quand commence un programme (ici en C ou asm) enfin plus exactement à partir de quand commence son "code" machine, je sais que les 2 premiers bytes ou octets correspondent à la taille mais après des fois y'a des octets vides et des fois y'en a pas
- et puis aussi par la même occasion quand il se finit ou plutôt quel est le code de la commande "ret" en binaire compilé
merci à ceux qui me repondront !!

oups je parlais de la commande assembly "rts" pas ret ... dsl

4e75 non ?

http://www.ticalc.org/pub/text/68k/68000ref.zip

bidoo :
Bonjour, voila j'aimerais savoir différentes choses : - est ce que quelqu’un connaît un tuto ou une "table" où sont répertoriées toutes les instructions C et leur équivalent en assembleur ?

Tout l'intérêt de faire un langage, c'est que les conversions dans un sens et dans l'autres ne sont pas de bêtes traductions ^^ Et dans quel sens ? ASM -> C ou C -> ASM (parce que le fait que tu postes ça dans prog C TI suggérerait que c pour apprendre le C et donc ASM -> C, mais je ne pense pas que ça soit ça que tu veux)

- et aussi est ce que qqun connaît une table ou tuto où d'un côté on a les instructions assembleur et de l'autre leur équivalent en binaire compilé?

demande à google 68kPM.pdf (ou 68kUM.pdf, je sais plus).

- sinon, j'ai "cru" comprendre que ça marchait comme ça les instructions compilé, les 4 premiers bites de l'octet correspondent a la "commande" et les 4 derniers correspondent à ce sur lequel agit la "commande" précédente .j'ai cru le lire qqpart mais je ne parvient pas a retrouver où... est ce que c'est ça?

Pour la plupart des instructions, tu as un truc de la forme
llllyyyx ssmmmmmm
avec l=classement des opcodes sur 4 bits, donc entre 0 et 15 (1, 2, 3 -> move; 6 -> sauts; 4 -> trucs divers)
m="effective address", les 3 bits de poids forts indiquent le mode et ceux de poids faible le n° de registre
s=taille de l'instruction (byte/word/long/mode spécial)
x=flag spécial (par exemple additionner vs soustraire...)
y=n° de registre (add.w <ea>,dY) ou valeur sur 3 bits (addq.w #7,d0)

Bien sûr, ça varie selon les instructions (pour move, yyyxss est en fait une autre "effective address", avec les champs inversés pour que yyy soit aussi le numéro de registre -- donc en fait ce serait plutôt xssyyy...)

- et encore un tout dernier truc, comment on fait pour savoir exactement a partie de quand commence un programme (ici en C ou asm) enfin plus exactement à partir de quand commence son "code" machine, je sais que les 2 premiers bytes ou octets correspondent à la taille mais après des fois y'a des octets vides et des fois y'en a pas

char bidon[6]="coucou";
(attention à bien prendre une taille paire !)

Mais pour un programme C, tu n'as aucune garantie qu'une fonction "tiendra" dans un endroit bien précis : le compilo peut mettre ton code n'importe où, donc ça risque de foirer dès que tu mets à jour le compilo -> à prendre avec des pincettes...

- et puis aussi par la même occasion quand il se finit ou plutôt quel est le code de la commande "ret" en binaire compilé

0x4e75, mais encore une fois tu n'as aucune garantie si c'est du C que "rts" sera bien la dernière instruction de ton programme

(pour move, yyyxss est en fait une autre "effective address", avec les champs inversés pour que yyy soit aussi le numéro de registre -- donc en fait ce serait plutôt xssyyy...)

Y'a des fois où je me dis que pour comprendre ça on doit vraiment pas être normaux. Et puis je me rappelle que au moins c'est pas moi qui l'ai écrit, donc y'a pire que moi
Hum, désolé pour cette interruption.

Et euh oui, comme le dit Pollux, en C tu ne devrais que rarement avoir besoin de l'adresse d'une fonction.

Pollux> Je comprends pas l'intérêt du tableau ?

L'idée d'une table C<->ASM n'a pas vraiment de sens... Parce qu'une même instruction peut donner différentes versions compilées selon le code qui est autour de l'instruction en question.

Sinon, cest bien le 68KPM.pdf qui regroupe toutes les instructions du 68k (et autres µP de la famille) et leurs opcodes.

spectras
:

(pour move, yyyxss est en fait une autre "effective address", avec les champs inversés pour que yyy soit aussi le numéro de registre -- donc en fait ce serait plutôt xssyyy...)

Y'a des fois où je me dis que pour comprendre ça on doit vraiment pas être normaux. Et puis je me rappelle que au moins c'est pas moi qui l'ai écrit, donc y'a pire que moi Hum, désolé pour cette interruption.

Mais euh, j'avais plein de trucs à dire à l'arrache, donc j'ai fait vite

Si tu veux je peux détailler plus : pour move, comme on n'a plus que 12 bits de libres en dehors des 4 premiers bits, et qu'on veut deux effective address pour la source et la destination (donc 2x6 = 12 bits), on est obligé de stocker ça différement, donc on utilise le champ "effective address" qui est déjà utilisé pour les instructions normales, et pour la deuxième effective address, on est obligé d'utiliser les 6 bits restants... Sauf que pour faciliter la réalisation physique, plutôt que de mettre le mode de l'effective address (les 3 bits qui disent si c'est de la forme Dn, An, (An), (An)+, etc...) dans "yyy", on va plutôt mettre le n° de registre dans "yyy" (bah oui, c'est ce qui sert pour indiquer le n° de registre dans add.w #42,d5, donc il y a déjà le câblage pour accéder au registre correspondant) et on va mettre le mode dans les 3 bits restants, à savoir "xss". Et donc on se retrouve avec une effective address de la même forme que le champ "mmmmmm", mais en échangeant les 3 bits de poids fort et les 3 bits de poids faible...

Ca devrait être compréhensible, mais c'est 5x plus long (et tu imagines ./4 en 5x plus long ? )

Et euh oui, comme le dit Pollux, en C tu ne devrais que rarement avoir besoin de l'adresse d'une fonction.

Ce qu'il veut, ce n'est pas l'adresse d'une fonction, c'est l'adresse du "début" d'une fonction (et probablement aussi l'adresse de fin). Malheureusement, ce n'est pas possible sans faire des trucs très gores...

Pollux> Je comprends pas l'intérêt du tableau ?

Tu parles de « char coucou[6]="coucou"; » ? Bah ça sert à déterminer où commence la fonction... (il suffit de rechercher "coucou" dans le binaire) A mettre bien sûr en déclaration globale avant la fonction.

Tout l'intérêt de faire un langage, c'est que les conversions dans un sens et dans l'autres ne sont pas de bêtes traductions ^^ Et dans quel sens ? ASM -> C ou C -> ASM (parce que le fait que tu postes ça dans prog C TI suggérerait que c pour apprendre le C et donc ASM -> C, mais je ne pense pas que ça soit ça que tu veux)

oui tu as raison , dsl j'ai pas été tres claire , je ne sais faire que du C rudimentaire et illisible et je chercher la conversion en asm

L'idée d'une table C<->ASM n'a pas vraiment de sens... Parce qu'une même instruction peut donner différentes versions compilées selon le code qui est autour de l'instruction en question.

tu parle de truc du genre if(condition ) et des for() , t sur que y'a pas un moyen de les distinguer correctement

Sinon, cest bien le 68KPM.pdf qui regroupe toutes les instructions du 68k (et autres µP de la famille) et leurs opcodes.

arf c pas vrai c'est le seul que j'arrive pas à telecharger,

en fait , je cherche à modifier mon programme à partir de mon programme (c un peu idiot mais j'en ai besoin )
et pour ca je pensais modifier directement le code binaire d'1 instruction en en faisant ceci :
1) j'enrengistre mon programme stockée en memoire tel quel dans une variable temporaire, handle ou tableau de byte
2) puis ensuite je cherche ce que je veux modifier ,je chope son offset à partir du debut du programme (sachant exactement les 4 l les 3 y le x les 2 s et les 6 m) puis je modifie les 2 bytes en les remplacant soit par des 0 (c'a doit pas faire de mal de mettre des 0 non? ) soit par une autre instruction (sachant qu'elle sera autonome et independante du prgm ,enfin, des variables du prgm ,par exemple elle changera une donnée ds un registre (mais j'aimerais bien essayer de changer des if et des for... ))
3)une fois mes modif faites , comme je ne vois absolument pas comment faire pour enregistrer mon prgrm pendant son utilisation (ca parait un peu riské non? ) j'enrengistre mon programme sous un autre nom ds un dossier connue, en changant juste la derniere lettre par un chiffre connue
4)puis en basic je sauvegarde ce prgm changé avec le nom de l'ancien prgm

j'aimerais savoir si ce que j'ai commencé à faire vous parait correct si au moins c possible de changer le code d'un prgm sans tro de risque ...

Mais euh, j'avais plein de trucs à dire à l'arrache, donc j'ai fait vite

C'était pas une critique, c'était juste une remarque. J'aime assez imaginer la tête du gars qui tomberait sur cette page par hasard et lirait le contenu des messages.
Un peu comme les private-jokes quand tu les sorts en public et que vous êtes 3 à rigoler tous seuls.

Ce qu'il veut, ce n'est pas l'adresse d'une fonction, c'est l'adresse du "début" d'une fonction (et probablement aussi l'adresse de fin)

Oui, mais ke vois toujours pas ce qu'il peut vouloir en faire

Tu parles de « char coucou[6]="coucou"; » ? Bah ça sert à déterminer où commence la fonction... (il suffit de rechercher "coucou" dans le binaire) A mettre bien sûr en déclaration globale avant la fonction.

Ah ok. Effectivement c'est très aléatoire. Surtout que si t'y fait aucune référence le compilateur ou le linker serait susceptible de dégager complètement la chaîne.
Ok, c'est improbable parce que le compilateur ne peut pas retirer un symbole non statique, et le linker ne connait pas habituellement la taille des éléments exportés, mais on sait jamais.

bidoo> Surtout que plein de choses du C ne se codent pas en une seule instruction en ASM.
Par exemple, une ligne for(i=0;i<N;i++) prendra plusieurs instructions réparties en plusieurs endroits plus ou moins éloignés selon le contenu de la boucle for...

bidoo
:

L'idée d'une table C<->ASM n'a pas vraiment de sens... Parce qu'une même instruction peut donner différentes versions compilées selon le code qui est autour de l'instruction en question.

tu parle de truc du genre if(condition ) et des for() , t sur que y'a pas un moyen de les distinguer correctement

Une boucle for (comme toutes les autres structures de contrôle du C), c'est jamais qu'un arrangement de if et de goto fait pour alléger la syntaxe.

en fait , je cherche à modifier mon programme à partir de mon programme (c un peu idiot mais j'en ai besoin ) et pour ca je pensais modifier directement le code binaire d'1 instruction

C'est un besoin réel, ou c juste pour voir comment on peut faire joujou avec du code binaire ?

puis je modifie les 2 bytes en les remplacant soit par des 0 (c'a doit pas faire de mal de mettre des 0 non? )

Le seul truc inoffensif c de remplacer par un "nop" (0x4e71), mais attention ça ne marche que si tu le mets à la place d'une instruction et pas au milieu d'une instruction...


Et sinon pkoi tu ne te contentes pas de modifier le code du programme sur PC ?

Pollux> Bof, c'est pas génial pour remplacer des instructions qui prennent plus de 2 octets.

Et euh oui, comme le dit Pollux, en C tu ne devrais que rarement avoir besoin de l'adresse d'une fonction.

heu, les pointeurs de fonction, c vachement pratique !
(en particulier qd tu compresse du code, le décompresse en ram qd tu en a besoin, le reloge, et branche dessus... (sisi, ça marche ; enfin, sur HW3 je sais pas... mais on verra vite ))

plusieurs nop, ça marche très bien... (même si c moins efficace niveau timing qu'un saut si on a 6 octets ou plus à remplir -- mais attention, pour plus de 128 octets de padding, les sauts deviennent bien plus durs à gérer (si on autorise les sauts de l'extérieur vers un bout de code qui se trouve au milieu))

squale92
:

Et euh oui, comme le dit Pollux, en C tu ne devrais que rarement avoir besoin de l'adresse d'une fonction.

heu, les pointeurs de fonction, c vachement pratique !
(en particulier qd tu compresse du code, le décompresse en ram qd tu en a besoin, le reloge, et branche dessus... (sisi, ça marche ; enfin, sur HW3 je sais pas... mais on verra vite ))

On ne parle pas de pointeurs de fonctions (qui, eux, sont effectivement vachement utiles), on parle de l'endroit où "commence" le code d'une fonction...

(par exemple :

begin:
error:
  moveq #-1,d0
  rts

DoStuff:
  subq.w #3,d0
  bmi error
  mulu d0,d0
  rts

begin != DoStuff)

On ne parle pas de pointeurs de fonctions (qui, eux, sont effectivement vachement utiles), on parle de l'endroit où "commence" le code d'une fonction...

heu, ok...
m'enfin, il avait parlé d'adresse de fonction...

où ça ?

et encore un tout dernier truc, comment on fait pour savoir exactement a partir de quand commence un programme (ici en C ou asm) enfin plus exactement à partir de quand commence son "code" machine, je sais que les 2 premiers bytes ou octets correspondent à la taille mais après des fois y'a des octets vides et des fois y'en a pas

cf ce que j'ai cité en ./13

Ah, tu parlais de spectras, pas de bidoo... ./15 s'adresse limite plus à lui qu'à toi, en fait

où ça ?

ba j'ai fait ce petit bout de code pour etudier le debut du code binaire de mes prgm et ds fois je vois des octets vide apres les 2 premiers

void affichbyte(void* ptr,short size,short offset) // pteur je l'obtien avec un heapderef et tou et tou
{ 
 FontSetSys(F_4x6);
 clrscr();
 short i,j;
 if(size>500)size=500;
 clrscr();
 for(i=0;i<size;i++)
 {for(j=0;j<8;j++)printf("%d",peek_bit(ptr+i,j));prinf(":");
 ngetchx();
}

C'est un besoin réel, ou c juste pour voir comment on peut faire joujou avec du code binaire ?

les 2 et meme plus que ca, je dirais que j'ai vraiment envie de savoar comment on peut le faire ca me parait necessaire

À la limite, programme seulement en ASM, si tu veux faire du SMC.

bidoo> il manque une accolade dans ton code... et si tu fais ça pour débugger tu code C, ce sera largement plus simple que tu apprennes l'asm et que tu regardes à quoi ressemble le code généré, et que tu voies comment ça se passe sous VTI...

arf g pas vti

[google]vti[/google]

heu, les pointeurs de fonction, c vachement pratique ! (en particulier qd tu compresse du code, le décompresse en ram qd tu en a besoin, le reloge, et branche dessus... (sisi, ça marche ; enfin, sur HW3 je sais pas... mais on verra vite ))

Tu fais pas ça tous les 4 matins non plus. Et puis, si tu travailles sur une autre architecture, tu peux pas forcément faire ça. Par exemple, sous pas mal de système, le tas n'est pas exécutable.

Jusqu'à présent les seules utilisations des pointeurs sur fonction que j'ai faites sont :
- pour du code qui appelle un callback passé en parametre
- pour optimiser un série de test, en la transofrmant en lookup dans une table d'adresses
- en faisant des choses TRES crades, en appelant du code C dans un gestionnaire d'interruyption avant d'avoir sauvegardé les registres.
Portabilité = 0, mais en même temps, " movem.l %%d0-%%d7/%%a1-%%a7,%%a0@- " c'est déjà moyen pour la portabilité, donc...

si c'est juste pour voir comment on peut faire joujou avec du code binaire, tu peux te mettre à l'assembleur, en plus c'est pratique, ça te permet de te donner une idée de comment est compilé du C
pour faire du self-modifying code, vaut mieux le faire en ASM, et encore si tu peux pas bloquer certaines optimisations de l'assembleur c'est casse-gueule

Et puis, si tu travailles sur une autre architecture, tu peux pas forcément faire ça. Par exemple, sous pas mal de système, le tas n'est pas exécutable

oué
mais bon, je code soit sur TI (où ça marche )
soit sur PC... et sur pc, je m'en fou de la taille de l'exécutable... (surtout que sur TI, l'exécutable est entier en RAM à l'exécution, même si le code des menus ne sert pas pdt le jeu par exemple)

(surtout que sur TI, l'exécutable est entier en RAM à l'exécution, même si le code des menus ne sert pas pdt le jeu par exemple)

D'ailleurs, je me demandais pourquoi je n'ai pas encore entendu parler d'overlays. Ca pourrait être une solution pour les gros programmes non ?

Je comptais faire ça dans GT-Basic (et ça pouvait aussi décompresser des données, etc...)