L’ABI System 5 sous OS4 et MOS ?
-
Krabob: tu es beau!
Krabob la tête bruler d’Hyperion
Krabob, en plein cours de « Système d’exploitation » a l’IUT
Moi, j’y connais rien, mais je suis d’accord avec Krabob
ah mais je comprend tout de suite mieux pourquoi il faut
systématiquement un ‘stack 15000000000’ pour les programmes os4
slobman a écrit :
Hip !!
Et c’est pour ça que les pauvres micro AOne avec leur pauvre petits 256 mo de ram vont vite se retrouver en occase ou au fond du garage…
!! qiH
(ben quoi, c’est un forum guéguérres oui ou non, j’ai pas le droit de faire du pessimisme extrème ?)
Lol ptdr……
/me qui sort et qui va se coucher
Bravo Krab’, tu as tout compris de l’intérêt d’un rigid stack frame (que nous n’avons évidemment pas inventé pour os4, hein
.C’est aussi ce qui permet à un programme Win32 crashé dans un debugger, de ressortir la pile d’appel des fonctions jusqu’en haut, idem sous Linux etc.
Ca mange évidemment plus de RAM que d’empiler à la mimine les 2 registres 68k utilisés dans une fonction, mais ça rend n’importe quel post mortem debuggable, comme tu l’as fort bien compris, que l’exécutable soit avec ou sans symboles de debug.
C’est effectivement aussi la principale raison pour laquelle un exécutable os4 a besoin de plus de pile que son équivalent 68k (et c’est aussi pourquoi on a passé la taille de pile par défaut de 4 k à 32 k).
Mais ce trade-off ne se discute pas quand on voit comment n’importe quel crashlog généré par GrimReaper devient instantanément une explication « le module X s’est planté à la ligne Y de la fonction Z, elle même appelée par la fonction etc. », et de toute façon tous les OS modernes ont adopté cette façon de faire. C’est aussi pour ça que l’usage des registres est imposé par l’ABI.
Enfin, pour compléter ton explication, en sus du stackframe standard, os4 détecte le premier appel à une instruction Altivec dans une tâche, et à partir de là, ajoute les regs altivec au stackframe de cette tâche (ce qui représente quand même 512 octets en plus par stackframe
.Ainsi ces regs ne sont pas sauvegardés quand ce n’est pas nécessaire. Je ne me rappelle plus si on a aussi fait ça pour les registres FPU, je crois que oui, car si je m’en rappelle bien, le PPC peut générer une exception sur les instructions FPU comme pour les instructions Altivec.
Au passage, si Crisot cherche encore comment optimiser un memcpy(), si je me rappelle bien, il est possible de pomper les données par paquets de 512 octets d’une manière très efficace… en les faisant justement passer par les regs Altivec, en utilisant les instructions qui permettent de les dépiler (mem -> regs) et de les empiler (regs -> mem) !-)
OS4 utilise les registres FPU de cette manière pour faire son CopyMem
Ajout de dernière minute : c’est aussi pourquoi sur PPC il vaut mieux limiter le nombre de fonctions et en augmenter la taille, pour éviter de passer son temps à empiler / dépiler.
Amigo,
—
Stéphane
Salut.
Moi je dit respect, bravo
Baron-Avoine
(en réponse à cls2086 qui demande « comment on gère le stack overflow ») :
Pour l’instant, pas
Mais voici la réponse et en même temps le principe de l’auto stack expander :
– OS4 utilise un système d’adressage virtualisé, c’est à dire qu’il gère un stock de pages physiques, qui sont affectées aux demandeurs à la demande (== allocation mémoire), et remises dans le stock à la libération mémoire. On va nommer le passage du stock aux applications le ‘mappage’ et le retour au stock le ‘unmappage’.
– lorsqu’une application essaye d’accéder à une adresse mémoire qui n’est pas dans une page mappée, ça provoque une exception MMU (alias erreur de type ‘DataStorageInterrupt’ dans le cas d’un accès à une donnée, par exemple déréférencement d’un pointeur invalide, ou bien ‘InstructionStorageInterrupt’ dans le cas d’un accès à une instruction, par exemple jump à une adresse invalide).
– les piles sont allouées à la création de chaque tâche, de manière à ce que la dernière page mappée par la pile soit suivie d’un « trou » dans lequel il n’y a pas de page mappée.
Ainsi, (quand on aura le temps et rien de plus urgent à faire), on ajoutera un handler d’exception, qui traitera le cas d’un DSI dans ce trou, et qui mappera une ou plusieurs pages en plus dans la pile, ce qui réalisera l’auto stack extension qu’on a promise.
Pour l’instant, ce handler n’existe pas, donc quand il y a débordement de pile, dans la plupart des cas ça se termine en grim reaper de type ‘DSI’ (et l’analyse des registres PPC permet de savoir pourquoi
Pour être complet, OS4 alloue les piles au milieu d’un espace légèrement plus grand, en mettant juste en dessous et juste au dessus, quelques octets contenant une signature particulière, qui, par magie du rigid stackframe, ne peut pas être issue d’un empilage
C’est ce qu’on appelle la ‘redzone’. Lorsque cette redzone a été écrasée, on sait, même sans DSI, que le programme a débordé de la pile allouée. C’est pourquoi un grim indique toujours ‘redzone damaged’ ou non.
Amicalement,
—
Stéphane
- Vous devez être connecté pour répondre à ce sujet.
