Bug du 68000 corrigé par le 68020 ? - Page 2

Ah je vois, c'est probablement que l'adresse qui foire n'est pas empilée (seuls PC et SR le sont).

vala, sans doute.

c'est très con d'ailleurs.

Link (./31) :
Ah je vois, c'est probablement que l'adresse qui foire

Euh, c'est pas le PC ça justement ?

Il veut dire l'adresse dont la lecture ou l'écriture a causé la faute.

Cela dit en théorie, ce n'est pas strictement nécessaire parce que tu peux désassembler l'instruction qui a foiré pour connaître l'adresse fautive… C'est juste de quelques ordres de magnitude plus lent.
Et puis à la base je pense pas que ce pauvre CPU ait été conçu pour avoir une mémoire virtuelle, donc c'est pas sa faute, et c'est pas un bug. :]

Mais c'est con de perdre le mmu pour si peu ...

K² : merci

a l'époque du 68k000 le mmu c'était 'achement high tech

GoldenCrystal (./35) :
Cela dit en théorie, ce n'est pas strictement nécessaire parce que tu peux désassembler l'instruction qui a foiré pour connaître l'adresse fautive… C'est juste de quelques ordres de magnitude plus lent.
Et puis à la base je pense pas que ce pauvre CPU ait été conçu pour avoir une mémoire virtuelle, donc c'est pas sa faute, et c'est pas un bug. :]

Pas exactement car dans mes souvenirs, le pc pointe vers l'instruction suivante, donc il faut que tu puisses remonter d'une instruction. Sinon ca aurait été bien plus simple.
Je ne suis même pas sûr de ce qui se passe pour des instructions du style move.l var1.l,var2.l
Edit: Reset / Bus Error / Address Error sont initiées dans les 2 cycles suivants l'anomalie (Group 0), donc tu peux effectivement avoir le pc au milieu d'une instruction.

Quelques infos sur les aspects non documentés du 68000, et le fonctionnement de clr.l.

Marrant.
Par contre, je comprends pas comment utiliser le fait que les copies de longwords soient faites en deux fois (comme certains jeux le font). A part le fait que move soit interruptible, qu'est-ce qu'on peut bien faire entre les deux ?

Folco (./40) :
Par contre, je comprends pas comment utiliser le fait que les copies de longwords soient faites en deux fois (comme certains jeux le font). A part le fait que move soit interruptible, qu'est-ce qu'on peut bien faire entre les deux ?

Si c'est en RAM, je ne vois pas trop non plus (à part que c'est une race condition potentielle dans les systèmes avec plusieurs processeurs, mais ça c'est un effet indésirable).

Par contre ça peut jouer si tu accèdes à deux registres 16 bits consécutifs d'un périphérique en utilisant une seule instruction 32 bits. Vu qu'il y a souvent des effets secondaires des accès en écriture (et parfois même en lecture), l'ordre d'accès peut avoir une importance.

Exemple : certains périphériques qui possèdent plusieurs registres internes n'utilisent que 2 adresses externes : une qui sert d'index (le numéro du registre interne à lire/écrire), et l'autre dans laquelle tu mets ou récupère les données. Généralement ces 2 adresses sont consécutives. Pour gagner du temps, on peut faire une seule écriture 32 bits qui écrit l'index et les données, mais ça ne marche correctement que si c'est l'adresse d'index qui est écrite en premier.

Zerosquare (./41) :
Exemple : certains périphériques qui possèdent plusieurs registres internes n'utilisent que 2 adresses externes : une qui sert d'index (le numéro du registre interne à lire/écrire), et l'autre dans laquelle tu mets ou récupère les données. Généralement ces 2 adresses sont consécutives. Pour gagner du temps, on peut faire une seule écriture 32 bits qui écrit l'index et les données, mais ça ne marche correctement que si c'est l'adresse d'index qui est écrite en premier.

Et à supposer qu'il n'y ait pas de latence à la modification de l'index au niveau dudit périphérique externe aussi, non ?

Exact. C'est en général le cas, mais il y a des exceptions.