L’ABI System 5 sous OS4 et MOS ?

[krabob]

krabob

#1021

[edit]Bon j’ai renommé le titre du thread qui avant était: la pile de l’OS4 bat celle de MOS a plate couture vu qu’elles ont la même ABI au derniére nouvelle. (mais sont pas forcément géré pareil ensuite au niveau mémoire selon le systeme.) [/edit]

J’avais entendu dire sur un thread une fois un truc ressemblant à: “GrimReaper c’est rien d’autre qu’une interface pour afficher la trace de debug de gcc.”

Ben c’est pas vrai, ça fait bien plus. Explication au pays merveilleux des pile des taches. Chaque tache posséde une zone mémoire appelé “pile”. Au sens informaztique une pile suit une logique “dernier rentré, premier sorti.”

Quand un programme s’execute, il saute de fonctions en fonctions, quand une fonction est terminé, le prog reviens a la fonction d’ou il est parti . La pile lui sert a marquer la ou il doit revenir une fois la fonction finie, mais aussi tout le contexte de la fonction quitté(registres,…) ainsi que les parametres passé a la fonction ou on va se rendre. (ou pas, selon le mode de saut et l’ABI (ce que dis le systeme.). Si une fonction A lance une fonction B qui elle meme lance une fonction C, la pile va etre déplié 2 fois.

Voilà. Tout les sytemes PPC (warpos, powerup,mos,os4) décrivent ce qui doit etre écrit dans la pile lors d’un passage de fonction.

En 68000, on devait ecrire trés peu de chose dedans.

Dans les ABI wos,pup et mos actuelle, on écrit plus, mais juste le necessaire: les parametres d’entrée peuvent passer par les registres sans écriture par la pile. dés lors, la signature d’une fonction (description des parametres passé) décident de la longueur de pile a déplier pour passer ces parametres. donc aucune fonction ne déplie la pile de la meme façon, pour les ABI actuelle, a part OS4:

l’OS4 déplie UN MAXIMUM LA PILE A CHAQUE SAUT DE FONCTION, MAIS AVEC UNE LONGUEUR CONSTANTE a chaque fois ( laquelle est multiple de 128). et ECRIT TOUT LES PARAMETRES a l’interieur.

Quand j’ai apris ça, j’ai hurlé.[edit aprés précision de henes]henes disait que l’os4 est lent par design pour d’ autres raisons, au niveau de l’emu 68k. [/edit] [ancienne version: Et C’est la raison pour laquelle henes disait que l’os4 était “lent par design”.]

Mais en fait, si ON COMPREND BIEN COMMENT MARCHE UN POWERPC ET SA CACHE, en réfléchissant une minute… ça ownz completement !!! quand une tache OS4 plante, meme sans mode debug, meme dans une sous-sous-sous fonction, grim reaper peut afficher l’historique des fonctions qui ont lancé la fonction coupable (ce qui serait impossible avec un systeme de pile mouvante classique comme sur les autre ABI) ET magie parmis les magies, il peut afficher les valeurs de parametres passé a toutes ces fonctions puisque qu’IL SAIT OU ELLES SE TROUVENT. (meme avec un algo récursif !!) et ce sur n’importe quel tache. quel confort !

Mais me diriez vous, ça fait énormément d’accés mémoire en plus et de mémoire utilisé, ça doit ralentir tout ça ! ->NON car la pile est toujours dans la datacache, ça signifie que les lectures/écritures réalisé dans la pile NE PASSENT PAS PAR LES BUS. de plus les lignes de cache de la pile qui reste non touché ne sont pas chargé non plus ! c’est carrément brillant et complétement adapté au PPC et a ses derniéres évolutions ! Brilliant !

(Voilà. Fallait pas m’énerver avec DCBZ sans raison. )

[breed]

breed

#26111

Krabob: tu es beau!

[anonyme]

anonyme

#26112

Krabob la tête bruler d’Hyperion

Krabob, en plein cours de “Système d’exploitation” a l’IUT

[Kokin0u]

Kokin0u

#26113

Moi, j’y connais rien, mais je suis d’accord avec Krabob

[thefab]

thefab

#26115

ah mais je comprend tout de suite mieux pourquoi il faut

systématiquement un ‘stack 15000000000’ pour les programmes os4

[gindrou]

gindrou

#26116

>> rim reaper peut afficher l’historique des fonctions qui ont lancé

>> la fonction coupable (ce qui serait impossible avec un systeme

>> pile mouvante classique comme sur les autre ABI)

Là Krabob je ne te suit plus.

Dépiler la pile d’un programme planté, a la manu, comme rim semble le faire a ce que j’ai compris, ne pourrait pas être réalisé sur MOS SAUF si on rajoutait une donnée indiquant la taille lors des fonctions appellantes. Ton avantage de OS4 serait caduc avec en plus, cache2 ou pas, du travail supplémentaire, car pile plus grande, donc perte de temps.

me trompe-je ?

[anonyme]

anonyme

#26117

@grindou:

Petit précision, le log de MorphOs quand un soft hit te fournit les

derniere fonction éxécuté sur la pile (mais il y a pas les

parametres).

Bye

[slobman]

slobman

#26118

Hip !!

Et c’est pour ça que hyperion ne sait pas faire de pile auto expandable…

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 ?)

[anonyme]

anonyme

#26120

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

[CLS2086]

CLS2086

#26121

Et les stack overflows ??

ça les gere comment ??

[SoundSquare]

SoundSquare

#26122

et les stacks hachés ?

/me prend ses cliques et ses claques et sort

[anonyme]

anonyme

#26123

en fin de compte, nous les pegosiens on s’est fait enflés et c’est les amigaoners qui ont gagnés ??? si c’est le cas, arghhh… encore une erreur de jugement avec l’achat de mon pegasosG4… arf… le monde de l’amiga, c’est terrible…

[sg2]

sg2

#26124

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

[baron]

baron

#26125

Salut.

Moi je dit respect, bravo

Baron-Avoine

[sg2]

sg2

#26126

(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