Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Point de vue : Pourquoi Amithlon était aussi rapide ?
(Article écrit par Bernd Meyer et extrait d'AmigaWorld.net - février 2023)
|
|
NDLR : dans un fil de discussion sur le forum
d'AmigaWorld.net, l'auteur d'Amithlon/Umilator, Bernd "Umisef" Meyer a donné quelques informations sur
les raisons de la si grande vitesse de son émulateur Amithlon. En voici une traduction :
La raison pour laquelle Amithlon (et par filiation, Umilator) étaient si rapides est que, malgré de
nombreuses affirmations contraires, il ne s'agit pas seulement d'UAE avec l'émulation des puces spécialisées.
Dans le compilateur à la volée (JIT) d'UAE, qui doit s'adapter à tout système d'exploitation sous-jacent, les accès à la mémoire
en mode haute compatibilité sont effectués par consultation d'une table et appel de fonction. En mode "accès
direct à la mémoire", ils sont toujours effectués de cette manière pendant la phase initiale de précompilation,
et le JIT enregistre simplement s'ils utilisent la mémoire ou quelque chose de spécial. Ensuite, au moment de
la compilation, les instructions qui accèdent à la mémoire sont supposées toujours accéder à la mémoire.
Et la mémoire est allouée par le système d'exploitation hôte à des adresses qui ont un décalage constant par
rapport aux adresses de l'Amiga, de sorte que l'accès à la mémoire doit "simplement" ajouter ce décalage.
Dans Amithlon, le système d'exploitation hôte joue plutôt le jeu avec l'émulateur. Les adresses que l'Amiga
émulé voit sont les mêmes que celles du côté x86 : pas besoin de décalage. Ce qui est problématique, car certaines
des adresses que l'Amiga considère comme très fermes sont celles où un PC de l'ère 2001 attribue
le bus PCI par défaut. Donc une des premières choses qu'Amithlon fait au démarrage est de réattribuer
tout l'espace PCI ailleurs.
Et ce sont tous les accès à la mémoire qui utilisent simplement la même adresse dans l'espace d'adressage
x86. Tout ce qui n'est pas un accès à la mémoire ou à la ROM est géré par la MMU, et le gestionnaire approprié
est appelé de cette façon.
De plus, dans UAE (du moins à l'époque), l'état de l'émulation des puces spécialisées est mis à jour
dans le fil d'exécution principal : ce qui signifie que le JIT doit garder une trace de la quantité de
travail qu'il a effectué, et occasionnellement, sortir pour faire avancer cette émulation. La même chose
s'applique aux interruptions 68k : si l'une d'entre elles se produit, le code JIT doit être quitté ; et
savoir si l'une d'entre elles s'est produite (par exemple à cause d'une entrée clavier) nécessite également
une vérification périodique avec le système d'exploitation. Et bien que j'aie réduit l'effort de suivi
autant que possible, cela, et surtout la vérification, a vraiment ralenti les choses (la vérification, par
nécessité, écrase les drapeaux, donc tous les drapeaux 68k qui sont maintenus dans les drapeaux x86 à ce
moment-là doivent être sauvegardés, et plus tard restaurés : ce ne sont pas des opérations rapides).
En revanche, dans Amithlon, les puces spécialisées qui restent (principalement les CIA) ont leur état
calculé à la demande, à partir du compteur de cycles du x86. Et toutes les interruptions 68k sont en fait
des interruptions du côté x86, qui sont ensuite transmises à l'émulateur comme des signaux (c'est-à-dire
qu'elles interrompent réellement l'exécution du programme). Elles nécessitent toujours une sortie bien définie
du code JIT, mais cela est réalisé en saupoudrant des instructions JSR dans tout le code, à une adresse qui
contient généralement simplement un RET. Ce genre de chose est incroyablement rapide, car tout est mis en
cache. De plus, cela ne gâche rien. Donc, si une sortie est nécessaire, le RET est remplacé par un JMP vers
un endroit qui sait comment chercher où se trouve le code correspondant pour dérouler l'état d'émulation
pour un JSR donné, remplace l'adresse de retour sur la pile par celle-ci, puis effectue un RET. C'est
douloureusement lent, bien sûr, car il s'agit d'un code auto-modifiant, et le remplacement de l'adresse de
retour provoque une prédiction erronée du cache correspondant : mais quand le processeur est incroyablement
rapide, les interruptions sont si (relativement) rares que cela n'a pas d'importance.
Il y a beaucoup d'autres bidouilles de ce genre. Certains sont très intelligents. D'autres sont vraiment
horribles, impliquant de méchantes bidouilles dans le noyau lui-même, FFS, et j'en aurais honte :
sauf pour le simple fait qu'ils font leur travail, ils rendent les choses plus rapides.
Construire ce genre de collection de bidouilles bizarres et merveilleuses, sans aucune restriction,
était très amusant. Pourtant, le résultat a donné à Amithlon des performances supérieures d'une ou
deux générations de processeur à celles d'UAE. Ou peut-être même trois, dans un bon jour. Nous
sommes maintenant en 2023, et nous avons, quoi, une douzaine de générations de processeurs de plus,
et il n'y a pas vraiment eu de développement de logiciels 68k entre-temps. Donc, tout ce qu'Amithlon
pouvait faire en 2002, UAE peut facilement le faire plus rapidement aujourd'hui, sans aucune des méchantes
bidouilles, et avec au moins la possibilité d'augmenter la compatibilité.
|
