v2BoiteAIdees

Fonctionnalités prévues pour la v2. Pour les sujets importants (MACRO, paramètres externes), il serait bon d'ouvrir la discussion ; Offset aura surement des desiderata, puisque Maxam lui fournit certaines fonctionnalités uniques sur CPC.

Refonte écran TRACE

Visualisation source

  • Passer à 7 lignes (voir 9)
    • Nb : on pourrait imaginer réutiliser l'espace dès lors que le source n'est pas trouvé. Mais ça peut être perturbant quand on alterne de "found" à "not found" (quand Orgams est perdu ou qu'on va piocher dans des routines externes).
    • Ou alors, pouvoir basculer sur un autre mode par raccourci clavier, indépendamment de la présence du source ou non. Exemple utile : dump mémoire à la dernière adresse sélectionné par 'm'.
  • Ne pas reprendre le même mécanisme que pour les opcodes (grisé = code venant d'être exécuté). Car ici c'est plutôt le contexte qui nous intéresse (typiquement, le label souvent placé un peu plus haut). Ainsi : pas de grisé en mode visualisation.

Dump mémoire anté-registres.

Scénario courant (du moins dans le 5ème) : on exécute une routine en mode rapide, et on aimerait voir ce qui a été écrit dans un table. Il faudrait donc voir les quelques octets avant l'adresse, à l'instar de ce qu'on fait avec SP. Cela donnerait :

01 02 03 04 ···· BC: 4004 00 00 00 00'00 00 00 00 ········
47 72 69 6d Grim DE: DADA 20 77 61 73'20 6e 6f 74 was not

ou encore

···· 01 02 03 04 BC: 4004 00 00 00 00'00 00 00 00 ········
Grim 47 72 69 6d DE: DADA 20 77 61 73'20 6e 6f 74 was not

MACRO

TODO : Décrire Quoi/comment. "Bibliographie" Reprendre le meilleur de Maxam-Winape, Nasm, voire assembleurs non-Z80s.

Anecdotique mais casse-tête intéressant : comment éviter les conflits avec le nom d'une macro et une future directive ?

Paramètres externes

Équivalent Get/Put de maxam, pour scriptage.

On envisage ici les solutions pour :

  • (a) Définir des labels de manière externe.
  • (b) A contriario fournir à un programme externe la valeur de labels.

Il s'agit de permettre un "linkage" automatisé (script en basic).

Questions :

  • Y a-t'il une autre utilité à ces fonctionnalités (a) & (b) ?
  • Quelle serait la vraie bonne solution pour le linkage ?

Écartons tout de suite le système de '#define' global à la C, et de tout ce qui va avec : c'est laid, piégeux et empêche plein d'optimisations de "build".
Au contraire, il faut identifier et regrouper (?) tous les paramètres qui influent l'assemblage. Cf solution 1.

Solution 0 (naze, indiquée par souci d'exhaustivité)

Permettre la lecture mémoire compile-time :

  ld a,@toto   ; remplacé par ld a,n où n est l'octet en toto au moment de l'assemblage (phase 2)
  ld hl,@@toto ; remplacé par ld hl,nn où nn est le mot en toto.

Placer les variables à partager dans une zone dédiée. On va piocher ou écrire dedans, en utilisant le fait que BYTE ou WORD sans paramètre n'écrase rien.

Eg :

      call @@in1

[...]

  ORG #BE80

in1  WORD      ; En lecture (doit être fourni avant)
in2  WORD
     WORD init ;
     WORD play ;

Solution 1. A la MaXaM.

    GET in1
    GET in2

Avec 2 différences :

  • Permettre valeurs par défauts. E.g. ' GET dev = 1 '. Exécuté sous ORGAMS, dev vaut 1.
  • Passer les valeurs en texte. E.g. ' |assemble,"dev=1 : dest=#4000" '
    • Cela autorise le point précédent
    • Beaucoup moins sensible aux erreurs de synchronisation, avec un tout petit prix à payer : en cas de renommage de label, il faut le reporter.

NB : le méchanisme sera re-exploitable pour les includes :

dest = #4000

   INCLUDE "3d.o" [ dev = 0 : dest = dest ]  ; Passe en paramètre le dest local.
   INCLUDE "3d.o" [ dev = 0 : dest ]         ; Version équivalente.

Symétriquement, un PUT dans un source devra être récupéré par un GET dans l'appel RSX, ainsi que décrit dans la section suivante.

RSX d'assemblage avec paramètres.

Choix du nom :

  • ORGASS (évite conflit avec |ASSEMBLE de Maxam)
  • Vu qu'on ouvre le fichier à assembler, j'avais pensé à OPENASS, mais c'est trop Charlie.

Solution 0

  • Bof, limitée par longueur ligne basic.

Syntaxe

|ORGASS,filename [,paramètres]

Paramètres possibles :

  • "label1= value1" (ou plusieurs assignations séparées par des ":")
  • "label1", suivi d'une variable entière value1.
  • "get label1,label2", suivi d'autant d'adresses de variables entières.
|orgass,"30ymd.o","debug= 0:gfx= 1","start=",start,"get init,play,draw",@init%,@play%,@draw%

Solution 1 (suggérée par Offset)

Utiliser une paire de RSX SETLABEL/GETLABEL

L'exemple devient

|orgopen,"30ymd.o"
|setlabel,"debug",0
|setlabel,"gfx",1
|setlabel,"start",start
|orgass
|getlabel,"init",@init%
|getlabel,"play",@play%
|getlabel,"draw",@draw%

Beaucoup plus propre, et permet de définir/récupérer facilement des batchs de labels (hook00, hook01, hook02, …).

Casse des labels

Levée de la sensibilité à la casse

Les sources Maxam sont insensibles à la casse. Pour les importer plus facilement, on pourrait faire de même dans Orgams.

Le principe serait le suivant : on saisie "call gensin". Si 'GenSin' existe déjà, le rapprochement est fait et on obtient " call GenSin". D'un autre côté, un label saisi avec au moins une majuscule changerait la casse de tous ses isotopes (nécessaire pour problématique import Maxam).

Unique "inconvénient", cela interdit la discrimination par la casse. Eg :

  • 'toto' en minuscule pour début de table, 'TOTO' pour fin.
  • 'x1' vs 'X1'

Mais qui diable ferait ça ? D'ailleurs je peine à trouver des exemples réalistes !

Sommaire

Il est prévu dans le futur d'avoir un accès rapide à des labels "privilégiés" : ceux commençant par une majuscule, ou tout en majuscule. Cela reste à définir (les votes sont ouverts).
Ainsi, on filtrerait tout les labels auxilliaires utilisant une minuscule initiale (loopY, ok_carry…) pour obtenir la liste des routines.

Numérotation automatique des labels (dans bloc répété)

(Où Tistou code un effet de vague masqué en quelques lignes)

Pour rappel, un label dans un bloc répété aboutit à une erreur de définition multiple, car tout se passe comme si le bloc était recopié à la main.
Une solution à ce problème est de numéroter automatiquement les labels avec l'indice de l'itération.

[TODO] Choisir : syntaxe (voir l'existant)

Imaginons que step(__iter__) se voit remplacé automatiquement par step0 step1 … dans le code suivant :

  size * [
        LD  a,(hl)
        OR  a          ;Transparent ?
        JR  z,step(__iter__)
        LD  (de),a
step(__iter__) NOP     ;replaced by INC H / DEC H / NOP
        INC L
        INC E
     ]

Non seulement cela résout le souci de définition multiple, mais cela permet de construire simplement une table d'index, avec les adresses de chaque label :

step_adr size * WORD step(__iter__)

Proposition

Plutôt que __iter__, symbole #.

Avantages :

  • le '#' porte en lui la notion de numérotation.
  • moins verbeux, et plus identifiable en tant que pseudo label.
  • surtout, extension simple en cas de boucles imbriquées. Eg, si 3 boucles, ### désignerait le compteur de la boucle externe, ## celui de la boucle intermédiaire et # celui de la boucle la plus interne.

Inconvénients :

  • moins explicite.
  • plus difficile à trouver avec une recherche texte simple.

Labels locaux.

Tous les labels considérés jusqu'à présnet sont "globaux", c'est à dire visibles de n'importe quel point du source. Introduire des labels locaux présente deux avantages :

  1. Éviter les conflits de nom.
  2. Souligner l'aspect privé (interne et temporaire) de tel label : utilisé à l'intérieur d'une routine, mais non censé être appelé en dehors.

Le point 1 se révèle important dès lors qu'on inclue des sources divers. On veut éviter que le "loopY" d'une routine de sprite entre en conflit avec celui d'un affichage de ligne (voir paragraphe suivant).

Un label local reste accessible en dehors de la routine en préfixant par le label global associé. Eg :

drawline
    [...]
.loopY
.mask ld  a,#ff   ;Mask
      [...]
      dec iyl
      jr nz,.loopY

    ret

[Ailleurs dans source]

frame1
   ld a,#55 ;Test !
   ld (drawline.mask+1),a
   ld (texture.mask+1),a

[TODO] Distinguer label réellement temporaires (seraient inaccessibles hors de la routine) ? Pour quoi faire ?

Préfixage automatique

Afin d'éviter des conflits entre labels, on
Préfixer labels fichier inclus :

   include "music.o" as music

puis ... call music.init
         call music.depack_regs
         call music.play_regs

Syntaxe alternative (à choisir : l'une ou l'autre !)

music  include "music.o"

'bookmarks'

Ceux de TurboAss se révèlent trop rustiques pour devenir utiles :

  • Lié à une ligne plutôt qu'un label.
  • C'est idiot d'avoir une commande pour les lister, puis une autre pour y accéder, surtout qu'entre temps il faut repasser par le source, perdant la liste de vue. D'un autre côté la liste n'est pas très parlante !

L'idée serait donc de pouvoir bookmarker des labels, et prévoir une combinaison à trois touches :
CTRL B 0 : Bookmark 0
CTRL B 1 : Bookmark 1

L'astuce étant que CTRL B affiche la liste des bookmarks ! D'un point de vue réactivité, on ne doit pas attendre la fin de l'affichage (même si ça prend 1/10 de seconde) dès lors que le numéro est appuyé.
Idéalement, la liste affiche un peu de contexte (les deux lignes qui suivent le label). Ça prend de la place, mais il n'y a pas besoin d'une douzaine de bookmarks. Six suffiraient amplement, je pense.

Moniteur: saisie commande intuitive.

Coupler l'efficacité de Dams (1 commande = 1 lettre) avec la lisibilité de Maxam, c'est possible :
Les commandes possèdent un nom complet mais se trouvent accessible par leur initiale, à l'instar du Hacker.
Contrairement au hacker, avant même de valider, l'auto-complétion automatique (m -> mdump) permet de s'assurer qu'il s'agit bien de la commande attendue.
Nb:

  • l'appui sur delete doit alors effacer toute l'entrée.
  • on peut préremplir un paramètre (eg, reprise adresse pour mdump)
Sauf mention contraire, le contenu de cette page est protégé par la licence Creative Commons Attribution-ShareAlike 3.0 License