question - Page 1

avec l'apparence des langages èvoluès(c,c++,java...)la programmation est devenue facile
et bien pourquoi la programmation en assembleur ?

Bon, stop, ça suffit.
Inutile de créer un topic à chaque question que tu veux poser. Essaie de comprendre comment fonctionne le forum pour l'utiliser correctement.
[edit] Et exprime toi mieux, s'il te plaît.

L'assembleur reste indispensable pour effectuer certaines instructions qui ne sont pas "accessibles" dans d'autres langages haut niveau.
Le code assembleur produit par les compilateurs de langages de haut niveau peut très souvent être largement optimisé.

cimment faire en assembleur pour acceder ç des instructions privilégiers e assembleur

Il faut passer en mode superviseur.
Ce mode n'est accessible que par le système d'exploitation.

merieme_info
: avec l'apparence des langages èvoluès(c,c++,java...)la programmation est devenue facile

Non. La complexité a simplement était déportée à un autre niveau.
Et sur TI le choix reste asm ou C.

Pour compléter Sasume, l'assembleur est aussi parfois plus facile à utiliser pour des manipulations "bas-niveau" d'adresses, de mémoire, d'op-codes... (FreeFlash, Ghostbuster et v200exep contiennent de l'asm uniquement pour ça par exemple).

Non, pas vraiment. (sauf si on veut faire du C réellement conforme à la norme C, à ce moment-là l'aliasing interdit certaines choses ; mais si l'alternative serait de coder en asm, on ne prétend pas à la portabilité et donc ça ne pose pas de problème de violer cette partie de la norme)

Par exemple :

#define byte_v(x) (char)(x)
#define byte_a(x) (*(char *)(x))
#define byte_ainc(x) (*((char *)(x)++))
#define byte_adec(x) (*(--(char *)(x)))
#define _byte_v byte_v(
#define _byte_a byte_a(
#define _byte_ainc byte_ainc(
#define _byte_adec byte_adec(
#define get_b(x) (_byte_##x))
#define get_w(x) (_word_##x))
#define move_b(x,y) (_byte_##x) = _byte_##y))
#define move_w(x,y) (_word_##x) = _word_##y))

void *f(void *p,void *q) {
  move_b(ainc p, v    sin(42.3)*rand());
  move_b(ainc p, ainc q               );
  move_w(ainc p, ainc q               );
  move_w(ainc p, a    0x4c00          );
  return p;
}

L'avantage étant que dès qu'on a besoin d'une expression en C, on peut s'en servir ^^ (cf sin(42.3)*rand())

C'est surtout que la TI a un proc qui a 20ans, donc bon

Bah il est très bien le 68000.
Le seul reproche que je lui trouve pour ma part c'est que move sr,<ea> ne soit pas privilégiée, ce qui empèche la virtualisation du système (pour faire un débugger, une sandbox et autres trucs du même acabit). Je mets l'impossibilité de reprendre l'exécution après une interruption du groupe 0 dans le même sac.

Accessoirement, pour faire un débuggeur/sandbox, ça *pourrait* être utile d'avoir une MMU, nan ?

C'est pas indispensable, même si évidemment ça serait utile pour isoler ^^
Mais ne pas l'avoir ne provoque pas de fuite dans le comportement du processeur virtualisé.
Alors que l'exécution d'un move sr,<ea> si.

Est-ce que tu peux donner plus de détails, je ne vois pas vraiment de quoi tu parles ?

Supposons que tu veuilles écrire un débugger. Pour ça, tu vas vouloir garder la main sur un certain nombre de choses, pour pouvoir récupérer en cas de bug.
Notamment, tu ne veux surtout pas laisser le programme debuggé jouer avec le mode superviseur, sinon il peut rendre la gestion des exceptions instable (s'il déplace le SSP, etc). Donc tu le fais tourner en mode utilisateur, tout le temps.

=> y compris son code privilégié.

Et pour ça la méthode est assez simple sur le principe : tu empèches le programme de redéfinir les handlers d'interruption, (mais tu enregistres quand il en définit). Lorsqu'une interuption survient, le débuggeur est appelé. Il marque un flag dans son état interne pour dire "émulation de mode superviseur : activé".

Par la suite, lorsque le programme débuggé génère une privilege violation, le débuggeur voit qu'il est en mode superviseur émulé, donc il émule l'instruction privilégiée et rend la main silencieusement.

Tout ceci marche très bien, et est complètement transparent pour le programme débuggé (sauf que c'est plus lent). Là où le problème survient, c'est pour une instruction spécifique, et une seule.

move sr,<ea>

Cette instruction flanque tout le bel édifice parterre, parce qu'elle n'est pas privilégiée. Du coup le débuggeur ne peut pas l'émuler, et, si le programme débuggé l'appelle alors qu'il est en mode superviseur, le résultat sera incohérent puisque le véritable sr sera retourné, et non celui émulé par le débugger.

Code          Etat réel              Etat émulé

              sr=0000                sr=0000
trap #12      trap debugger          trap tios

              sr=0000                sr=2000
rte           privilege violation    pas de probleme (le debuggeur émule le rte, en travaillant sur le SR virtuel)

              sr=0000                sr=2000  (puisque trap#12)

move sr,d0    pas de probleme        pas de probleme
              => d0 devient 0000     => émulation impossible donc d0=0000 alors qu'il devrait valoir 2000

              sr=0000                sr=2000
move d0,sr    privilege violation    pas de probleme, mais le d0 erronné fait que le débuggeur met le SR virtuel à 0

              sr=0000                sr=0000
move usp,a0   privilege violation    privilege violation (puisque le sr virtuel est à 0)

=> colonne de gauche, ce qu'il se passe réellement sur le processeur
=> colonne de droite, ce que voit le programme débuggé à travers la virtualisation réalisée par le debuggeur.

Dit autrement, move sr,ea est une instruction (la seule) qui donne accès à l'environnement superviseur même quand tu n'es pas en mode superviseur.

Et le problème ne reste malheureusement pas caché, parce que les gestionnaires d'exception de TIOS utilisent cette instruction.

OK, je vois

Spectras: sachant ça, il est vraimetn aps possible de trouver un moyen d'éviter ce genre d'erreurs ?

Si. Ca s'appelle recompilation dynamique, et c'est très chiant à implémenter, pas parfait, et pas transparent pour l'application.
Ca consiste à scanner dynamiquement le programme que tu exécutes à la recherche des instructions dangereuses.

Dans mon exemple un peu plus haut, il s'agit de détecter le move sr,<bidule>, le dégager et le remplacer par exemple par un illegal (en se laissant une note dans un coin pour émuler correctement).

Mais c'est pas le seul problème : il faut aussi être en mesure d'empècher et rediriger les écritures vers les vecteurs d'exception. Et pour détecter ça, là ça devient compliqué.

Dans le cas particulier des TI, tu me diras on a l'autoint7 avec un support matériel pour faire ça. Mais en fait ça ne fait que déplacer le problème : au lieu d'empècher et rediriger les écritures vers les vecteurs, il faut empècher et rediriger les écritures vers les ports io mappés.