CPCWiki forum

Section française => Discussion générale => Topic started by: madram on 23:17, 30 August 16

Title: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 23:17, 30 August 16

Un coin pour recueillir les souhaits concernant votre assembleur favori, discuter et laisser mijoter les idées.

Quand j'ai abordé le sujet au café, personne ne s'est montré intéressé.
Histoire vraie : malgré la puissance de Monogams, il m'arrive d'avoir recours au hackeur/hackit, principalement pour le couple CLEAR + M (dump graphique). Le but étant d'obtenir une vue d'ensemble des zones utilisées par un programme (*).
La commande CLEAR du hacker efface les 128 premiers KO, sauf les zones systèmes. Si une bank est connecté (C4, C5, ...) c'est elle qui se voit nettoyée plutôt que la page &4000 d'origine.
Je prévois donc ajouter deux commandes, valables également dans un source (effectuées à chaque assemblage).

 * CLEAR: Efface les 128 premiers KO à l'exception des les zones systèmes, indépendamment de la bank connectée.
 * CLEAR128: Efface les 128 premiers KO, indépendamment de la bank connectée.

Pour nettoyer d'autres banks à l'assemblage, on pourra se rabattre sur la séquence BANK n:ORG &4000:FILL &4000,0

(*) Il faudra imaginer des façons plus rigoureuses/pratiques de mener à bien cette analyse.

Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 00:20, 01 September 16
Bonne suggestion d'un membre des AA (Artistics Anonymous) : une valeur optionnelle de remplissage (00 par défaut).


(*) Mécanisme suivant à méditer :
  * Snapshot des 128k premiers cas juste avant l'exécution.
  * Comparaison mémoire entre l'état courant et le snapshot référent.
  * Pour faciliter l'analyse, annotation du source afin d'indiquer les zones sensées être (auto) modifiées.
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: Ast on 00:50, 01 September 16
Pour ma part, je souhaiterais bien une option macro du style :


Code: [Select]
...
Ex1 byte 1,2,3,4,5,6,7,8
Ex2 byte 7,6,5,4,3,2,1,0
...
Pattern Ex1,Ex1,Ex2,....


Tu vois ce que je veux dire?

Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 09:51, 01 September 16

@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573) Intéressant. Deux pistes pour cela : tableaux et effectivement macros.


1/ Tableaux


Code: [Select]
Ex1 = [1,2,3,4,5,6,7,8]
Ex2 = [7,6,5,4,3,2,1,0]


Pattern  Byte Ex1,Ex1,Ex2
La seule chose à régler ici est qu'on ne voit pas à l'utilisation (ligne Pattern) qu'il s'agit de tableaux.
En revanche cela permet plus de choses, comme :


