68080 AMMX Devpac Macros Support – Projet en développement.
15 sujets de 1 à 15 (sur un total de 15)
-
Avec le développement de l’Amos Professional Unity, je vais d’ici peu, commencer à développer la version SAGA (Vampire V4SA).
Mais avant cela, pour être sûr d’avoir la possibilité d’utiliser le gain de performance qu’offre ces cartess, je dois ajouter le support des instructions AMMX du 68080 de la Vampire dans GenAm (Devpac).J’ai donc démarré un mini-projet pour cela. Projet directement placé dans le site internet de l’Amos Professional Unity. Il contiendra un mini blog pour parler de la progression du projet.
Une version Alpha de tests a été mise à disposition sous le format de fichier .gs (‘Output Symbols’ à inclure comme un .s). Cela signifie que les macros sont fournies au format pré-compilé (pas en code source clair).
Vous pouvez récupérer cette 1ère alpha de test qui contient deux macros : Load et Store (AMMX_Load & AMMX_Store).
Tous les détails sont dans l’archive :
http://amos-professional-aga.frederic-cordier.fr/?i68080-ammx-devpac-macros-supportEDIT : Purée, il faut que j’arrête de poster sur les forums anglais … Je me mets à poster Anglais sur AI :p loool
J’ai corrigé ci-dessus 😉WIth the development of Amos Professional Unity,
I will soonly start the Vampire V4SA version to handle its new functionalities.
But before that, to be sure to have the capability to reach the maximum performances as possible, I must add support for 68080 instructions set inside GenAm (DevPac).I have started a new ‘mini project’ for this, directly hosted in my official “Amos Professional Unity” website.
It will contain a mini “blog” with news and progress in this project.
And alpha to test. The alpha releases are under the DevPac .gs (Output Symboles) file format. This mean the macros are pre-compiled (not plain source code).
You can get the 1st alpha that own 2 macros : Load & Store (labelled AMMX_Load and AMMX_Store).
All details are in the archive :http://amos-professional-aga.frederic-cordier.fr/?i68080-ammx-devpac-macros-support
@Kamelito :
Simplement car, malgré l’option “compatibilité avec Devpac”, VASM me génère beaucoup d’erreurs à fixer alors qu’il ne s’agit pas d’erreurs (tout compile correctement avec GenAm).
Et du coup, quitte à prendre du temps, je me suis dit qu’apprendre les instructions MMX au travers du développement de macros pour ces dernières pourrait être intéressant (plus que fixer du formatage code source, etc.) J’ai eu un seul problème avec les labels contenant des points. J’ai demandé de l’aide et au final PHX a modifié VASM pour le support des labels avec des points. S’il y a des choses qui ne marchent pas donnes moi des bout de codes et je lui demanderait de corriger.
bah à chaque fois que je fixe une différence, une autre viens.
Il y a par exemple :
moveq.w #x,Dn qui n’est pas reconnu sous VAsm
(il n’aime pas le .w dans les moveq)Puis des erreurs qui compilent parfaitement sous Devpac :
genre “illegal relocation”
pour des : move #lflash*FlMax-1,d0Genre “Absolute value expected
pour des : moveq #lflash-1,d0(il n’aime pas le .w dans les moveq)
Normal!
MOVEQ.Wn’existe pas. MOVEQ assigne une valeur 8bits étendue à 32 dans un registre D. Donc pas d’extension pour les MOVEQ. On faitMOVEQ #nn,Dxtout court.Puis des erreurs qui compilent parfaitement sous Devpac :
genre « illegal relocation »
pour des : move #lflash*FlMax-1,d0Oui c’est logique. Le code objet amiga n’a pas de relocation de type
adresse* constante. Es tu sur de vouloir manipuler une adresse via D0 ? Les registres Ax (d’adresses 😉 ) sont mieux pour ca en général.Je me demande si tu ne serais pas tombé dans l’erreur (je l’ai faite souvent) des symboles non définis qui sont automatiquement importés. En effet VASM considère qu’on fait un XREF implicite sur les symboles non définis plutôt que de faire une erreur… Un simple typo dans un symbole peut alors transformer une constante en adresse comme ici:
Genre « Absolute value expected
pour des : moveq #lflash-1,d0Ca flaire que lflash est un adresse (XREF implicite?) et pas une constante (EQU). Il y a l’option ‘-x’ de VASM pour qu’il fasse une erreur en cas de XREF implicite.
‘-x’ Show an error message, when referencing an undefined symbol. The default behaviour is to declare this symbol as externally defined.Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.) @__Sam__
pour le moveq.w je le comprends, le problème c’est que le code de l’Amos Professional en contient … Donc Devpac le compile comme un moveq standard je pense.
Après comme je dis, j’ai déjà pas mal de taf à faire pour un projet “hobby” sur “temps libre”, sans devoir me reprendre le code pour l’adapter à Vasm alors que sur Devpac je n’ai pas de soucis.pour le illegal relocation, ce n’est pas une adresse directement mais une valeur.
la valeur calculée dans d0 est souvent utilisée dans un truc genre :
move.l (a0,d0),d5
tu comprends ?pour le lflash, non je crois que c’est un SET genre :
lflash SET 1
ou
lflash SET AutreValue-4Voila.
je testerai l’option -x au cas où …En tout cas pour VASM c’est une adresse puisqu’il parle de relocation. A noter aussi, il manque “.w” au move (il est parfois implicite mais ca dépend des assembleurs.)
Après oui c’est du boulot, mais remettre d’équerre un vieux code n’est pas forcément inutile sur le long terme.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.) Oui, VASM la considère comme une relocation (ça je l’avais compris) alors que ce n’est pas le cas . En ce sens, VASM se plante ou est mauvais concernant son option “compatible devpac” qui en définitive n’est pas si compatible que cela …
Après, pour le justificatif de dimension (.b/.w ou .l) je n’ai pas repris tout le code Amos Professional pour vérifier à chaque fois que François Lionet aurait oublié de préciser … Juste j’ai repris ce qui m’était nécessaire pour l’AGA … Avec Devpac, tout fonctionne à ce niveau là, donc je n’ai pas cherché plus loin (tu n’imagines pas la quantité de lignes de code pour l’Amos Professional complet). Mais en effet, ne pas avoir de justificatif de dimension, c’est pas génial.
Sinon, remettre d’équerre … oui … Mais considérer que VASM ait raison en parlant de relocation où ça ne l’est pas … non. Sur Devpac (GenAm) la compilation et l’outil compilé fonctionnent bien … Pourquoi perdre du temps sur un projet hobby à reprendre des morceaux de code (où la modif ne changera rien au fonctionnement du produit compilé, la version AGA de l’Amos Professional le démontre) alors que j’ai beaucoup de taf à avancer…
J’imagine que VASM parle de relocation car il interprète le code différemment de ce que nous lisons nous humains. Un peu comme si le # était absent et qu’on parlait d’une simple étiquette. C’est troublant.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.) @__Sam__ :
Tu sais, je cherche pas à me prendre la tête.
J’ai appris à travailler d’une certaine façon.
Lorsque j’ai une structure, j’ai un registre d’adresse An qui pointe à son octet #0 (pas de décalage)
Et j’utilise un registre de données Dn pour calculer le décalage.
Après je fais ma lecture (An,Dn)->Dm et mon écriture Dm->(An,Dn) lorsque cela simplifie le travail.
Après parfois on utilise juste des (An)+ pour se décaler …
Mais j’ai pas besoin de comprendre pourquoi VAsm projète cette donnée différemment de Devpac…
ça fonctionne sur Devpac, (GenAm) ça me suffit 🙂
Je peux compiler l’Amos Professional Unity et le faire évoluer .. pas besoin de chercher plus loin 😉Bon c’est sur que du coup je dois me créer mes macros pour les instructions AMMX, mais cela ne me dérange pas car en définitive cela me permet d’apprendre ce qu’il y a à savoir sur le 68080 et les instructions AMMX pour décider où je l’utiliserai dans l’Amos Professional Unity (rien n’est dû au hasard, tout sert à un moment donné 😉 )
Oui oui c’est cool que tu trouve une façon de faire. Mais faut pas croie que VASM serait buggé. Il a probablement sa cohérence interne et ses raisons à lui qui nous échappent et que j’aimerais comprendre. C’est pour ca que je suis troublé. Mais c’est pas très grave.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.) Je mets régulièrement le projet à jour.
J’ai de plus optimisé ce jour mon système de macros. Ainsi je créé maintenant des “modèles de base”.
Pour l’instant, mon système possède 2 modèles de base :
<vea>,d
d,<vea>Cela permet d’optimiser le développement des MACROS. Ainsi, à chaque fois que cela sera possible une nouvelle instruction AMMX mise sous MACRO utilisera un modèle déjà créé pour une instruction précédemment ajoutée.
L’impact est majeur.
1. Cela permet de réduire l’impact en mémoire des MACROS d’instructions AMMX lors du processus de compilation.
2. Cela permet de rendre les potentiels bugs visibles plus rapidement et plus rapidement fixés (oui, un bug présent dans un modèle impactera toutes les instructions utilisant ce modèle et sera donc plus facilement visible).
3. Réduire les temps de développements de macros et réduire la quantité potentielle de bugs.L’archive de test Alpha a été mise à jour et est disponible sur le site officiel :
68080-ammx-devpac-macros-support page officielleVoici le détail de ce qui est actuellement supporté par le système de Macros :
Load (An),dn
Load (An)+,dn
Load (An,Dm),Dn
Load (An,Dm.w),Dn
Load (An,Dm.l),Dn
Load ADR,(An),Dn
Load ADR,(An,Dm),Dn
Load ADR,(An,Dm.w),Dn
Load ADR,(An,Dm.l),DnLoadi (An),dn
Loadi (An)+,dn
Loadi (An,Dm),Dn
Loadi (An,Dm.w),Dn
Loadi (An,Dm.l),Dn
Loadi ADR,(An),Dn
Loadi ADR,(An,Dm),Dn
Loadi ADR,(An,Dm.w),Dn
Loadi ADR,(An,Dm.l),DnStore Dn,(An)
Store Dn,(An)+
Store Dn,-(An)
Store Dn,(An,Dm)
Store Dn,(An,Dm.w)
Store Dn,(An,Dm.l)
Store Dn,ADR,(An)
Store Dn,ADR,(An,Dm)
Store Dn,ADR,(An,Dm.w)
Store Dn,ADR,(An,Dm.l)Storei Dn,(An)
Storei Dn,(An)+
Storei Dn,-(An)
Storei Dn,(An,Dm)
Storei Dn,(An,Dm.w)
Storei Dn,(An,Dm.l)
Storei Dn,ADR,(An)
Storei Dn,ADR,(An,Dm)
Storei Dn,ADR,(An,Dm.w)
Storei Dn,ADR,(An,Dm.l)VPerm $DIRECTVALUE,DnIn1,DnIn2,DnOut
c2p (An),dn
c2p (An)+,dn
c2p (An,Dm),Dn
c2p (An,Dm.w),Dn
c2p (An,Dm.l),Dn
c2p ADR,(An),Dn
c2p ADR,(An,Dm),Dn
c2p ADR,(An,Dm.w),Dn
c2p ADR,(An,Dm.l),Dn(Bien lire la documentation sur comment utiliser les macros AMMX_****)
15 sujets de 1 à 15 (sur un total de 15)
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › 68080 AMMX Devpac Macros Support – Projet en développement.
