Ještě doplním, že příště budou popsány vybrané modely řady IBM System/360 i některé jejich klony ze zemí RVHP. Pokud někdo vlastní fotky ECček, nechť se prosím ozve.
Předpokládám, že nějaké fotografie budou v archivu ÚVT MU. ( http://www.ics.muni.cz/ ), ale je potřeba to prozkoumat osobně.
Zdravim,
plne potvrzuji, ze EBCDIC je dinosaurus, ktery zapomnel zemrit :-). Stale jeste vesele zije a chrousta si sve dabelske kody :-), jmenovite v telefonnich ustrednach Siemens typu EWSD, ktere sice pro nektere operace umoznuji I/O i v ISO kodu, avsak chcete-li plnou kompatibilitu vstupu a vystupu, tak jedine EBCDIC. Jeste ze linuxovy recode jej podporuje :-).
Vi nekdo o dalsi oblasti, kde se dosud pouziva tohoto kodovani ?
Zdravi Pavel
EBCDIC se stale jeste pouziva na mainframech zSeries (treba nejnovejsi z10), ktere jsou potomky System/360. Protoze prevest vsechen kod do ASCII (protoze IBM zarucuje binarni kompatibilitu az nekam prave k System/360) by bylo nemozne, velka cast programu spoleha na konkretni format EBCDIC kodovani (napr. prevod cisel).
EBCIDIC se stále také používá v IBM produkčních tiskárnách Infoprint (dnes již tuším divize Ricoh) v tiskových formátech AFP/Metacode. Prakticky EBCIDIC používá už jen a pouze IBM, která je zavedla do svých produktů – IMHO tenhle zombie-dinosaurus bude žít ještě pekelně dlouho :-(
Tohle je pro IBM priznacne. Kdyz jde neco udelat jednoduse tak to udelaji velice slozite. Nejde jen o EBCDIC, staci se podivat na scan-cody co posila klavesnice PCcek. Asi je to nejaka jejich firemni kultura.
Jinak z10 (viz. en.wikipedia.org/wiki/IBM_z10_(microprocessor)) me prekvapil, necekal bych ze dnes nekdo bude potrebovat IBM-360 taktovanou na 4GHz. Pro spousteni starych programu by prece mel stacit emulator (kvuli dekadickym floatum by bylo vhodne ho udelat pro POWER6 procesor). Jinak by pri pouziti dynamicke rekompilace (jako mela Transmeta) nemel byt prilis rozdil mezi z10 a POWER6. Asi maji v IBM hodne penez ze si muzou dovolit bojovat na mnoha frontach zaroven.
Stejně jako dnes „nikdo nepotřebuje“ 8086 taktovanou na 4 GHz. ;-)
Nejde jen o staré programy, pro tuhle platformu vznikají i nové programy. Kompatibilita je sice značná komplikace, ovšem přináší jednu velice užitečnou věc – inženýrský konzervativismus, neboli možnost použít léty prověřené, dokonale protestované a chyb zbavené technologie.
Velká banka asi sotva nechá své účty primárně spravovat zabuggovanými programy běžícími na zabuggovaných strojích, když má možnost použít 40 lety provozu prověřenou technologii.
To je i důvod, proč „IBM/360“ pravděpodobně přežije i PC a proč FORTRAN a COBOL přežijí Javu, C# apod. Ty technologie jsou tak dobře otestované a používají se v tolika kritických aplikacích, že použití nových technologií zatím nepřináší žádné podstatné výhody a použití tradičních technologií nepředstavuje žádná podstatná omezení.
Mainframy programuji (v assembleru :-)), takze o tom neco vim.
Za prve, EBCDIC vzniklo drive nez ASCII, a s timto ohledem neni zase tak hure navrzene (ja osobne myslim, ze ty duvody, proc je EBCDIC horsi, ktere uvadi pan Tisnovsky, jsou diskutabilni). Spousta veci na System/360 je ostatne vymyslena velice elegantne, a ten system take spoustu veci de-facto standardizoval, jako treba 8-bitovy byte nebo dvojkovy komplement. Takze opravdu zde neni realny duvod opirat se do IBM.
Za druhe, z10 procesor je daleko dal nez byl System/360. Ma radove bohatsi instrukcni sadu a umi velice moderni instrukce. Je to asi jako srovnavat AMD64 architekturu s 8086 procesorem. Krome toho ma vlastnosti, ktere POWER6 nema, jako treba ochranu proti porucham (ale neni pochyb o tom, ze IBM interne sdili architekturu z10 a POWER6, a z10 ackoli je navenek znacne CISCovy, je interne vicemene RISCovy). A z mainframu ma IBM dost penez, takze si muze dovolit specialni procesory.
EBCDIC vznikla pozdeji nez ASCII. Prvni verze ASCII je z roku 1960, prvni verze standardu z roku 1963. EBCDIC naproti tomu byla vytvorena v letech 1963–1964. Firma IBM byla velkym propagatorem ASCII, ale pri uvadeni S/360 uz nemela cas na predelani vsech perifernich zarizeni atd. na ASCII, proto zustala u EBCDICu.
Jediny problem ;-) je v tom, ze S/360 se stala opravdu velmi oblibena, takze se EBCDIC rozsiril a predevsim s nami zustava dele, nez je nam mladsim programatorum mile :-)
Ono mit treba na AS/400 webservisu, ktera chrousta XMLka kodovana v EBCDIC vypada hoodne podivne…
Podle toho, co vim, tak presne z toho duvodu, ktery uvadite – IBM uz v te dobe mela velke spektrum „IT“ zarizeni, ktere vyrabela, vcetne zarizeni pro cteni i zapis na derne stitky (ostatne s nemi firma zacinala). Takze to „blokova“ struktura EBCDIC odpovida potrebam dernych stitku.
Klasicke derne stitky byly urceny pro ukladani cisel v BCD, ktere byly rozsireny o 2 „zonove“ bity, coz v prvopocatcich umoznilo zakodovat 64 znaku (4*16, zpocatku nikoli EBCDIC) a pozdeji se to upravilo no „uplnou“ EBCDIC. Ono to je videt pri pohledu na celou tabulku a take na derny stitek, ktery ma mnohdy jednotlive sloupce nadepsany EBCDIC kodem (resp. znaky v blocich a poradi dane EBCDICem).
Ano, programator musi o neprijemnych vlastnostiach EBCDICu vediet. Napriklad v COBOLe, ked ma funkcia ORD() vratit pre znaky A,..,Z hodnoty ORD(A)=1,..,ORD(Z)=25 je to mozne urobit definovanim vlastnej collating sequence v programe:
OBJECT-COMPUTER. IBM-ISERIES PROGRAM COLLATING SEQUENCE IS IBAN-ALPHA.
ale neni mozne nadefinovat si tuto vlasnu abecedu IBAN-ALPHA jednoducho takto (ako by to bolo zrejme pri ASCII):
SPECIAL-NAMES. ALPHABET IBAN-ALPHA IS 'A' THRU 'Z'
Na EBCDIC-masine ako je aj AS/400 musi programator vediet, ze EBCDIC ma diery a musi to nadefinovat takto:
SPECIAL-NAMES. ALPHABET IBAN-ALPHA IS 'A' THRU 'I', 'J' THRU 'R', 'S' THRU 'Z'
pretoze inac to nebude fungovat.
Ahoj, ja take u jedne nejmenovane firmy pracuji jako vyvoja v High level Assembleru pro Mainframe (os360/zOS). Nove paskove mechaniky maji jiz interface delany pomoci XML (posle se jim prikaz a odpovi nejake diagnosticke info v XML zprave). Takze samozrejme parsuji XML v EBCDICu :), ale uz sem si zvyknul. Takze myslim ze EBCDIC uz tu bude navzdy. A jak tady byl ten dotaz k cemu 4Ghz, no ono se to ma tak, ze na jednom ,,zeleze,, bezi nekolik systemu vedle sebe virtualizovane, a v momente kdy je pripojeno hodne uzivatelu bych jeste nejake zrychleni v klidu uvital.
Ty scan-kódy klávesnice jsou taky kvůli zpětné kompatibilitě. Na původní XT klávesnici nebyly šipky, nebyla tam šestice Ins/Del/Home/End/PageUp/PageDown, byla tam jen numerická klávesnice, která se pomocí Num Locku přepínala mezi módem pro šipky nebo pro čísla. Na XT to bylo tak, že co scan-kód, to klávesa. Když tam v AT ty šipky přidali, tak je přidali se stejnými kódy jako numerické šipky a přidali před ně prefix 0×E0 (aby zachovali funkčnost programů, které četli přímo ty scan-kódy, za předpokladu, že ten prefix budou ignorovat). Jinak – AT klávesnice jde přepnout do módu 3, kdy jeden scankód je jedna klávesa, ale protože operační systémy tento mód nepoužívají, tak je v klávesnicích implementován bugovitě (údajně 10% klávesnic) a v klávesnicích je implementován bugovitě, protože ho operační systémy nepoužívají.
Co se týče toho z10, architektura „z“ jako jediná se dokáže zotavit z hardwarové chyby procesoru — prostě, když se ti procesor pokazí, tak se instrukce předají jinému procesoru, a program běží nez pádu dál a ani to nepozná. Jsou místa, kde je potřeba absolutní spolehlivost a kde si mohou dovolit za takovou vlastnost zaplatit statisíce dolarů.
:) Nejsem si jist jestli se následující informace neobjevují v jiných článcích autora. Nečetl jsem je ještě všechny.
Myšlenka že IBM-360 je dinosauros hodny vyhynutí je zhruba ekvivalentní myšlence že 80×86 je dinosurus vhodný vyhynutí. Jakkoli nemám přímery rád, neb jsou velmi zavádějící, nedopustil jsem si tento.
Protože žijeme ve světě plném PC na architekruře Intel/Amd tak nám IBM s 360 a jejímy následníky tak nějak zmizel z očí. Neuvědomujeme si je proto.
Pokud má někdo čas a nervy se prokousávat http://www.bitsavers.org/pdf/ibm/ najde zde kupu informací o kterých ani netušil. Někde je tam popsán vztah IBM k ASCII. Volně tolik: Se standardizací ASCII jej chtěli plně převzít i v IBM. Nechali si spočítat, kolik by stálo přepsání stávajícího software s ohledem na ASCII. Výsledná suma, řádu tehdy snad desítek milionů, rozhodla.
A pokud se týče architektury. Připomenul bych málo známě věci např architekturu System/4PI (http://en.wikipedia.org/…_System/4_Pi). Tam kde 360 znamenalo 360 stupňů kruhu, tam je 4PI 4*pi strediánů povrchu koule.
A to je architektura jenž tak rychle nevymizí.
Vojáci nechtějí, se zkušenostmi které mají, jen tak vyměnovat fungující počítače a jejich odladěný software v bojové technice.
Závěrem, co já vím, tak 360 je nejdéle fungující binárně kompatibilní platforma. Osobně se domnívám že bude existovat ještě dlouho poté, co Intel/Amd x86_(64) upadnou v zapomění.
Dobry den,
o S/4PI jsem jeste nepsal, takze dekuji za informace, doufam, ze se k tomu jeste dostanu.
To dodrzovani zpetne binarni kompatibility je dvojsecna zbran – samozrejme je dobre, ze je mozne provozovat aplikace, do nichz se jednou zainvestovalo (treba spousta bankovnich aplikaci bezi na mainframech), na druhou stranu se nekde zakonzervuji veci, na nez by lide radi zapomeli :-)
Mozna budete mit pravdu v tom, ze S/360 a S/370 preziji (napriklad v podobe zpetne kompatibilnich zSeries) architekturu i386, coz se klidne muze stat – uz ted je videt nastup napriklad netbooku a chytrych telefonu, ktere pouzivaji jine procesory (ARM napriklad), dost casto se pouzivaji MIPSy atd. Uvidime
Dobrý den
:)
jsem rád že má informace i 4PI byla zajímavá. Když už to po mě někdo čte, doplnil bych pár úvah.
Když se začtete do těch dokumentů na bitsavers.org, zjistíte že v IBM, a ani řadě dalších firem, neseděli trotli. To jen nám se to z našich PC trůnů může tak zdát. Často by jejich tehdejší rozhodnutí obstála i v dnešní době. Naříklad instrukční sada S360 svým návrhem umožnila rozšiřování o nové instrukce.
Když jsem přemýšlel nad tím jak je konstruována řada procesorů, dospěl jsem k názoru že buďto:
1. realizujete dekódování instrukcí v dekodéru. Ten musí znát vaši sadu instrukcí. Pokud vylepšujete architekturu musíte změnit instrukční sadu odpovídající novým potřebám. viz. CISC->RISC.
2. musíte zachovat instrukční sadu. pak před dekodér instrukcí „vsunete“ překladač. hw zařízení do kterého na jedné straně vstupují instrukce žádané instrukční sady a na druhé straně vystupují instrukce daného konkrétního hw řešení. Tak můžete zachovat vaši prehistorickou sadu instrukcí a přitom realizovat hw nejmodernějším možným způsobem. Podle mě, to je ničím nepodložená spekulace, je veškerý nový CISC HW RISC. Jen je zamaskovaný nějakým on-fly překladačem CISC instrukcí.
Řada aplikací v reálném světě si vysloveně vynucuje zachování instrukční sady a veškerého napsaného sw. Týká se to, zejména ale nejen, palubních počítačů v leteckých a raketových prostředcích, a například také všech aplikací na kterých závisí lidský život.
Při bežném pohledu na svět výpočetní techniky sestávající z našich PC, a nyní i mobilů a další chytré elektroniky si to ne vždy plně uvědomujeme.
Teď jsem si vzpoměl, ale nemám k tomu relevatní odkazy, že palubní počítače Airbusu rovněž fungují na technologi S360 kompatibilní.
Nedávno jsem rovněž narazil na informaci, dlouho dolovanou, že palubní počítače Sovětětské raketové techniky, tedy aspoň nekteré jsou rovněž postaveny na technologii kompatibilní s S360. (mrknu do zápisků … http://www.computer-museum.ru/…/argon17.htm, ale v tuto chvíli nemám odkaz na stránku ze které jsem toto vydedukoval, ono o sovětské technice se velmi špatně shánějí informace. Konkrétně o POISKu se mi nepodařilo sehnat vůbec nic.).
Náš pohled na svět je velmi zkreslený. Je to tím, že jej zakládáme na informacích které máme a které jsme schopni získat. A tyto jsou tvrdě filtrovány. Teprve se spožděním několika desetiletí se snad některé filtry uvolní.
Málokdo například ví, že první mikroprocesor nepochází z dílny firmy Intel. A jeho vynalezci/konstruktéři nikdy nedošli uznání, nikdy nemohli na veřejnosti říct že to byli oni kdo zkonstruovali první mikroprocesor.