Fonction dans une lib statique - Page 1

Si u as besoin de place plus que de vitesse crée une sous fonction contenant ce code... et appelée par chacune des autres fonctions.

Si tu fais une fonction non inline, non. Si tu fais une macro ou une fonction inline, oui.
Après c'est pas forcément moins gros de faire ça, ça dépend essentiellement de la quantité de code dans ta partie commune.

Euh on est en assembleur là désolé.
La sous-fonction ne sera jamais recopiée à l'intérieur du code (rappelle-toi qu'en assembleur le code généré est (à quelques éventuelles optimisations près) exactement celui de ta source).

Martial Demolins
: j'y ai pensé, mais à chaque appel à une fonction, le code de la sous-fonction sera recopié non?

Non, si tu mets la sous-fonction dans un fichier source à part, elle sera copiée dans l'exécutable linké seulement une fois.

Faut voir, comme dit Ximoon, si le code d'empilage des paramètres + appel ne prend pas plus de place que le code de la fonction.

Quel empilage des paramètres? La fonction appelante et la sous-fonctions sont tous les deux en l'assembleur, donc on n'a pas besoin de respecter une convention d'appel. On fait un jsr (qui sera optimisé en un bsr par le linker quand c'est possible) et on n'a pas du tout besoin de changer le code qu'on met dans la sous-fonction (à part pour ajouter 4 aux offsets sur la pile).

Oui.

"Propre", pas vraiment, mais ça marche avec tous les AMS connus, et je pense que AMS 3 n'y change rien.

ça revient strictement au même, et ça utilise probablement autant de registres
EDIT: post croisé

Et les raisons pour lesquelles ce n'est pas propre:
1. Tu utilises un trap non-documenté à la place d'un ROM_CALL exporté.
2. Il n'y a aucune documentation officielle qui te dit que le trap #1 ne détruit pas de registres autres que %d0. Un trap peut détruire ce qu'il veut, même des registres qui ne sont normalement pas call-clobbered. Tout dépend du trap en question.

GoldenCrystal
: ça revient strictement au même, et ça utilise probablement autant de registres

En effet, OSSetSR ne fait qu'appeler le trap #1 en copiant le paramètre de la pile vers %d0.

Martial Demolins> L'instruction TRAP n'est pas une instruction dont la fonction change avec le numéro... C'est juste une instruction qui éxécute la fonction dont l'adresse est stockée dans la table des vecteurs à l'emplacement TRAP #N prévu, en mode superviseur.

Martial Demolins
: le trap #1 bouffe des registres?

Non (à part %d0).
Mais ça pourrait théoriquement changer.

./19 >
1. Ta syntaxe est incorrecte, il faut écrire lea.l 10(%a7),%a7

2. include "os.h" ?


Sinon, je ne comprends pas comment on peut changer les interruptions en appelant trap #1
Je croyais qu'on pouvait simplement les inhiber.

Sasume :
Sinon, je ne comprends pas comment on peut changer les interruptions en appelant trap #1 Je croyais qu'on pouvait simplement les inhiber.

C'est ce qu'il doit vouloir dire par "changer".

Sasume>Il utilise probablement A68k et -y'a pas besoin de .l à lea, il me semble

Sinon, je ne comprends pas comment on peut changer les interruptions en appelant trap #1 Je croyais qu'on pouvait simplement les inhiber.

Changer les interruptions ~ Changer le masque d'interruption

Martial Demolins
:

1. Ta syntaxe est incorrecte, il faut écrire lea.l 10(%a7),%a7

c'est donc du gnu asm avec as? pourtant il compile correctement quand je fait des move.w #3,D0

Je crois qu'il ne parle pas du même AS que toi. Tu veux dire l'AS on-calc?

EDIT: ./26 -> Et voilà.

ok, au temps pour moi

GoldenCrystal> Non, ce n'est pas indispensable que préciser .l avec lea, mais je trouve que c'est mieux de le faire.

Martial Demolins> Tu n'as pas de fichier os.h sur ta TI, mais normalement, il y a un fichier "ams" livré avec AS, qui contient ce dont tu auras besoin pour utiliser les ROM_CALLs