[Technique] Débat codé autour de nos bien aimées 16 bit

[Invité]

Un nouveau topic spécialement créé pour les fous amoureux des lignes de code.
Allez y, exprimez vous, ceci est votre espace de liberté !

[Invité]

la syntaxe du movem est la suivante :

Code:


movem.w (%ax), reglist          // 12+4n
movem.l (%ax), reglist          // 12+8n

ou

movem.w reglist, (%ax)          // 8+4n
movem.w reglist, (%ax)          // 8+8n


Normalement tu utilises cette instruction pour sauvegarder tes registres en début d'appel d'une fonction et les restaurer à la fin.

Tu vois que pour la première instruction movem qui va copier depuis la mémoire dans une liste de registre, tu as un temps d'init de 12 cycles, ensuite n est le nombre de registre écrits.
Quand tu écrit en word (16 bits) tu as 4 cycles par registre copié et 8 cycles quand tu es en long (32 bits).

Pour la seconde instruction movem le temps d'init est de 8 cycles, ensuite pareil tu as 4 cycles par registre transféré en mémoire si t'es en word et 8 cycles si t'es en long.

La liste de registre que tu transfert lors d'un movem est paramétrable, tu peux transférer un seul registre tout comme tu peux transférer les 16 d'un coup.
En réalité tu es obligé de conserver 2 à 3 registres pour le stack et pour les pointers sources et destinations... du coup au moins tu transfert 13 registres au maximum d'un coup ce qui te fait :

12 + (13*8) pour lire 52 octets depuis la mémoire et les copier dans les registres
8 + (13*8) pour copier les 13 registres 32 bits (soit 52 octets) en mémoire.

Du coup tu as transféré 52 octets en 12 + 8 + (13 * 8) + (13 * 8) = 228 cycles
228 / 52 = 4.38 cycles par octet.