Code: [Select]
8 ** [ ld (hl),Ex2[#]:inc l ]   ; Expend to ld (hl),7:inc l:ld (hl),6:inc l ...

2/ Macros


Ton exemple est un peu lacunaire, car ni l'utilisateur ni l'assembleur ne peuvent deviner qu'Ex1 et Ex2 sont des macros. Je verrais plutôt un truc du genre :


Code: [Select]
Macro Ex1()
    Byte 1,2,3,4,5,6,7,8
 End
 Macro Ex2()
    Byte 7,6,5,4,3,2,1,0
 End


Pattern Ex1():Ex1():Ex2()
La syntaxe précise reste à définir. Etudier l'existant (Pyradev et cross-assembleurs).
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: Targhan on 11:50, 01 September 16
Si macro il y a, permettre des paramètres si possible !


Exemple dans SJAsmPlus que j'utilise:


Sans paramètres:
MACRO ADD_HL_A
ADD A,L
JR NC,.hup
INC H
.hup
LD L,A
ENDM


Avec paramètres:
MACRO WAVEOUT reg, data

LD A,reg
OUT (7EH),A
LD A,data
OUT (7FH),A
ENDM

; this macro will make WAVEOUT 2,17 expand to:
LD A,2
OUT (7EH),A
LD A,17
OUT (7FH),A

Les mnémoniques MACRO/ENDM définissent le début et la fin.
Pas forcément simple à implémenter cela dit !

Trg.Aks
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 12:23, 01 September 16

Bonjoir TrgInRennes, merci pour ton apport.


Oui pour les paramètres, les parenthèses étaient prévues pour cela. Mais j'aime l'absence de parenthèses !
Le plus enquiquinant sera la gestion des labels locaux, mais ça peut être fait dans un second temps, surtout que je prévois une autre solution à ce problème : pseudo label "_" pour aller à la ligne :


Code: [Select]
   add a,l
   jr nc,_:inc h
   ld l,a
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: Ast on 14:03, 01 September 16
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573) Intéressant. Deux pistes pour cela : tableaux et effectivement macros.


1/ Tableaux


Code: [Select]
Ex1 = [1,2,3,4,5,6,7,8]
Ex2 = [7,6,5,4,3,2,1,0]


Pattern  Byte Ex1,Ex1,Ex2
La seule chose à régler ici est qu'on ne voit pas à l'utilisation (ligne Pattern) qu'il s'agit de tableaux.
En revanche cela permet plus de choses, comme :


Code: [Select]
8 ** [ ld (hl),Ex2[#]:inc l ]   ; Expend to ld (hl),7:inc l:ld (hl),6:inc l ...

2/ Macros


Ton exemple est un peu lacunaire, car ni l'utilisateur ni l'assembleur ne peuvent deviner qu'Ex1 et Ex2 sont des macros. Je verrais plutôt un truc du genre :


Code: [Select]
Macro Ex1()
    Byte 1,2,3,4,5,6,7,8
 End
 Macro Ex2()
    Byte 7,6,5,4,3,2,1,0
 End


Pattern Ex1():Ex1():Ex2()
La syntaxe précise reste à définir. Etudier l'existant (Pyradev et cross-assembleurs).



C'est juste un exemple avec ce qu'il serait important d'ajouter, à mon humble avis! La syntaxe reste à définir, of course.
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: Ast on 18:43, 01 September 16
Ce qui serait également interressant pour moi serait de pouvoir utiliser l'asic en même temps qu'Orgams et ainsi éviter tout plantage qui compromet mon code source!
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: TFM on 18:50, 01 September 16
Maxam II (the CP/M Plus version) can do macros. IMHO they are very helpful. Also 6128 Plus specific support would be a great idea. But question is what's needed first (sorry for non-french answer).  :)
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 11:54, 02 September 16

C'est juste un exemple avec ce qu'il serait important d'ajouter, à mon humble avis! La syntaxe reste à définir, of course.


Justement, le but de ces discussions est aussi de définir la meilleure syntaxe possible, par essais et affinements.


"asic": qu'est-ce que c'est ? Voir avec Grim.
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 11:55, 02 September 16

Concernant les macros, je résume ici les fonctionnalités attendues (à compléter).

* gestion de paramètres
   * séparés par virgule à la définition et à l'appel
   * noms obligatoires dans définition (a contrario de certains assembleurs où l'on accède aux paramètres par \1 \2 ...). Plus explicite.
* valeur par défaut possible pour chaque paramètre
   * E.g. macroprint msg repeat=1
* possibilité de substituer des instructions complètes. E.g. BRESENHAM inc l, inc d
* contexte frais + labels locaux
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: Ast on 12:34, 02 September 16

"asic": qu'est-ce que c'est ? Voir avec Grim.

tu te fous de ma gueule ?
:-p

C'est gérable ou non? A mon avis, ce doit être le bordel, surtout avec les extensions mémoires>128K!
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 15:44, 02 September 16
* possibilité de substituer des instructions complètes. E.g. BRESENHAM inc l, inc d


Si la virgule sert de séparateur entre paramètres, ce point pose la question du passage d'instruction avec virgule.
On pourrait mettre de telles instructions entre guillemets (e.g. "ld a,h"), ce qui pose la question du passage de chaines.[size=78%]  [/size]
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: krusty on 16:00, 02 September 16
Je pense avoir testé beaucoup d'assembleurs z80 et les directives préprocesseurs qui vont avec.

Je n'ai pas le souvenir d'en avoir utilisé un qui permette de fournir des arguments avec des virgules (ou des chaines de caractères qu'il peut assembler ailleurs).
Je pense que systématiquement les paramètres des macros sont des entiers (que la valeur soit obtenue directement ou après résoudre des symboles).

J'imagine que tu peux t'en abstenir en fournissant l(es) opcode(s) en paramètre(s) ou un codage quelconque et utiliser des if dans la macro pour gérer le fait que l'instruction que tu vient de passer peut avoir une taille variable.
Sinon c'est peut être plus un pré-processeur type cpp que tu as écrire, qui te génère une seconde version du code qui elle est réellement assemblée par ton assembleur ?


Si la virgule sert de séparateur entre paramètres, ce point pose la question du passage d'instruction avec virgule.
On pourrait mettre de telles instructions entre guillemets (e.g. "ld a,h"), ce qui pose la question du passage de chaines.[size=78%]  [/size]
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 16:35, 02 September 16
Passage de paramètres arbitraires:

Maxam II le permet (e.g. swap hl bc). Funny enough, le premier exemple de la notice est ADDHLA. Ref: http://www.cpcwiki.eu/imgs/6/6e/Maxam_II_ (http://www.cpcwiki.eu/imgs/6/6e/Maxam_II_)(Arnor)_Manual.pdf

Pyradev le permet.

Marrant, tous ces gens passés sur PC pour des outils plus puissants, alors qu'ils étaient disponibles sur CPC depuis toujours !
On note au passage que les deux assembleurs cités utilisent un préfixe pour référencer les paramètres lors de la définition :

Code: [Select]
MACRO swap $reg1 $reg2
push $reg1
push $reg2
pop $reg1
pop $reg2
MEND

Avantages:
   * Rend explicites l'utilisation et le rôle particulier du paramètre
   * Facilite l'échappement ?!?
Inconvénient:
   * Syntaxe à connaître

Avec ou sans préfixe, quelle serait votre préférence ?

Yep, j'envisage une substitution textuelle, mais à la volée, et seulement si le paramètre n'est pas une expression numérique (avec ou sans labels) évaluable.
En effet, évaluer l'expression avant remplacement évite les pièges de précédences ou autres trucs plus vicieux (cf tous les problèmes de macro en C/C++).
Il faudra vérifier si cette approche hybride n'introduit pas d'autres pièges ou comportements surprenants.
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: krusty on 17:32, 02 September 16
Finalement je n'ai pas été assez curieux ; vasm n'est pas aussi limité que ce que mon message supposait (les autres aussi peut être).
Il est capable de faire :

macro myswap, r1, r2
  push \r1
  push \r2
endm

macro cmd, cmd
 \cmd
endm

 myswap hl, de
 myswap de, hl
 cmd xor a
en générant le bon binaire ...

je n'ai pas trouvé par contre de syntaxe pour avoir des arguments à virgule
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 11:56, 03 September 16
Le manque de curiosité tue !

Sur feu P'n'P, il y avait eu un fil intéressant sur les macros utiles.
Il serait sympa de les remettre ici (ou sur une page wiki dédiée).

Encore plus intéressant serait de lister les macros que vous auriez aimé avoir, mais que les limites de votre assembleur rendent impossibles à définir.
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: Ast on 12:32, 03 September 16
Ne vous demandez pas ce qu'OrgAms peut faire pour vous, demandez vous plutôt ce que vous pouvez faire pour OrgAms!
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: krusty_benediction on 15:35, 03 September 16
Le manque de curiosité tue !

Sur feu P'n'P, il y avait eu un fil intéressant sur les macros utiles.
Il serait sympa de les remettre ici (ou sur une page wiki dédiée).

Encore plus intéressant serait de lister les macros que vous auriez aimé avoir, mais que les limites de votre assembleur rendent impossibles à définir.

le définition de fonctions quelconques pour pouvoir faire des choses du type (je pense que sjasmplus peut faire ce genre de chose en lua ; pour orgams ça pourrait être du basic) :



; Définition de la fonction sin avec la syntaxe approprié
; ...

; Utilisation

  ld a = sin(pi)*256


L'intéret étant de diminuer la quantité d'outils annexes à écrire pour calculer/transformer des données
L'assembleur pourrait proposer des fonctions prédéfinie (mathématique, image, ... voir même octets de représentant l'instruction z80 fournie en argument (une fois assemblée) pour faciliter l'écriture des codes générant du code)




Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 18:04, 03 September 16
le définition de fonctions quelconques


Orgams propose déjà les fonctions ABS, SIN et COS en natif, ces dernières recalibrées sur une période de 256, et renvoyant une valeur entière signée 16 bits.
Ainsi, on peut génèrer une table  ainsi:

Code: [Select]
onde1  256 ** BYTE ABS(SIN(#)/256)   ; Rebond  (# est le compteur interne de repétition. Ici de 0 à 255)
onde2  256 ** BYTE ABS(SIN(4*#)/[256+#+#]) ; Rebond amorti (amplitude 3 fois moins grande en fin de courbe)

ou encore
             LD A,ABS(shift)

Voir le fichier d'exemple 'plot.o (ou 'ondes.o ) sur la disquette.
Après, pour une fonction arbitraire, faut voir le besoin ! Aurais-tu d'autres exemples en tête ?

Quote
; Utilisation

  ld a = sin(pi)*256

 Je ne comprends pas cette syntaxe. Pourquoi un '=' ?
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: krusty_benediction on 19:36, 03 September 16

Après, pour une fonction arbitraire, faut voir le besoin ! Aurais-tu d'autres exemples en tête ?

Je n'ai pas d'exemple précis en tête tout de suite.
Ca peut avoir un intérêt pour stocker
 - un sprite (issue d'un window ocp) de façon non conventionnelle (par exemple pour l'afficher en zigzag en suivant un ordre de code gray). Dans ce cas la fonction produit des octets plutot que retourner une valeur
 - générer des valeurs pour lesquelles il est plus agréable de lire le nom de la fonction qui a un sens plutôt que le calcul mathématique/binaire qui peut devenir incompréhensible après une trop grande période sans coder



Je ne comprends pas cette syntaxe. Pourquoi un '=' ?
coquille => virgule
Title: Re: Assembleur plus que parfait que nous eussions assemblé
Post by: madram on 18:34, 06 September 16
Je n'ai pas d'exemple précis en tête tout de suite.

Je suis assez fan du principe YAGNI !
Le CPC dispose déjà d'un système de plugin : les RSXs.
Après, si la question est de bien séparer le "build-time" du "run-time" (par exemple pour obtenir un binaire prêt à enregistrer avec la version gray-arrangée de ton sprite), alors il s'agit d'un problème indépendant qui mérite discussion.

Un exemple concret serait fort instructif : écrire cet appel à un pré-processing tel que tu aimerais en disposer dans un monde idéal.