Programmation ASM sur Amiga
-
Petite question pour les programmeurs.
J’ai toujours entendu dire que l’assembleur 68k était un des plus simple/plaisant à utilisé. En tant que bon fanboy d’Amiga, j’aimerai pouvoir expliquer pourquoi à un ami qui connais la programmation (assembleur et autres).
Quelqu’un pourrait me faire un petit topo ? Même s’il y a des choses uniquement compréhensibles par un programmeur 🙂
Merci,
Amiga RULEZZZZZZZ
Salut,
Pas mal de choses derrière tout çà – de l’objectivité et de la subjectivité 🙂
Une des premières chose est que le 68K est un CPU CISC, Complex Instruction Set Computer. Par complexe, il faut comprendre ‘Plein d’instructions sympathiques’ et non ‘compliqué’. Le 68K propose donc beaucoup d’instructions pour simplifier la tache du programmeur. A contrario des CPU RISC (PPC notamment) pour lesquels il faut coder beaucoup plus avec beaucoup moins.
Deuxième chose, la syntaxe est nettement plus ‘agréable’ que la syntaxe d’un x86 par exemple.
Autre chose, l’API de l’AmigaOS s’utilise facilement en ASM 68K. Normal, il a été conçu pour.
Il y a d’autres arguments mais je suis pris de court… à plus.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
Deja la syntaxe est simple/claire :
add mul move etc…
On comprends facilementles registres sont « banalises » tu as 8 registres de donnees et 8 registres d adresse (qui fonctionnent tous les 8 pareils)
Ces registres servent (et non pas la pile) a appeler l ‘AmigaOS
par les fonctions des .libraryLe 68000 est 16/32 bits mais les registres sont utilisable en 32bits comme si tout etait 32bits
Voila…
En attendant de trouver un peu de temps pour mettre à jour l’ensemble du site j’ai remis en accès les PDF des dossiers, ils sont accessibles depuis le lien Documents de la page d’accueil. Have fun
Je dois être fatigué, je ne trouve pas le lien Document pour l’accès des PDF
Merci de votre aide 🙂
Un autre avantage du 68K c’est qu’il produit en principe des binaires nettement plus petit que du code PPC. Il suffit d’ailleurs de comparer sur Aminet par exemple, pour un même programme, la taille du binaire AmigaOS3.x (68K) est en principe plus petit que le binaire AmigaOS4 (PPC).
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.Voila la réponse que j’ai eu, c’est comparé au 6502, il y a même quelques mots de R.J.Mical (Si je pollue le post, un admin peut ouvrir un nouveau sujet)
La moitié des réponses pointent l’intérêt du 68K par rapport au système d’exploitation de l’Amiga. C’est du hors sujet.
On parle spécifiquement de l’assembleur, pas d’une machine en particulier.
Par ailleurs, parmi les 4 langages assembleur que j’ai appris, la facilité et la puissance d’utilisation du 6502/6510 a été claire.
Avec ses différents modes d’adressages (directs, indirects, pré-indexés, post-indexés, etc) utilisables pour presque toutes les instructions, c’était un plaisir de coder.
Pour le 68K, les modes d’adressage ne fonctionnent pas tous pour toutes les instructions. Des fois oui, des fois non. Bonjour les erreurs d’assemblage qui vont contraindre de revoir la façon de programmer et modifier le source. Grosse perte de temps et énervement à la clef.
Q. Why does the Lynx use a 6502 and not a 68000?
A. « Some people believe it’s less of a processor than the 68000, for example. That series of chip was used in the Amiga, but it wouldn’t make our machine do things any better. In fact, it would only make the unit larger and more expensive. It’s also harder to write 68000 code, so we definitely made the right decision. »
–R.J. Mical
« The real answer for the choice for the 6502 vs. 68000 was price. Secondary considerations (that did not really enter into the decision making process): 68000 code is very fat compared to 6502 code. An application that takes 1K of 6502 code averages 2.5 to 3K of 68000 code. The 6502 is very bus-efficient, the 68000 has lots of dead time on the bus. As for it being harder to write 68000 code, that is probably not true, and in any case was not part of the reason the decision was made. »
–Stephen Landrum
Additionally, inside sources at Atari say that one major reason for the 6502 vs 68000 processor choice was that the 6502 design was available as a component that could be plugged into a custom chip design. This allowed engineers to build a chip with a 6502 and other supporting hardware around it all in one package. It is only around 1993-1994 that Motorola offered the 68000 as a design component.
Il est dommage que ces modes d’adressages n’aient pas été réutilisés. ça aurait bien simplifié le codage en ASM 68k.
En même temps, les 2 cpu 65xx et 68k sont bien différents : 4 ans d’écart, 8 bits vs 16 bits, 25$ vs 140$, 1MHz vs 8MHz
Autre particularité du 6502, c’était un cpu qui tenait à la fois du RISC et du CISC.
Même les instructions utilisant les modes d’adressage complexes faisaient que chaque instruction ne prenait que 2 à 7 cycles d’horloge au maximum. Sur le 68K, on va de 4 à plus de 30 cycles d’horloge. Le max est d’environ 150 cycles pour la multiplication et la division (que ne faisait pas le 6502 de base mais son grand frère 16 bits à 20MHz).
Après avoir pris le temps de passer en revue le jeu d’instruction du 68K, il est indéniable que le les modes d’adressage qui « fluctuent » d’une instruction à l’autre sont rédhibitoires :
Pour être opérationnel de façon efficace sur le 68K, il faut connaître à fond PAR COEUR tous les modes d’adressage instruction par instruction…
Ben voyons ! On n’a que ça à faire. Déjà que coder en ASM c’est plus long qu’en langage évolué, ça devient le pompon.
Bon, après mettre pris ça, je suis en train de rechercher mes dents 😉
« Le max est d’environ 150 cycles pour la multiplication et la division (que ne faisait pas le 6502 de base mais son grand frère 16 bits à 20MHz). »
Je me souviens sur Apple][c qu’il fallait faire une boucle d’addition ou de soustraction pour faire notre preopre multiplication ou division :p
Le gros avantage de l’ASM 68K par rapport à d’autres CPU c’est que tu peux commander des appareils externes comme une machine à café ou un lave linge. Tu peux expliquer cela comme ça, c’est facile à comprendre.
Ha tiens j’avais loupé ce post, bon alors mis à part les réponses de Mical et Landrum qui sont basées sur des contraintes de coût je trouve les autres réponses pas très objectives.
Tout d’abord il faut prendre en compte ce que l’on veut faire avec cet assembleur, tant que l’on se contente de programmes assez simple (comme un jeu d’arcade) alors oui le 6502 est largement suffisant et clairement plus efficace (à vitesse égale) qu’un 68000 à ceci près qu’il faut souvent jongler avec la limitation à 8bits. Mais si on commence à faire des choses plus complexes comme de la 3D ou carrément un OS (multitâche de surcroît) alors il ne fait aucun doute que le 68000 dépasse largement le 6502.
Quelques exemples, il n’existe pas d’appel de fonction en mode indexé sur le 6502 (du genre « jsr (Adr) »), alors c’est vrai que sur un système monotache ou la gestion de la mémoire n’existe pas vraiment ce n’est pas trop grave, mais dès que l’on veut faire du multitache ça devient compliqué, il faut jouer avec la pile et un « jmp (Adr) » pour remplacer celà. Idem pour la copie de buffer, tant que l’on reste dans la limite des 256 octets ça reste assez trivial avec le 6502 mais au delà ça se complique, on est loin du « move.l (a1)+,(a2)+ » d’un 68000.
Je vais revenir aussi sur une remarque :
Même les instructions utilisant les modes d’adressage complexes faisaient que chaque instruction ne prenait que 2 à 7 cycles d’horloge au maximum. Sur le 68K, on va de 4 à plus de 30 cycles d’horloge. Le max est d’environ 150 cycles pour la multiplication et la division (que ne faisait pas le 6502 de base mais son grand frère 16 bits à 20MHz)
Là faut pas abuser, qu’est ce qu’il appel mode d’adressage complexe, le plus complexe sur 6502 c’est l’indirect indexé genre « lda (Adr),y », qui n’est d’ailleurs, en passant, disponible que sur les instructions relatives à l’accumulateur (oué pas de « ldx (Adr),y » désolé), donc en gros un « move.w (a1,d0.w),a2 » du 68000, on est loin d’un mode complexe du point de vue 68000 comme le serait un « move.w 8(a1,d0.w),(a2)+ » (qui au passage ne prend que 20 cycles).
Certes l’instruction « nop » d’un 68K prend 4 cycles et seulement 2 sur un 6502, d’ailleurs sur 68K toute instruction prend un multiple de 4 cycles, mais déjà il faut voir que le 68000 c’est 8 fois la fréquence du 6502 (en général), donc globalement il reste 4 fois plus rapide, de plus cette contrainte de 4 cycles est liée à la faible vitesse de la RAM de l’époque qui oblige le proc à attendre des cycles d’accès, va jeter un oeil au nouveau core de l’équipe apollo (http://www.apollo-core.com/) pour te rendre compte ce qu’un 680×0 accompagné d’une mémoire rapide peu donner.Sincèrement j’adore le 6502, en son temps c’était un merveilleux proc, parfait pour les machines 8bits, efficace, bien pensé, agréable à coder, mais sincèrement le 68000 est un cran au dessus niveau fonctionnalité.
Bonne journée
Bonjour,
juste pour vous signaler que le site est à nouveau consultable dans son intégralité et avec un nouveau design à cette adresse http://flabrador.free.fr/lexo
Bonne lecture
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Programmation ASM sur Amiga