(et on voit que je me suis planté dans mon calcul, c'est plutot 4.4 que 4.3 :p)

Merci, du coup là c'est plus clair .
Mais tes registres de destinations, tu dois les initialiser avant (pour qu'ils pointent sur ta destination) ..
Et une fois que les 52 octest sont copiés, es ce que tu dois initialiser de nouveau tes registres de destination ou sources(je pense que oui,car 1 des 2 est non auto incrementé),pour la copie de 52 octets suivants ??
Parce que moi c'est tii @source,@dest,#1024, et c'est tout, pas de boucles, pas de cycles sup, rien, sauf 17+(6*1024) cycles .

Parce que là,si on prend 1024 octets, soit 1024/52 = 19,692, bah ça marche plus trop ton truc
et ça il faut que tu le gères aussi, donc entre les inits, la gestion du nobre à copier etc, finalement on en arrive au même taux de transfert que sur le 6280, seulement moi ça prend juste 7 octets .

Mais c'est vrai que cette façon d'utiliser les registres pour la copie est intéressante, et effectivement un simple 65xx ne fait pas le poid dans la copie de bloc de données .
Même le 65816 d'ailleurs .
le 6280 s'en sort grâce aux instructions de copie de blocs .
Ce que je veux juste montrer, c'est que 8 bit ne veux pas dire forcement 2x plus lent qu'un 16, ou qu'un 16 traite 2 fois plus de données qu'un 16 .
Tout dépend des CPU .

Sur megadrive, la division prend jusqu'à 140/158 cycles, l'instruction peut prendre moins selon le nombre de bits à positionné à 1 dans tes opérandes.
Et puis il s'agit d'une division type 32 bits / 16 bits = 16 bits quotient : 16 bits remainder
Ca te prendrait *beaucoup plus* que 150 cycles de le refaire à la main, même avec un 6280.
Mais il est évident que c'est une instruction que tu évites d'utiliser sur MD dans la mesure du possible (tout comme la multiplication) vu que ça reste très couteux.

Oui c'est pour ça que je dis, div limitée aux entiers et sur 16 bit max, après c'est clair que je suis au dessus ..
L'instruction div du 68000, est plus complète , moi je ferrais selon les cas, donc plus rapide selon ce que je dois traiter .
ex div entière sur 8 bit .
Mais j'en ai pas l'utilité (pour le moment), donc pas de soucis

[Stef]

Merci, du coup là c'est plus clair .
Mais tes registres de destinations, tu dois les initialiser avant (pour qu'ils pointent sur ta destination)...

oui mais encore une fois ça n'a d'importance que pour les petits transfert, au dessus de 100 octets tu peux considérer le temps de chargement des registres d'adresses comme "caché", ça coute 8 ou 12 cycles pour initialiser un registre d'adresse (selon que tu charges une adresse 16 ou 32 bits).

Et
une fois que les 52 octest sont copiés, es ce que tu dois initialiser
de nouveau tes registres de destination ou sources(je pense que oui,car 1
des 2 est non auto incrementé),pour la copie de 52 octets suivants ??

Ah oui c'est vrai ! J'étais resté dans la logique de pure set mais dans le cas de la copie t'es embêté avec le mode post inc qui manque dans un des 2 cas ce qui est bien dommage :-/
du coup tu dois rajouté 8 cycles : 236 cycles en tout donc 236/52 soit ~4.5 cycles / octet.

J'oublie tjs cette post incrementation manquante d'un coté avec le movem, c'est tellement pas logique comparé à l'adressage classique du 68k.
Du coup en effet t'as une petite pénalité avec la copie (comparé au set).

Parce que moi c'est tii @source,@dest,#1024, et c'est tout, pas de boucles, pas de cycles sup, rien, sauf 17+(6*1024) cycles .

Parce que là,si on prend 1024 octets, soit 1024/52 = 19,692, bah ça marche plus trop ton truc
et
ça il faut que tu le gères aussi, donc entre les inits, la gestion du
nobre à copier etc, finalement on en arrive au même taux de transfert
que sur le 6280, seulement moi ça prend juste 7 octets .

Ok ok ca te fait donc 6161 cycles pour 1024 octets transférés soit un débit exact de 1 octet tout les 6.0166 cycles (on peut donc considérer 6).

Si je compte tout sur 68000 (avec l'init et tout...) ça me fait :
init : 12 + 12 = 24
copie de 19 * 52 (988) octets : (236 * 19) = 4484
dernière copie de 36 octets : 12 + 8 + (9 * 8) + (9 * 8) = 164

Soit 4672 cycles en tout et un débit de 1 octet tout les 4.5625 cycles.

En fait on pourrait utiliser 1 registre de plus pour la copie (c'est possible grace au registre USP que j'ai oublié tout à l'heure) et dans ce cas tu arrives plutot à 1 octet pour un poil moins de 4.5 cycles... mais bon ça change plus grand chose. On va dire que j'ai été quand même un peu optimiste dans mes calculs mais on reste en dessous du 6280.
Bon après, pour les copies sur MD, on utilise le DMA quand c'est possible car il est bien plus rapide que le 68000 pour ça.

Mais
c'est vrai que cette façon d'utiliser les registres pour la copie est
intéressante, et effectivement un simple 65xx ne fait pas le poid dans
la copie de bloc de données .
Même le 65816 d'ailleurs .

Oui c'est pourquoi j'insiste sur le fait que si le 68000 a un mauvais débit d'instruction de manière générale (ses instructions sont assez lentes), il se rattrape largement grace à son large jeu d'instructions et son architecture un peu hybride 16/32 bits.

le 6280 s'en sort grâce aux instructions de copie de blocs .

Clairement, son instruction de copie de bloc est très performante pour un CPU 8 bits...
Sur Z80 tu en as une aussi mais heu... elle est genre... 3 fois plus lente :p
Bon après sur le Z80 y'a moyen d'aller plus vite que l'instruction de bloc si je me plante pas (avec la pile).

Ce
que je veux juste montrer, c'est que 8 bit ne veux pas dire forcement
2x plus lent qu'un 16, ou qu'un 16 traite 2 fois plus de données qu'un
16 .
Tout dépend des CPU .

Mais j'ai toujours été d'accord avec ça... ce que je voulais dire c'est qu'une vraie architecture 16 bits (je parle pas du CPU SNES qui ressemble plus à un 8 bits) apporte tout de même un avantage non négligeable sur une architecture 8 bits selon les cas, mais ça ne fait pas tout c'est sur. Un bon cpu 8 bits avec une haute fréquence peut être plus rapide qu'un cpu 16 bits moyen (genre un 8086 :p) fréquencé plus bas, à mon avis un 6280 à 7 Mhz est bien plus rapide qu'un 8086 à 4 Mhz, pourtant le 8086 est un 16 bits...

Oui c'est pour ça que je dis, div limitée aux entiers et sur 16 bit max, après c'est clair que je suis au dessus ..
L'instruction div du 68000, est plus complète , moi je ferrais selon les cas, donc plus rapide selon ce que je dois traiter .
ex div entière sur 8 bit .
Mais j'en ai pas l'utilité (pour le moment), donc pas de soucis

J'évite de m'en servir aussi :p
Dernièrement je m'amusais à faire un peu de 3D sur MD et là sans vraie division point de salut :-/ Déjà j'ai du me limiter à avoir des résultats sur 16 bits (la division du 68000, si elle divise un nombre 32 bits, donne un résultat sur 16 bits seulement, les 16 bits de poids fort étant utilisé pour le reste de la division).

[Invité]

oui mais encore une fois ça n'a d'importance que pour les petits transfert, au dessus de 100 octets tu peux considérer le temps de chargement des registres d'adresses comme "caché", ça coute 8 ou 12 cycles pour initialiser un registre d'adresse (selon que tu charges une adresse 16 ou 32 bits).

Oui ça c'est ok, effectivement ;-)

Ah oui c'est vrai ! J'étais resté dans la logique de pure set mais dans le cas de la copie t'es embêté avec le mode post inc qui manque dans un des 2 cas ce qui est bien dommage :-/
du coup tu dois rajouté 8 cycles : 236 cycles en tout donc 236/52 soit ~4.5 cycles / octet.

J'oublie tjs cette post incrementation manquante d'un coté avec le movem, c'est tellement pas logique comparé à l'adressage classique du 68k.
Du coup en effet t'as une petite pénalité avec la copie (comparé au set).

Eh eh
Sinon, j'ai trouvé ça dommage que la copie d'un (An)+ -> (An)+ ne puisse pas se faire, je pense que ça serait bien plus rapide ..

Si je compte tout sur 68000 (avec l'init et tout...) ça me fait :
init : 12 + 12 = 24
copie de 19 * 52 (988) octets : (236 * 19) = 4484
dernière copie de 36 octets : 12 + 8 + (9 * 8) + (9 * 8) = 164

Soit 4672 cycles en tout et un débit de 1 octet tout les 4.5625 cycles.

En fait on pourrait utiliser 1 registre de plus pour la copie (c'est possible grace au registre USP que j'ai oublié tout à l'heure) et dans ce cas tu arrives plutot à 1 octet pour un poil moins de 4.5 cycles... mais bon ça change plus grand chose. On va dire que j'ai été quand même un peu optimiste dans mes calculs mais on reste en dessous du 6280.
Bon après, pour les copies sur MD, on utilise le DMA quand c'est possible car il est bien plus rapide que le 68000 pour ça.

Tu oublies encore entre chaque copie de 52 octets non ??
Et ta boucle de 19 x movem ?? (sauf si tu unrolles bien sur )

Ton DMA, te permet de faire RAM -> RAM ???

Oui c'est pourquoi j'insiste sur le fait que si le 68000 a un mauvais débit d'instruction de manière générale (ses instructions sont assez lentes), il se rattrape largement grace à son large jeu d'instructions et son architecture un peu hybride 16/32 bits.

Oui ,ca en fait un CPU clairement intéressant, difficile à appréhender, surtout si comme moi tu viens de l'architecture 65xx .. :8I:

Clairement, son instruction de copie de bloc est très performante pour un CPU 8 bits...
Sur Z80 tu en as une aussi mais heu... elle est genre... 3 fois plus lente :p
Bon après sur le Z80 y'a moyen d'aller plus vite que l'instruction de bloc si je me plante pas (avec la pile).

Le Z80, est très agréable aussi à programmer, mais bon les perfs sont pas top, sauf bien sur si la machine compense avec une fréquence élevée .

Mais j'ai toujours été d'accord avec ça... ce que je voulais dire c'est qu'une vraie architecture 16 bits (je parle pas du CPU SNES qui ressemble plus à un 8 bits) apporte tout de même un avantage non négligeable sur une architecture 8 bits selon les cas, mais ça ne fait pas tout c'est sur. Un bon cpu 8 bits avec une haute fréquence peut être plus rapide qu'un cpu 16 bits moyen (genre un 8086 :p) fréquencé plus bas, à mon avis un 6280 à 7 Mhz est bien plus rapide qu'un 8086 à 4 Mhz, pourtant le 8086 est un 16 bits...

Bien sur, par exemple le faitde n'avoir que peu de registre sur un 65xx, fait que c'est simple à coder (franchement très très simple), mais chiant quand tu es obligé de stocker une valeur en ram ou dans la pile pour la garder intacte ..

J'évite de m'en servir aussi :p
Dernièrement je m'amusais à faire un peu de 3D sur MD et là sans vraie division point de salut :-/ Déjà j'ai du me limiter à avoir des résultats sur 16 bits (la division du 68000, si elle divise un nombre 32 bits, donne un résultat sur 16 bits seulement, les 16 bits de poids fort étant utilisé pour le reste de la division).

Oui pour la 3D je me doute bien que les divs et mul sont obligatoires, mais je pense que tout dépend ce que tu as besoin, une solution soft ferait peut être mieux ..

Mais des fois c'est chiant de se casser la tête pour reinventer la roue .
Sur PCE, la 3D c'est trop la merde, l'archi 100% tiles à la con ne s'y prête pas du tout ..

Je sais pas sur MD, mais sur PCE, elles sont entrelacées en VRAM en plus (d'où le "à la con") ..

[Stef]

Eh eh
Sinon, j'ai trouvé ça dommage que la copie d'un (An)+ -> (An)+ ne puisse pas se faire, je pense que ça serait bien plus rapide ..

C''est possible un move.l (An)+, (An)+, mais ça prend 20 cycles (soit un débit de 1 octet pour 5 cycles) donc c'est plus lent que le movem. En gros tu te prends un pénalité de 4 cycles pour 4 octets transférés là ou un movem te donne une pénalité de 28 cycles (pour tout prend en compte) pour 56 octets transférés.

Le truc qu'il manque c'est un movem.l (An)+, (An)+ tu veux dire, mais dans ce cas ça serait une instruction de bloc, ce genre d'instruction existe... dans le 68010.

Tu oublies encore entre chaque copie de 52 octets non ??
Et ta boucle de 19 x movem ?? (sauf si tu unrolles bien sur )

non non je n'ai rien oublié ce coup ci, et oui c'est enrollé, le nombre que je t'ai donné c'est pour un transfert "static" de 1024 octet. Mais toi c'est pareil, le nombre d'octet à copier est "statique" j'imagine (un immédiat 8 bits ou 16 bits). Bon après rien ne t'empêche de faire de l'auto modification de code pour le rendre paramétrable, faut il encore pouvoir executer du code en RAM.

Ton DMA, te permet de faire RAM -> RAM ???

Ah non hélas :-/
Je parlais uniquement pour des copies type ROM/RAM --> VRAM.
Enfin perso ça doit représenter un bon 80% de mes copies :p

Oui ,ca en fait un CPU clairement intéressant, difficile à appréhender, surtout si comme moi tu viens de l'architecture 65xx ..

Une fois habitué tu l'adoptes vite :p

Le Z80, est très agréable aussi à programmer, mais bon les perfs sont pas top, sauf bien sur si la machine compense avec une fréquence élevée.

Je fais un peu de Z80 (pour la partie sonore de la MD) et je dois admettre ne pas être un grand grand fan de ce CPU. Il a pas mal de registres (pour un 8 bits) et peut être assez performant bien utilisé mais je suis souvent un peu frustré avec ce CPU, genre les registres IX et IY quasi inutilisable tellement leurs utilisation est lente... dommage :-/

Oui pour la 3D je me doute bien que les divs et mul sont obligatoires, mais je pense que tout dépend ce que tu as besoin, une solution soft ferait peut être mieux ..

Mais des fois c'est chiant de se casser la tête pour reinventer la roue .
Sur PCE, la 3D c'est trop la merde, l'archi 100% tiles à la con ne s'y prête pas du tout ..

Je sais pas sur MD, mais sur PCE, elles sont entrelacées en VRAM en plus (d'où le "à la con") ..

Non heureusement la MD stocke ses tiles de manière linéaire (comme la SMS), c'est une des raisons qui font que j'aime bien programmer sur cette machine, la plupart (NES, SNES, PCE...) stockent ça en plan et c'est une galère pas possible à manipuler...

Enfin de base l'architecture en tile c'est pas vraiment adapté à faire de la 3D quand même, ça aurait été bien d'avoir un chip qui transforme l'adressage tile en adressage bitmap et vice versa. Y'a ça dans le Mega CD et franchement ça te permet de gagner de précieux cycles pour toute les opérations bitmap.

Sur MD je suis obligé de simuler un frame buffer bitmap en mémoire centrale que je converti en tile au moment du transfert en VRAM.

[Invité]

Le truc qu'il manque c'est un movem.l (An)+, (An)+ tu veux dire, mais dans ce cas ça serait une instruction de bloc, ce genre d'instruction existe... dans le 68010.

Oui, c'est du movem que je parlais, c'était sous entendu, dsl ..

non non je n'ai rien oublié ce coup ci, et oui c'est enrollé, le nombre que je t'ai donné c'est pour un transfert "static" de 1024 octet. Mais toi c'est pareil, le nombre d'octet à copier est "statique" j'imagine (un immédiat 8 bits ou 16 bits). Bon après rien ne t'empêche de faire de l'auto modification de code pour le rendre paramétrable, faut il encore pouvoir executer du code en RAM.

Lol, voilà tu viens de trouver la solution pour faire varier la source,dest,et la taille, sinon oui c'est statique, mais en faisant exécuter la/les fonctions en RAM, pas de soucis ..

Encore une question :
Désolé d'y revenir, mais là j'arrive pas à savoir comment c'est fait .
Quand tu as copié tes premiers 52 octets(avec tes 13 registres), comment le 68000, il sait qu'il doit passer aux adresses suivantes dans tes 13 registres, pour copier les 52 suivants ???

Ah non hélas :-/
Je parlais uniquement pour des copies type ROM/RAM --> VRAM.
Enfin perso ça doit représenter un bon 80% de mes copies :p

Oui, et de toutes façon, il est bien plus performant que sur PCE..
Et en vitesse,et aussi sur sur le fait que tu puisses faire ROM/RAM --> VRAM ..

Une fois habitué tu l'adoptes vite :p

Oui je m'en doute

Je fais un peu de Z80 (pour la partie sonore de la MD) et je dois admettre ne pas être un grand grand fan de ce CPU. Il a pas mal de registres (pour un 8 bits) et peut être assez performant bien utilisé mais je suis souvent un peu frustré avec ce CPU, genre les registres IX et IY quasi inutilisable tellement leurs utilisation est lente... dommage :-/

Oui, c'est pas faux, mais quand on voit ce certains en font (CPC/spectrum), faut avouer qu'il à quand même des ressources ..
Au fait, t'es tu déjà inspiré de code 68000 de codeurs ST ???
Parce que vu ce qu'ils arrivent à faire dessus, ces gars maitrisent grave le CPU ..

Non heureusement la MD stocke ses tiles de manière linéaire (comme la SMS), c'est une des raisons qui font que j'aime bien programmer sur cette machine, la plupart (NES, SNES, PCE...) stockent ça en plan et c'est une galère pas possible à manipuler...

En plus les plans (sur PCE) sont même pas contigus, c'est putin de chiant à modifier .

Enfin de base l'architecture en tile c'est pas vraiment adapté à faire de la 3D quand même, ça aurait été bien d'avoir un chip qui transforme l'adressage tile en adressage bitmap et vice versa. Y'a ça dans le Mega CD et franchement ça te permet de gagner de précieux cycles pour toute les opérations bitmap.

Sur MD je suis obligé de simuler un frame buffer bitmap en mémoire centrale que je converti en tile au moment du transfert en VRAM.

Exact les tiles c'est pas trop fait pour la 3D ..
Un truc que je trouve domage (puristes obligent peut être), c'est pourquoi pas de demo techniques ou de jeux homebrew, qui exploitent le megaCD ???
C'est pourtant une belle machine,avec un super hardware quand même ..

[Stef]

Oui, c'est du movem que je parlais, c'était sous entendu, dsl ..

Non mais oui je m'en suis aperçu en cours de route :p

Lol, voilà tu viens de trouver la solution pour faire varier la source,dest,et la taille, sinon oui c'est statique, mais en faisant exécuter la/les fonctions en RAM, pas de soucis ..

Ouais c très puissant l'auto modification/génération de code, c'est vraiment le dernier step pour optimiser ton code :p

Encore une question :
Désolé d'y revenir, mais là j'arrive pas à savoir comment c'est fait .
Quand tu as copié tes premiers 52 octets(avec tes 13 registres), comment le 68000, il sait qu'il doit passer aux adresses suivantes dans tes 13 registres, pour copier les 52 suivants ???

Ben d'un côté tu as le post incrément (le pré décrémente de l'autre), donc oui selon le nombre de registre utilisé le registre d'index va être modifié en conséquence, genre là 13 registres 32 bits, ben il va ajouter ou soustraire 52 au registre d'index.

Oui, c'est pas faux, mais quand on voit ce certains en font (CPC/spectrum), faut avouer qu'il à quand même des ressources ..
Au fait, t'es tu déjà inspiré de code 68000 de codeurs ST ???
Parce que vu ce qu'ils arrivent à faire dessus, ces gars maitrisent grave le CPU ..

Oui oui non mais c sur, il a de la resource :) mais je pense que j'ai pris un peu trop l'habitude du 68000. La demo Batman sur CPC montre qu'un Z80 en a sérieusement dans le ventre...
Sinon j'ai pas vraiment regardé le code des différentes démo Atari ou Amiga, j'en suis pas encore là ^^ C'est clair qu'il suffit de regarder les différentes productions sur ces machines (en particulier l'atari qui offre peu d'assistance) pour se rendre compte que le 68000 a de la ressource
Ca fait pas si longtemps que je programme *vraiment* sur MD et donc 68000, j'apprends, j'expérimente... c'est plus pour le fun :)

En plus les plans (sur PCE) sont même pas contigus, c'est putin de chiant à modifier .

Haha oui il me semble que tom (c'est son nom sur un autre forum) m'en avait parlé... enfin dans son cas, ça l'arrangeait pas mal pour mettre au point son algo de compression pour BadApple... je me demande s'il va continuer à bosser dessus d'ailleurs, je crois qu'il était pas mal pris avec son émulation NES :)

Exact les tiles c'est pas trop fait pour la 3D ..
Un truc que je trouve domage (puristes obligent peut être), c'est pourquoi pas de demo techniques ou de jeux homebrew, qui exploitent le megaCD ???
C'est pourtant une belle machine,avec un super hardware quand même ..

Bah déjà peu de personnes possèdent un mega CD comparé à la MD et ce qui est sympa avec un homebrew c'est de le faire tourner sur la vraie machine. Et puis c'est plus compliqué pour développer dessus, par exemple ma librairie de développement ne permet pas de le faire (pas directement du moins). Mais c'est vrai que c'est une bonne machine ! Je pense que Sega n'aurait jamais du sortir le 32X, ça a ruiné la crédibilité des addons... et donc écourter la vie du mega CD.

[Lesarthois]

Heu... Le méga CD est sorti en 1991, le 32X en 1994... Sachant que la Mégadrive a été arrêtée en 1996, c'est juste que Sega a pris une décision stupide de sortir le 32X (ou bien ils auraient dû le sortir plus tôt).

[Invité]

Non mais oui je m'en suis aperçu en cours de route :p

Pas de soucis, j'avais compris

Ouais c très puissant l'auto modification/génération de code, c'est vraiment le dernier step pour optimiser ton code :p

Ouai, c'est sympa à faire, mais pour le moment, j'en utilise pas bcp ..

Ben d'un côté tu as le post incrément (le pré décrémente de l'autre), donc oui selon le nombre de registre utilisé le registre d'index va être modifié en conséquence, genre là 13 registres 32 bits, ben il va ajouter ou soustraire 52 au registre d'index.

Donc au movem suivant, le contenu de ta liste de registres est mis à jour ??
Tu exécutes 19 fois tes movem sans rien faire ??
J'ai compris lol ??

Sinon j'ai pas vraiment regardé le code des différentes démo Atari ou Amiga, j'en suis pas encore là ^^ C'est clair qu'il suffit de regarder les différentes productions sur ces machines (en particulier l'atari qui offre peu d'assistance) pour se rendre compte que le 68000 a de la ressource
Ca fait pas si longtemps que je programme *vraiment* sur MD et donc 68000, j'apprends, j'expérimente... c'est plus pour le fun :)

Amiga je suis pas sur que ça soit super, car dans son architecture, le CPU est la dernière roue du carosse, donc peu d'optimisation de ce côté là à mon avis ..
Mais le ST, doit y avoir des mines d'or dans les codes ..

Haha oui il me semble que tom (c'est son nom sur un autre forum) m'en avait parlé... enfin dans son cas, ça l'arrangeait pas mal pour mettre au point son algo de compression pour BadApple... je me demande s'il va continuer à bosser dessus d'ailleurs, je crois qu'il était pas mal pris avec son émulation NES :)

Je sais pas pour les tiles, je sais qu'il parlait surtout du mode N&B de la pce, comme avantage pour la démo ..

Bah déjà peu de personnes possèdent un mega CD comparé à la MD et ce qui est sympa avec un homebrew c'est de le faire tourner sur la vraie machine. Et puis c'est plus compliqué pour développer dessus, par exemple ma librairie de développement ne permet pas de le faire (pas directement du moins). Mais c'est vrai que c'est une bonne machine ! Je pense que Sega n'aurait jamais du sortir le 32X, ça a ruiné la crédibilité des addons... et donc écourter la vie du mega CD.

Oui, je me souvient que le MCD était présenté comme une bête à l'époque .
D'ailleurs je suis surpris que FF, n'utilise pas les ressources du megaCD ..

Un petit post de tom sur sega-16

Actually, I did a few test examples of 16bit and 32bit math/operations.
Not everything mind you, but just some stuff relative to an old game
discussion thread. IIRC, the 65816 cycle wise was faster in every
instance - although it did take more operations (but that's irrelevant
when the measurement is speed). The 65816 would be incredibly fast if
they actually designed it with a 16bit data bus. It wouldn't be to
limited in the number of instructions. But then again, it wouldn't be
that staple "simple but fast" ISA of the 65x series is known for. But at
minimum, you wouldn't need to drop down into 8bit Acc or such mode
every time you just want to do byte operations on the 65816

The original 68000 has a really beautiful ISA. And the processor was
available in very high speeds from the start (16mhz was incredibly fast
for a processor at the time in '81). That makes for a great combination.
And the fact that it was forward thinking model for when the 32bit bus
and 32bit ALU versions came around. Very nice speed boost right there
alone.

Surtout pour les opérations mathématiques .

[Stef]

Heu... Le méga CD est sorti en 1991, le 32X en 1994... Sachant que la Mégadrive a été arrêtée en 1996, c'est juste que Sega a pris une décision stupide de sortir le 32X (ou bien ils auraient dû le sortir plus tôt).

Ils auraient jamais du le sortir et se concentrer sur la Saturn. La mégadrive avec son mega CD aurait pu tenir encore quelque temps. Le 32X ça faisait vraiment un patch pour booster la mégadrive aux hormones en attendant la prochaine génération qui arrivait ... un an après..

[Invité]

Perso, j'ai jamais accroché à la saturn, même maintenant je la trouve vraiment bof
J'y ai préféré la PS1 ..
La dreamcast par contre m'a scotchée, elle fait partie de mes meilleurs souvenirs consoles .

[Stef]

Ouai, c'est sympa à faire, mais pour le moment, j'en utilise pas bcp ..

Ouais enfin on en vient là quand on a plus d'autre solution :p

Donc au movem suivant, le contenu de ta liste de registres est mis à jour ??
Tu exécutes 19 fois tes movem sans rien faire ??
J'ai compris lol ??

Ah ok je pense comprendre pourquoi tu ne comprends pas
pour faire la copie tu as besoin de 2 movem.
Le premier lis depuis la mémoire et copie dans les registres.
Le deuxième copie le contenu des registres en mémoire.
Tu as besoin de 2 registres d'index, un pour chaque movem.
Seul un des 2 movem supporte la post incrémentation donc en gros tu fais 19x ça :

Code:


movem.l (a0)+,reglist
movem.l reglist,(a1)
lea      52(a1),a1        // ajoute 52 à a1


Amiga je suis pas sur que ça soit super, car dans son architecture, le CPU est la dernière roue du carosse, donc peu d'optimisation de ce côté là à mon avis ..
Mais le ST, doit y avoir des mines d'or dans les codes ..

Oui je pense aussi, pour ça que je disais surtout l'atari

Oui, je me souvient que le MCD était présenté comme une bête à l'époque .
D'ailleurs je suis surpris que FF, n'utilise pas les ressources du megaCD ..

Le gros avantage du mega CD c'est surtout le stockage supplémentaire, le chip sonore PCM (pour avoir de bon bruitages) et la piste audio CD.
Ensuite y'a aussi quelques ajouts interesants comme la puce vectorielle pour déformer une image un peu comme le mode 7 (en fait c'est beaucoup plus flexible et puissant que le mode 7) et puis un truc de transformation tile/bitmap, compression font....

Le CPU du mega CD est surtout utilisé pour driver le lecteur CD, alimenter le chip PCM et la puce vectorielle (qui demande pas mal de calcul). Soul Star utilise bien le mega CD dans le sens ou il exploite pleinement la puce vectorielle et doit donc pas mal soliciter le sub CPU pour ça.
Pour les jeux 2D classiques sans ce genre d'effet au final tout passe par la megadrive, c'est la megadrive qui alimente le VDP et non le mega CD. Ce qui m'étonne dans Final Fight, c'est la qualité des animations... honnêtement c'est encore plus difficile à faire avec le mega CD qu'avec la MD car tu n'as pas accés à toute la rom d'un coup ! Tu dois charger en RAM centrale du mega CD (qui fait 512 KB) et ensuite le 68000 de la megadrive doit y accéder par bank de 128 KB (et pendant ce temps le second cpu est à l'arrêt).

Actually, I did a few test examples of 16bit and 32bit math/operations.
Not everything mind you, but just some stuff relative to an old game
discussion thread. IIRC, the 65816 cycle wise was faster in every
instance - although it did take more operations (but that's irrelevant
when the measurement is speed). The 65816 would be incredibly fast if
they actually designed it with a 16bit data bus. It wouldn't be to
limited in the number of instructions. But then again, it wouldn't be
that staple "simple but fast" ISA of the 65x series is known for. But at
minimum, you wouldn't need to drop down into 8bit Acc or such mode
every time you just want to do byte operations on the 65816

The original 68000 has a really beautiful ISA. And the processor was
available in very high speeds from the start (16mhz was incredibly fast
for a processor at the time in '81). That makes for a great combination.
And the fact that it was forward thinking model for when the 32bit bus
and 32bit ALU versions came around. Very nice speed boost right there
alone.

Oui c'est pas étonnant, le 65816 est capable de calculer sur 16 bits en natif donc il n'est pas surprenant que sur le nombre de *cycles* nécessaires pour faire une opération sur 16 bits voire même 32 (dans certains cas uniquement je pense) puissent être inférieur au 68000... mais globalement ce cpu est quand même assez poussif car souvent sur une basse fréquence à cause de la mémoire qui ne peut pas suivre, puis un bus 8 bits :-/

[Invité]

Ouais enfin on en vient là quand on a plus d'autre solution :p

Lol, je voyais ça comme the best des codeurs ...

Ah ok je pense comprendre pourquoi tu ne comprends pas
pour faire la copie tu as besoin de 2 movem.
Le premier lis depuis la mémoire et copie dans les registres.
Le deuxième copie le contenu des registres en mémoire.
Tu as besoin de 2 registres d'index, un pour chaque movem.
Seul un des 2 movem supporte la post incrémentation donc en gros tu fais 19x ça :

Code:


movem.l (a0)+,reglist
movem.l reglist,(a1)
lea      52(a1),a1        // ajoute 52 à a1


Ok, là je comprends mieux ..
Mais tu vois ,au final l'écart n'est plus si important ..

Oui c'est pas étonnant, le 65816 est capable de calculer sur 16 bits en natif donc il n'est pas surprenant que sur le nombre de *cycles* nécessaires pour faire une opération sur 16 bits voire même 32 (dans certains cas uniquement je pense) puissent être inférieur au 68000... mais globalement ce cpu est quand même assez poussif car souvent sur une basse fréquence à cause de la mémoire qui ne peut pas suivre, puis un bus 8 bits :-/

En fait sans dire qu'il égale le 68000, car faut pas se leurer, c'est pas possible, mais je pense sérieusement que les programmeurs ne codaient pas correctement dessus ..
Je le remarque même sur PCE, sur du desassemblage de code de jeux, pourtant fait par des pros ..
Bcp codent comme sur 6502, sans utiliser les modes ou certaines instructions propres au 6280 (le 65816 doit avoir le même soucis) ..
un exemple simple, pour mettre a,z,ou y à zero, ils font lda,ldx,ou ldy #$0, alors qu'il existe des instruction pour ça: cla,clx,cly ...

[Invité]

Le gros avantage du mega CD c'est surtout le stockage supplémentaire, le chip sonore PCM (pour avoir de bon bruitages) et la piste audio CD.
Ensuite y'a aussi quelques ajouts interesants comme la puce vectorielle pour déformer une image un peu comme le mode 7 (en fait c'est beaucoup plus flexible et puissant que le mode 7) et puis un truc de transformation tile/bitmap, compression font....

Le CPU du mega CD est surtout utilisé pour driver le lecteur CD, alimenter le chip PCM et la puce vectorielle (qui demande pas mal de calcul). Soul Star utilise bien le mega CD dans le sens ou il exploite pleinement la puce vectorielle et doit donc pas mal soliciter le sub CPU pour ça.
Pour les jeux 2D classiques sans ce genre d'effet au final tout passe par la megadrive, c'est la megadrive qui alimente le VDP et non le mega CD. Ce qui m'étonne dans Final Fight, c'est la qualité des animations... honnêtement c'est encore plus difficile à faire avec le mega CD qu'avec la MD car tu n'as pas accés à toute la rom d'un coup ! Tu dois charger en RAM centrale du mega CD (qui fait 512 KB) et ensuite le 68000 de la megadrive doit y accéder par bank de 128 KB (et pendant ce temps le second cpu est à l'arrêt).

Il me semble également que le Mega CD permet une plus grande quantité de couleurs affichables simultanément à l'écran.
Quant à Final Fight sur Mega CD, c'est tout bonnement la meilleure version jamais sortie. Bon sang, elle enterre la mouture Super Famicom six pieds sous terre ! Fou !

[Lesarthois]

Ils auraient jamais du le sortir et se concentrer sur la Saturn. La mégadrive avec son mega CD aurait pu tenir encore quelque temps. Le 32X ça faisait vraiment un patch pour booster la mégadrive aux hormones en attendant la prochaine génération qui arrivait ... un an après..

Oui, en plus.
Mais à cette époque là, Sega a vraiment merdé niveau comm, en annonçant le 32X, puis la Neptun et la Saturn dans l'année qui suit, et 2 ans à peine après la sortie de la Saturn, hop ils annonçent bosser sur la Dreamcast...

D'ailleurs de ce que je vois des vieux magazines, j'ai l'impression que si la Mégadrive était bien mise en avant, niveau MegaCD y'avait pas de publicité, si?

[Stef]

Ouais enfin on en vient là quand on a plus d'autre solution :p

Lol, je voyais ça comme the best des codeurs ...

Ben oui tout de même il faut bien maitriser la machine et même la programmation en général pour faire ça, la génération de code demande un certain recul pour comprendre ce qu'il est possible ou pas de faire avec, et surtout comment tu peux gagner de précieux cycles :p

Ok, là je comprends mieux ..
Mais tu vois ,au final l'écart n'est plus si important ..

Ben c'est celui que je t'ai donné plus haut : ~6 cycles contre ~4.5 soit un rapport de 4/3. Sans être le nirvana c'est pas négligeable non plus, sachant qu'on critique souvent le 68000 sur le fait qu'il consomme beaucoup de cycles pour faire ses opérations.

En fait sans dire qu'il égale le 68000, car faut pas se leurer, c'est pas possible, mais je pense sérieusement que les programmeurs ne codaient pas correctement dessus ..

Très probablement, en même temps pour avoir regardez l'instruction set, il a l'air bien chiant à coder, avec ses 2 modes d'opérations... puis le fait que t'as des pénalités dans tout les sens, maitriser le CPU doit pas être évident c'est sur.

Je le remarque même sur PCE, sur du desassemblage de code de jeux, pourtant fait par des pros ..
Bcp codent comme sur 6502, sans utiliser les modes ou certaines instructions propres au 6280 (le 65816 doit avoir le même soucis) ..
un exemple simple, pour mettre a,z,ou y à zero, ils font lda,ldx,ou ldy #$0, alors qu'il existe des instruction pour ça: cla,clx,cly ...

haha c'est marrant sur 68000 t'as une instruction clr mais au contraire il faut pas l'utiliser car plus lente qu'un moveq X'D
Ils devaient venir du 68000... ou alors ils sont passés par un compilateur C.
Sur MD honnêtement on voit souvent du code mal foutu voir carrément buggué mais qui marche grace à des timings internes particuliers.

[Stef]

Il me semble également que le Mega CD permet une plus grande quantité de couleurs affichables simultanément à l'écran.
Quant à Final Fight sur Mega CD, c'est tout bonnement la meilleure version jamais sortie. Bon sang, elle enterre la mouture Super Famicom six pieds sous terre ! Fou !

Oui je sais pas d'ou est sorti cette rumeur, c'est vrai que dans les magazines à l'epoque on lisait souvent que le mega CD permettait d'afficher 128 couleurs (comparé au 64 de la MD) or c'est faux, l'affichage est géré par la MD seule donc on garde exactement les mêmes contraintes !

Final Fight CD déboite un max, trop dommage qui n'y ait pas eu de version MD.

[Stef]

Mais à cette époque là, Sega a vraiment merdé niveau comm, en annonçant le 32X, puis la Neptun et la Saturn dans l'année qui suit, et 2 ans à peine après la sortie de la Saturn, hop ils annonçent bosser sur la Dreamcast...

Oui je suis d'accord, ils se sont clairement planté... c'est dommage car c'est SOA (Sega Of America) qui a fait le forcing avec le 32X alors que SOJ (Sega Of Japan) n'en voulait pas et se concentrait sur la saturn... La megadrive avait beaucoup de succés au US, d'ou l'interet pour SOA de la maintenir en vie le plus longtemps possible, mais ce 32X, sachant que la saturn arrivait peu de temps après, ct du foutage de gueule...

D'ailleurs de ce que je vois des vieux magazines, j'ai l'impression que si la Mégadrive était bien mise en avant, niveau MegaCD y'avait pas de publicité, si?

Je me souviens qu'il y en avait eu pas mal quand même, le problème c'est qu'il était quand même bien cher. A l'époque je me voyais clairement pas mettre 2000 balles dans une simple extension (aussi bonne soit elle).

[Lesarthois]

Il aurait fallu des bons jeux... Moins chers surtout, parce que quand même, le gros coût des vieux jeux c'est bien la cartouche. Et beaucoup de jeux.
Quasi le prix d'une Super Nintendo pour une extension sans jeux et des jeux aussi chers que les cartouches, c'est sûr que c'est repoussant.

[Invité]

Ben oui tout de même il faut bien maitriser la machine et même la programmation en général pour faire ça, la génération de code demande un certain recul pour comprendre ce qu'il est possible ou pas de faire avec, et surtout comment tu peux gagner de précieux cycles :p

J'ai encore pas mal de boulot de ce côté là, mais bon rome ne s'est pas faite en 1 jour, on apprend chaque jour

Ben c'est celui que je t'ai donné plus haut : ~6 cycles contre ~4.5 soit un rapport de 4/3. Sans être le nirvana c'est pas négligeable non plus, sachant qu'on critique souvent le 68000 sur le fait qu'il consomme beaucoup de cycles pour faire ses opérations.

Bien sur c'est pas négligeable, mais bon le 68000 n'est bon partout, certaines instructions sont assez lente pour un 16 /32 bit ..
Tu prends un ARM à côté, tu vois vite la différence .

Très probablement, en même temps pour avoir regardez l'instruction set, il a l'air bien chiant à coder, avec ses 2 modes d'opérations... puis le fait que t'as des pénalités dans tout les sens, maitriser le CPU doit pas être évident c'est sur.

Oui, il semble être quand même un 16 bit batard.
Tu es obligé de sxitcher le CPU quand tu veux coder en 8bit, puis reswitcher pour du 16 bit .
Par contre il est plein de mode d'adressages sup, tu peux faire des opérations avec la pile, et un accumlateur supplémentaire .
Ce qui est très pratique .
De plus les opération en 16 bit sont aussi très rapides .
Mais aucune instructions de transfert de blocs .

haha c'est marrant sur 68000 t'as une instruction clr mais au contraire il faut pas l'utiliser car plus lente qu'un moveq X'D
Ils devaient venir du 68000... ou alors ils sont passés par un compilateur C.

lol, c'est possible, et fort probable aussi ..
Mais c'est comme coder en pensant 6502 sur un 68000, tu vas droit dans le mur .
Et je suis sur que sur Md, tu devais avoir ce genre de truc aussi ..

Sur MD honnêtement on voit souvent du code mal foutu voir carrément buggué mais qui marche grace à des timings internes particuliers.

Bon ça répond à ma question plus haut ..
J'imagine bien des mecs ayant fait de la nes, ou de la SMS pendant 10 ans, coder pour la Md, ça devait être marant

La difficulté sur le 68000, c'est que si tu veux faire du code performant, ta intérêt à revoir ta façon de faire .
C'est très déroutant, bien sur une personne qui maîtrise le Z80 aura moins de mal, mal un codeur 65xx il pleure ..
Toi tu es habitué, mais si tu regardes le tableau des instructions/cycles, un CPU comme le 65xx c'est ultra simple à comprendre en comparaison avec le 68000 .

[Invité]

Juste à titre info sur les divisions ..
ici les cycles d'un div 8 bit, et 8/16 bit sur un Z80

(Paramètres: HL=dividende, A=diviseur; résultat: A=quotient, HL=reste (modulo)).

Maintenant voici le temps pris par ces 2 premières routines :

Division 8 bits : mini. 35 cycles maxi. 210 cycles
Division 16/8 bits : mini. 155 cycles maxi. 171 cycles

Pas si énorme sachant que ça tourne sur un Z80.

[Invité]

Final Fight CD déboite un max, trop dommage qui n'y ait pas eu de version MD.

Pas sûr qu'on aurait pu profiter du mode 2 joueurs sur MD.
Et puis, surtout, on aurait pas eu les superbes musiques de la version CD... juste sublimes !
Du coup, je n'ai aucun regret quant au fait qu'il soit uniquement sorti sur Mega CD. En revanche, je peux comprendre la frustration de ceux qui ne possédaient "que" la Mega Drive à l'époque.

[sergent_buck]

héhé, quand on dit débat codé, pour le profane c'est vraiment codé ! (je parle de la discussion Touko/Stef)

[Stef]

Bien sur c'est pas négligeable, mais bon le 68000 n'est bon partout, certaines instructions sont assez lente pour un 16 /32 bit ..
Tu prends un ARM à côté, tu vois vite la différence .

C'est absolument incomparable
Le 68000 est hyper vieux, le ARM est un CPU de type RISC infiniment plus moderne :p
Je comparais à ce qui se faisait à l'époque :p
Aujourd'hui c'est sur que le 68000 passe pour un ancêtre mega super lent.

Oui, il semble être quand même un 16 bit batard.
Tu es obligé de sxitcher le CPU quand tu veux coder en 8bit, puis reswitcher pour du 16 bit .
Par contre il est plein de mode d'adressages sup, tu peux faire des opérations avec la pile, et un accumlateur supplémentaire .
Ce qui est très pratique .
De plus les opération en 16 bit sont aussi très rapides .
Mais aucune instructions de transfert de blocs .

Faire des opérations sur la pile ou avoir un accumulateur supplémentaire, ca peut prêter à sourire quand tu viens d'un autre cpu ^^ Mais pour les habitués du 6502 c'est surement une petite révolution :) Je trouve aussi le manque d'instruction de division ou multiplication assez pénible pour un cpu 16 bits. Sur un 8 bits ça peut se comprendre (bien que certains comme le 6809 en possède) mais sur un 16 bits c'est moins excusable.

lol, c'est possible, et fort probable aussi ..
Mais c'est comme coder en pensant 6502 sur un 68000, tu vas droit dans le mur .
Et je suis sur que sur Md, tu devais avoir ce genre de truc aussi ..
...
J'imagine bien des mecs ayant fait de la nes, ou de la SMS pendant 10 ans, coder pour la Md, ça devait être marant

En fait quand tu codes en C en désactivant les optimisation en gros tu te retrouve avec du code style 6502 : load mémoire / 1 opération / save mémoire...
Et là c clair qu'en performance ca craint un max
L'avantage sur MD, c'est que tu peux coder en C pour la plupart des jeux, avec un compilateur correct t'as déjà de bonnes performances, c'est vraiment si tu veux aller plus loin que tu passes en assembleur.

La difficulté sur le 68000, c'est que si tu veux faire du code performant, ta intérêt à revoir ta façon de faire .
C'est très déroutant, bien sur une personne qui maîtrise le Z80 aura moins de mal, mal un codeur 65xx il pleure ..
Toi tu es habitué, mais si tu regardes le tableau des instructions/cycles, un CPU comme le 65xx c'est ultra simple à comprendre en comparaison avec le 68000 .

Tout dépends avec quel assembleur t'as commencé, moi c'était sur x86 principalement donc le passage au 68000 s'est fait très facilement, j'étais même hyper emballé de voir le nombre de registre que possédait ce CPU et son architecture qui paraissait bien plus clean que celle du x86.
Si tu regarde l'instruction set, je suis d'accord que tu peux avoir des appréhensions...

Juste à titre info sur les divisions ..
ici les cycles d'un div 8 bit, et 8/16 bit sur un Z80

(Paramètres: HL=dividende, A=diviseur; résultat: A=quotient, HL=reste (modulo)).

Maintenant voici le temps pris par ces 2 premières routines :

Division 8 bits : mini. 35 cycles maxi. 210 cycles
Division 16/8 bits : mini. 155 cycles maxi. 171 cycles

Pas si énorme sachant que ça tourne sur un Z80.

Très impressionnant, surtout pour la routine 16/8 bits qui affiche un temps assez stable (qui est préférable).
Je pense qu'elle doit utiliser des lut assez importantes... pas sur qu'on puisse faire beaucoup mieux avec un 6502 même en terme de cycle.

[Stef]

Final Fight CD déboite un max, trop dommage qui n'y ait pas eu de version MD.

Pas sûr qu'on aurait pu profiter du mode 2 joueurs sur MD.
Et puis, surtout, on aurait pas eu les superbes musiques de la version CD... juste sublimes !
Du coup, je n'ai aucun regret quant au fait qu'il soit uniquement sorti sur Mega CD. En revanche, je peux comprendre la frustration de ceux qui ne possédaient "que" la Mega Drive à l'époque.

Le Mega CD n'apporte rien en ce qui concerne la vitesse d'animation et la taille des sprites, sur ce point le jeu aurait pu être fait tel quel sur Megadrive (avec une grosse cartouche quand même, genre 3 ou 4Mo). La seule différence qu'on aurait eu, c'est au niveau des musiques et des bruitages, là ça aurait été *beaucoup* moins bon ^^

[Stef]

Oui, et ça met un peut de compétition, ça motive...

C'est clair :) J'aurai bien aimé voir une version PCE de BadApple par exemple mais vu le temps que j'y ai passé je comprend que Tom n'ai pas eu envie de trop investir là dedans...

Oui, pour moi c'est le principal frein pour ne faire qu'une chose à la fois ..
C'est pas un question d'envie, car elle est là .

Bien sur, pareil pour moi, je ne bosse que sur un seul projet à la fois sinon tu es sur de ne pas aller au bout.

C'est un compilateur optimisé pour prendre le plus de place possible lol ..
Un exemple, un simple accès à un élément d'un tableau te prend 150 cycles en C ..

Et comme tu passes du temps à réécrire plein de choses en ASM, autant tout faire ..
Mais
bon à sa décharge, il a été fait pour permettre aux débutant de se
familiariser avec la console, et passer ensuite à l'ASM .
Et il est plus maintenu depuis 2005,donc assez buggé

Arf, on avait un compilateur dans le genre sur MD, SGCC ou un truc dans le genre, j'ai commencé avec ça et c'était tellement buggué que c'était vraiment inexploitable... J'ai fini par recompiler moi même un GCC en target 68000.
Dommage qu'il n'y ai pas de target 6280 ou même 6502 pour GCC.
Sinon un compilo comme cc65 ne pourrait pas faire l'affaire ? en utilisant conjointement du code assembleur pour les fonctions de copie ou nécessitant de la vitesse.