Coder sur la Vampire

15 sujets de 1 à 15 (sur un total de 20)

  • 1
  • 2
  • Mod

    amigaouf

      #297819

      Hello

      je propose de parler ici de tout se qui concerne le code pour ses carte

      et vu que j y connais rien je vous laisse le champs libre

      __sam__

        #297828

        Edit:
        Moveq #imm est en effet plus court que add.l #imm. 1 byte au lieu de 4. Mais n a t on pas ADDQ.L pour ca ?

        Avec addq tu est limité aux valeurs -8..-1 et 1..8. C’est pas mal, mais si tu dois faire un addq.l #12,d0, vaut-il mieux faire 2 addq (un de 8 puis un de 4), un seul addl de 12, ou un moveq + addl reg,reg ?

        Tiens ca me fait penser que c’est des trucs comme ca que j’avais codé dans Popt pour 030/040 il y a longtemps sur aminet: http://aminet.net/package/dev/asm/popt Si je retrouve les sources et les docs utiles sur les nouvaux 68k ca serait cool de l’adapter au 060 et 080!!

        Samuel.

        Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
        A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
        A500 Vampire V2+ ^8^ 🙂
        (mais aussi TO8, TO8D, TO9. Groupe PULS.)

        seg

          #297829

          @sam
          Je viens de tester ma version de quake sans optim (juste la c2p et le sin/cos en asm), et j’obtiens 5.5 fps en AGA.

          J’ai la version 1.01 des sources.

          Sinon, pour info, on peut trouver les derniers sources officiels ici: https://github.com/id-Software/Quake/tree/master/QW/client

          [EDIT] Sans optim cos/sin, j’obtiens 5.2 fps. (dans les 2 cas, je vire le shell quake maintenant)

          flype

            #297833

            @Sam
            En cas de doute sur ce genre de question, il y a sur le 080 un compteur de cycles temps réel (que CPUMon080 utilise) qui permet de savoir ca. Je testerai à l’occasion.

            A600 Rev 1.5 + Vampire 600 V2-128.
            A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.

            thellier

              #297837

              >moveq.l #20,d0
              >add.l d0,d1

              >est mieux que

              >add.l #20,d0

              >alors que j’ai cru comprendre que sur 080 la 2e version est mieux
              >car elle fait tout sur une seule instruction (Gunnar m’a indiqué
              >que les « long » operation prennent toutes 1 seul cycle.)

              Probablement que la 1ere version se fait aussi sur 1 cycle grace au superscalaire avec une instruction par coeur
              Enfin je suppose

              Alain

              flype

                #297839

                Oui je suppose pareil (sur 060 et 080), sur 080 le “add.l #imm,Dn” a pour avantage d’économiser un registre. Bref, je me prends pas autant la tête en codant, j’ai tendance à coder ‘standard’.

                A600 Rev 1.5 + Vampire 600 V2-128.
                A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.

                __sam__

                  #297840

                  Si la 1ere version se fait sur 1 cycle elle n’est pas optimale car je pense que
                  [code]
                  moveq #12,D0
                  add.l d0,D1
                  ori.l #nn,D2
                  [/code]
                  se fait en 2 cycles. Le “ori” coute par ici! Alors que:
                  [code]
                  add.l #12,D1
                  ori.l #nn,D2
                  [/code]
                  se fait en un 1 cycle. Le “ori” est gratuit!

                  Donc quelque part la 1ère version est localement aussi bonne que la 2nde, mais globalement moins bonne que cette dernière quand on regarde le superscalar dans sa totalité, c-à-d avec les instructions qui suivent.

                  Samuel.

                  Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
                  A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
                  A500 Vampire V2+ ^8^ 🙂
                  (mais aussi TO8, TO8D, TO9. Groupe PULS.)

                  seg

                    #297841

                    Sur 060, comme sur 080 j’imagine, il faut coder en une instruction. Peu importe sa taille, surtout sur le 080.

                    Il faut se concentrer sur l’entrelacement des instructions uniquement. Et sur le 080, c’est encore plus poussé puisqu’il propose “l’instruction bonding”, ce que le 060 ne fait pas.

                    Cette techno permet au 080 de considérer 2 instructions consécutives comme une seule et même instruction. Bien entendu, tout dépend des cas de figure.

                    Par exemple, un move.l #1,d0 suivi d’un add.l d0,d1 sont traitées ensemble alors que l’une dépend de l’autre.

                    flype

                      #297852

                      Test de 100 itérations sur 080 :

                      https://usercontent.irccloud-cdn.com/file/Emh5LddV/image.png

                      Test #1 montre : 2 instructions = 2 cycles (donc pas de fuse/bond sur ce cas)

                      Test #2 montre : 1 instruction = 1 cycle

                      A600 Rev 1.5 + Vampire 600 V2-128.
                      A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.

                      seg

                        #297853

                        @flype
                        T’as essayé avec un move.l et pas un moveq?

                        Sinon, en cherchant sur internet, j’ai trouvé un mec qui traite le “fusing”: http://forum.apollo-accelerators.com/viewtopic.php?t=1702

                        Pour le “bonding”, pas grand chose. Juste ça: http://wiki.apollo-accelerators.com/doku.php/cpu_bond

                        flype

                          #297860

                          @seg

                          Oui c’est pareil. 1 cycle comme moveq.

                          Moveq est juste plus court dans le binaire compilé.

                          Et ca restera toujours une bonne pratique d’utiliser moveq aussi souvent que possible pour par exemple faire des branchements avec bcc.s au lieu de bcc.w

                          A600 Rev 1.5 + Vampire 600 V2-128.
                          A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.

                          seg

                            #297881

                            @flype
                            Tu peux demander à Gunnar pourquoi le “bonding” ne fonctionne pas dans ce cas de figure?

                            Sinon, je confirme et je signe, il est quasiment peine perdue d’optimiser la taille des instructions sur 060 (idem sur 080 surement). Ce cpu est une merveille pour l’époque.
                            Avec la prédiction de branchement, un bcc.b ou un bcc.w, c’est négligeable.

                            En revanche, si tu veux que ton code assure sur un 040 ou un 030, tu peux respecter ton principe.

                            Pour l’anecdote, j’ai passé un temps fou à convertir en asm mon émulateur 6809 que j’avais fait en C. Je l’ai pensé pour reproduire au mieux les performances d’un vrai 6809, tout en facilitant l’exécution des instructions par le cpu. Et bien cet ingrat de 060 s’en branle. Que tu codes bien ou mal, il se démerde comme un dieu. J’ai évidemment gagné des cycles, mais c’est peanuts par rapport au temps passé. En revanche, le gain était très perceptible sur 030.

                            J’ai eu la même expérience avec un moteur 3D perso.

                            seg

                              #298506

                              Le document est léger mais c’est un début. La Team vient de publier un document sur les nouvelles instructions du 68080.

                              Il est visible ici: http://www.apollo-core.com/AMMXQuickRef.pdf

                              Il y a l’instruction c2p…

                              Source

                              __sam__

                                #298507

                                Comme il manque les timings, j’ai demandé des précisions à Gunnar. Si j’ai bien compris toutes les instructions AMMX (ou presque) font 1 cycle + 1 cycle de latence. Donc en pratique elles prennent 2 cycles, mais en utilisant bien le pipeline ca peut descendre à 1 si je comprends bien. A comparer aux 2 instructions/cycles quand on fait du calcul entier. Mais là on fait du parallèle, donc on gagne en perfs au final.

                                Samuel.

                                Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
                                A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
                                A500 Vampire V2+ ^8^ 🙂
                                (mais aussi TO8, TO8D, TO9. Groupe PULS.)

                                seg

                                  #298512

                                  Merci pour la précision sam.

                                  Il manque aussi les opcodes utilisés. Ça n’intéresse personne, sauf moi…

                                15 sujets de 1 à 15 (sur un total de 20)

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

                                Forums AmigaOS, MorphOS et AROS Développement Coder sur la Vampire

                                Amiga Impact