• naur
    link
    fedilink
    Polski
    arrow-up
    1
    ·
    1 month ago

    Z wypowiedzi wynika, że 8087 dekodował rozkazy równolegle z CPU. Bardzo mnie to zaskoczyło, bo dekoder x86 nie jest prosty ani tani w implementacji (chociaż może w tamtych czasach jeszcze taki był).

    Z innej beczki, kazałem AI zaimplementować 128-bitowe floaty używając typu double i dostałem w wyniku stronę demonstracyjną w React.
    Wszystko spoko, tylko na ostatnim etapie obliczeń wartości były chamsko konwertowane z powrotem do pojedynczego double i traciły całą precyzję. Przecież nawet student uczący się programowania nie popełniby takiej głupoty.

    • サぺルOPM
      link
      fedilink
      Polski
      arrow-up
      1
      ·
      1 month ago

      Zawsze mi się wydawało, że CPU kiedy otrzymał nielegalny rozkaz, generował jakiś sygnał. Ten sygnał odczytywał FPU i uznawał, że to co został odczytane z linii danych to jego rozkaz. Jeśli to nieprawda to zawsze mogli skopiować część dekodera, która była potrzebna do odróżniania rozkazów. Trzeba sobie powtórnie poczytać Ken Shirriff’s blog

      Trzeba było napisać, że nie podoba ci się taki wynik.

      • naur
        link
        fedilink
        Polski
        arrow-up
        1
        ·
        24 days ago

        Dzięki za przeanalizowanie tematu. Ten schemat wykrywania ma sens w przypadku procesorów, które odczytują rozkazy bajt po bajcie. Pewnie dlatego 486 i późniejsze miały już wbudowane FPU.

        ModR/M zależy od opcode’u. Niektóre rozkazy go wymagają, inne nie. Na przykładzie NOP: https://www.felixcloutier.com/x86/nop

        • サぺルOPM
          link
          fedilink
          Polski
          arrow-up
          1
          ·
          23 days ago

          Okazało się, że intel produkował przynajmniej jeszcze jeden koprocesor, który komunikował się w ten sam sposób: 8089 - i/o coprocessor. Jeszcze nie czytałem na jego temat zbyt wiele. Ma całkiem dużo zastosowań. Zobaczyłem, że ma lepszy schemat w którym linie Sn są połączone bezpośrednio z procesorem i z kontrolerem magistrali. Więc xPU może za ich pomocą wykrywać kiedy jest opcode, a kiedy coś innego. Wcześniej na podstawie diagramu w dokumentacji 8087 wydawało mi się, że niezależnie trafiają do kontrolera magistrali.

          Dzięki za tę stronę. Nie ma tam wyszczególnionych rozkazów ESC, ale są F*. To co pierwsze co rzuciło mi się w oczy, są dwubajtowe. Ten drugi bajt to różne modyfikacje ModR/M? Dzięki niemu generowane są chyba całkiem różne instrukcje.

    • サぺルOPM
      link
      fedilink
      Polski
      arrow-up
      1
      ·
      29 days ago

      Postanowiłem zbadać temat.

      Najpierw zostałem zgwałcony umysłowo przez haluny AI. Jestem bardzo zawiedziony.

      Nie znam się zbyt dobrze na kodzie maszynowym x86 i na protokole magistrali 8086. Staram się tego nauczyć. Napisz sprostowanie jak by co.

      8086 ma wyprowadzenia które pozwalają określić jaki rodzaj danych pobrał przez magistralę (Sn). Ma też takie które pozwalają określić co jest w jego wewnętrznej kolejce (QSn). Ma też sygnały które pozwalają przejąc magistralę przez zewnętrzny układ (RQ/GTn).

      (Mocno uproszczone)

      8087 wie kiedy 8086 pobiera opcode. Sprawdza jaki jest jego kod. Jeśli jego kod to jeden z zarezerwowanych rozkazów ESC (0xD8…0xDF), to znaczy, że jest to rozkaz dla FPU. CPU traktuje je jak NOP. Tych opkodów jest 8 więc można łatwo je wykryć.

      (Wiedza niepotwierdzona)

      8087 wie o ModR/M. Kiedy rozkaz (ESC) ma argument adresu, procesor pobiera pierwszy bajt (do niczego go nie wykorzystuje). FPU kopiuje adres tego bajtu, przejmuje magistralę i sam pobiera resztę bajtów/słów w zależności od typu.

      Czego jeszcze nie rozumiem:

      • ModR/M (nie wiem jak to współpracuje z opcodami, czy jest opcjonalne czy co?)
      • Nie mogę znaleźć schematu IBN (#PDK) 5150 na którym jest pokazana podstawka pod FPU. Chciałbym zobaczyć jak sygnały są podłączone w rzeczywistości. Szczególnie QSn i Sn.
      • Sygnały Sn wskazują jaki rodzaj danych pobiera procesor. Wydaje się, że FPU z nich nie korzysta. Są chyba wykorzystywane do arbitrażu współdzielonej magistrali.
      • Sygnały QSn przedstawiają stan kolejki procesora i FPU z nich korzysta i chyba określa za ich pomocą czy na magistrali jest opcode. Przynajmniej tak mi się wydaje, bo są podłączone bezpośrednio między CPU i FPU.

      Czego jeszcze chciałbym się dowiedzieć:

      • Podobno FPU Wietek miały jakieś ulepszenia. Podobno dostęp do kolejki rejestrów FPU był obszarem w pamięci lub i/o.
      • Jak działało FPU 68k.