Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Autres questions


Index du Forum » Autres questions » Assembleur utilisé par la Graph 90+E
Potter360 En ligne Rédacteur Points: 1127 Défis: 0 Message

Assembleur utilisé par la Graph 90+E

Posté le 15/03/2022 20:03

Bonjour !
Pour un nouveau projet, j’aurais besoin de quelques infos :
-Quel est le language assembleur du SH4AL-DSP, le processeur de la Graph 90+E ?
-Peut on exécuter du code hexadécimal de cet assembleur directement sous Gint ?
Vu que Gint est (presque) un OS à part entière si j’ai bien compris ça doit être possible (?)
Je dis peut être n’importe quoi, dans ce cas là corrigez moi xD
Merci !


Lephenixnoir En ligne Administrateur Points: 22772 Défis: 149 Message

Citer : Posté le 15/03/2022 20:06 | #


C'est du SuperH. Tutoriel d'initiation ici : https://www.planet-casio.com/Fr/forums/topic12345-1-tutoriel-initiation-a-lassembleur-superh.html

Et des infos un peu plus à jour côté gint par ici : https://www.planet-casio.com/Fr/forums/topic16807-2-casm-optimiser-au-cycle-pres-la-reference.html#184936

Exécuter de l'assembleur c'est facile il suffit d'y sauter en C. Le plus dur c'est de l'assembler, parce que même si les instructions elles-mêmes ont une traduction directe en hexa, dès que tu as des labels, des références à d'autres variables ou fonctions du code, etc. il faut linker et ça c'est plus difficile.
Potter360 En ligne Rédacteur Points: 1127 Défis: 0 Message

Citer : Posté le 15/03/2022 20:48 | #


Coucou !
Merci pour tes liens, je vais regarder ça attentivement.
Pour la dernière partie on s’est mal compris :
En gros je voudrais que l’utilisateur puisse rentrer du code assembleur, que ce dernier soit assemblé et ensuite exécuté, donc il n’est pas directement dans le code du programme…
Globalement, coder. Mal, mais coder.
Lephenixnoir En ligne Administrateur Points: 22772 Défis: 149 Message

Citer : Posté le 15/03/2022 20:50 | #


En gros je voudrais que l’utilisateur puisse rentrer du code assembleur, que ce dernier soit assemblé et ensuite exécuté, donc il n’est pas directement dans le code du programme…

Oui, c'est bien ça qui est difficile : linker le code assembleur entré par l'utilisateur
Potter360 En ligne Rédacteur Points: 1127 Défis: 0 Message

Citer : Posté le 15/03/2022 21:25 | #


Heu, le linkage c'est pas l'opération qui permet de rassembler tous les fichiers différents et les labels ?
Pour moi le problème ce serait plus à l’exécution : on ne peut pas faire un saut en C vers le code puisqu'il n'existe pas à la compilation de l'add-in (le code est créé dans l'add-in)...
Globalement, coder. Mal, mais coder.
Lephenixnoir En ligne Administrateur Points: 22772 Défis: 149 Message

Citer : Posté le 15/03/2022 21:39 | #


Heu, le linkage c'est pas l'opération qui permet de rassembler tous les fichiers différents et les labels ?

Oui, si tu regardes le processus de développement sur le PC, l'édition des liens c'est l'étape qui consiste à rassembler tous les fichiers et à résoudre les références.

Si ton code assembleur ne fait absolument rien à part du calcul et n'appelle aucune fonction externe, tu n'as pas de liens à éditer. Mais si ton code assembleur doit interagir avec n'importe quoi d'autre dans le programme, genre appeler dpixel() ou cos() ou aller lire la valeur d'une variable globale, tu vas te retrouver assez vite coincé parce que tu ne pourras pas éditer les liens. (Il faudrait insérer l'adresse de la fonction ou variable concernée, mais le problème c'est qu'une fois à l'exécution les noms des variables/fonctions sont perdus !) Tu seras obligé de «tricher» de différentes façons.

Il y a un processus similaire à faire dans tous les cas, qui est la résolution des labels dans ton code assembleur. Personne n'a envie d'écrire ça :

