picol Le 01/10/2002 à 14:13 je suis d'accord avec timad
C'est ce que j'allais dire... Donne donc des exemples !
Si j'étais comme le sont TiMad et Thibaut et d'autres personnes, je pourrais dire que TiMad ne doit pas prendre son cas pour une généralité...
Mais je ne le dirai pas, car ce n'est pas forcément vrai.
Mais, tout dépend de ce qu'on appelle mal programmé:
- si c'est que ce n'est pas programmé en assembleur ultra-optimisé à la main, d'accord (encore que les programmes kernels ne soient pas forcément extrêmement
bien optimisés, la macro ROM_CALL est il me semble *assez* inefficace).
- si c'est que c'est buggé, ce n'est tout simplement pas vrai. Et si c'est ça que tu veux dire, je te donne le conseil de regarder la poutre qui est dans ton oeil, plutôt que la paille qui est dans l'oeil du voisin: il me semble que **** n'est pas exempte de bugs...
Mais en utilisant un bsr.s ROMCALLX (...) ROMCALLX: jmp rom_callx en kernel, on y gagne par rapport à l'optimize_rom_calls.
> Attends, tu viens de dire une bêtise là. L'appel standard de ROM_CALLs en mode kernel est jsr doorsos::toto. Mais c'est quand-même inefficace par rapport à
> OPTIMIZE_ROM_CALLS.
Ah, je me suis probablement mélangé entre la macro ROM_CALL (dont tu disais qu'elle était peu optimisée, quand on parlait de l'optimisation de uninevhk), et le ROM_CALL en mode kernel...
La version _nostub est plus efficace en taille, mais pas vraiment en vitesse. Et tu as cité le pire cas pour le _nostub (pas OPTIMIZE_ROM_CALLS...)
Par contre, je ne comprends pas pourquoi faire un bsr puis un jmp. Ca prend plus de temps et de place !
Le plus intéressant en vitesse et en taille, est jsr tios::toto, l'adresse de tios::toto étant mise dans le jsr par le programme lui-même, au commencement. Pour un nombre de ROM_CALLs suffisamment important, la taille de la routine de relocation est faible par rapport à la taille des ROM_CALLs, et cela ne nécessite pas de kernel, puisque c'est le programme qui le fait tout seul...
