Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Computer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Czym jest jednostka sterująca ?

Pan Korsarz 15 Gru 2018 23:11 1230 48
  • #31
    BlueDraco
    Specjalista - Mikrokontrolery
    To, co piszesz, ma się niestety nijak do rzeczywistości. Porównanie, jakie się nasuwa - to silnik parowy i elektryczny silnik liniowy. I to, i to jest silnikiem. Jeden ma regulator Watta i zawory pary, drugi - komutator elektroniczny. Naprawdę lepiej byłoby, gdybyś zanim rozpoczniesz dyskusję, zdobył minimum wiedzy o działaniu procesora wielocyklowego i potokowego. Na razie kolejne Twoje posty są świadectwem braku wiedzy podstawowej. Filozofowanie jej nie zastąpi.
    Inna koncepcja, inna zasada działania, inne bloki funkcjonalne - taka jest prawda o tych dwóch pomysłach na realizację procesora, o których tu dyskutujemy (czyli dokładnie odwrotna, niż próbujesz to wmawiać). Procesor potokowy nie ma IR, nie ma MAR ani MDR i nie musi mieć żadnych buforów, które pełniłby podobną rolę. Procesor wielocyklowy praktycznie nie może działać bez tych trzech rejestrów. Proponuję uważną lekturę książki duetu Patterson+Hennessy - może coś Ci się rozjaśni.
  • Computer Controls
  • #32
    Freddie Chopin
    Specjalista - Mikrokontrolery
    stmx napisał:
    W ARM PC nie pokazuje następnej tylko z reguły 8 bajtów na przód.

    stmx napisał:
    Róznice występują jak zaczynamy "robić dziwne rzeczy" z progreamem. Np instrukcje, które sa discardowane na poziomie dekodowania (nop na te przykład) potrafią mocno zmienić te +8. Znalazłem parę takich innych ciekawych rzeczy - ale za dużo by o tym pisać.

    Nie mogę znaleźć oficjalnego potwierdzenia mojej teorii, niemniej jednak uważam że sprawa jest generalnie wyjątkowo prosta i całkowicie deterministyczna. PC zawiera adres wskazujący na dwie _INSTRUKCJE_ do przodu (w przypadku układu z trzypoziomowym pipeline). Ponieważ instrukcje mogą mieć zarówno 2 jak i 4 bajty, tak więc wartość PC jest w zakresie 4-8 bajtów większa niż faktycznie wykonywana instrukcja. Posługiwanie się w tej sytuacji ilością bajtów to prosta droga do pogubienia się.
  • #33
    _lazor_
    Moderator Projektowanie
    Co do 3 poziomowym pipeline to ciężko coś znaleźć bezpośrednio, ale znalazłem info że 3-stage pipeline jest podobny do tego z ARM7:
    https://www.arm.com/files/pdf/CortexM3_Uni_Intro.pdf strona 27

    A w dokumentacji do ARM7 można znaleźć taki zapis:
    "The Program Counter (PC) points to the instruction being fetched rather than to the instruction being executed."

    http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0084f/ch01s01s01.html

    Oczywiście znalazłem jeszcze coś takiego:
    http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0321a/BIHGJICF.html

    Gdzie jest informacja, że jeśli dwie instrukcje są 16bit to mogą zostać fechowane jednocześnie (thumb-2 posiada również instrukcje 32bit).
  • Computer Controls
  • #34
    Użytkownik usunął konto
    Poziom 1  
  • #35
    BlueDraco
    Specjalista - Mikrokontrolery
    To może wyjaśnij jak pogodzić nieobecność w procesorze rejestru R15 zawierającego adres następnej instrukcji z wykonywaniem przez procesor skoków względnych, podczas których do nPC jest dodawana stała zawarta w instrukcji skoku. Jeśli znów nie wierzysz - przyjrzyj się dokładnie sposobowi zapisu instrukcji np. BL w ARM. Nie odkrywam tu nic nowego - tak jest od kilkudziesięciu lat we wszystkich procesorach, niezależnie od ich budowy. Tu nie chodzi o to, jaką wartość zawiera zakopany głęboko w procesorze, niedostępny rejestr, a o to, jaka wartość tego rejestru jest widoczna/dostępna na poziomie modelu programowego - to jest wartość zapisywana przy skoku ze śladem lub używana do wyliczenia adresu docelowego skoku względnego. O ile dobrze kojarzę, w ARM jest to wartość o 4 większa od adresu instrukcji skoku (niezależnie od tego, czy instrukcja ma 2, czy 4 bajty - Freddie popraw, jeśli się mylę).
    Jak już to wyjaśnisz, to następnie wyjaśnij, skąd bierze się wartość zapisywana do LR w instrukcji BX czy BL.
    R15 czyli nPC czyli "logiczny" PC musi istnieć w każdym procesorze. Oprócz niego istnieją w ARM przynajmniej dwa inne PC. Jeden z nich zawiera adres wyprzedzający instrukcję i służy do pobierania instrukcji na zapas - o nim właśnie piszecie. Jest jeszcze jeden dobrze ukryty PC, bez którego procesor nie mże działać - ten pokazujący aktualną instrukcję. W każdym procesorze potokowym taki opis, jako podałem powyżej, jest wciąż nieprecyzyjny, bo przecież procesor wykonuje równocześnie kilka instrukcji. Zwykle opis jak wyżej dotyczy instrukcji w ostatnim stopniu potoku - przynajmniej tak jest przy krótkich potokach, 3..4 stopniowych. Przy 5-stopniowym opisuje się to trochę inaczej, odnosząc wykonanaie do trzeciego lub czwartego stopnia. Przy wielopotokowych jest jeszcze zabawniej...
  • #36
    Użytkownik usunął konto
    Poziom 1  
  • #37
    BlueDraco
    Specjalista - Mikrokontrolery
    No i...? Jakieś wnioski własne?
    Wskazałem Ci trzy przypadki do analizy. Spróbujmy jeszcze raz:
    Jaka wartość PC jest używana przy obliczaniu adresu docelowego skoku względnego?
    Jaka wartość PC jest zapamiętywana przy skoku ze śladem w LR?
    Jaka wartość PC jest zapamiętywana przy wyjątkach synchronicznych (SYSCALL, HardFault)?

    Jak myślisz, skąd biorą się te trzy wartości? Szklana kula, arytmetyka czy kopia z rejestru? Ja pierwszą odpowiedź wykluczam, druga być może jest poprawna w niektórych przypadkach, trzecia jest na ogół poprawna i najbardziej zdroworozsądkowa. Możliwe jest też zachowanie mieszane (>1 rejestr zagrzebany w CPU i arytmetyka) - wydaje mi się, że ARM robi to właśnie tak. Rozwiązanie z jednym rejestrem i arytmetyką jest popularne w RISCach o stałej długości instrukcji; ARM nie należy do tej klasy architektur. Rozwiązanie z trzema PC jest typowe dla CISC - to też niby nie ARM, ale jakby bliżej.

    Spośród tych trzech sytuacji zachowanie ARM różni się tylko częściowo w jednym przypadku od zachowania 95% wszystkich znanych architektur procesorów. W pozostałych jest całkiem standardowe.
    W dotychczasowych postach piszesz, jak bardzo nie mam racji i jak bardzo się ze mną nie zgadzasz, nie wchodzisz jednak w merytoryczną dyskusję.
  • #38
    _lazor_
    Moderator Projektowanie
    BlueDraco, a masz coś co potwierdzi Twoje słowa? Bo pisanie rewelacji bez potwierdzenia swoich słów nie można uznać za merytoryczną dyskusję a bardziej coś pokroju gawędzenia przy piwie.
  • #39
    BlueDraco
    Specjalista - Mikrokontrolery
    A konkretnie co z tego, co napisałem, jest dla Ciebie "rewelacją" i jakiego potwierdzenia oczekujesz? Przecież to wiedza wzięta wprost z przeglądu dokumentacji kilkudziesięciu procesorów. Odpowiedzi na trzy pytania, o PC, które postawiłem powyżej (#37), są b. łatwe do znalezienia w dokumentacji. Nie we wszystkich architekturach są one identyczne, ale w większości - tak. Co można wnioskować o budowie procesora z faktu, że na poziomie oprogramowania posługuje się on dwiema różnymi wartościami PC, a instrukcje pobiera z wyprzedzeniem (do czego jest potrzebny kolejny adres wskazujący instrukcję "na przyszłość")?
  • #40
    _lazor_
    Moderator Projektowanie
    To o czym piszesz nie jest truizmem i aby Twoja wypowiedź była bardziej wiarygodna chciałbym byś wskazał te rzeczy w dokumentacji, zwłaszcza że jest to według Ciebie b. łatwe.

    Temat jest sporny i bez twardych dowodów, wątek zamieni się w obrzucanie kamieniami, a b. łatwe wskazanie zagadnienia w dokumentacji utnie dyskusję natychmiast i wszyscy poszerzymy naszą wiedzę.
  • #41
    BlueDraco
    Specjalista - Mikrokontrolery
    Co jest spornego w tym temacie? Gdzie są dwa różne stanowiska i argumenty na ich poparcie?

    Nie widzę w tej "dyskusji" merytorycznych argumentów za tym, że moje objaśnienie jest błędne, ani prób objaśnienia tego, co widać gołym okiem, w jakikolwiek inny sposób, niż ja proponuję na podstawie tego, co napisano w różnych dokumentach nt. różnych procesorów. Z czym mam więc dyskutować? Gdyby ktoś przedstawił alternatywny punkt widzenia, może bym się z nim zgodził, rzecz w tym, że póki co nawet nie mam się z czym zgadzać.

    Twarde fakty co do różnych zachowań bytu pt. PC przedstawiłem w #37. Obserwujemy w każdym procesorze trzy przejawy działania, w których widać trzy różne adresy instrukcji:
    - pobieranie instrukcji (na zapas - niekiedy nie dochodzi nawet do ich wykonania, więc procesor używa tu przewidywanego adresu przyszłej instrukcji),
    - wykonanie instrukcji skoków i składowanie śladu przy wywoływaniu procedur (używany jest tu adres następnej instrukcji),
    - obsługa niektórych wyjątków synchronicznych, gdy jest zapamiętywany adres bieżącej instrukcji.
    Jak wyjaśnić to, że procesor używa trzech różnych adresów związanych z instrukcjami, a więc z wartością PC?

    Kol. stmx wyjaśnia to bardzo prosto: nie wiadomo, jak to się dzieje, ale moje wyjaśnienie tego fenomenu jest na pewno błędne. Argumentów na poparcie tej tezy dotychczas nie przedstawił.

    Moje wyjaśnienie opieram na tym, co wiadomo o budowie wielu różnych procesorów. W opisach wielu architektur pojawiają się trzy zaszyte w procesorze rejestry, z których jeden jest widoczny w aplikacyjnym modelu programowym jako PC (ten środkowy, oznaczany w budowie wewnętrznej procesora jako nextPC, czyli nPC). Posługując się tym modelem łatwo wyjaśnić i opisać zachowanie większości procesorów. Nie znaczy to, że w każdym procesorze fizycznie muszą istnieć takie trzy rejestry, jednak bez ich istnienia z wyjaśnieniem działania każdego mądrzejszego procesora mamy pewne kłopoty, zwłaszcza, gdy poszczególne instrukcje procesora mają różne długości, a pobieranie instrukcji zachodzi w jednostkach większych niż słowa procesora (oba te przypadki zachodzą w ARM Cortex). Zachowanie Cortexa tylko w jednym aspekcie odbiega od tego modelu - w przypadku 16-bitowych instrukcji skoków względnych. W innych przypadkach zachowuje się zgodnie z modelem.

    W uP 8-bitowych na ogół mamy tylko nPC. w 8086 były pierwsze dwa PC, nie było trzeciego, zawierającego adres bieżącej instrukcji (cPC). Pojawił się on w 80186. Wszystkie trzy występują w całej serii M68k. W prostych RISCach był niby tylko jeden (w zasadzie cPC), ale wartość widoczna dla oprogramowania odpowiada nPC (zinkrementowany cPC); takie rozwiązanie jest możliwe tylko wtedy, gdy wszystkie instrukcje mają jednakową długość.
  • #42
    Użytkownik usunął konto
    Poziom 1  
  • #43
    BlueDraco
    Specjalista - Mikrokontrolery
    W potoku "marnowanie" jest częstsze niż w wielocyklowym, bo każda instrukcja musi przelecieć przez potok tak samo, nawet jeśli nie ma w danym stopniu nic do roboty, więc zaliczyłeś pudło numer jeden.
    Strona w dokumentacji ARM, którą wskazałeś, zawiera informację o "wyłuskiwaniu" instrukcji skoków z przodu potoku, co raczej sugeruje ich wykonanie poza sekwencją - takie rozwiązanie jest spotykane w różnych architekturach (ale przeczy Twojemu zdaniu powyżej o sekwencyjnym wykonaniu - pudło numer dwa).

    Znaczenie skrótu IR jest bardzo dokładnie określone. Jest to REJESTR INSTRUKCJI, przechowujący niezdekodowany lub częściowo zdekodowany obraz binarny aktualnie wykonywanej instrukcji po pobraniu jej z pamięci. IR nie jest "blokiem dekodującym", a jedynie jego elementem. Dekoder instrukcji korzysta z zawartości IR. IR dotyczy wyłącznie procesorów wielocyklowych, takich, jak np. 8080, MC68000 czy 8086. W jednocyklowych jest niepotrzebny, w potokowych równocześnie wykonuje się kilka instrukcji i różne ich kawałki są potrzebne w różnych miejscach procesora, a instrukcja pobrana jest bezpośrednio dekodowana bez potrzeby jej przechowywania, więc żaden IR nie występuje (występują natomiast rejestry potoku, przechowujące szczątki tego, co pozostało po dekodowaniu poszczególnych instrukcji, ale nie używa się tu nazwy IR).
    Pojęcia, których tutaj używamy, nie są płynne i dowolne - mają one b. dobrze zdefiniowane znaczenie w dziedzinie informatyki, jaką jest architektura komputerów, proszę Cię więc o poprawne posługiwanie się nimi, co znacznie ułatwi dyskusję.
    W architekturach OoO "blok dekodujący" jak to nazwałeś, poprzedza część OoO, więc znów popełniasz w swej wypowiedzi poważny błąd terminologiczny.
    Z kolei procesor potokowy różni się od wielocyklowego właśnie zasadą działania, a nie jakimiś "usprawnieniami". W wielocyklowym każda instrukcja siedzi pojedynczo w IR dopóki się nie zakończy, a dane dla tej instrukcji hulają po procesorze w różne strony; w potokowym instrukcja wraz z danymi przesuwa się zawsze tak samo "wzdłuż" procesora, a za nią tą samą ścieżką pełznie w tym samym czasie kilka następnych. Pudło trzecie.
  • #44
    Użytkownik usunął konto
    Poziom 1  
  • #45
    BlueDraco
    Specjalista - Mikrokontrolery
    Zgadza się, wyrób końcowy taki sam, tylko fabryka całkiem inna, a Ty się upierasz, że właściwie taka sama, a obrabiarka CNC to właściwie takie kowadło z ręcznym miechem, tylko trochę lepsze i ten miech się nazywa frez, a może młotek - w końcu to wszystko jedno jaką nazwą określimy obrabiarkę lub jej dowolną część, skoro wyrób ten sam. No i przecież na taśmę produkcyjną też można powiedzieć, że to obcęgi... ;)

    W każdej architekturze potokowej instrukcja wraz ze swoimi danymi (a nie "dane za instrukcją", jak to imputujesz) przepływa przez potok. Nie wiem, ile różnych procesorów programowałeś w asemblerze, ilu budowę znasz i ile sam zaprojektowałeś, odnoszę jednak wrażenie, że chyba nieco mniej ode mnie. Za sugestię dziękuję, doczytam więcej o działaniu potoku ARM w wolnej chwili - dotychczas nie miałem takiej potrzeby.

    To co, podejmiesz się w końcu wyjaśnienia w jaki sposób ARM używa trzech (a właściwie czterech) różnych wartości jednego-jedynego PC do różnych celów - pobierania następnych instrukcji na zapas, wyliczania adresu skoku, zapamiętania śladu przy wywołaniu procedury i zapamiętywania adresu instrukcji, która spowodowała np. HardFault? Bardzo chciałbym poznać ten prosty sposób, nie wymagający takich dziwactw, jak dwa lub trzy różne PC, o których pisałem.
  • #46
    Użytkownik usunął konto
    Poziom 1  
  • #47
    BlueDraco
    Specjalista - Mikrokontrolery
    Nie widzę, żeby mi się coś paliło, a moje proste pytania, które Ci zadałem, nadal pozostają bez odpowiedzi. W każdym razie konkretów brak. Spróbuj przez chwilę powstrzymać się od wycieczek osobistych i zająć meritum sprawy - może posuniemy coś do przodu.

    Ok, zatem twierdzisz, że mamy jeden PC, zawierający adres instrukcji pobieranej. Instrukcje są pobierane z pamięci np. po 64 bity. Czy wobec tego uważasz, że PC skacze co 8? Czy raczej wypadałoby uznać, że ten PC zawiera adres instrukcji pobieranej z kolejki/bufora do potoku? Tylko w takim razie skąd Twoim zdaniem bierze się adres pobierania z pamięci, który wyprzedza PC, skoro odrzucasz moją teorię o oddzielnym, dodatkowym PC (sPC) do pobierania z wyprzedzeniem?

    Dalej: W fazie pobrania nie jest znany kod binarny instrukcji, ani przemieszczenie skoku. Są one znane pod koniec tej fazy. W którym stopniu i do czego jest dodawane przemieszczenie skoku w celu utworzenia adresu docelowego skoku? Na pewno nie do wartości PC wskazującej pierwsze słowo instrukcji skoku, ale również nie do PC następnej instrukcji, co widać chociażby po zapisie binarnym instrukcji skoków. Możesz to wyjaśnić tak konkretnie, posługując się przykładami 16- i 32-bitowych instrukcji skoku?

    Twierdzisz, że w fazie Fetch jest wyznaczana wartość LR. To o tyle ciekawe, że w tej fazie niby-jedyny PC wskazuje na instrukcję skoku ze śladem. W którym stopniu potoku następuje zapis LR i skąd pochodzi wartość zapisywana do LR - jak jest tworzona? Mógłbyś to wyjaśnić? Przyjmując mój model wyjaśnienie jest b. proste. żeby było ciekawiej - w Twoim modelu też da się to chyba wyjaśnić, ale jakoś tego wyjaśnienia nie podałeś.

    HF oczywiście czyści potok, ale skąd procesor bierze adres zapamiętywany przy HF, skoro jedyny (Twoim zdaniem) PC wskazuje instrukcję pobieraną, czyli np. o 2 instrukcje i 4..8 bajtów dalej przy potoku 3-stopniowym (nie wiadomo, 4, 6 czy 8, bo to zależy od długości instrukcji następujących po tej błędnej). Jeśli moja teoria o cPC jest nieprawdziwa i w procesorze nie ma adresu instrukcji znajdującej się przy końcu potoku, gdzie jest wykrywany HF, to jakim cudem nagle ten adres się odnajduje? Szklana kula? Kiedy już to wyjaśnisz ten fenomen, pomyśl o uogólnieniu na wszystkie Cortexy, które różnią się od siebie długościami potoków oraz o sytuacji, gdy zaraz za instrukcją powodującą HF mamy w potoku instrukcję skoku.

    Wszystkie dane podróżują przez potok zawsze wraz z instrukcją, której dotyczą, tylko niekoniecznie pojawiają się one już w pierwszym stopniu. Dane z rejestrów pojawiają się typowo w drugim stopniu potoków RISCowych - tam, gdzie następuje odczyt rejestrów. Dane z pamięci - najczęściej w przedostatnim lub ostatnim, w zależności od budowy potoku. Tu akurat nie mam problemów z precyzją.

    Wreszcie, skoro uparcie twierdzisz, że jest tylko jeden PC, to co oznacza Twoje zdanie "Niekoniecznie musi to być ten widoczny dla programu - może być on cieniem czegoś bardziej wewnętrznego". Przecież Twoim zdaniem nie ma "czegoś bardziej wewnętrznego" (a moim zdaniem - jest).
  • #48
    Użytkownik usunął konto
    Poziom 1  
  • #49
    BlueDraco
    Specjalista - Mikrokontrolery
    1. Wiem. To jak bardzo "imprecise" będzie adres, gdy po instrukcji z HF jest skok, a wykrycie HF następuje w ostatnim stopniu potoku, kiedy pierwszy stopień pobiera już instrukcję spod adresu docelowego skoku i w procesorze nie ma żadnego innego PC poza tym służącym do pobierania?

    2. Kilka. Dla zabawy i eksperymentów, nic komercyjnego.

    3. Nie odpowiedziałeś konkretnie na żadne z moich całkiem prostych pytań o działanie procesora z jedynym PC, więc może jednak skończ tę niemerytoryczną przepychankę.

    4. Co to za "bardziej wewnętrzny" PC, o którym piszesz, skoro PC jest, jak utrzymujesz, tylko jeden? To przecież ja twierdzę, że są jakieś "bardziej wewnętrzne" PC, a Ty negujesz ich istnienie.