Ze spraw zupełnie, ale to zupełnie nie związanych: prowadzone są intensywne badania nad wypracowaniem metod i samodyscypliny pozwalającej na częstsze publikacje materiałów wideo. ;-)
@@undefined_cat Jedna pozycja rejestru RZ to jedno przerwanie. Każdy bit rejestru odpowiada jednemu wejściu przerywającemu, do którego podłączone jest źródło pojedynczego przerwania.
Masz mega wiedzę o tej maszynie i super słucha się o szczegółach konstrukcyjnych i logicznych tej maszyny. Ale może zrobił byś odcinek na temat zastosowań gdzie Mera 400 była użwyana, w jakich języka pisało się na nią aplikacje oraz może coś o tym jak wyglądała na niej codzienna praca?
Genialny materiał. Chcę więcej! Bardzo fajnie prowadzisz. Bez bajerów i cyrków, kawał solidnej wiedzy przekazywanej w bardzo przystępny sposób. Mam do Mery i CROOKa pewien sentyment - przez 2 lata moją szefowa na OiO była Hania Czerniak - autorka dokumentacji CROOKa. Dwa piętra wyżej firmę CROCOM prowadził jej mąż, Zbigniew Czerniak, często wpadał na herbatę na katedrę. Na ETI miałem zajęcia z Martinem ;D Na stanie miałem K-202 i Merę z CROOKiem. Hania kilka razy sugerowała, żeby to odkurzyć i odpalić. Ale młody byłem i głupi, nie wiedziałem, co mam w łapach.
Ależ Ci zazdroszczę tamtego towarzystwa. :-) Dzięki zaangażowaniu pani Hani uratowała się ostatnia MERA-400, na której powstawał CROOK. Udało mi się odczytać dysk twardy tej maszyny i tylko dzięki temu mamy dziś działającego CROOK-a. Chwała pani Hani! Pan Zbigniew natomiast przez kilka lat cierpliwie pomagał mi nie tylko z uruchomieniem CROOK-a w emulatorze MERY-400, ale i z samym emulatorem. Miałem mnóstwo pytań dotyczących szczegółów, które on, ku mojemu zaskoczeniu, zawsze pamiętał. Dostałem też od niego taśmy ze źródłami CROOK-a, począwszy od pierwszych wersji, kiedy to jeszcze nie nazywał się CROOK. Skarbnica!
@@MERA400 boli, ze grono zainteresowanych tak male. A narod wielki. Teraz co trzeci to informatyk. Ludzie, ktorzy to tworzyli sa zbyt skromni. Nie widac ich. A maszyna wyszla im przemyslana i przeprzepiekna. A dopiero jak sie internet pojawil to wyszlo, ze i u nas sie komputery robilo i to z sensem, a nie hobbistyczne.
Świetnie zrealizowany materiał. Trzeba było w to włożyć dużo serca i wiele godzin pracy. Gratulacje! Jeżeli chodzi o samo porównanie, to trudno jednoznacznie stwierdzić, która architektura była lepsza. Już sam fakt, że daje się je porównywać oznacza, że w jakimś sensie są one (architektury) podobne. Zawsze mieliśmy świetnych inżynierów. Sprzyjały temu dobre technika, klasy matematyczno-fizyczne w liceach, doskonałe wyższe uczelnie techniczne. Jacy inżynierowie, taka architektura opracowanych przez nich procesorów - czyli na wysokim, światowym poziomie. Zasadnicza różnica tkwi w technologii. Mera została zbudowana na układach TTL małej i średniej skali integracji. Architektura Intela została zamknięta wewnątrz jednego, relatywnie taniego układu LSI (Large Scale of Integration). I to był prawdziwy przełom, który na dobre zaczął się w latach 70-tych ubiegłego wieku, od 8-bitowych procesorów Intela, Motoroli, Ziloga. Świetne konstrukcje mogły powstawać w garażach, a potem być masowo produkowane, dzięki niskiej cenie układów LSI.
Piękne dzięki, z przyjemnością przypomniałem sobie pracę na MERZE przed 40 paru laty, grzebałem wtedy w systemie SOM-3. MERA była używana do sterowania procesami.
powinieneś chgłopie stworzyć jakis odcinek o tym - jak sie to wszystko u Cebie zaczęło (rtówniez z Merą) - czym sie zajmujesz - rownież zawodowo itd itp... Miażdzysz chłopie :) wiedzą i profesjonalizmem :)
W końcu trafiłem na właściwy odcinek i już rozumiem Twoją fascynację Merą 400, a to dlatego że nie wiedziałem że to jest ten słynny K-202 o którym sporo czytałem i nie wiedziałem że dzieło Karpińskiego przetrwało. To dużo tłumaczy. Ta moja mera 9150 mimo że też 16 bitowa to jak widzę to tylko mały komputerek do zbierania danych i nic ponad to. Fajny odcinek, rób kolejne bo bardzo dobrze to robisz i miło się ogląda :)
Uwielbiałem prace z Z80,8051,itp. Chyba czas wrócić do tematu. Niesamowite że nie jesteśmy potęgą technologiczną, zbudowanie czegoś takiego to nie jest przypadek.
Jak na tamte czasy to przeskoczyli epokę, uniwersalny zestaw rejestrów to kwestia następnej dekady. Spodziewalem się też procesora typu RISC - system zbudowany z układów TTL średniej skali integracji i CISC... czapki z głów.
17/10pkt kolego. Jesteś prawdziwym pasjonatem, masz ogromna wiedzę i w sposób bardzo przyjazny, przystępny dzielisz sie. Zdrowia, czasu i wytrwałości na jak najwięcej odcinkow !
@Mera400 wygląda na to, że odpalenie dwuprocesorowej MERA 400 to tylko kwestia czasu, gdyż z tego co zrobiłem rozeznanie, to Pan Bogumił zadbał o to, żeby te dwie MERA400 i okablowanie zachować :) Hehe.
Ostatnio znajomy podesłał mi filmik z odczytu dysku i zacząłem oglądać każdy filmik po kolei. Z chęcią bym obejrzał całą serię, jak się na takim komputerze programowało w językach wysokich i oczywiście w samym asemblerze. Na pewno dowiedziałbym się czegoś więcej o samym symulatorze i również jego obsłudze. PS Robisz świetną robotę z tymi filmami.
Ha wreszcie wpadłem na taki kanal. Jestem zaciekawiony, podejściem, sposobem i profesjonalizmem. rozmowa opis a w nastepnych odcinkach logika śledztwa niesamowita. Fakt to jest dla ludzi myślących dlatego mało subów :) i kciuków, ale czuję się wyróżniony że YT mi to zaproponował. Oglądam z zapartym tchem, dziekuję
To jest najciekawszy film, który widziałem na yt dlatego to jest moja jedyna subskrypcja na yt. Może to nie świadczy o mnie dobrze, bo kto normalny w dzisiejszych czasach interesuje się procesorem lutowanym ze scalaków zamiast iCore, czy Radeonem. Wiem tylko, że chciałabym mieć taki komputer w domu. Ponadto materiał przygotowany jest w sposób bardzo fachowy i zrozumiały z dużą znajomością tematu. Choć być może wymaga pewnej wiedzy z zakresu działania procesorów. Dzisiaj nie każdy dyplomowany programista wie co to jest przerwanie maskowalne i niemaskowalne (dla współczesnego programisty Pythona to jak fale grawitacji - podobno są i podobno nawet ktoś je zmierzył). Asembler na studniach, to zaliczyć i zapomnieć. A wiedzą po co na froncie komputera rząd magicznych przełączników, to alchemia. Ja na szczęście jestem alchemikiem i z chęcią obejrzę wszystkie odcinki tego cyklu. 😊
- Super - fajnie, że ktoś mówi o takich rzeczach - znaczy o naszych osiągnięciach, bo w oczach większości młodych Polaków, to Polska nic nie potrafi i jesteśmy skazani na "pomoc" krajów "mądrzejszych od nas"... ..A jak widać po tym materiale (i wielu podobnych) - Polacy potrafili robić super rzeczy na światowym poziomie, jak by nasze rządy tego wszystkiego nie zniszczyły, to moglibyśmy być potęgą pod praktycznie każdym względem... ..Dziś "mądrzy" Polacy są w Polsce tłamszeni i niszczeni, a gdy wyjadą za granicę, to ich osiągnięcia są przypisywane innym, a Polska jest teraz totalnie uzależnionym krajem od innych i musimy skakać jak małpy w cyrku, słuchając wszystkiego, co obcokrajowcy nam każą, bo inaczej nas odetną od rzeczy, od których jesteśmy uzależnieni... ..Sami robiliśmy super elektronikę i sprzęt - teraz większość podzespołów kupujemy zza granicy, Polak jako pierwszy wydobywał ropę w Polsce i wykorzystał jako paliwo, a teraz kupujemy ropę zza granicy, choć mamy jej złoża, które wcale nie są trudne w eksploatacji, mamy super jakościowo węgiel, jednak kupujemy go zza granicy, mamy przeróżne surowce mineralne - wydobycie jest zablokowane lub zagraniczne firmy trzymają na tym łapy - tak jest z większością rzeczy - korupcja totalnie zniszczyła nasz kraj, a ile lepiej by świat był teraz rozwinięty, gdyby Polaków się nie tłamsiło... - Fajnie opracowany materiał - pozdrawiam :)
Dziękuję! Faktycznie: wieki całe. A ten za krótki. Jest o czym mówić. A tak mało osób mówi o Polskiej historii informatyki. Chcemy więcej! Na przykład wprowadzenie jak zacząć z emulatorem. Jak uruchomić i coś praktycznego zrobić. Jak coś prostego napisać i skompilować w asm (hello world?). Chętnie posłuchałbym też o kanałach. Czym to się różni od obecnie przyjętych rozwiązań? O ile różni się od zwykłego portu i/o lub kontrolera dysku czy rs232 i równoległego/centronics.
Cóż 8086 powstał jako rozwinięcie 8-bitowego 8080, a właściwie jego "nowszej" wersji 8085, dla tego pozwala obsługiwać 8 bitowe porcje danych, i dla tego też ma taka zakręconą szynę adresową i te nie fortunne 1MB przestrzeni adresowej. Natomiast ma 2 tryby pracy. Minimalny, który można w uproszczeniu nazwać trybem 1 procesorowym i Maksymalny który przy współpracy z kooprocorami, 8089 pozwala tworzyć systemy wieloprocesorowe. Z jednej strony jest to procesor na swoje czasy rewolucyjny, z drugiej przez kompatybilność wsteczną z 8-bitowym 8080 pokręcony. Czy są inne procesory do porównania z MERA 400? Zasadniczo procesory 16-bitowe, były tylko takim epizodem rozwojowym, i nie zagościły tak naprawdę za długo w komputerach, ani specjalnie nie były rozwijane. Powstała 16 bitowa alternatywa dla 6502 w postaci 65C816, zmodyfikowany wylądował w konsoli Nintendo SNES, można powiedzieć drugi 16-bitowy mikroprocesor który odniósł rynkowy sukces, ale też procesor specyficzny bo z 8 bitowa szyna danych, natomiast full 16MB adres. Z8000 który nigdy nie odniósł sukcesu. no i zasadniczo koniec. Intel 8086, a właściwie jego ekonomiczna wersja 8088 odniosła sukces, tylko i wyłącznie dla tego że IBM udostępnił schematy PC XT, i zaczęto budować tanie klony tego komputera. Jest jeszcze jeden kandydat, znany, lubiany, ale też specyficzny bo to, tak naprawdę 32 bitowy procesor z 16 bitowa szyną danych. Tak wszystkim znana z AMIGI MOTORLA MC68000. Czy I8086 jest dobrym porównaniem do MERY 400? Zasadniczo rocznikowo tak, choć prawdziwym pełnokrwistym 16,bitowecem był jego następca I80286. PS. Moim zdaniem jeżeli uwzględnimy kartę kooprocesora dla MERy 400, to bliżej jej do MC68000, niż intel 8086 który dla mnie jest ewolucyjna jednostką 8/16 bit.
Z przedstawionego filmu wynika, że bliższym odpowiednikiem do porównań byłby Zilog Z8000, tylko to porównanie byłoby równie obce dla odbiorców, jak sama Mera400.
Jak widać ekipa ELWRO miała potencjał. Gdyby wyposażyć ją w technologie scalania która wtedy w Polsce była w totalnym lesie i nie narzucano ograniczeń po linie politycznej przez braci ze wschodu, kto wie jak potoczylyby się dalsze lisy ELWRO. Siemens wiedział po co kupił ten zakład i czemu go wygasił. Żal tylko fachowców którychwiedza i zaangażowanie poszły na marne. W dzisiejszych czasach odbudowanie tego potencjału tak żeby był w stanie konkurować ze współczesnymi procesorami jest już niemożliwe. A film jak zwykle miodny :).
Bardzo proszę o kolejna część opisujaca fizyczna budowę procesora. Rozumiem, że zajmie to dużo czasu, dlatego proszę tylko o informację, kto produkowal ten procesor, czy była to produkacja od podstaw (w przypadku mikroprocesorów jest to od wytworzenia wafli krzemowych), czy też tylko montaż gotowych elementów wyprodukowanych w innych krajach.
Zawsze wiedziałem że obcy mają swoje kanały na YT i oglądają różne swoje produkcje. Właśnie trafiłem na taki kanał. Obcy używa dla niepoznaki języka polskiego, ale i tak nie udało mu się ukryć. Ta wiedza go zdradziła! Łapać obcego!!!!
8086 na 5Mhz miał rzeczywiście około 0.33 mips ale to był początek serii i kolejne wersje miały 8Mhz a natępny w typoszeregu będący już standardem miał 10Mhz i ta wersja 8086 miała już 0.75 mips co deklasuje już Merę... choć wiadomo w Merze procek jest zrobiony na piechotę :)
Ja poproszę odcinek o tym dlaczego procesor działa bez zegara. A do odcinka proszę o wtrącenie czy współczesne procesory mogłyby mieć "bezzegarową" architekturę. Bo to dlaczego nie mieliśmy możliwości rozwoju procesora do postaci VLSI tłumaczyć nie trzeba.
Co do działania bez zegara mam pewna teorię. Cała prędkość pracy procesora ograniczona jest czasami propagacji na kolejnych elementach elektronicznych. A zakończone operacje zwracają sygnał na wejście procesora o możliwości wykonania rozkazu, stąd instrukcje mają różne czasy wykonania. Skomplikowana instrukcja na dłużej blokuje możliwość rozpoczęcia kolejnego kroku. Albo inaczej, jakaś flaga informuje o zakończonej instrukcji i to dopiero wyzwala kolejną instrukcję. Wtedy czas ich realizacji nie ma znaczenia bo nie potrzeba taktowania.
👉 Mam wrażenie, że procesorowi Mery bliżej jest do Motoroli 68000 pod względem uniwersalności rejestrów. Intel zawsze był dziwny, jeśli chodzi o zastosowanie rejestrów, trochę jakby go pijany inżynier projektował.
Dzień dobry! 1. Wytrzymamy więcej! 2. Czy byłoby możliwe porównanie Mery z czymś bardziej porównywalnym co do ciężaru, czasu powstania i technologii, np. PDP-11/44?
Zasadniczo to trolling mający na celu podniesienie ratingu tej super ciekawej produkcji. Ale rozbudowa kanału szeregowego, a potem budowa jakiegoś mobilnego emulatora terminala, a może nawet panelu sterowania/technicznego, monitora stanu rejestrów? to też pomysł na rozwój kanału.
Bezprzewodowy port szeregowy jest na "liście TODO". :-) Zdalne sterowanie do pulpitu również, ale w pierwszej wersji raczej na kablu, bo jest tam trochę niewiadomych.
@@MERA400Dziekuje za odpowiedz. Też kiedyś na studiach pracowałem na Mera400, pamiętam to od strony tasiemki perforowanej produkowanej przy biureczku w pracowni komputerowej.
Seria procesorów x86 Intela to było rozbudowywanie kalkulatora o kolejne możliwości :) Niestety "zredukowany procesor" superkomputerów: Motorola 68000 powstał parę lat później. Ma on więcej cech procesora Mery ale też ma elementy architektury 32bit, więc nie nadaje się do porównania. Pierwsze zdanie to parafrazowany fragment artykułu "Czemu wolę Motorolę" Adama Foryckiego (do znalezienia w sieci)
Dokładnie o ten sam font pytałem kogoś kto opublikował jakiś zrzut ekranu na twitterze chyba z pół roku temu. Dopiero jakoś przedwczoraj dostałem odpowiedź :D
Czy w ARMach stos dla funkcji nie jest podobnie realizowany jak w mera 400? BTW mere400 raz w użyciu restartowalem z panelu jakieś 30 lat temu w technikum - nic nie rozumiejąc. Gratuluję filmu 😊
W ARMach jest podobna instrukcja skoku ze śladem (BL), ale ma też tryby adresowania z pre-/post-in-/dekrementacją, podczas gdy w merze, o ile się nie mylę, trzeba to robić osobną instrukcją. Za to podobnie jak w ARMach do v7, można było przesłać do/z pamięci kilka rejestrów naraz, czego 8086 nie potrafił. Można więc powiedzieć, że mera i 8086 się tutaj różnią, ale trudno wskazać, który jest jednoznacznie lepszy.
Asynchronicznie, czyli pewnie tak jak w uproszczeniu działa prosty sumator na bramkach, wszystko dzieje się od razu i jak najszybciej się da, tylko trzeba odrobinę poczekać, aż wynik się ustabilizuje i tak samo pewnie tutaj, zmiana na wejściu powoduje szereg reakcji na "bramkach", a czas wykonywania instrukcji, to po prostu czas, po którym wynik operacji jest stabilny i jest generowany sygnał STEP z opóźnieniem zależnym od instrukcji. W sumie można przerobić procesor Mery na pseudo-synchroniczny, wystarczy podać jakiś przebieg na sygnał STEP, choć nie ma to sensu, bo okres takiego taktowania musiałby być równy lub większy niż czas najdłużej wykonywanej instrukcji. Teraz to zacząłem się trochę zastanawiać, czy nie było takich pseudo-asynchronicznych procesorów.
na końcowym slajdzie jest dla 8086 wpisane 64KB portów I/O - bez B, bo to nie są bajty tylko 'sztuki'. W 8086 jest 64tys jedno bajtowych portów (rejestrów) lub 32tys dwu-bajtowych portów (rejestrów)
01:26 8088 nie był "8 bitową wersją 8086" w dalszym ciągu był to procesor 16 bitowy, jedynie magistrala danych była obcięta do 8 bitów to uprościło i potaniło konstrukcję ówczesnych płyt dla IBM PC i kompatybilnych klonów, stąd i pierwsza ISA 8bit później rozszerzona do 16bit po zastosowaniu późniejszych wersji procesora.
Zgadza się, dzięki za uszczegółowienie. "8-bitowa wersja" była skrótem myślowym w kontekście rodziny procesorów. Być może faktycznie zbyt mało precyzyjnym.
Czy ten emulator to Twoje dzieło ? O ile kojarzę oryginalnie ARM też ma LINK & JUMP zamiast CALL, a rekurencja bywa bardzo niebezpieczna - co zresztą widać nawet w nazwie ukochanej strony programistów ;)
Tak, emulator to też moje "dzieło". Jeśli patrzeć na inne procesory - jak ARM - to dochodzi jeszcze dyskusja RISC vs CISC. No i trzeba pamiętać, że porównanie dotyczy bardzo krótkiego odcinka historii procesorów. A czasy jak to czasy - zmieniają się. :-)
Where is Część 2? Jak wytrzymacie ? Mnie dopiero narobiłeś smaka... Na kompilacji to 8086 by upadł na kolana, tam prawie same odwołania do pamięci i skoki, prawie dam rękę, że nie wykręci 0.33 MIPS
Myślę, że bitwy na szybkość wystarczy tyle, ile było w odcinku. Wrócę natomiast jeszcze kiedyś do prędkości samej MERY-400, bo jest tam kilka ciekawostek.
Rozważałem porównanie do PDP-11, ale to podobnie archaiczna i egzotyczna architektura, a chciałem umieścić MERĘ-400 w jakimś bardziej znajomym kontekście.
Udało mi się namierzyć tylko jedno miejsce, w którym taka konfiguracja kiedyś działała - Instytut Informatyki Uniwersytetu Warszawskiego. Z tego, co mi wiadomo, to była wykorzystywana jedynie w pracach badawczych (współbieżność w systemie dwuprocesorowym).
@@MERA400 Dowiedz się co stało się s MERA-400 z Wydziału Chemicznego Politechniki Warszawskiej. Byla tam ona 'moja pierwszą kochanką" z którą spędzałem upojne wieczory. Z tego co wiem nigdy mnie nie zdradziła ... bo inni w okolicy nie mieli pojęcia jak do niej nawet zagadnąć ... nie wspominając o bitowej konwersacji.
Szkoda że technologicznie nie było możliwości upchnięcia tego systemu w jednym lub kilku układach scalonych. Awaryjność w porównaniu do 8086 niestety kładła system na łopatki. Sam materiał super !!!
Na samym początku lat 80. takie możliwości zaczęły się pojawiać i były już prowadzone plany dotyczące dalszej miniaturyzacji. No ale historia okazała się mieć inny pomysł na kolejne lata.
Awaryjność? Pracowałem a włašciwie "randkowałem" z Merą 400 przez ponad dwa lata. Byłem praktycznie jedynym jej amantem jako że inni nie byli w stanie się z Nią dogadać a co dopiero romansować. Przez ten okres nigdy mnie Ona nie zawiodła! Jedynymi problemami były ... zagięta karta czy taśma. Nie wiem jak potoczyłoby się moje życie ... gdyby tylko umiała gotować i ...
@@MichaelT_123 W ośrodku gdzie pracowałem była intensywnie eksploatowana no i co jakiś czas coś się działo. Porównanie awaryjności dotyczy konstrukcji z 8086.
Porównanie nie jest do końca 'fair'. 1)8086 ma wsparcie wieloprocesorowe - przykładami są systemy MULTIBUS. x86 posiada prefiks LOCK do blokowania magistrali dla operacji read-update-write. A dokładnie LOCK EXCH to pojedyncza instrukcja próbująca zablokować semafor. 2) Wywołanie procedury z zapisaniem wartości PC do rejestru jest w rzeczywistości szybsze niż zapisanie wartości na stosie. Działa szybciej w przypadku wywołania najbardziej wewnętrznej funkcji w pętli! /*nie ma potrzeby przechowywania na stosie*/ Oczywiście w przypadku innych wywołań funkcji będą dwie komendy - przechowywane do rejestru, a następnie backup na stosie, więcej pamięci, ale niewielki wpływ na szybkość.
Porównanie nie było ani "fair", ani kompletne, o czym wspominam w filmie chyba dwa razy. Ma jedynie dać ogólny pogląd na to, o jakiej klasy sprzęcie w ogóle mówimy. Twoje uwagi są jak najbardziej słuszne. O LOCK dla porządku rzeczywiście mogłem wspomnieć, bo pozwala zrealizować funkcjonalność rozkazu IS MERY-400. Ale wtedy powinienem też opowiedzieć o arbitrażu magistrali na przykład... Podobnie mogłem rozwinąć wątek o "manualnej" realizacji stosu... Gdzieś niestety trzeba postawić granicę zakresu tematyki odcinka. :-)
14:14 narzekasz, że nie ma instrukcji do wywołania funkcji i jednoczesnego odłożenia adresu na stos, a przecież współczesne architektury robią to samo, np. ARM, RISC-V, PowerPC.
Chodzi nie tyle o brak odpowiednika instrukcji CALL, co o brak stosu, na którym program mógłby coś odłożyć (mniejsza o to, czy automatycznie - przy wołaniu funkcji, czy nie).
Procesory ARM i PowerPC również używają LR ale posiadają rozkazy odkładające rejestry na stos. To znacznie ułatwia zarządzanie wywołaniem funkcji. Można oczywiście osiągnąć to samo przy pomocy adresowana pośredniego ale wymaga to poświęcenia jednego rejestru na wskaźnik stosu. Właśnie dlatego w nowoczesnych procesorach jest dedykowany rejestr na ten cel. Bez stosu nie da się zrealizować konceptów takich jak zmienna liczba argumentów funkcji, rekurencja czy wyjatki.
KDS: 50 lat temu potrafiliśmy zbudować dobry procesor, a dzisiaj warstwę elektroniczną dowodów osobistych musimy opierać o zagraniczne rozwiązania. JPRDL k_*wa ;-(
Owszem ale do zbudowania tego procesora potrzebowaliśmy zagranicznych części. Podstawowe bramki były owszem z CEMI, ale już ALU były SFC4181 z National Semiconductor.
O ile sprzętowe wsparcie dla stosu procesora się przydaje, o tyle odziedziczony z 8-bitówek pomysł automatycznego odkładania na nim adresu powrotu się nie przyjął we współczesnych architekturach. O ile wiem ani ARM ani RISC-V nie odkładają adres powrotu na stosie, tylko w rejestrze. Wąskim gardłem wydajności będzie zawsze wywołanie funkcji najgłębiej zagnieżdżonych (leaf), a one nie potrzebują trzymać adresu powrotu na stosie i robienie tego automatycznie jest czystym marnotrawstwem.
Cholera, niech o jakości filmu świadczy fakt, że sam zaskakująco dużo zrozumiałem, a jestem technikiem sieciowcem i z takimi detalami, jakie poruszają programiści i inżynierowie, to nawet nie śmiem się spoufalać inaczej niż dla relaksu. :D
Chciałeś napisać: prymitywne TTL vs. prymitywne HMOS? ;-) Ale poważnie: tak, różnice technologiczne i architektoniczne są ogromne, o czym wspominam na początku odcinka, a przypominam jeszcze potem na końcu, żeby nie było wątpliwości, o czym nie jest ten odcinek. ;-)
@@MERA400 w tym sensie że prądożerne bipolarne vs tranzystory MOS, dopiero chyba w polskiej produkcji MCY7880 są mosy :) Pomijając w różnice technologiczne rozwijanie techniki TTL okazało się ślepą uliczką.
Nieśmiało zauważę, że "prymitywna" technologia bipolarna (ecl), zbliżona od strony technologicznej do technologii ttl, posłużyła do konstrukcji superkomputerów Cray... Kiedy został cray x-mp "zdetronizowany" przez scalony procesor?
@@sagittarius10 lampowe układy cyfrowe zostały błyskawicznie zdeklasowane przez układy tranzystorowe. Układom mos "wyprzedzenie" układów bipolarnych zajęło ok. dekadę. A i dziś 500ps propagacji przez bramkę w układach mos nie jest takie łatwe, a było osiągane przez dyskretną bramkę ecl w latach 70... Pochodne technologii mos wygrały ceną, ale nie tym, że jakoś były istotnie szybsze. Wiele technologii, jak np siso ze względów ekonomicznych nie trafiło pod strzechy... Zresztą w filmiku widać, że dużo młodszy cmos jakoś nie wymiata...
Z tym brakiem instrukcji call i ret to chyba jakiś żart? Nie ma ich też w wielu procesorach RISC i nikt nie robi tragedii. Obsługa stosu umożliwiająca zastosowanie rekurencji sprowadza się do dodania *jednej* instrukcji "Remember and Increment" na początku wywoływanej funkcji oraz do *jednej* instrukcji dekrementującej wskaźnik stosu przed skokiem powrotu z funkcji, żadne wsparcie kompilatora nie jest wymagane. Jeśli funkcja jest "reentrant" - trzeba o tym pamiętać przy pisaniu kodu. Z drugiej strony funkcje nierekurencyjne nie ponoszą kosztów obsługi stosu, a użycie osobnych stosów dla adresów powrotnych i zmiennych jest trywialne co bardzo utrudnia ataki przez przepełnienie bufora. To na co trzeba zwrócić uwagę to wysoka ortogonalność zestawu instrukcji uzyskana dzięki koncepcji argumentu efektywnego. Jestem przekonany że Merida-400 zmiażdży x86 jako interpreter języka Forth.
Ależ oczywiście, że nie ma tragedii. Można to zrobić "na piechotkę", można też załatwić to odpowiednio implementujac konwencję wołania funkcji w kompilatorze, co jest znacznie praktyczniejszym rozwiązaniem. "Stracimy" w ten sposób jeden rejestr (rezerwując go na wskaźnik stosu), albo spowolnimy wołanie funkcji (jeśli wskaźnik będzie w pamięci, która jest powolna), ale jak najbardziej da się zrobić. Ale skoro film porównuje dwie "bliskie" architektury CISC, to jest to różnica, o której należało wspomnieć, co uczyniłem. O zaletach argumentu normalnego wspomniałem przelotnie - szczegóły chciałem zostawić na film o liście rozkazów. I zgadzam się - jest on mocną stroną architektury. :-)
@@MERA400 Ok, tylko że... x86 też zużywa rejestr na wskaźnik stosu, nie ma tu przewagi ani różnicy. Te wszystkie "brakujące" instrukcje dają się zaimplementować jako najwyżej dwie instrukcje w MERA400, lecz posiadające znacznie większą moc w tym sensie, że nie narzucające organizacji stosów (ani kierunku ani ilości). Push jest dostępne bezpośrednio jako 'Remember and Increment. Dlatego określenie braku tych instrukcji jako wady jest nieporozumieniem, równie dobrze można powiedzieć że w x86 brakuje Link Jump albo Return Jump... Warto by porównać wydajność za pomocą benchmarków (choćby Drystone), przydatne też byłoby porównanie gęstości kodu (przypuszczam że Mera wygra w cuglach w obu przypadkach), oczywiście w 16 bitowym kodzie (w sensie arytmetyki i adresowania). Innym wartym zbadania kierunkiem jest przeanalizowanie możliwości stworzenia 32 i 64 bitowych rozszerzeń oraz wysokowydajnych implementacji (potokowe przetwarzanie i out of order) - tutaj jest już według mnie gorzej.
Ze spraw zupełnie, ale to zupełnie nie związanych: prowadzone są intensywne badania nad wypracowaniem metod i samodyscypliny pozwalającej na częstsze publikacje materiałów wideo. ;-)
Masz chyba pomyłkę w ilości przerwań. Na etykietce było 32 bit przerwań, to nie 2^32 przerwań na merze?
@@undefined_cat Jedna pozycja rejestru RZ to jedno przerwanie. Każdy bit rejestru odpowiada jednemu wejściu przerywającemu, do którego podłączone jest źródło pojedynczego przerwania.
😂
lol
@@adasjot Cicho, robi się już no... :-)
Masz mega wiedzę o tej maszynie i super słucha się o szczegółach konstrukcyjnych i logicznych tej maszyny. Ale może zrobił byś odcinek na temat zastosowań gdzie Mera 400 była użwyana, w jakich języka pisało się na nią aplikacje oraz może coś o tym jak wyglądała na niej codzienna praca?
My nie tylko wytrzymamy ale i nie możemy doczekać się kolejnego odcinka! Dziękujemy i prosimy o jak najwięcej takich smaczków technicznych.
Genialny materiał. Chcę więcej!
Bardzo fajnie prowadzisz. Bez bajerów i cyrków, kawał solidnej wiedzy przekazywanej w bardzo przystępny sposób.
Mam do Mery i CROOKa pewien sentyment - przez 2 lata moją szefowa na OiO była Hania Czerniak - autorka dokumentacji CROOKa. Dwa piętra wyżej firmę CROCOM prowadził jej mąż, Zbigniew Czerniak, często wpadał na herbatę na katedrę. Na ETI miałem zajęcia z Martinem ;D
Na stanie miałem K-202 i Merę z CROOKiem. Hania kilka razy sugerowała, żeby to odkurzyć i odpalić. Ale młody byłem i głupi, nie wiedziałem, co mam w łapach.
Ależ Ci zazdroszczę tamtego towarzystwa. :-) Dzięki zaangażowaniu pani Hani uratowała się ostatnia MERA-400, na której powstawał CROOK. Udało mi się odczytać dysk twardy tej maszyny i tylko dzięki temu mamy dziś działającego CROOK-a. Chwała pani Hani! Pan Zbigniew natomiast przez kilka lat cierpliwie pomagał mi nie tylko z uruchomieniem CROOK-a w emulatorze MERY-400, ale i z samym emulatorem. Miałem mnóstwo pytań dotyczących szczegółów, które on, ku mojemu zaskoczeniu, zawsze pamiętał. Dostałem też od niego taśmy ze źródłami CROOK-a, począwszy od pierwszych wersji, kiedy to jeszcze nie nazywał się CROOK. Skarbnica!
@@MERA400 boli, ze grono zainteresowanych tak male. A narod wielki. Teraz co trzeci to informatyk. Ludzie, ktorzy to tworzyli sa zbyt skromni. Nie widac ich. A maszyna wyszla im przemyslana i przeprzepiekna. A dopiero jak sie internet pojawil to wyszlo, ze i u nas sie komputery robilo i to z sensem, a nie hobbistyczne.
Świetnie zrealizowany materiał. Trzeba było w to włożyć dużo serca i wiele godzin pracy. Gratulacje!
Jeżeli chodzi o samo porównanie, to trudno jednoznacznie stwierdzić, która architektura była lepsza. Już sam fakt, że daje się je porównywać oznacza, że w jakimś sensie są one (architektury) podobne. Zawsze mieliśmy świetnych inżynierów. Sprzyjały temu dobre technika, klasy matematyczno-fizyczne w liceach, doskonałe wyższe uczelnie techniczne. Jacy inżynierowie, taka architektura opracowanych przez nich procesorów - czyli na wysokim, światowym poziomie.
Zasadnicza różnica tkwi w technologii. Mera została zbudowana na układach TTL małej i średniej skali integracji. Architektura Intela została zamknięta wewnątrz jednego, relatywnie taniego układu LSI (Large Scale of Integration). I to był prawdziwy przełom, który na dobre zaczął się w latach 70-tych ubiegłego wieku, od 8-bitowych procesorów Intela, Motoroli, Ziloga. Świetne konstrukcje mogły powstawać w garażach, a potem być masowo produkowane, dzięki niskiej cenie układów LSI.
Ha, a gdyby tak ubole nie zabrały dokumentacji prototypu k202 to w ogóle wyprzedzalibyśmy stany o naście lat...
Dobry material. Oceniam na 11/10. Poprosze o wiecej.
Piękne dzięki, z przyjemnością przypomniałem sobie pracę na MERZE przed 40 paru laty, grzebałem wtedy w systemie SOM-3. MERA była używana do sterowania procesami.
Domyślam się, że procesami produkcyjnymi - można prosić o garść szczegółów? Zastosowania tego komputera to ciekawy i bardzo szeroki temat.
powinieneś chgłopie stworzyć jakis odcinek o tym - jak sie to wszystko u Cebie zaczęło (rtówniez z Merą) - czym sie zajmujesz - rownież zawodowo itd itp...
Miażdzysz chłopie :) wiedzą i profesjonalizmem :)
:)
Super porównanie. I nie mogę się doczekać filmu o działaniu tego procesora bez zegara.
W końcu trafiłem na właściwy odcinek i już rozumiem Twoją fascynację Merą 400, a to dlatego że nie wiedziałem że to jest ten słynny K-202 o którym sporo czytałem i nie wiedziałem że dzieło Karpińskiego przetrwało. To dużo tłumaczy. Ta moja mera 9150 mimo że też 16 bitowa to jak widzę to tylko mały komputerek do zbierania danych i nic ponad to. Fajny odcinek, rób kolejne bo bardzo dobrze to robisz i miło się ogląda :)
Uwielbiałem prace z Z80,8051,itp. Chyba czas wrócić do tematu. Niesamowite że nie jesteśmy potęgą technologiczną, zbudowanie czegoś takiego to nie jest przypadek.
Nie szkoda marnować czasu? Są tysiące razy lepsze choćby STM32, ESP32, Rp2040. :-)
Znakomity wykład. Dydaktyka na wysokim poziomie.
Dziękuję i pozdrawiam
Jak na tamte czasy to przeskoczyli epokę, uniwersalny zestaw rejestrów to kwestia następnej dekady. Spodziewalem się też procesora typu RISC - system zbudowany z układów TTL średniej skali integracji i CISC... czapki z głów.
17/10pkt kolego. Jesteś prawdziwym pasjonatem, masz ogromna wiedzę i w sposób bardzo przyjazny, przystępny dzielisz sie. Zdrowia, czasu i wytrwałości na jak najwięcej odcinkow !
@Mera400 wygląda na to, że odpalenie dwuprocesorowej MERA 400 to tylko kwestia czasu, gdyż z tego co zrobiłem rozeznanie, to Pan Bogumił zadbał o to, żeby te dwie MERA400 i okablowanie zachować :) Hehe.
Ostatnio znajomy podesłał mi filmik z odczytu dysku i zacząłem oglądać każdy filmik po kolei. Z chęcią bym obejrzał całą serię, jak się na takim komputerze programowało w językach wysokich i oczywiście w samym asemblerze. Na pewno dowiedziałbym się czegoś więcej o samym symulatorze i również jego obsłudze.
PS
Robisz świetną robotę z tymi filmami.
Obejrzałem z wielką przyjemnością. Dziękuję!
Ha wreszcie wpadłem na taki kanal. Jestem zaciekawiony, podejściem, sposobem i profesjonalizmem. rozmowa opis a w nastepnych odcinkach logika śledztwa niesamowita. Fakt to jest dla ludzi myślących dlatego mało subów :) i kciuków, ale czuję się wyróżniony że YT mi to zaproponował. Oglądam z zapartym tchem, dziekuję
Super odcinek ! Takie opisy techniki lubimy :)
To jest najciekawszy film, który widziałem na yt dlatego to jest moja jedyna subskrypcja na yt. Może to nie świadczy o mnie dobrze, bo kto normalny w dzisiejszych czasach interesuje się procesorem lutowanym ze scalaków zamiast iCore, czy Radeonem. Wiem tylko, że chciałabym mieć taki komputer w domu.
Ponadto materiał przygotowany jest w sposób bardzo fachowy i zrozumiały z dużą znajomością tematu. Choć być może wymaga pewnej wiedzy z zakresu działania procesorów. Dzisiaj nie każdy dyplomowany programista wie co to jest przerwanie maskowalne i niemaskowalne (dla współczesnego programisty Pythona to jak fale grawitacji - podobno są i podobno nawet ktoś je zmierzył).
Asembler na studniach, to zaliczyć i zapomnieć. A wiedzą po co na froncie komputera rząd magicznych przełączników, to alchemia.
Ja na szczęście jestem alchemikiem i z chęcią obejrzę wszystkie odcinki tego cyklu. 😊
Dzień dobry, Niesamowita wiedza - zazdroszczę i czekam na kolejne filmy.
To jest kosmos. Bardzo ciekawy material. Gratulacje.
Troszke sie dowiedzialem czegos .
Rzeczywiście świetnie zrealizowany materiał. Fakty przedstawione w przyjemny sposób, a strona wizualna bardzo estetyczna.
- Super - fajnie, że ktoś mówi o takich rzeczach - znaczy o naszych osiągnięciach, bo w oczach większości młodych Polaków, to Polska nic nie potrafi i jesteśmy skazani na "pomoc" krajów "mądrzejszych od nas"... ..A jak widać po tym materiale (i wielu podobnych) - Polacy potrafili robić super rzeczy na światowym poziomie, jak by nasze rządy tego wszystkiego nie zniszczyły, to moglibyśmy być potęgą pod praktycznie każdym względem... ..Dziś "mądrzy" Polacy są w Polsce tłamszeni i niszczeni, a gdy wyjadą za granicę, to ich osiągnięcia są przypisywane innym, a Polska jest teraz totalnie uzależnionym krajem od innych i musimy skakać jak małpy w cyrku, słuchając wszystkiego, co obcokrajowcy nam każą, bo inaczej nas odetną od rzeczy, od których jesteśmy uzależnieni... ..Sami robiliśmy super elektronikę i sprzęt - teraz większość podzespołów kupujemy zza granicy, Polak jako pierwszy wydobywał ropę w Polsce i wykorzystał jako paliwo, a teraz kupujemy ropę zza granicy, choć mamy jej złoża, które wcale nie są trudne w eksploatacji, mamy super jakościowo węgiel, jednak kupujemy go zza granicy, mamy przeróżne surowce mineralne - wydobycie jest zablokowane lub zagraniczne firmy trzymają na tym łapy - tak jest z większością rzeczy - korupcja totalnie zniszczyła nasz kraj, a ile lepiej by świat był teraz rozwinięty, gdyby Polaków się nie tłamsiło...
- Fajnie opracowany materiał - pozdrawiam :)
Dziękuję! Faktycznie: wieki całe. A ten za krótki. Jest o czym mówić. A tak mało osób mówi o Polskiej historii informatyki. Chcemy więcej! Na przykład wprowadzenie jak zacząć z emulatorem. Jak uruchomić i coś praktycznego zrobić. Jak coś prostego napisać i skompilować w asm (hello world?). Chętnie posłuchałbym też o kanałach. Czym to się różni od obecnie przyjętych rozwiązań? O ile różni się od zwykłego portu i/o lub kontrolera dysku czy rs232 i równoległego/centronics.
Zanotowałem. :-)
Cóż 8086 powstał jako rozwinięcie 8-bitowego 8080, a właściwie jego "nowszej" wersji 8085, dla tego pozwala obsługiwać 8 bitowe porcje danych, i dla tego też ma taka zakręconą szynę adresową i te nie fortunne 1MB przestrzeni adresowej. Natomiast ma 2 tryby pracy. Minimalny, który można w uproszczeniu nazwać trybem 1 procesorowym i Maksymalny który przy współpracy z kooprocorami, 8089 pozwala tworzyć systemy wieloprocesorowe. Z jednej strony jest to procesor na swoje czasy rewolucyjny, z drugiej przez kompatybilność wsteczną z 8-bitowym 8080 pokręcony. Czy są inne procesory do porównania z MERA 400? Zasadniczo procesory 16-bitowe, były tylko takim epizodem rozwojowym, i nie zagościły tak naprawdę za długo w komputerach, ani specjalnie nie były rozwijane. Powstała 16 bitowa alternatywa dla 6502 w postaci 65C816, zmodyfikowany wylądował w konsoli Nintendo SNES, można powiedzieć drugi 16-bitowy mikroprocesor który odniósł rynkowy sukces, ale też procesor specyficzny bo z 8 bitowa szyna danych, natomiast full 16MB adres. Z8000 który nigdy nie odniósł sukcesu. no i zasadniczo koniec. Intel 8086, a właściwie jego ekonomiczna wersja 8088 odniosła sukces, tylko i wyłącznie dla tego że IBM udostępnił schematy PC XT, i zaczęto budować tanie klony tego komputera. Jest jeszcze jeden kandydat, znany, lubiany, ale też specyficzny bo to, tak naprawdę 32 bitowy procesor z 16 bitowa szyną danych. Tak wszystkim znana z AMIGI MOTORLA MC68000. Czy I8086 jest dobrym porównaniem do MERY 400? Zasadniczo rocznikowo tak, choć prawdziwym pełnokrwistym 16,bitowecem był jego następca I80286.
PS. Moim zdaniem jeżeli uwzględnimy kartę kooprocesora dla MERy 400, to bliżej jej do MC68000, niż intel 8086 który dla mnie jest ewolucyjna jednostką 8/16 bit.
Wytrzymamy. Możesz wrzucać takie materiały. ❤
To jest niesamowita maszyna, dobrze że ma tak mądrego miłośnika.
0:52 - piękne to było :D
;-)
Z przedstawionego filmu wynika, że bliższym odpowiednikiem do porównań byłby Zilog Z8000, tylko to porównanie byłoby równie obce dla odbiorców, jak sama Mera400.
Jak widać ekipa ELWRO miała potencjał. Gdyby wyposażyć ją w technologie scalania która wtedy w Polsce była w totalnym lesie i nie narzucano ograniczeń po linie politycznej przez braci ze wschodu, kto wie jak potoczylyby się dalsze lisy ELWRO.
Siemens wiedział po co kupił ten zakład i czemu go wygasił.
Żal tylko fachowców którychwiedza i zaangażowanie poszły na marne.
W dzisiejszych czasach odbudowanie tego potencjału tak żeby był w stanie konkurować ze współczesnymi procesorami jest już niemożliwe.
A film jak zwykle miodny :).
Wydaje mi się, że mylisz ELWRO z Zakładami ERA.
@@MERA400 Fakt. Chodziło o zakłady Mera-ELWRO które produkował Odry. To one zostały przejęte i wygaszone przez Siemensa.
Za każdym razem jak się pojawia nowy odcinek to rewatchuję całość :X
No taką postawę to ja rozumiem! :D
Szanuję
Bardzo proszę o kolejna część opisujaca fizyczna budowę procesora. Rozumiem, że zajmie to dużo czasu, dlatego proszę tylko o informację, kto produkowal ten procesor, czy była to produkacja od podstaw (w przypadku mikroprocesorów jest to od wytworzenia wafli krzemowych), czy też tylko montaż gotowych elementów wyprodukowanych w innych krajach.
Zawsze wiedziałem że obcy mają swoje kanały na YT i oglądają różne swoje produkcje. Właśnie trafiłem na taki kanał. Obcy używa dla niepoznaki języka polskiego, ale i tak nie udało mu się ukryć. Ta wiedza go zdradziła! Łapać obcego!!!!
Witam podziwiam Pan wiedzę świetny materiał procki 8086 za moich czasów to były bardzo popularne jednostki wszędobylskie.
No lezka w oku... Dzieki!!
8086 na 5Mhz miał rzeczywiście około 0.33 mips ale to był początek serii i kolejne wersje miały 8Mhz a natępny w typoszeregu będący już standardem miał 10Mhz i ta wersja 8086 miała już 0.75 mips co deklasuje już Merę... choć wiadomo w Merze procek jest zrobiony na piechotę :)
Bardzo dobry material
fajnie poprowadzony odcinek
Cenny materiał!
super materiał
Ja poproszę odcinek o tym dlaczego procesor działa bez zegara. A do odcinka proszę o wtrącenie czy współczesne procesory mogłyby mieć "bezzegarową" architekturę. Bo to dlaczego nie mieliśmy możliwości rozwoju procesora do postaci VLSI tłumaczyć nie trzeba.
Co do działania bez zegara mam pewna teorię. Cała prędkość pracy procesora ograniczona jest czasami propagacji na kolejnych elementach elektronicznych. A zakończone operacje zwracają sygnał na wejście procesora o możliwości wykonania rozkazu, stąd instrukcje mają różne czasy wykonania. Skomplikowana instrukcja na dłużej blokuje możliwość rozpoczęcia kolejnego kroku.
Albo inaczej, jakaś flaga informuje o zakończonej instrukcji i to dopiero wyzwala kolejną instrukcję. Wtedy czas ich realizacji nie ma znaczenia bo nie potrzeba taktowania.
Ale super matreialy masz ! Poprostu mega.
👉 Mam wrażenie, że procesorowi Mery bliżej jest do Motoroli 68000 pod względem uniwersalności rejestrów.
Intel zawsze był dziwny, jeśli chodzi o zastosowanie rejestrów, trochę jakby go pijany inżynier projektował.
Obie uwagi bardzo trafne. ;-)
Wielce interesujące
Odcinki sa super
Dzień dobry!
1. Wytrzymamy więcej!
2. Czy byłoby możliwe porównanie Mery z czymś bardziej porównywalnym co do ciężaru, czasu powstania i technologii, np. PDP-11/44?
No w końcu nowy film :)
Interfejs Wifi do Mery 400 to naturalny kolejny krok rozwoju tej rekonstrukcji.
A tak z ciekawości: do czego konkretnie miałby to być interfejs?
Zasadniczo to trolling mający na celu podniesienie ratingu tej super ciekawej produkcji. Ale rozbudowa kanału szeregowego, a potem budowa jakiegoś mobilnego emulatora terminala, a może nawet panelu sterowania/technicznego, monitora stanu rejestrów? to też pomysł na rozwój kanału.
Bezprzewodowy port szeregowy jest na "liście TODO". :-) Zdalne sterowanie do pulpitu również, ale w pierwszej wersji raczej na kablu, bo jest tam trochę niewiadomych.
@@MERA400Dziekuje za odpowiedz. Też kiedyś na studiach pracowałem na Mera400, pamiętam to od strony tasiemki perforowanej produkowanej przy biureczku w pracowni komputerowej.
Super! Pozdrawiam👍
Rewelacja :)
Spoko. Wrzucaj kolejne części.
Seria procesorów x86 Intela to było rozbudowywanie kalkulatora o kolejne możliwości :) Niestety "zredukowany procesor" superkomputerów: Motorola 68000 powstał parę lat później. Ma on więcej cech procesora Mery ale też ma elementy architektury 32bit, więc nie nadaje się do porównania. Pierwsze zdanie to parafrazowany fragment artykułu "Czemu wolę Motorolę" Adama Foryckiego (do znalezienia w sieci)
super film
Super materiał! Czy są może analogiczne, traktujące o wewnętrznej architekturze maszyn serii ODRA, czy RIAD (R-32, R-34)?
Nie spotkałem.
Dzięki
Materiał bardzo ciekawy i pouczający - gratulacje.
Pytanie trochę nie ma temat :) - jakiej czcionki używasz w konsolach pokazanych pod koniec filmu?
Może i nie na temat, ale sprawa jest zaiste kluczowa. :-) Iosevka.
@@MERA400 Dzięki za szybką odpowiedź.
Dokładnie o ten sam font pytałem kogoś kto opublikował jakiś zrzut ekranu na twitterze chyba z pół roku temu. Dopiero jakoś przedwczoraj dostałem odpowiedź :D
wincej wincej!!!!
Czy w ARMach stos dla funkcji nie jest podobnie realizowany jak w mera 400? BTW mere400 raz w użyciu restartowalem z panelu jakieś 30 lat temu w technikum - nic nie rozumiejąc. Gratuluję filmu 😊
W ARMach jest podobna instrukcja skoku ze śladem (BL), ale ma też tryby adresowania z pre-/post-in-/dekrementacją, podczas gdy w merze, o ile się nie mylę, trzeba to robić osobną instrukcją. Za to podobnie jak w ARMach do v7, można było przesłać do/z pamięci kilka rejestrów naraz, czego 8086 nie potrafił. Można więc powiedzieć, że mera i 8086 się tutaj różnią, ale trudno wskazać, który jest jednoznacznie lepszy.
Asynchronicznie, czyli pewnie tak jak w uproszczeniu działa prosty sumator na bramkach, wszystko dzieje się od razu i jak najszybciej się da, tylko trzeba odrobinę poczekać, aż wynik się ustabilizuje i tak samo pewnie tutaj, zmiana na wejściu powoduje szereg reakcji na "bramkach", a czas wykonywania instrukcji, to po prostu czas, po którym wynik operacji jest stabilny i jest generowany sygnał STEP z opóźnieniem zależnym od instrukcji. W sumie można przerobić procesor Mery na pseudo-synchroniczny, wystarczy podać jakiś przebieg na sygnał STEP, choć nie ma to sensu, bo okres takiego taktowania musiałby być równy lub większy niż czas najdłużej wykonywanej instrukcji. Teraz to zacząłem się trochę zastanawiać, czy nie było takich pseudo-asynchronicznych procesorów.
na końcowym slajdzie jest dla 8086 wpisane 64KB portów I/O - bez B, bo to nie są bajty tylko 'sztuki'. W 8086 jest 64tys jedno bajtowych portów (rejestrów) lub 32tys dwu-bajtowych portów (rejestrów)
👍
01:26 8088 nie był "8 bitową wersją 8086" w dalszym ciągu był to procesor 16 bitowy, jedynie magistrala danych była obcięta do 8 bitów to uprościło i potaniło konstrukcję ówczesnych płyt dla IBM PC i kompatybilnych klonów, stąd i pierwsza ISA 8bit później rozszerzona do 16bit po zastosowaniu późniejszych wersji procesora.
Zgadza się, dzięki za uszczegółowienie. "8-bitowa wersja" była skrótem myślowym w kontekście rodziny procesorów. Być może faktycznie zbyt mało precyzyjnym.
@@MERA400 👍😃
Czy ten emulator to Twoje dzieło ?
O ile kojarzę oryginalnie ARM też ma LINK & JUMP zamiast CALL, a rekurencja bywa bardzo niebezpieczna - co zresztą widać nawet w nazwie ukochanej strony programistów ;)
Tak, emulator to też moje "dzieło".
Jeśli patrzeć na inne procesory - jak ARM - to dochodzi jeszcze dyskusja RISC vs CISC. No i trzeba pamiętać, że porównanie dotyczy bardzo krótkiego odcinka historii procesorów. A czasy jak to czasy - zmieniają się. :-)
A właśnie miałem spytać czy coś wiesz o K-202, ale już się wszystko rozjaśniło
@1:30 Sorry, że się czepiam ale 8088 nie jest 8-bitowy, jest tak samo jak 8086 16-bitowy, ale ma 8-bitową szynę danych.
Słuszna uwaga, powinienem był doprecyzować, że chodzi o szynę danych.
Ciekawe jaką wydajność miałby procesor o architekturze Mery 400 gdyby był wykonany w takiej technologii, jakiej Intel użył do zrobienia 8086.
Bardziej toto przypomina MC68000 niż Intela (też ortogonalny, też ma rozkazy zrzutu/pobrania wielu rejestrów na raz). Już go polubiłem.
I też ograniczone możliwości operowania na bajtach - np. cały 32 bitowy rejestr na 1 bajt.
Błąd w filmie w 9.44 na liście przerwań jest 2x przerwanie z drugiego procesora na górze i u dołu listy
To dlatego, że są dwa przerwania, które procesory mogą między sobą zgłaszać. Jedno o bardzo wysokim, a drugie o bardzo niskim priorytecie.
Ok, to bylo mocniejsze czy słabsze od ZX Spectrum?
Inne
Where is Część 2?
Jak wytrzymacie ? Mnie dopiero narobiłeś smaka...
Na kompilacji to 8086 by upadł na kolana, tam prawie same odwołania do pamięci i skoki, prawie dam rękę, że nie wykręci 0.33 MIPS
Cieroliwości, będzie na pewno. :-)
🙂👍
Panowie gdzie ten procesor można zobaczyć?
Kto go produkował?
Chyba znalazłem
MERA-400 - jednostka centralna
Czy możesz nagrać film o bitwie na szybkość? Benchmark Mandelbrota wygląda dobrze th-cam.com/video/oEFJ2KQDdAk/w-d-xo.html
Co myślisz?
Myślę, że bitwy na szybkość wystarczy tyle, ile było w odcinku. Wrócę natomiast jeszcze kiedyś do prędkości samej MERY-400, bo jest tam kilka ciekawostek.
Myślę, że jeszcze ciekawiej byłoby gdyby to porównanie było zrobione z PDP-11, któremu koncepcyjnie bliżej do Mery 400.
Rozważałem porównanie do PDP-11, ale to podobnie archaiczna i egzotyczna architektura, a chciałem umieścić MERĘ-400 w jakimś bardziej znajomym kontekście.
@@MERA400 to może… m68k?
PS. Nie mogę się doczekać następnych części.
Ciekawi mnie czy gdziekolwiek kiedykolwiek wykorzystywano Merę 400 w konfiguracji dwuprocesorowej.
Udało mi się namierzyć tylko jedno miejsce, w którym taka konfiguracja kiedyś działała - Instytut Informatyki Uniwersytetu Warszawskiego. Z tego, co mi wiadomo, to była wykorzystywana jedynie w pracach badawczych (współbieżność w systemie dwuprocesorowym).
@@MERA400 Dowiedz się co stało się s MERA-400 z Wydziału Chemicznego Politechniki Warszawskiej.
Byla tam ona 'moja pierwszą kochanką" z którą spędzałem upojne wieczory. Z tego co wiem nigdy mnie nie zdradziła ... bo inni w okolicy nie mieli pojęcia jak do niej nawet zagadnąć ... nie wspominając o bitowej konwersacji.
Szkoda że technologicznie nie było możliwości upchnięcia tego systemu w jednym lub kilku układach scalonych. Awaryjność w porównaniu do 8086 niestety kładła system na łopatki. Sam materiał super !!!
Na samym początku lat 80. takie możliwości zaczęły się pojawiać i były już prowadzone plany dotyczące dalszej miniaturyzacji. No ale historia okazała się mieć inny pomysł na kolejne lata.
Awaryjność?
Pracowałem a włašciwie "randkowałem" z Merą 400 przez ponad dwa lata. Byłem praktycznie jedynym jej amantem jako że inni nie byli w stanie się z Nią dogadać a co dopiero romansować. Przez ten okres nigdy mnie Ona nie zawiodła!
Jedynymi problemami były ... zagięta karta czy taśma.
Nie wiem jak potoczyłoby się moje życie ... gdyby tylko umiała gotować i ...
@@MichaelT_123 W ośrodku gdzie pracowałem była intensywnie eksploatowana no i co jakiś czas coś się działo. Porównanie awaryjności dotyczy konstrukcji z 8086.
@mera400 wincyj! Nie zanudzisz nas, nie ma szans!
Wow ale to była maszyna.
Czy te piski na końcu to piszczące cewki?
Nie, to emulowany dźwięk głośniczka znajdującego się w pulpicie technicznym komputera.
Porównanie nie jest do końca 'fair'.
1)8086 ma wsparcie wieloprocesorowe - przykładami są systemy MULTIBUS. x86 posiada prefiks LOCK do blokowania magistrali dla operacji read-update-write. A dokładnie LOCK EXCH to pojedyncza instrukcja próbująca zablokować semafor.
2) Wywołanie procedury z zapisaniem wartości PC do rejestru jest w rzeczywistości szybsze niż zapisanie wartości na stosie. Działa szybciej w przypadku wywołania najbardziej wewnętrznej funkcji w pętli! /*nie ma potrzeby przechowywania na stosie*/ Oczywiście w przypadku innych wywołań funkcji będą dwie komendy - przechowywane do rejestru, a następnie backup na stosie, więcej pamięci, ale niewielki wpływ na szybkość.
Porównanie nie było ani "fair", ani kompletne, o czym wspominam w filmie chyba dwa razy. Ma jedynie dać ogólny pogląd na to, o jakiej klasy sprzęcie w ogóle mówimy. Twoje uwagi są jak najbardziej słuszne. O LOCK dla porządku rzeczywiście mogłem wspomnieć, bo pozwala zrealizować funkcjonalność rozkazu IS MERY-400. Ale wtedy powinienem też opowiedzieć o arbitrażu magistrali na przykład... Podobnie mogłem rozwinąć wątek o "manualnej" realizacji stosu... Gdzieś niestety trzeba postawić granicę zakresu tematyki odcinka. :-)
14:14 narzekasz, że nie ma instrukcji do wywołania funkcji i jednoczesnego odłożenia adresu na stos, a przecież współczesne architektury robią to samo, np. ARM, RISC-V, PowerPC.
Chodzi nie tyle o brak odpowiednika instrukcji CALL, co o brak stosu, na którym program mógłby coś odłożyć (mniejsza o to, czy automatycznie - przy wołaniu funkcji, czy nie).
Procesory ARM i PowerPC również używają LR ale posiadają rozkazy odkładające rejestry na stos. To znacznie ułatwia zarządzanie wywołaniem funkcji. Można oczywiście osiągnąć to samo przy pomocy adresowana pośredniego ale wymaga to poświęcenia jednego rejestru na wskaźnik stosu. Właśnie dlatego w nowoczesnych procesorach jest dedykowany rejestr na ten cel. Bez stosu nie da się zrealizować konceptów takich jak zmienna liczba argumentów funkcji, rekurencja czy wyjatki.
KDS: 50 lat temu potrafiliśmy zbudować dobry procesor, a dzisiaj warstwę elektroniczną dowodów osobistych musimy opierać o zagraniczne rozwiązania. JPRDL k_*wa ;-(
Owszem ale do zbudowania tego procesora potrzebowaliśmy zagranicznych części. Podstawowe bramki były owszem z CEMI, ale już ALU były SFC4181 z National Semiconductor.
O ile sprzętowe wsparcie dla stosu procesora się przydaje, o tyle odziedziczony z 8-bitówek pomysł automatycznego odkładania na nim adresu powrotu się nie przyjął we współczesnych architekturach. O ile wiem ani ARM ani RISC-V nie odkładają adres powrotu na stosie, tylko w rejestrze. Wąskim gardłem wydajności będzie zawsze wywołanie funkcji najgłębiej zagnieżdżonych (leaf), a one nie potrzebują trzymać adresu powrotu na stosie i robienie tego automatycznie jest czystym marnotrawstwem.
Doom na tym pójdzie?
Obawiam się, że nie. :-)
ja pitolę świetnie, i bardzo zrozumiałe nawet dla bardziej wysokopoziomowców
Cholera, niech o jakości filmu świadczy fakt, że sam zaskakująco dużo zrozumiałem, a jestem technikiem sieciowcem i z takimi detalami, jakie poruszają programiści i inżynierowie, to nawet nie śmiem się spoufalać inaczej niż dla relaksu. :D
0:56 RIP palec (chyba bolało)
Czego się nie robi dla dramatycznego efektu ;-)
Jedna z najważniejszych różnic to: prymitywne TTL vs. CMOS
Chciałeś napisać: prymitywne TTL vs. prymitywne HMOS? ;-) Ale poważnie: tak, różnice technologiczne i architektoniczne są ogromne, o czym wspominam na początku odcinka, a przypominam jeszcze potem na końcu, żeby nie było wątpliwości, o czym nie jest ten odcinek. ;-)
@@MERA400 w tym sensie że prądożerne bipolarne vs tranzystory MOS, dopiero chyba w polskiej produkcji MCY7880 są mosy :) Pomijając w różnice technologiczne rozwijanie techniki TTL okazało się ślepą uliczką.
Nieśmiało zauważę, że "prymitywna" technologia bipolarna (ecl), zbliżona od strony technologicznej do technologii ttl, posłużyła do konstrukcji superkomputerów Cray... Kiedy został cray x-mp "zdetronizowany" przez scalony procesor?
@@marcinp.8108 Tak, lampowe komputery też były szybsze niż pierwsze tranzystorowe. Mogli rozwijać te szybkie lampy zamiast jakieś procesory robić.
@@sagittarius10 lampowe układy cyfrowe zostały błyskawicznie zdeklasowane przez układy tranzystorowe. Układom mos "wyprzedzenie" układów bipolarnych zajęło ok. dekadę. A i dziś 500ps propagacji przez bramkę w układach mos nie jest takie łatwe, a było osiągane przez dyskretną bramkę ecl w latach 70... Pochodne technologii mos wygrały ceną, ale nie tym, że jakoś były istotnie szybsze. Wiele technologii, jak np siso ze względów ekonomicznych nie trafiło pod strzechy... Zresztą w filmiku widać, że dużo młodszy cmos jakoś nie wymiata...
To jest już zapomniana technologia czy gdzieś się jeszcze ją stosuje?
Staram się, żeby nie została zapomniana. ;-)
Ale w zastosowaniach praktycznych nie jest już nigdzie używana.
Ja pierdole, to nie je arduino... tu trzeba mieć łeb.
Z tym brakiem instrukcji call i ret to chyba jakiś żart? Nie ma ich też w wielu procesorach RISC i nikt nie robi tragedii.
Obsługa stosu umożliwiająca zastosowanie rekurencji sprowadza się do dodania *jednej* instrukcji "Remember and Increment" na początku wywoływanej funkcji oraz do *jednej* instrukcji dekrementującej wskaźnik stosu przed skokiem powrotu z funkcji, żadne wsparcie kompilatora nie jest wymagane. Jeśli funkcja jest "reentrant" - trzeba o tym pamiętać przy pisaniu kodu. Z drugiej strony funkcje nierekurencyjne nie ponoszą kosztów obsługi stosu, a użycie osobnych stosów dla adresów powrotnych i zmiennych jest trywialne co bardzo utrudnia ataki przez przepełnienie bufora.
To na co trzeba zwrócić uwagę to wysoka ortogonalność zestawu instrukcji uzyskana dzięki koncepcji argumentu efektywnego.
Jestem przekonany że Merida-400 zmiażdży x86 jako interpreter języka Forth.
Ależ oczywiście, że nie ma tragedii. Można to zrobić "na piechotkę", można też załatwić to odpowiednio implementujac konwencję wołania funkcji w kompilatorze, co jest znacznie praktyczniejszym rozwiązaniem. "Stracimy" w ten sposób jeden rejestr (rezerwując go na wskaźnik stosu), albo spowolnimy wołanie funkcji (jeśli wskaźnik będzie w pamięci, która jest powolna), ale jak najbardziej da się zrobić.
Ale skoro film porównuje dwie "bliskie" architektury CISC, to jest to różnica, o której należało wspomnieć, co uczyniłem.
O zaletach argumentu normalnego wspomniałem przelotnie - szczegóły chciałem zostawić na film o liście rozkazów. I zgadzam się - jest on mocną stroną architektury. :-)
@@MERA400 Ok, tylko że... x86 też zużywa rejestr na wskaźnik stosu, nie ma tu przewagi ani różnicy. Te wszystkie "brakujące" instrukcje dają się zaimplementować jako najwyżej dwie instrukcje w MERA400, lecz posiadające znacznie większą moc w tym sensie, że nie narzucające organizacji stosów (ani kierunku ani ilości). Push jest dostępne bezpośrednio jako 'Remember and Increment.
Dlatego określenie braku tych instrukcji jako wady jest nieporozumieniem, równie dobrze można powiedzieć że w x86 brakuje Link Jump albo Return Jump...
Warto by porównać wydajność za pomocą benchmarków (choćby Drystone), przydatne też byłoby porównanie gęstości kodu (przypuszczam że Mera wygra w cuglach w obu przypadkach), oczywiście w 16 bitowym kodzie (w sensie arytmetyki i adresowania).
Innym wartym zbadania kierunkiem jest przeanalizowanie możliwości stworzenia 32 i 64 bitowych rozszerzeń oraz wysokowydajnych implementacji (potokowe przetwarzanie i out of order) - tutaj jest już według mnie gorzej.
Kawał świetnej, nikomu nie potrzebnej roboty.
ale mylisz