Acorn archimedes 3010
+29
epc35
ericde45
Capitaine
YannAros
k1200rs21
chiss
Belfedia
oiseau de proie
tristan33
Cormano
cryodav76
fonzi
kawickboy
eraserhead
G-fly
Atlantis
meuhmeuh
Zarnal
ace76
upsilandre
Matari
Vortex
TotOOntHeMooN
Tryphon
drfloyd
babsimov
Urbinou
ArchieForEver
jameson28fr
33 participants
Page 5 sur 34
Page 5 sur 34 • 1, 2, 3, 4, 5, 6 ... 19 ... 34
Re: Acorn archimedes 3010
J'ai été assez étonné des résultats qu'on peut obtenir sur MD avec du C pur
Tryphon- Docteur *
- Nombre de messages : 26166
Date d'inscription : 23/07/2016
Re: Acorn archimedes 3010
Tryphon a écrit:J'ai été assez étonné des résultats qu'on peut obtenir sur MD avec du C pur
également avec du basic.... meme si en dessous du C
_______________________________________________________
![Acorn archimedes 3010 - Page 5 Americ10](https://i.servimg.com/u/f11/11/03/61/79/americ10.gif)
Re: Acorn archimedes 3010
drfloyd a écrit:Tryphon a écrit:J'ai été assez étonné des résultats qu'on peut obtenir sur MD avec du C pur
également avec du basic.... meme si en dessous du C
La Basic de la MD étant COMPILÉ, il n'y a pas de raison qu'il soit fondamentalement plus lent que le C.
Cependant,
* le langage ne permet certainement pas aisément certaines constructions du C (comme les pointeurs, en particulier les pointeurs sur fonctions) et du coup, même si c'est possible, les codeurs Basic les utilisent peu
* je pense probable que la bibliothèque SGDK de Stef soit mieux codée et efficace que les routines internes des Basics (pure spéculation)
Tryphon- Docteur *
-
Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Acorn archimedes 3010
Une erreur un peu souvent lu , comme c'est compilé c'est aussi rapide que du C :pLa Basic de la MD étant COMPILÉ, il n'y a pas de raison qu'il soit fondamentalement plus lent que le C.
Cela dépend du langage (même le java compilé reste plus lent que du C ou C++ compilé).
Mais surtout la grosse dif c'est que le C profite d'un certain compilateur (GCC) qui permet de faire de grosse optimisation que ferait un programmeur assembleur expérimenté
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Alors que le basic c'est transcodé tel quel et donc "super long" (c'est un peu l'équivalent entre l'option -O0 et -O3 de GCC , la dif entre les deux sont énorme en terme d'optimisation).
Programmer en assembleur ne garantie pas que ton code sera rapide ,si tu ne fait pas les optimisations nécessaire (comme GCC) , ben l'asm peut être bien plus lent que du C pour un programmeur débutant/moyen face au C.
(enfin même expérimenté parce que le compilo C va dans des opti assez poussé).
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:Une erreur un peu souvent lu , comme c'est compilé c'est aussi rapide que du C :pLa Basic de la MD étant COMPILÉ, il n'y a pas de raison qu'il soit fondamentalement plus lent que le C.
Cela dépend du langage (même le java compilé reste plus lent que du C ou C++ compilé).
J'ai simplifié pour le doc : ce sont deux langages très proches (pas de construction haut-niveau : c'est pas du CaML ou du Python, ni même du java), compilés. Donc on peut très bien imaginer un compilateur Basic optimisant tout aussi bien que GCC (on pourrait par exemple faire une traduction Basic -> C quasiment immédiate). Et pourtant, je pense qu'on observerait des programmes C toujours plus rapides, principalement pour les raisons que j'ai évoquées, et pas pour l'optimisation fournie par GCC.
Par exemple, pour Shinobi, j'ai commencé mon développement avec une vieille version de SGDK qui utilise GCC 2, et je n'activais pas les options d'optimisation. Ça m'empêchait pas d'atteindre les 60fps, même en debug.
La principale optimisation à faire, c'est dans les algorithmes utilisés, et il est plus facile et naturel d'utiliser des algorithmes efficaces en C (parce que le fait de coder avec des pointeurs t'oblige à réfléchir aux manipulations de la mémoire ; le basic est plus transparent pour ça)
Programmer en assembleur ne garantie pas que ton code sera rapide ,si tu ne fait pas les optimisations nécessaire (comme GCC) , ben l'asm peut être bien plus lent que du C pour un programmeur débutant/moyen face au C.
(enfin même expérimenté parce que le compilo C va dans des opti assez poussé).
Oui, je suis d'accord avec ça. Tout comme il est parfois possible de faire du Python ou du Java plus rapide que du C. Mais c'est plus une question d'algorithme que du comptage de cycles (ça c'est bon pour la SNES
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Tryphon- Docteur *
-
Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Acorn archimedes 3010
Je suis totalement d'accord avec ça , c'est la premier optimisation à faire avant de se concentrer sur la génération du code produit :pLa principale optimisation à faire, c'est dans les algorithmes utilisés
Le comptage de cycles, je le fais partout même sur des consoles puissante comme le Dreamcast /PS2.Mais c'est plus une question d'algorithme que du comptage de cycles (ça c'est bon pour la SNES)
Quand tu veux faire de la transformation de perspective en temps réel , un gain de 5 cycles peut te donner des milliers de triangles supplémentaires
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Invité- Invité
Re: Acorn archimedes 3010
Je ne savais même pas qu'il y avait eu des consoles après la SNES ![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Tryphon- Docteur *
-
Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Acorn archimedes 3010
Kannagi a écrit:Je suis totalement d'accord avec ça , c'est la premier optimisation à faire avant de se concentrer sur la génération du code produit :pLa principale optimisation à faire, c'est dans les algorithmes utilisésLe comptage de cycles, je le fais partout même sur des consoles puissante comme le Dreamcast /PS2.Mais c'est plus une question d'algorithme que du comptage de cycles (ça c'est bon pour la SNES)
Quand tu veux faire de la transformation de perspective en temps réel , un gain de 5 cycles peut te donner des milliers de triangles supplémentaires
Tout comme sur Archimedes quand tu veux afficher un sprite : quelques cycles gagnés par série horizontale de pixels composant ton sprite, au final tu peux afficher entre 4 et 8 fois voire bien + de sprites à l'écran.
Pas grand'chose * bcp ça finit par faire.
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Re: Acorn archimedes 3010
C'est le cas de toute les machines où tu vas coder quand tu as beaucoup d'élément a gérer quelque cycles est important.
Mais l'archimede aura une optimisation plus facile , vu que tout fait 1 cycle , sauf les accès mémoire (qui doivent faire sûrement entre 2-3 cycles).
Il n'y a pas comme le 6502 ou le M68000 où tu vas devoir privilégier certaine instructions (parce qu'elles ont un taux de cycle bas) , ou sur des consoles PS1/Saturn et les suivantes où l'ordre des instructions détermine la vitesse des instruction ce qui cause que rajouter quelque instruction sur ton code t'oblige à le réécrire de zero quelque fois
Mon conseil pour optimiser (et savoir si on peut aller plus loin ) c'est de connaître le max théorique.
On peut calculer le max théorique du taux de fillrate de l'archimede , sachant qu'il est de 4MIPS (pour le 8 MHz) , tu as du coup un fillrate de 8 Mpixels/s (chaque instruction peut écrire sur 2 octets vu que c'est la taille du bus de données) mais dans les fait t'aura forcément moins si on compte les load/store + calcul , techniquement je le verrai à 3-4 Mpixels/s
Je parle ici pour 256 couleurs ,c'est le double pour du 16 couleurs.
L'Amiga est de 4 Mpixels/s et la MD/SNES de 13 Mpixels/s par seconde![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Mais l'archimede aura une optimisation plus facile , vu que tout fait 1 cycle , sauf les accès mémoire (qui doivent faire sûrement entre 2-3 cycles).
Il n'y a pas comme le 6502 ou le M68000 où tu vas devoir privilégier certaine instructions (parce qu'elles ont un taux de cycle bas) , ou sur des consoles PS1/Saturn et les suivantes où l'ordre des instructions détermine la vitesse des instruction ce qui cause que rajouter quelque instruction sur ton code t'oblige à le réécrire de zero quelque fois
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
Mon conseil pour optimiser (et savoir si on peut aller plus loin ) c'est de connaître le max théorique.
On peut calculer le max théorique du taux de fillrate de l'archimede , sachant qu'il est de 4MIPS (pour le 8 MHz) , tu as du coup un fillrate de 8 Mpixels/s (chaque instruction peut écrire sur 2 octets vu que c'est la taille du bus de données) mais dans les fait t'aura forcément moins si on compte les load/store + calcul , techniquement je le verrai à 3-4 Mpixels/s
Je parle ici pour 256 couleurs ,c'est le double pour du 16 couleurs.
L'Amiga est de 4 Mpixels/s et la MD/SNES de 13 Mpixels/s par seconde
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Dernière édition par Kannagi le Mar 11 Aoû 2020 - 10:57, édité 5 fois
Invité- Invité
Re: Acorn archimedes 3010
Je ne comprends pas cette histoire de fillrate : à quoi correspondent ces nombres et en quoi sont-ils pertinents ?
Tryphon- Docteur *
-
Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Acorn archimedes 3010
On va prendre la MD comme exemple alors
Mais le fillrate (remplissage) est important que ça soit en 2D ou 3D parce qu'il est le principal bottleneck (goulot d'étranglement).
Sur MD , tu peux remplir 3 fois l'écran , c'est une réso de 320x224 , donc tu peux dessiner 320x224*3 (2 BG + 80 sprite qui peuvent remplir l'écran).
Et si tu veux connaityre le nombre de pixel/s que fait la MD tu fait donc 320x224*3*60![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Si tu voudrais faire pareil sur micro , ça serait pas possible , parce que dessiner autant à l'écran avec les co-proc ou le CPU ne peuvent pas le faire (ou alors tu vise pas le 60 fps).
La 3D c'est un peu pareil , tu as souvent sur certaine machine , plus de calcul de triangle que de draw qui est capable de suivre (techniquement la gamecube qui peut calculer plus de triangle que la PS2 et la XBOX , mais le GPU en dessine juste 2 fois moins que les deux autres).
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
Mais le fillrate (remplissage) est important que ça soit en 2D ou 3D parce qu'il est le principal bottleneck (goulot d'étranglement).
Sur MD , tu peux remplir 3 fois l'écran , c'est une réso de 320x224 , donc tu peux dessiner 320x224*3 (2 BG + 80 sprite qui peuvent remplir l'écran).
Et si tu veux connaityre le nombre de pixel/s que fait la MD tu fait donc 320x224*3*60
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Si tu voudrais faire pareil sur micro , ça serait pas possible , parce que dessiner autant à l'écran avec les co-proc ou le CPU ne peuvent pas le faire (ou alors tu vise pas le 60 fps).
La 3D c'est un peu pareil , tu as souvent sur certaine machine , plus de calcul de triangle que de draw qui est capable de suivre (techniquement la gamecube qui peut calculer plus de triangle que la PS2 et la XBOX , mais le GPU en dessine juste 2 fois moins que les deux autres).
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:C'est le cas de toute les machines où tu vas coder quand tu as beaucoup d'élément a gérer quelque cycles est important.
Mais l'archimede aura une optimisation plus facile , vu que tout fait 1 cycle , sauf les accès mémoire (qui doivent faire sûrement entre 2-3 cycles).
Il n'y a pas comme le 6502 ou le M68000 où tu vas devoir privilégier certaine instructions (parce qu'elles ont un taux de cycle bas) , ou sur des consoles PS1/Saturn et les suivantes où l'ordre des instructions détermine la vitesse des instruction ce qui cause que rajouter quelque instruction sur ton code t'oblige à le réécrire de zero quelque fois![]()
Mon conseil pour optimiser (et savoir si on peut aller plus loin ) c'est de connaître le max théorique.
On peut calculer le max théorique du taux de fillrate de l'archimede , sachant qu'il est de 4MIPS (pour le 8 MHz) , tu as du coup un fillrate de 8 Mpixels/s (chaque instruction peut écrire sur 2 octets vu que c'est la taille du bus de données) mais dans les fait t'aura forcément moins si on compte les load/store + calcul , techniquement je le verrai à 3-4 Mpixels/s
Je parle ici pour 256 couleurs ,c'est le double pour du 16 couleurs.
L'Amiga est de 4 Mpixels/s et la MD/SNES de 13 Mpixels/s par seconde
Et non, sur Archie les accès mémoire par paquets, c'est 4 cycles pour le 1er registre, et seulement 1 (oui : UN) cycle pour chaque registre supplémentaire.
Et ...
... comme tu as 16 registres ( R0 à R15 )
... que R15 c'est le PC, donc il t'en reste 15 utilisables pour tes routines de sprites
... qu'il te faut 1 registre pointant sur tes pixels, et 1 registre pointant là où tu voudras écrire ton sprite
... ça te laisse 13 registres, de 32 bits
... en mode 256 couleurs ou 1 pixel est représenté sur 8 bits, tu peux donc utiliser 13 registres contenant chacun 4 octets, ça fait donc 52 pixels, qui vont te prendre
4 cycles pour ton 1er registre puis
12 x 1 cycle pour les 12 autres, donc 12 cycles
soit au total 16 cycles pour mettre dans les registres 52 pixels
et autant quand tu vas stocker le contenu de tes registres en mémoire
Au final ça fait 16 x 2 = 32 cycles pour lire et afficher 52 pixels à l'écran, soit une moyenne de 1,6 cycle par pixel
Typiquement
si R0 contient l'adresse source des pixels
si R14 contient l'adresse mémoire destination
tu fais ton chargement puis ton écriture avec
LDMIA R0!,{R1-R13}
STMIA R14!,[R1-R13}
Le '!' fait automatiquement l'incrémentation de l'adresse, et ça coûte 0 cycle
Ceux qui connaissent me diront 'Mais tu utilises R13 habituellement retenu pour être pointeur de pile, et R14 qui contient ton adresse de retour de sous-routine'
ce à quoi je répondrai que sauvegarder R13 et R14 avant ce n'est pas fait pour les chiens.
Tu les recharges à la fin du tracé de ton sprite.
Ca c'est vrai quand tu vas écrire des paquets de 4 octets sur des adresses multiples de 4 (typiquement les bandes de parallax dans SOTB, une image de fond, en décor pour un jeu où une démo).
Ca devient moins bon quand c'est un sprite, puisque ses segments horizontaux de pixels ne vont :
1/ Pas être de tailles multiples de 4
1/ Pas être naturellement toujours écrits en mémoire sur des adresses multiples de 4 ( les instructions de transferts rapides travaillent sur adresse source ou destination multiples de 4 )
et c'est là où des routines optimisées vont faire toute la différence :
- pas de masque, pas de chargement du 'fond', pas de trouage, de ORR etc ... c'est lamentablement lent
- usage de sprites compilés qui évite ci-dessus et vont quand nécessaire ( 3 fois sur 4 on va dire ) charger ce qui est immédiatement à gauche et à droite du sprite pour compléter les bords gauche et droit du sprite à concurrence de 4 pixels 'remplissant 'entièrement des adresses multiples de 4, et ainsi maximiser les écritures multiples par paquet de 4 pixels, sur adresses multiples de 4
Le rapport de vitesse entre la méthode crasse et le sprite compilé c'est minimum 1 à 4
La méthode la + crasse (enfin presque, on peut encore faire pire, genre manipulation pixel par pixel) c'est celle de Pacmania qui shifte les tiles de fond à la volée.
Et malgré tout ça le jeu reste en 50 fps, tellement l'Archie est puissant.
J'imagine qu'il shifte aussi les sprites, leurs masques, charge le fond, troue le fond avec le masque, ORR le sprite avec le fond troué, et balance le résultat à l'écran.
Ca donne envie de vomir rien que d'y penser, quel gâchis.
Ca fera 10 € pour le cours et vous me copierez 1000 fois 'L'Archimedes est une bécane de ouf au potentiel inutilisé en 2D'
Dernière édition par ArchieForEver le Mar 11 Aoû 2020 - 12:39, édité 4 fois (Raison : routines optimisées + j'veux des sous + fôtes grammaire)
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Re: Acorn archimedes 3010
Kannagi a écrit:On va prendre la MD comme exemple alors![]()
Mais le fillrate (remplissage) est important que ça soit en 2D ou 3D parce qu'il est le principal bottleneck (goulot d'étranglement).
Sur MD , tu peux remplir 3 fois l'écran , c'est une réso de 320x224 , donc tu peux dessiner 320x224*3 (2 BG + 80 sprite qui peuvent remplir l'écran).
Et si tu veux connaityre le nombre de pixel/s que fait la MD tu fait donc 320x224*3*60
Si tu voudrais faire pareil sur micro , ça serait pas possible , parce que dessiner autant à l'écran avec les co-proc ou le CPU ne peuvent pas le faire (ou alors tu vise pas le 60 fps).
La 3D c'est un peu pareil , tu as souvent sur certaine machine , plus de calcul de triangle que de draw qui est capable de suivre (techniquement la gamecube qui peut calculer plus de triangle que la PS2 et la XBOX , mais le GPU en dessine juste 2 fois moins que les deux autres).
En mode 16 couleurs et en 320x224 je pense que l'Archie écrit 3 fois l'écran par VBL, ou alors pas loin, vraiment, vraiment, pas loin.
Je répète à nouveau que dans les idées fondamentales de la conception de l'ARM et de son contrôleur mémoire, le MEMC, il y avait le fait de maximiser l'usage de la bande passante des mémoires DRAM de l'époque.
Regarde ma démo des bouboules c'est du 320 x 256 16 couleurs.
Par VBL :
- je recopie tout l'écran pour le fond ( donc 320 x 256 pixels )
- j'affiche 80 bouboules 32x32 (en ayant à lire le décor pour le faire, comme expliqué + haut ) et ça couvre tout l'écran 320 x 256
et il me reste encore plein de cycles, alors que je joue un MOD ce qui prend 10% à 12,5% du temps CPU dispo par VBL.
Et là on parle bien d'une machine à 8 Mhz, 4,5 MIPS.
Certes, mode graphique 50 Hz, pas 60 Hz comme la MD. ( Superbe bécane, rien à voir avec les copros tout limités de l'Amiga. Oui, oui j'ai bien eu un Amiga et quand j'ai eu la MD j'ai quasi arrêté de jouer sur Amiga, aucun intérêt face à ce qui se faisait sur MD, vu que c'était les shoot em up qui me plaisaient. L'Amiga m'a servi à regarder des démos, et écouter des MODs, jusqu'à ce que j'ai un PC avec une Gravis, où je suis passé aux S3M et l'Amiga 500 m'a définitivement fait totale pitié, ayant de surcroît expérimenté la programmation sur Archie, et compris à quel point cette machine était sous exploitée en 2D. Le 1200 je le trouve assez cool, lui ).
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Re: Acorn archimedes 3010
Je vais pas répondre point par point
Mais merci je connais sûrement l'ARM2 mieux que toi mais effectivement pour :
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
ce qui fait que cela fait plus de 1 cycles (normalement 2) , mais apparemment cela fait plus sur l'Archie (sauf si on parle du 32 bits)
Et du coup cela baisse le fillrate![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
un load/store fait 4 cycle chaqu'un tu dis ? donc on a 8 cycles au total![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Sur 256 couleurs , 1 pixel = 1 octet donc là tu écrit sur 4 octet à l'écran , donc on est plus sur du 4 pixel/8 cycles
Ou 8 pixel/8 cycles sur 16 couleurs.
Pour te dire que ces MIPS ne veulent rien dire quand on parle de rendu, compare là à la NG , c'est plus flagrant
La Neo Geo c'est du 2 MIPS , mais t'arrivera jamais afficher 1536 pixel/ligne avec le CPU seul
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Mais merci je connais sûrement l'ARM2 mieux que toi mais effectivement pour :
La vitesse du CPU est secondaire sur l'affichage des sprite (même si elle est non nélgigable) , c'est surtout la bande passante qu'il faut regarderRegarde ma démo des bouboules c'est du 320 x 256 16 couleurs.
Par VBL :
- je recopie tout l'écran pour le fond ( donc 320 x 256 pixels )
- j'affiche 80 bouboules 32x32 (en ayant à lire le décor pour le faire, comme expliqué + haut ) et ça couvre tout l'écran 320 x 256
et il me reste encore plein de cycles, alors que je joue un MOD ce qui prend 10% à 12,5% du temps CPU dispo par VBL.
Et là on parle bien d'une machine à 8 Mhz, 4,5 MIPS.
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Cela doit être alors une version modifié de l'ARM2 , parce que l'ARM2 fait tout sur un cycle (même les accès RAM) , le seul truc qui fait les accès RAM sont plus "lente" et un conflit de bus entre les data de données et des instructions , du coup l'ARM2 bloque les instructions le temps de lire les données.Et non, sur Archie les accès mémoire par paquets, c'est 4 cycles pour le 1er registre, et seulement 1 (oui : UN) cycle pour chaque registre supplémentaire.
ce qui fait que cela fait plus de 1 cycles (normalement 2) , mais apparemment cela fait plus sur l'Archie (sauf si on parle du 32 bits)
Et du coup cela baisse le fillrate
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Justement si tu fait un load /store ,t'es pas à 1,6 pixel cycle
Au final ça fait 16 x 2 = 32 cycles pour lire et afficher 52 pixels à l'écran, soit une moyenne de 1,6 cycle par pixel
Typiquement
si R0 contient l'adresse source des pixels
si R14 contient l'adresse mémoire destination
tu fais ton chargement puis ton écriture avec
LDMIA R0!,{R1-R13}
STMIA R14!,[R1-R13}
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
un load/store fait 4 cycle chaqu'un tu dis ? donc on a 8 cycles au total
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Sur 256 couleurs , 1 pixel = 1 octet donc là tu écrit sur 4 octet à l'écran , donc on est plus sur du 4 pixel/8 cycles
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
Ou 8 pixel/8 cycles sur 16 couleurs.
Je ne dis pas le contraire , je dis que elle aura comme toute machine des limites , mais si tu la compare à une MD ou une SNES, elle sera loin de celle ci.Ca fera 10 € pour le cours et vous me copierez 1000 fois 'L'Archimedes est une bécane de ouf au potentiel inutilisé en 2D'
Pour te dire que ces MIPS ne veulent rien dire quand on parle de rendu, compare là à la NG , c'est plus flagrant
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
La Neo Geo c'est du 2 MIPS , mais t'arrivera jamais afficher 1536 pixel/ligne avec le CPU seul
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:Je vais pas répondre point par point![]()
Mais merci je connais sûrement l'ARM2 mieux que toi mais effectivement pour :La vitesse du CPU est secondaire sur l'affichage des sprite (même si elle est non nélgigable) , c'est surtout la bande passante qu'il faut regarderRegarde ma démo des bouboules c'est du 320 x 256 16 couleurs.
Par VBL :
- je recopie tout l'écran pour le fond ( donc 320 x 256 pixels )
- j'affiche 80 bouboules 32x32 (en ayant à lire le décor pour le faire, comme expliqué + haut ) et ça couvre tout l'écran 320 x 256
et il me reste encore plein de cycles, alors que je joue un MOD ce qui prend 10% à 12,5% du temps CPU dispo par VBL.
Et là on parle bien d'une machine à 8 Mhz, 4,5 MIPS.Cela doit être alors une version modifié de l'ARM2 , parce que l'ARM2 fait tout sur un cycle (même les accès RAM) , le seul truc qui fait les accès RAM sont plus "lente" et un conflit de bus entre les data de données et des instructions , du coup l'ARM2 bloque les instructions le temps de lire les données.Et non, sur Archie les accès mémoire par paquets, c'est 4 cycles pour le 1er registre, et seulement 1 (oui : UN) cycle pour chaque registre supplémentaire.
ce qui fait que cela fait plus de 1 cycles (normalement 2) , mais apparemment cela fait plus sur l'Archie (sauf si on parle du 32 bits)
Et du coup cela baisse le fillrateJustement si tu fait un load /store ,t'es pas à 1,6 pixel cycle
Au final ça fait 16 x 2 = 32 cycles pour lire et afficher 52 pixels à l'écran, soit une moyenne de 1,6 cycle par pixel
Typiquement
si R0 contient l'adresse source des pixels
si R14 contient l'adresse mémoire destination
tu fais ton chargement puis ton écriture avec
LDMIA R0!,{R1-R13}
STMIA R14!,[R1-R13}![]()
un load/store fait 4 cycle chaqu'un tu dis ? donc on a 8 cycles au total
Sur 256 couleurs , 1 pixel = 1 octet donc là tu écrit sur 4 octet à l'écran , donc on est plus sur du 4 pixel/8 cycles![]()
Ou 8 pixel/8 cycles sur 16 couleurs.Je ne dis pas le contraire , je dis que elle aura comme toute machine des limites , mais si tu la compare à une MD ou une SNES, elle sera loin de celle ci.Ca fera 10 € pour le cours et vous me copierez 1000 fois 'L'Archimedes est une bécane de ouf au potentiel inutilisé en 2D'
Pour te dire que ces MIPS ne veulent rien dire quand on parle de rendu, compare là à la NG , c'est plus flagrant![]()
La Neo Geo c'est du 2 MIPS , mais t'arrivera jamais afficher 1536 pixel/ligne avec le CPU seul![]()
non, ce que j'ai dit est parfaitement exact, et tu peux vérifier dans la doc de VLSI qui est en ligne.
Je le reposte ici :
Et non, sur Archie les accès mémoire par paquets, c'est 4 cycles pour le 1er registre, et seulement 1 (oui : UN) cycle pour chaque registre supplémentaire.
Et ...
... comme tu as 16 registres ( R0 à R15 )
... que R15 c'est le PC, donc il t'en reste 15 utilisables pour tes routines de sprites
... qu'il te faut 1 registre pointant sur tes pixels, et 1 registre pointant là où tu voudras écrire ton sprite
... ça te laisse 13 registres, de 32 bits
... en mode 256 couleurs ou 1 pixel est représenté sur 8 bits, tu peux donc utiliser 13 registres contenant chacun 4 octets, ça fait donc 52 pixels, qui vont te prendre
4 cycles pour ton 1er registre puis
12 x 1 cycle pour les 12 autres, donc 12 cycles
soit au total 16 cycles pour mettre dans les registres 52 pixels
et autant quand tu vas stocker le contenu de tes registres en mémoire
Au final ça fait 16 x 2 = 32 cycles pour lire et afficher 52 pixels à l'écran, soit une moyenne de 1,6 cycle par pixel
Typiquement
si R0 contient l'adresse source des pixels
si R14 contient l'adresse mémoire destination
tu fais ton chargement puis ton écriture avec
LDMIA R0!,{R1-R13}
STMIA R14!,[R1-R13}
Le '!' fait automatiquement l'incrémentation de l'adresse, et ça coûte 0 cycle
Ceux qui connaissent me diront 'Mais tu utilises R13 habituellement retenu pour être pointeur de pile, et R14 qui contient ton adresse de retour de sous-routine'
ce à quoi je répondrai que sauvegarder R13 et R14 avant ce n'est pas fait pour les chiens.
Tu les recharges à la fin du tracé de ton sprite.
Je vais rajouter des smileys, ça fera cool :
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
![MDR](/users/3412/15/69/90/smiles/3621806995.gif)
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
![Very Happy](https://2img.net/i/fa/i/smiles/icon_biggrin.png)
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
![Cool](https://2img.net/i/fa/i/smiles/icon_cool.gif)
![MDR](/users/3412/15/69/90/smiles/3621806995.gif)
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Dernière édition par ArchieForEver le Mar 11 Aoû 2020 - 13:16, édité 1 fois
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Re: Acorn archimedes 3010
Inutile de me copier ton pavé a chaque fois ,je sais que l'ARM2 à 16 registres merci
Et encore heureux qu'il a 16 registres ,c'est le minimun syndical pour les processeurs RISC (qui ne peuvent pas fonctionné avec peu de registre comme le z80,le x86 ou le 65xx).
D’ailleurs les ARM suivant sont passé à 32 registres![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Mais tu explique très mal , je te le dis au cas où![Acorn archimedes 3010 - Page 5 435303](/users/3412/15/69/90/smiles/435303.gif)
Mais je comprend où tu veux en venir donc oui tu peux te rapprocher des chiffres théorique de la bande passante grâce aux instructions de LDMIA/STMIA.
L'explication brouillon du reste n'était pas nécessaire![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
Et encore heureux qu'il a 16 registres ,c'est le minimun syndical pour les processeurs RISC (qui ne peuvent pas fonctionné avec peu de registre comme le z80,le x86 ou le 65xx).
D’ailleurs les ARM suivant sont passé à 32 registres
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Mais tu explique très mal , je te le dis au cas où
![Acorn archimedes 3010 - Page 5 435303](/users/3412/15/69/90/smiles/435303.gif)
Mais je comprend où tu veux en venir donc oui tu peux te rapprocher des chiffres théorique de la bande passante grâce aux instructions de LDMIA/STMIA.
L'explication brouillon du reste n'était pas nécessaire
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:Inutile de me copier ton pavé a chaque fois ,je sais que l'ARM2 à 16 registres merci ,![]()
Et encore heureux qu'il a 16 registres ,c'est le minimun syndical pour les processeurs RISC (qui ne peuvent pas fonctionne avec peu de registre comme le z80,le x86 ou le 65xx).
D’ailleurs les ARM suivant sont passé à 32 registres
Mais tu explique très mal , je te le dis au cas où
Mais je comprend où tu veux en venir donc oui tu peux te rapprocher des chiffres théorique de 8/16 Mpixel/s du coup grâce aux instruction de LDMIA/STMIA.
Ah bon j'explique mal ?
Tu viens de comprendre que tu as posté n'importe quoi surtout : aucun de tes commentaires n'est valide.
Aucun.
Dommage.
Perdu.
Mets des pièces et essaie encore.
![Very Happy](https://2img.net/i/fa/i/smiles/icon_biggrin.png)
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
![MDR](/users/3412/15/69/90/smiles/3621806995.gif)
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
![Cool](https://2img.net/i/fa/i/smiles/icon_cool.gif)
![MDR](/users/3412/15/69/90/smiles/3621806995.gif)
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Re: Acorn archimedes 3010
J'ai du relire la doc de l'ARM2 de larchie pour savoir où tu voulais en venir
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
Ce que je dis ne vient que de ce wiki donc sauf si tu considère que cet article est faux.
Mais il n'est pas exhaustive.
Tu peux voir sur ce wiki toute les instructions ARMv1 et v2 :
https://en.wikichip.org/wiki/arm/armv1
https://en.wikichip.org/wiki/arm/armv2
Donc que LDMIA/STMIA permet de faire un load/store par paquet n'est pas expliqué.
Mais dire que le fonctionnement de LDR/STR est faux , c'est que tu connais mal l'ARM![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
![Acorn archimedes 3010 - Page 5 435303](/users/3412/15/69/90/smiles/435303.gif)
C'est vraiment mal connaître l'architecture de l'ARM2 alors, je te conseille de lire ceci :Tu viens de comprendre que tu as posté n'importe quoi surtout : aucun de tes commentaires n'est valide.
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
Ce que je dis ne vient que de ce wiki donc sauf si tu considère que cet article est faux.
Mais il n'est pas exhaustive.
Tu peux voir sur ce wiki toute les instructions ARMv1 et v2 :
https://en.wikichip.org/wiki/arm/armv1
https://en.wikichip.org/wiki/arm/armv2
Donc que LDMIA/STMIA permet de faire un load/store par paquet n'est pas expliqué.
Mais dire que le fonctionnement de LDR/STR est faux , c'est que tu connais mal l'ARM
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
Dernière édition par Kannagi le Mar 11 Aoû 2020 - 13:33, édité 1 fois
Invité- Invité
Re: Acorn archimedes 3010
essayez de vous mettre d'accord en toute amitié si vous etes fans tous les deux de l'architecture ARM :)
_______________________________________________________
![Acorn archimedes 3010 - Page 5 Americ10](https://i.servimg.com/u/f11/11/03/61/79/americ10.gif)
Re: Acorn archimedes 3010
Kannagi a écrit:On va prendre la MD comme exemple alors![]()
C'est un excellent exemple
![Very Happy](https://2img.net/i/fa/i/smiles/icon_biggrin.png)
Mais le fillrate (remplissage) est important que ça soit en 2D ou 3D parce qu'il est le principal bottleneck (goulot d'étranglement).
Sur MD , tu peux remplir 3 fois l'écran , c'est une réso de 320x224 , donc tu peux dessiner 320x224*3 (2 BG + 80 sprite qui peuvent remplir l'écran).
Et si tu veux connaityre le nombre de pixel/s que fait la MD tu fait donc 320x224*3*60
Si tu voudrais faire pareil sur micro , ça serait pas possible , parce que dessiner autant à l'écran avec les co-proc ou le CPU ne peuvent pas le faire (ou alors tu vise pas le 60 fps).
La 3D c'est un peu pareil , tu as souvent sur certaine machine , plus de calcul de triangle que de draw qui est capable de suivre (techniquement la gamecube qui peut calculer plus de triangle que la PS2 et la XBOX , mais le GPU en dessine juste 2 fois moins que les deux autres).
Je vois, mais je conçois quand même pas la pertinence de l'information pour le développeur, ni en quoi c'est le principal goulot d'étranglement.
Typiquement, la MD, tu ne peux pas modifier intégralement au CPU les 2 BG + les sprites en une frame (au mieux quelques ko).
De même, sur micro, tu vas pas organiser ton affichage en 2 BG complet, tu vas plutôt utiliser des algos pour savoir ce qu'il faut rafraîchir ou pas, et minimiser les réécritures.
Du coup :
* pris séparément chaque nombre me semble inutile (le goulot d'étranglement me semble plutôt être la puissance CPU pour gérer les différents objets, et la vitesse de transfert en VRAM)
* les comparer entre eux me semble non pertinent (vu que tu n'utilises pas du tout les mêmes méthodes pour gérer l'affichage)
D'ailleurs je ne me suis jamais posé la question de leurs valeurs quand je développe sur une machine ou une autre (j'ai un peu tâté de l'Amiga par le passé)
![saispas](/users/3412/15/69/90/smiles/3135148816.gif)
C'est certainement différent en 3D.
(ma remarque n'est pas agressive, je comprends juste pas en quoi ce nombre est important et ce qu'il implique pour le dev)
Tryphon- Docteur *
-
Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Acorn archimedes 3010
J'ai pas dit que c'était une comparaison pertinente (vu lesn ombreux effet hard des consoles ) , ce qui peut être intéressant c'est juste de se dire "est qu'on peut faire comme la MD donc 2 BG + 80 Sprite" qui rempli l'écran.
Et remplir l’écran dépend de la bande passante, alors sur MD , c'est le VDP qui s'en charge tu n'as pas à t'inquiéter mais sur micro (voir même sur PC de l'époque) , c'est intéressant de savoir ce que peut faire la machine au maximum (on regardant rien que la bande passante).
C'est un goulot d'étranglement parce que les calculs du CPU pour définir un BG ou des sprites sont relativement rapide , par contre les dessiners prend plus de temps.
Donc tu as une grosse dif entre les calcul de sprite/BG (lesp ositionner , les tiles utilisé ) et combien tu peux en dessiner![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Et remplir l’écran dépend de la bande passante, alors sur MD , c'est le VDP qui s'en charge tu n'as pas à t'inquiéter mais sur micro (voir même sur PC de l'époque) , c'est intéressant de savoir ce que peut faire la machine au maximum (on regardant rien que la bande passante).
C'est un goulot d'étranglement parce que les calculs du CPU pour définir un BG ou des sprites sont relativement rapide , par contre les dessiners prend plus de temps.
Donc tu as une grosse dif entre les calcul de sprite/BG (lesp ositionner , les tiles utilisé ) et combien tu peux en dessiner
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:J'ai pas dit que c'était une comparaison pertinente (vu lesn ombreux effet hard des consoles ) , ce qui peut être intéressant c'est juste de se dire "est qu'on peut faire comme la MD donc 2 BG + 80 Sprite" qui rempli l'écran.
Je comprends mieux, je n'avais pas compris qu'on souhaitait répondre à cette question.
C'est juste que pour moi elle n'a tellement aucun sens
![Razz](https://2img.net/i/fa/i/smiles/icon_razz.gif)
Tryphon- Docteur *
-
Nombre de messages : 26166
Age : 47
Localisation : Un peu plus à l'Ouest
Date d'inscription : 23/07/2016
Re: Acorn archimedes 3010
C'est un troll ?Tryphon a écrit:
Autant faire comme les devs SNES : des jeux avec moins de sprites, mais on compense autrement.
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
Non mais la SNES est intéressant sur ce point là , le GPU de la SNES est vraiment trop puissant pour le CPU (je l'avoue ) , c'est tout l'inverse des autres machines (et des micro/PC) où la limite était bien souvent atteinte sur ce qu'on peut dessiner à l'écran.
Surtout pour le mode7 est très gourmand en calcul , pour ça que sur Super Mario Kart ils ont rajouté une puce pour gérer les calcul du mode 7
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:J'ai du relire la doc de l'ARM2 de larchie pour savoir où tu voulais en venir
C'est vraiment mal connaître l'architecture de l'ARM2 alors, je te conseille de lire ceci :Tu viens de comprendre que tu as posté n'importe quoi surtout : aucun de tes commentaires n'est valide.
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
Ce que je dis ne vient que de ce wiki donc sauf si tu considère que cet article est faux.
Mais il n'est pas exhaustive.
Tu peux voir sur ce wiki toute les instructions ARMv1 et v2 :
https://en.wikichip.org/wiki/arm/armv1
https://en.wikichip.org/wiki/arm/armv2
Donc que LDMIA/STMIA permet de faire un load/store par paquet n'est pas expliqué.
Mais dire que le fonctionnement de LDR/STR est faux , c'est que tu connais mal l'ARM
Doc VLSI page 2-20 [url=http://home.marutan.net/arcemdocs/datasheets/ARM-1bpp 300 2of2.pdf]http://home.marutan.net/arcemdocs/datasheets/ARM-1bpp%20300%202of2.pdf[/url]
Les chiffres sont encore meilleurs, LDM et STM coûte 1 cycle de moins, chacun
Load Multiple : ns + 1 N +1 I
Store multiple (n-1)S + 2N
-
Dans celle de VLSI ultérieure, ISBN 0-13-781618-9 qui correspond aux systèmes avec MEMC1A, page 2-11 :
LDM (n+1) S + 1N
STM (n-1)S + 2N
voir 1er lien pour comprendre ce que signifie les lettres.
J'ai raison et tu te plantes.
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Re: Acorn archimedes 3010
Parce que ça montre la flexibilité d'un blitter par rapport au hard borné d'une console .(typiquement, je trouve que le Supa Zazai Da du Doc est un très bon exemple de quelque chose qui tourne très bien sur un STE, et que je vois pas trop comment reproduire simplement sur une MD par exemple. Et le jeu est bon, de ce que j'ai compris).
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:J'ai du relire la doc de l'ARM2 de larchie pour savoir où tu voulais en venir
C'est vraiment mal connaître l'architecture de l'ARM2 alors, je te conseille de lire ceci :Tu viens de comprendre que tu as posté n'importe quoi surtout : aucun de tes commentaires n'est valide.
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
Ce que je dis ne vient que de ce wiki donc sauf si tu considère que cet article est faux.
Mais il n'est pas exhaustive.
Tu peux voir sur ce wiki toute les instructions ARMv1 et v2 :
https://en.wikichip.org/wiki/arm/armv1
https://en.wikichip.org/wiki/arm/armv2
Donc que LDMIA/STMIA permet de faire un load/store par paquet n'est pas expliqué.
Mais dire que le fonctionnement de LDR/STR est faux , c'est que tu connais mal l'ARM
C'est ton, problème si tu prends des sites qui n'expliquent pas que LDMIA et STMIA marchent par paquets, pas le mien.
LDR / STR je connais bien mieux que toi, et ce n'est pas ce dont je te parlais, puisque je parlais d'instructions de transferts par paquets, LDM / STM et toi tu me donnes les chiffres pour transferts 'simples' LDR / STR : du coup
1/ Tu es hors sujet
2/ Tu ne maîtrises pas le jeu d'instructions de l'ARM2, puisque tu ne sais pas comment fonctionnent les familles d'instructions LDM et STM et je dois te l'expliquer, te le rappeler de nouveau, avec exemple et comptages des cycles à l'appui, ce qui est, au contraire de tes dires, hautement intelligible, à moins d'être limité intellectuellement, et / ou de ne pas savoir lire ( normalement, si on est allé + loin qu'une 3è, la lecture et compréhension d'un court texte explicatif sont maîtrisées )
3/ Au final tu te ridiculises en exposant ta méconnaissance du sujet ; et de surcroît tu es arrogant en pensant que tu vas m'apprendre quoi que ce soit, et en affirmant à de multiples reprises que je connaitrais mal l'ARM, alors que c'est bien toi qui pédales dans la choucroute, prouvé par A+B
Qu'est ce qu'on rigole ici
![MDR](/users/3412/15/69/90/smiles/3621806995.gif)
Au suivant.
Y a un volontaire pour jouer au + malin ?
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Re: Acorn archimedes 3010
Non non j'ai bien raison sur ce que tu dis , le taux de cycle n'a aucun sens sur un processeur ARM ou les suivants , c'est un processeur avec une pipeline et cette doc est assez incomplète , elle n'indique pas la pipeline des instructions.
Techniquement un ARM fait tout sur 3 cycles (je suppose il y'a rarement une explication exhaustive de la pipeline) et il va paralléliser certaine instructions. (et donc réduire tout à 1 cycle au mieux).
Et comme je l'ai dit avant LDR/STR ne pourra jamais faire un cycle , parce qu'il y a une contrainte physique qui l’empêche (le bus) qui entre en conflit avec les autres instructions exécuter en //.
Le taux de cycle est une question de contexte sur ce genre de proco.
Techniquement un ARM fait tout sur 3 cycles (je suppose il y'a rarement une explication exhaustive de la pipeline) et il va paralléliser certaine instructions. (et donc réduire tout à 1 cycle au mieux).
Et comme je l'ai dit avant LDR/STR ne pourra jamais faire un cycle , parce qu'il y a une contrainte physique qui l’empêche (le bus) qui entre en conflit avec les autres instructions exécuter en //.
Le taux de cycle est une question de contexte sur ce genre de proco.
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:Non non j'ai bien raison sur ce que tu dis , le taux de cycle n'a aucun sens sur un processeur ARM ou les suivants , c'est un processeur avec une pipeline et cette doc est assez incomplète , elle n'indique pas la pipeline des instructions.
Techniquement un ARM fait tout sur 3 cycles et il va paralléliser certaine instructions. (et donc réduire tout à 1 cycle au mieux).
Et comme je l'ai dit avant LDR/STR ne pourra jamais faire un cycle , parce qu'il y a une contrainte physique qui l’empêche (le bus) qui entre en conflit avec les autres instruction exécuter en //.
Le taux de cyle est une question de contexte sur ce genre de proco.
Je ne t'ai jamais parlé de LDR ou STR.
Je t'ai parlé de LDM ou STM, alors utiliser les timings de LDR et STR pour contredire ce que j'ai écrit et qui concerne LDM et STM : c'est ton problème de dissonance cognitive, et pas le mien.
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Re: Acorn archimedes 3010
Apprend à lire ce qu'est une dissonance cognitive ,ce qui n'est pas le cas ici
Et j'ai bien dit que oui je n'avais pas compris que tu parlais de LDM/SDM ton explication n'était pas clair , on plus d’être très poli sur la forme
Et j'ai ensuite dit que oui avec ces instruction tu peux atteindre une bande passante correct sur la RAM , et tu as continué en disant que je disais n'importe quoi ce qui n'est pas le cas (rien ce que j'ai dit était faux ,au mieux non exhaustive), vu que je parlais de load/store normal dans mon explication et j'ai basé mes calculs dessus (ce qui semble assez évident si tu avais bien lu).
ensuite on parle d'un processeur ARM et donc j'ai rajouté des détails technique sur la pipeline des instructions , le bus , et les processeurs RISC , mais c'est pas un sujet que tu connais apparemment![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
![Rolling Eyes](https://2img.net/i/fa/i/smiles/icon_rolleyes.gif)
Et j'ai bien dit que oui je n'avais pas compris que tu parlais de LDM/SDM ton explication n'était pas clair , on plus d’être très poli sur la forme
![Mr. Green](https://2img.net/i/fa/i/smiles/icon_mrgreen.png)
Et j'ai ensuite dit que oui avec ces instruction tu peux atteindre une bande passante correct sur la RAM , et tu as continué en disant que je disais n'importe quoi ce qui n'est pas le cas (rien ce que j'ai dit était faux ,au mieux non exhaustive), vu que je parlais de load/store normal dans mon explication et j'ai basé mes calculs dessus (ce qui semble assez évident si tu avais bien lu).
ensuite on parle d'un processeur ARM et donc j'ai rajouté des détails technique sur la pipeline des instructions , le bus , et les processeurs RISC , mais c'est pas un sujet que tu connais apparemment
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
Dernière édition par Kannagi le Mar 11 Aoû 2020 - 14:22, édité 1 fois
Invité- Invité
Re: Acorn archimedes 3010
Kannagi a écrit:Apprend à lire ce qu'est une dissonance cognitive ,ce qui n'est pas le cas ici![]()
Et j'ai bien dit que oui je n'avais pas compris que tu parlais de LDM/SDM ton explication n'était pas clair , on plus d’être très poli sur la forme![]()
Et j'ai ensuite dit que oui avec ces instruction tu peux atteindre une bande passante correct sur la RAM , et tu as continué en disant que je disais n'importe quoi ce qui n'est pas le cas (rien ce que j'ai dit était faux ,au mieux non exhaustive), vu que je parlais de load/store normal dans mon explication et j'ai basé mes calculs dessus (ce qui semble assez évident si tu avait bien lu).
Mon explication est totalement limpide puisque je parle de chargements par paquets multiples.
Tu ne sais pas lire et / ou ne comprends pas un texte simple, même avec un exemple complètement détaillé et commenté, comme celui que j'ai rédigé.
Je l'ai dit : c'est ton problème ; pas le mien.
ArchieForEver- Guéri miraculeux
-
Nombre de messages : 2573
Age : 52
Localisation : France
Date d'inscription : 10/12/2011
Page 5 sur 34 • 1, 2, 3, 4, 5, 6 ... 19 ... 34
![-](https://i.servimg.com/u/f62/11/03/61/79/moins10.png)
» Acorn archimedes 3010 (& Co !)
» AMIGA vs ARCHIMEDES 3010, FIGHT !
» AMIGA vs ARCHIMEDES 3010, FIGHT !
» Acorn Archimedes A3020
» Le vrai successeur des ST et AMIGA : L'ARCHIMEDES
» AMIGA vs ARCHIMEDES 3010, FIGHT !
» AMIGA vs ARCHIMEDES 3010, FIGHT !
» Acorn Archimedes A3020
» Le vrai successeur des ST et AMIGA : L'ARCHIMEDES
Page 5 sur 34
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum