L’ABI System 5 sous OS4 et MOS ?

15 sujets de 31 à 45 (sur un total de 81)

  • krabob

      #26144

      A moins que vous arriviez à me prouver que l’une, n’est aucunement néfaste pour l’autre… ce que je doute personnellement.

      c’est fait plus haut, et c’est pourquoi c’est si étonnant. Rappel:

      – Permet de tracer la totalité des appels depuis le main, avec les param de chaque fonctions.

      – bouffe (un peu) plus de mémoire en RAM mais en économise a terme dans sa forme finale.

      – est aussi rapide, de par le fonctionnement du cache PPC.

      et tient aussi: on dirait (pas sur) qu’avec l’application.library de l’os4, un developeur peut faire serveur et recevoir les logs de plantage d’utilisateurs lambda par le net.

      Yomgui

        #26145

        krabob:

        Non c’est pas si étonnant car tu ne répond pas à ma question véritablement.

        – Ca je trouve que c’est un faut-argument… car on peut très bien pratiquer un débug suffisent sans à avoir la totalité des valeurs des paramétres… il suffit pour cela de programmer propre… Je veux dire par là d’implémenter des bout de codes (assert?) permettant de vérifier déjà que les paramétres sont ‘conforme’ à ce que l’on attend (genre pas de pointeur Null, etc…). Ces bouts de code peuvent être des macros, définies uniquement par flags de compile, et ainsi disparaitre lors de l’élaboration de la version ‘utilisateur’. Ensuite si c’est un pb d’une valeur d’un paramétre étant ‘bonne’ mais non véritablement attendue alors là il faut faire du pas-à-pas pour voir comment on arrive à ce résultat… et là ce qui nous manque ce sont des véritables outils pour cela. Car il faut bien voir une chose: c’est pas parceque tu sais que tu as un paramétre incorrect (or cas des trucs genre pointeurs Null & Co.) que forcement tu sais immédiatement d’où ça vient et comment le corriger. Donc tracer dans la pile toutes les valeurs des paramétre est pour moi comme sortir le buldozer pour écraser la mouche.

        – bah si je comprend bien, la quantité de mémoire bouffée est directement proportionnelle à la profondeur des fonctions? En général c’est pas énorme (si on design bien son code…plus qu’on ne “code” bien)

        – Les explications du point 3 ne me conviennent pas du tout mais bon… (je veux dire par là: on ne cache pas tout, et les switch de context sont nombreux, d’autant plus que le système est réactif ;-))

        anonyme

          #26146

          En tout cas moi j’ai un peu lu le thread et j’abandonne.

          Quand je vois certainnes réactions ou encore des SAS dont la grande connaissances des Os et dont les capacités de codeurs ne sont plus à démontrer dire qu’un “grand nombre de mensonges se cachent”…

          Krabob, SG2, je vous respecte. Mais pour certains utilisateurs ici, l’algorythme de réponse est:

          Si: “un point d’Os 4 est kick ass”: Alors: “répondre ‘mensonge’ “.

          Partant de ce principe, effectivement, beaucoup de mensonges se trouve dans ce thread, pour et selon certains.

          Tex

            #26147

            a quand un driver lexmark pour nos amiga et compatibles ?! ;)

            en meme temps je préfère Canon :)

            henes

              #26148

              Linux, PowerUP (ppc.library), MorphOS et OS4 utilisent la même ABI SystemV et donc le même format de StackFrame.

              Ce qui est vrai pour l’un l’est pour les autres: Linux, PowerUP et MorphOS permettent de connaître l’historique des fonctions appelantes, même sans mode debug etc etc…

              La meilleur preuve de ce “etc” est peut-être qu’il suffit de prendre un compilateur GCC produisant du code PPC prévu pour Linux et de lui faire compiler des sources MorphOS, PowerUP et OS4. Les fichiers objets ainsi obtenus seront constitué de code parfaitement fonctionnel sous MorphOS, PowerUP et certainement aussi OS4.

              Que le tout soit compilé en mode debug ou pas ne change rien: le format et les informations restent les mêmes. Vive les normes.

              Le SDK de MorphOS compare d’ailleurs 3 ABI PowerPC, cf:

              SDK:Documentation/Articles/Porting/PowerOpenAPI.txt

              Bien sûr, c’est en anglais et assez technique… mais ce n’est certainement pas une raison pour aller affirmer l’inverse de ce qui y est expliqué.

              Il est assez fantastique de voir un poignée de personnes utiliser des arguments mensongers et arriver convaincre toutes les autres du contraire…

              Presque 40 posts de désinformation anti-MorphOS…

              Ce n’est pas le premier thread “pseudo technique” de désinformation apparu ces derniers temps. C’est triste mais c’est la vie ;-(

              Yomgui

                #26149

                ArticiaRoxx:

                Arrête de te plaindre… c’est le forum guéguerre ici ! X-D

                Yomgui

                  #26150

                  henes:

                  Ah tiens! ça faisait longtemps que je t’avais pas vu sur le forum ;-)

                  edit depuis le 29/9/2004 à 13:39:48 pour être précis ;-). !edit

                  Lanza

                    #26151

                    Ben voilà une précision qu’elle est utile.

                    Bon retour parmi nous henes :)

                    krabob

                      #26152

                      ah ah… effectivement j’étais renseigné du coté OS4, mais pas du coté morphos sur ce sujet. Et je ne savais pas que ces 3 systémes utilisaient la meme ABI. Donc l’intervention d’Henes est informative, mais il reste un énorme doute: dans un message en privée, henes dit que comme OS4=aBI system5, les parametres ne sont pas passé dans la pile (comme sous windows) et que donc “grimreaper” ne peut pas afficher les parametres de l’historique des fonctions. Hors coté OS4 on a entendu que c’était le cas. (sacré difference) De plus, l’ABI coté ABOX est elle la meme que coté QBOX ? henes parle til pour l’ABOX la QBOX ou les 2 ? l’OS4 a til sa propre version de l’ABI system 5 ? bon je materais le doc de l’abi si j’ai le temps.

                      Lanza

                        #26154

                        C’est fou comme certains sont allergiques aux interfaces graphiques :-D

                        Anonyme

                          #26155

                          > ah ah… effectivement j’étais renseigné du coté OS4, mais pas du coté

                          > morphos sur ce sujet.

                          Bouh, honte sur vous maître Krabob, auteur du thread “La pile OS4 bat la pile MOS a plate couture.” :)

                          falcon1

                            #26156

                            /me totalement d’accord,

                            krabob, t’affirmes que X est supérieur à Y, mais tu ne te renseignes pas sur Y????

                            TU SORS et tu ne reviens pas !!!

                            krabob

                              #26157

                              Bon je suis beau joueur, j’ai renommé le thread et expliqué pourquoi dans le 1er post.

                              /me totalement d’accord,

                              krabob, t’affirmes que X est supérieur à Y, mais tu ne te renseignes pas sur Y???? TU SORS et tu ne reviens pas !!!

                              En fait je connaissait l’ABI system5 depuis des lustres, me ‘doutait’ que c’était celle utilisé par mos, et on m’a donné d’autre part une description de ce que faisait l’ABI de l’os4, qui n’était pas 100% raccord. Il reste un flou sur le coup des parametres écrit ou non dans la pile, et le choix que laisse l’ABI system 5 de déplier la pile comme bon semble au systeme. (l’altivec implique une autre sorte de depliage.)

                              Donc -> A SUIVRE. et cherchez bien: je retire rien a ce que j’ai dis.

                              [edit]

                              bon d’accord, je ne savais pas que ces ABI pourtant classique permettait de tracer l’historique de la pile. Et je rajoute que je n’ai pas a être beau joueur, mais juste faire amende honorable. et puis pardon à henes aussi pour lui avoir prété des paroles qui n’était pas sa pensée. le dépliage spécial altivec doit etre une extension prévu meme si pas documenté,ça reste un comportement appliqué par GCC.

                              Mais bon finalement dans cette histoire c bon pour tout le monde: AOS4 et MOS. ya que moi qui est l’air béte. :-( . Bon du coup je rajouterais des liens vers la description des ABI sur mon cours ASM de gurumed.

                              Yomgui

                                #26158

                                Décidement les normes sont faites pour ne jamais êtres respectées!

                                ;-)

                                Yomgui

                                  #26159

                                  StackFrame[-20].LR-> Address 0x20dae5e4 -> MOSSYS:LIBS/muimaster.library Hunk 1 Offset 0x00022874

                                  Comment ça la muimaster.library serait-elle buguée ? X-D

                                  /me va voir ailleur si il y serait pas…

                                15 sujets de 31 à 45 (sur un total de 81)

                                • Vous devez être connecté pour répondre à ce sujet.

                                Forums AmigaOS, MorphOS et AROS Guéguerres L’ABI System 5 sous OS4 et MOS ?

                                Amiga Impact