_my_function:
        mov.l   @(4,pc),r0
        mov.l   @(8,pc), r1
        rts
        add     r1, r0

        .long 0xc0ffee
        .long 0x8c000000

Non seulement parce que c'est moche mais surtout parce qu'il faut recalculer le 4 et le 8 chaque fois qu'on change la distance entre le mov.l et le .long correspondant.

À la place, on veut écrire ça :

_my_function:
        mov.l   .x,r0
        mov.l   .y, r1
        rts
        add     r1, r0

.x:     .long 0xc0ffee
.y:     .long 0x8c000000

Et donc ton assembleur il doit résoudre les labels pour générer l'hexadécimal correspondant à @(4,pc) et @(8,pc), ce qui est la version facile (quoique pas gratuite non plus) de l'édition des liens. J'ai un peu mis les deux dans le même panier dans ma réponse précédente.

Quant à ce qui est de sauter vers le code, tu n'as pas besoin qu'il soit dans l'add-in. Il suffit de le charger dans la RAM (s'il est position-independent, c'est encore tout un truc).

uint8_t asm_buffer[256];

void assemble_code(...)
{
    // On prétend que tu assembles du code, là je copie juste la fonction ci-dessus
    uint32_t my_hardcoded_function[] = {
        0xd001d102, 0x000b301c, 0x00c0ffee, 0x8c000000,
    };
    memcpy(asm_buffer, my_hardcoded_function, 16);
}

void call_code(...)
{
    int (*code)(void) = (void *)&asm_buffer;
    // Et pouf, la RAM est exécutable
    (*code)();
}
Potter360 En ligne Rédacteur Points: 1127 Défis: 0 Message

Citer : Posté le 16/03/2022 12:51 | #


Ah, c’est plus clair comme ça, merci !
Du coup si je comprends bien @(4,pc) correspond à l’adresse 0xc0ffee ?

Je crois que j’ai quelques idées pour le linkage, en tout cas j’imaginais pas que le saut vers le code serait aussi simple, merci !
Globalement, coder. Mal, mais coder.
Lephenixnoir En ligne Administrateur Points: 22772 Défis: 149 Message

Citer : Posté le 16/03/2022 13:22 | #


Pour être exact @(4,pc) représente la position 4 octets après la position actuelle (plus des broutilles d'alignement/etc), ce qui est donc l'adresse de la valeur 0xc0ffee.
Potter360 En ligne Rédacteur Points: 1127 Défis: 0 Message

Citer : Posté le 16/03/2022 13:31 | #


Ah d’accord !
Mais pourquoi mettre @(8,pc) alors que le .long 0x8c[…] est à 5 octets de la position actuelle ?

Je sais qu’un long fait 4 octets, mais en memoire non, pas dans le code ?
Globalement, coder. Mal, mais coder.
Lephenixnoir En ligne Administrateur Points: 22772 Défis: 149 Message

Citer : Posté le 16/03/2022 13:43 | #


Chaque instruction fait 2 octets, chaque long fait 4 octets. La "taille d'un long dans le code" n'a pas de sens/d'intérêt, lorsque tu exécutes le programme le code source n'existe plus depuis très longtemps.

La distance entre le mov.l @(8,pc), r1 et le .long 0x8c000000 est donc de 10 octets, sauf que c'est pas si simple. Tu ne peux faire un accès mémoire de 4 octets que sur une adresse alignée à 4 octets (= multiple de 4), alors qu'une instruction peut être alignée à 2 octets. La formule exacte pour le calcul de la destination c'est donc (adresse_du_move & ~3) + 4 + valeur_deplacement, ce qui revient bien à PC+disp.

Ici le mov.l @(8,pc), r1 est à l'adresse 2, le déplacement est 8, ça donne bien l'offset 12.
Potter360 En ligne Rédacteur Points: 1127 Défis: 0 Message

Citer : Posté le 16/03/2022 17:11 | #


Ah,ok merci !
Globalement, coder. Mal, mais coder.

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2022 | Il y a 127 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd