Puisque personne n'est manifestement content avec toutes les interfaces proposées jusqu'à présent, je pense qu'on doit continuer l'exploration des solutions possibles, à la fois dans leur design et dans leur implémentation
PpHd, tu veux aussi gérer les ROM_CALLs qui sont des variables (genre FiftyMsecTick)?
Si PedroM a des ROM_CALLs données en Flash (par exemple, sur AMS, il y a FLOATTAB), il faut pouvoir distinguer entre ROM_CALLs données en RAM, ROM_CALLs code en Flash et ROM_CALLs données en Flash.
Distinguer entre RAM et Flash est facile (comparaison d'adresse), mais deviner le type des ROM_CALLs en Flash n'est pas faisable. Il faut donc utiliser une table qui indique le type du ROM_CALL en Flash (code ou données), mais même en utilisant un bit par ROM_CALL, ça coûterait jusqu'à un peu moins de 200 octets, selon le numéro le plus élevé parmi les ROM_CALLs supportés par PedroM (FiftyMsecTick ?).
la seule interface raisonnable est de retourner le résultat dans %a0.l quel que soit le RAM_CALL.
Pas bon pour les RAM_CALLs qui prennent un argument dans a0...
Au prix d'une utilisation 8 fois plus grande de l'espace F000-F7FF, on pourrait permettre à l'utilisateur de spécifier le registre (soit de données, soit d'adresse) dans lequel il veut voir la valeur de retour: les bits 8-10 pourraient servir à ça.
Pour utiliser moins de registres, je pense (sans l'avoir codé, attention
) à quelque chose du genre:[ul][li]rester en mode superviseur le temps de l'exécution du handler, modifier sur la pile superviseur l'adresse de retour (sans oublier, si c'est nécessaire, par exemple pour les ROM_CALLs en F-Line, de pousser l'adresse de retour du ROM_CALL sur la pile utilisateur), et utiliser RTE;[/li]
[li]On peut aussi pousser sur la pile d0-d7/a0-a6 tout au début du handler, les modifier comme nécessaire sur la pile superviseur pour le retour, et les restaurer juste avant le RTE.[/li][/ul]
Certes, sauvegarder et restaurer 15 registres, en plus des autres écritures en mémoire, n'est pas ce qui se fait de plus rapide... mais de toute façon, si c'est la vitesse qu'on cherche, on commence par ne pas utiliser des exceptions processeur comme les A-Line, F-Line ou autres TRAP !