Názory k článku Příchod hackerů – příběh Antonína Svobody: EPOS
-
klusacek (neregistrovaný)
Diky za clanek, ale neni mi jasne toto:
Podobně jako SAPO, také EPOS používal systém aritmetiky reziduálních tříd – příslušnou decimální aritmetickou jednotku navrhli Valach se Svobodou
Jak to tedy bylo? Minule nekdo v diskusi rikal, ze SAPO pouzivalo reprezentaci pomoci zbytkovych trid, ale nekdo jiny ze pracovalo s 32 bitovymi binarnimi floaty. Zkousel jsem trochu googlit, ale bohuzel je o teto dobe napsana spousta obecnych pribehu bez vetsich technickych detailu, ve kterych se technicky popis (pokud vubec na internetu existuje) uspesne ztrati.
Krome toho se zde: http://cs.wikipedia.org/wiki/EPOS_1 pise, ze EPOS byl ciste dekadicky, cimz asi mysli ze cisla byla kodovana jako BCD floaty, jenze to je neco jineho nez zbytkove tridy. Bylo to tedy tak, ze v pameti to bylo ulozene jako BCD a pri vstupu do ALU se to prevedlo na zbytkove tridy, udelal se vypocet a pak se to zase prevedlo zpet?
Bylo by skvele kdyby nekdo popsal architekturu techto stroju detailnim stylem pana Tisnovskeho.
-
Radovan (neregistrovaný)
On je dneska docela problém zjistit podrobnosti, protože staré knížky se shánějí čím dál tím hůře, a na netu je většina informací chybná. Takže aspoň něco z toho mála na co jsem během let listování před sběrem zachráněnou dobovou literaturou narazil, kódování číslic v EPOSu:
0 = 01010
1 = 01100
2 = 00011
3 = 01001
4 = 00110
5 = 00101
6 = 10001
7 = 10100
8 = 10010
9 = 11000 -
robotron (neregistrovaný)
Hezke je, jak se tenhle vzor navrhu chybam odolneho CPU udrzel. Kombinace kodu 2z5 (a z toho plynouci desitkovy EDAC) spolu se SAPOidnim ztrojenim radice a ALU. Kdyz navrhoval (svedsky obcan ceskeho puvodu) J. Gaisler svoji upravu CPU pro vesmirny prumysl, dodnes asi nejoblibenejsi a nejrozsirenejsi CPU v kosmu vubec, dosel k temuz reseni: presuny dat skrz EDAC a ALU+radic trojita redundance.
-
robotron (neregistrovaný)
Jo, v konkurenci s LEONem to prave IBM silenym zpusobem prohralo. IBM bylo radove drazsi a mnoho let ve zpozdeni. Kolik jich nakonec silou a ITARem natlacili na trh, mi neni znamo, ale je mi znamo, ze americkou cast ISS ridi po celou dobu LEON (tehdy tedy jeste ERC32), bez vymeny a jedineho vypadku, a vsichni rikaj Amikum: hlavne na to nehrabejte a nechte tam ten spolehlivej CPU!
(Folklorni zajimavost: prvni ERC32 byl delan na zakazku pro projekt Hermes, ktery nebyl nikdo dokoncen. Pamatuje si to jeste nekdo z vas? Psali o tom ve VTM a tak ;-))
-
balki (neregistrovaný)
Tu je nasledovnik, pustali ho vo februari:
http://en.wikipedia.org/wiki/Intermediate_eXperimental_Vehicle
-
Kaafa (neregistrovaný)
Ze sborníku referátů z konference ke 25. výročí VÚMS - r. 1975:
(Kráceno)V EPOSu2 byl zásadně tok dat v kódu M z N .(Pro stálou zátěž obvodů i kontrolu). Pro data se používal kód dva z pěti a jedna z deseti; v aritmetických obvodech podmnožiny kódů tři z deseti (jedna ze dvou, jedna ze tří, jedna z pěti) a dva z devíti (jedna ze čtyř, jedna z pěti); na děrné pásce byl použit kód čtyři z osmi.
Bylo využito desítkové soustavy. Šířka toku dat v obvodech byla 1 desítková číslice, kódovaná v registrech na 5 bitech v kódu dva z pěti. Aritmetické obvody pracovaly v kódu zbytkových tříd podle algoritmu +- X - Y + Z, kde X,Y,Z jsou dekadické číslice.
Alfabetické znaky byly kódovány dvojicí čísel. -
klusacek (neregistrovaný)
Diky!
Docela prekvapive je, ze dokazali udelat vsechno to prekladani z kodu do kodu s rozumnym poctem soucastek.
Šířka toku dat v obvodech byla 1 desítková číslice
Chapu to tedy dobre tak, ze pocitac v jedom kroku zpracoval 1 cislici? Takze kdyz cislo bylo 1 slovo (65 bitu) tak tedy, pokud to byl integer, melo 13 cislic a trvalo 13 kroku nez to dokazalo napr. secist obsahy 2 registru?
Pak ale nerozumim te poznamce o zbytkovych tridach. Aritmetika zbytkovych trid funguje tak ze si vyberete nekolik navzajem nesoudelnych cisel r1,r2...rn a cislo A kodujete jako zbytky po deleni temito cisly, tedy jako (A mod r1, A mod r2,... A mod rn). Diky nesoudelnosti je to jednoznacne pro hodny A od 0 do lcm(r1..rn)-1, kde lcm je nejmensi spolecny nasobek.
Vyhoda je v tom, ze pri scitani nemusite resit prenos a nasobeni je stejne rychle jako scitani. Tedy pokud zvolite rka mala abyste uvnitr trid mohli resit operaci pomoci napr. tabulky v pameti ROM, nebo jednoducheho kombinacniho obvodu. Funguje to takhle:
(A + B) mod r = ((A mod r) + (B mod r)) mod r
(A - B) mod r = ((A mod r) - (B mod r)) mod r
(A * B) mod r = ((A mod r) * (B mod r)) mod rJestli to tak EPOS opravdu mel, tak by v te dokumentaci treba mohli napsat jaka (r1,r2,...rN) byla pouzita......
-
hmmm (neregistrovaný)
S temi vyrobnimi linkami s kaskadou elektraren se mi to nechce moc verit.
Dokazal bych si predstavit, kdyby pocital nejaky model "co by kdyby", ale nechce se mi verit, ze takovyhle kanon ridil neco realtime (i kdyz u te kaskady by stacilo 4x denne nakrmit stroj a bylo by to realtime az az). -
Ono to nemuselo být realtime - počítalo se velké množství optimalizačních úloh - od stabilizace napětí v síti, stabilizace tlaku plynu, nebo optimalizace profilu křídla. Vzhledem k dost malé paměti a pomalým perifériím to bylo rychlejší než kdyby to počítal člověk, ale nějak extrémně rychlé to nebylo. Slyšel jsem vyprávět své profesory, jak v rámci nějakého úkolu několik měsíců vymýšleli jak vůbec spočítat násobení větších matic v rozumném čase (do hodin).
-
Radovan (neregistrovaný)
Přímo pro realtime byl určený spíš RPP-16 vyvinutý v Trenčíně, o pěkných pár let později, ale už krátce po tom přišla inovace v tom smyslu, že se z Ameriky pašovaly TRS-80 a na koleně k nim dodělávaly periférie pro řízení linek :-D
Ale ta vltavská kaskáda konkrétně fungovala tak, že v každé elektrárně byl jeden nebo dva PDP-11, a všechny měly kabel k centrálnímu IBM S/360, který to celé dirigoval podle okamžité spotřeby elektřiny.
Pochopitelně že ty stroje byly už východní výroby, mohl to být třeba JPR-12R a nějaké ECčko, přesný typ nevím. Bylo by fajn kdyby se tu objevil nějaký pamětník jako u toho zbrojováckého harddisku a upřesnil to :) -
Vladimír (neregistrovaný)
Dovolím si několik poznámek, které snad pomohou. Je potřeba rozlišit matematické a přenosové operace. Matematické operace jsou (velmi hrubě) to, co je úkolem stroje, tedy dobrat se ke kýženému výsledku. Ten může být buďto číselný, nebo logický (boolova algebra, tedy zjednodušeně odpověď ano - ne).Účelem přenosových operací je dostat informaci bez chyby a co nejrychleji tam, kam chceme, ať je to třeba tiskárna, nebo buffer (dočasná paměť), nebo úložiště (dnes např. HDD, tehdy třeba děrné štítky). Za tím účelem je použit kód. Ten má dvě vlastnosti: redundanci a váhovost. Váhovost můžeme pro zjednodušení nahradit soustavou (osmičková, desítková, šestnáctková). Ale nemusí to být tak - např. měny, tedy ty peníze, co máme občas v kapse, používají několika hodnost z nichž můžete (pokud je máte) sestavit libovolné číslo - částku. Obdobně i závaží na klasických dvouramenných vahách, odkud pochází onen název.Druhou věcí je způsob jak je kód zapsán, kódován. Tady se často používá redundantní zápis, což je způsob umožňující kontrolu a případnou rekonstrukci obsahu.Redundantní znamená přebyteční, je to ta část kódu, která nenese vlastní informaci, ale pomáhá k jeho ochraně. Určitě si vzpomenete na CRC, tedy kontrolní součet. Když sedí je to ok., když ne pak se může obsah buď poslat znovu, nebo rekonstruovat. Nechci zabíhat do detailů, jen připomenu, že dnes jsou takto kódována např. RAID pole , tedy mám hlavně na mysli RAID 5 a výše (disková pole - zjednodušeně vice spojených disků, které se jeví jako jeden). Ta umí díky tomu zrekonstruovat kompletně obsah jednoho ze svých disku při jeho fatální poruše (ano, lze ho dnes často dokonce "vyrvat" za vyměnit za provozu, systém se po výpočtu plně zregeneruje).
A ještě k historickému názvosloví: EC není ec, ačkoliv si to myslela i část součastníků. Jsou to písmena z azbuky Je Es a znamenají jedinstvěnaja systěma -sjednocený systém. Zkratka ZPA znamenala závody průmyslové automatizace a kromě civilní výroby vyráběl podnik i věci pro vojáky - z tématu je jasné, co asi.
