IBM a sedm trpaslíků 15 - superpočítač CDC 6600 (2.)

Pavel Tišnovský 9. 6. 2011

V dnešní části seriálu o historii vývoje výpočetní techniky budeme pokračovat v popisu architektury superpočítače CDC 6600 zkonstruovaného v první polovině šedesátých let minulého století týmem vedeným Seymourem Crayem. Procesorová jednotka tohoto počítače měla několik zajímavých vlastností.

Obsah

1. Organizace operační paměti superpočítače CDC 6600

2. Adresování dat uložených v operační paměti

3. Řešení konfliktů při přístupu do operační paměti

4. Ochrana regionů operační paměti

5. Kontrola přístupu do správné oblasti operační paměti

6. Pracovní registry procesorové jednotky počítače CDC 6600

7. Formát instrukcí počítače CDC 6600

8. Obsah následující části seriálu

9. Odkazy na Internetu

1. Organizace operační paměti superpočítače CDC 6600

V předchozí části seriálu o historii vývoje výpočetní techniky jsme si řekli základní informace o superpočítači CDC 6600 navrženého v šedesátých letech minulého století Seymourem Crayem pracujícím tehdy ve společnosti Control Data Corporation (CDC). Tento stroj se v období let 1964 až 1969 pyšnil pozicí nejvýkonnějšího počítače na světě. Později byl jeho výpočetní výkon překonán jeho přímým (i když binárně nekompatibilním) pokračovatelem – superpočítačem CDC 7600. I dnes se budeme zabývat popisem superpočítače CDC 6600. Nejdříve se zaměříme na strukturu jeho paměťových modulů i způsob adresování slov v operační paměti, posléze si popíšeme formát instrukcí zpracovávaných řadičem procesoru CDC 6600. Začněme nejprve s popisem organizace operační paměti a formátu adres používaných při načítání a ukládání dat do paměti. Operační paměť superpočítače CDC 6600 měla podle volby zákazníka (a jeho ochoty utrácet :-) kapacitu 32768, 65536 nebo 131072 slov, přičemž každé slovo mělo šířku šedesát bitů.

Obrázek 1: Fotografie superpočítače CDC 6600 s typickým řídicím panelem obsahujícím dvojici obrazovek.

Pokud budeme kapacitu operační paměti měřit v současných jednotkách, dostaneme se k hodnotám 240 kB, 480 kB a 960 kB, což se sice může zdát málo, ale na poměry vládnoucí IT v oboru v polovině šedesátých let minulého století se jednalo o poměrně vysoké hodnoty. Ovšem samotná relativně velká kapacita operační paměti v žádném případě nezaručovala vysoký výpočetní výkon, protože přístup k bitům uloženým v paměťové matici zkonstruované z feritových jader byl pomalý v porovnání s rychlostí CPU. Z důvodu co největšího urychlení přístupu programů k datům uloženým v operační paměti se Seymour Cray rozhodl, že celou paměť rozdělí do samostatně pracujících bank, přičemž pro každou banku byla zvolena kapacita 4096 šedesáti­bitových slov. Snadno lze vypočítat, že při celkové kapacitě 32768 slov se využívalo celkem osm bank, při kapacitě 65536 se jednalo o šestnáct bank a při nejvyšší možné kapacitě operační paměti 131072 slov byla paměť rozdělena na 32 bank.

Obrázek 2: Fragment manuálu k superpočítači CDC 6600.

2. Adresování dat uložených v operační paměti

S rozdělením operační paměti do jednotlivých bank, které pracovaly nezávisle na sobě, souvisí i způsob adresování operandů a taktéž instrukcí. Index banky byl totiž uložen v nejnižších bitech adresy, což znamenalo, že při kontinuálním čtení dat se postupně měnila banka, ze které se provádělo čtení nebo zápis – jinými slovy to znamenalo, že procesor (a programátor) sice viděli, že celá paměť tvoří jeden kontinuální adresový prostor, ve skutečnosti však byla sousední slova uložena v odlišných bankách a tím pádem i (fyzicky) v odlišných paměťových modulech. Osmnáctibitová adresa neměla nejvyšší bity obsazeny (jednalo se o určitou rezervu pro počítače s většími kapacitami operační paměti), poté následovalo dvanáct bitů pro adresaci 4096 slov ve specifikované bance a konečně se v nejnižších třech, čtyřech či osmi bitech nacházel index banky. Adresa pro čtení/zápis byla poslána do všech bank současně a pouze banka, jejíž index se rovnal obsahu posledních n-bitů adresy, se zúčastnila přenosu dat.

Obrázek 3: Modulová struktura superpočítače CDC 6600.

Díky tomuto způsobu práce s operační pamětí se s pomocí dalších podpůrných obvodů dosáhlo toho, že se v ideálním případě mohlo do paměti zapsat jedno šedesátibitové slovo, popř. přečíst jedno slovo v každém strojovém cyklu, tj. každých 100ns (časování na úrovni strojových cyklů však bylo v případě počítače CDC 6600 dosti komplikované). Struktury adres jsou ve skutečnosti poměrně jednoduché, o čemž se můžeme přesvědčit při pohledu na bitová pole zobrazená pod tímto odstavcem.

Struktura adresy pro 8 bank = 32768 slov

 +---+------------+---+
 |xxx|12 bitů/4096|b# |
 +---+------------+---+
17  14            2   0

Struktura adresy pro 16 bank = 65536 slov

 +--+------------+----+
 |xx|12 bitů/4096| b# |
 +--+------------+----+
17 15            3    0

Struktura adresy pro 32 bank = 131072 slov

 +-+------------+-----+
 |x|12 bitů/4096| b#  |
 +-+------------+-----+
17 16           5     0

Obrázek 4: Paměť s feritovými jádry použitá v superpočítači CDC 6600.

3. Řešení konfliktů při přístupu do operační paměti

Ve skutečnosti však nebyla práce s operační pamětí tak snadná, jak by se mohlo při čtení předchozí kapitoly zdát, protože bylo nutné nějakým vhodným způsobem vyřešit konflikty vznikající při opakovaném přístupu k datům umístěným v jediné bance, například v případě, že se přistupovalo ke každému osmému prvku pole. Konflikt mohl vzniknout taktéž tehdy, pokud o přístup k operační paměti žádalo více zdrojů, což bylo u počítače CDC 6600 možné, neboť ten obsahoval – jak jsme si již řekli v předchozí části tohoto seriálu – sice jen jedinou centrální procesorovou jednotku (CPU), ale navíc ještě deset řídicích procesorů, z nichž každý mohl k operační paměti v libovolnou chvíli přistoupit. Z tohoto důvodu nemohl žádný z těchto procesorů ani CPU k buňkám v operační paměti přistupovat přímo, ale přístup musel být proveden přes takzvaný stunt box, jehož funkce se v některých ohledech podobala funkci řadičů sběrnice.

Obrázek 5: Další pohled na paměťový modul použitý v superpočítači CDC 6600.

Ve chvíli, kdy do stunt boxu přišla adresa slova z jakéhokoli zdroje (například z CPU), byla tato adresa distribuována do všech bank operační paměti. V této chvíli mohly nastat dvě situace. V příznivějším případě jedna z bank paměti tuto adresu akceptovala a následně automaticky provedla čtení či zápis slova. V opačném případě se však mohlo stát, že příslušná banka ještě prováděla předchozí operaci čtení či zápisu a novou adresu ignorovala. Tehdy si musel stunt box ještě nezpracovanou adresu uložit do své lokální sady registrů a opakovaně se snažit o její zpracování až do chvíle, kdy byla operace čtení či zápisu skutečně provedena. Stunt box takto dokázal současně pracovat s větším množství adres, což znamená, že nemusel nutně čekat na jedinou paměťovou banku, ale mohl v průběhu čekání vyřizovat další požadavky na čtení či zápis. Jednalo se o poměrně efektivní a přitom pružný mechanismus, do něhož Seymour Cray a jeho spolupracovníci navíc přidali i podporu pro prioritní vyřizování některých požadavků.

Obrázek 6: Unifikovaný modul počítače CDC 6600 – pohled na spodní část modulu s plošným spojem.

4. Ochrana regionů operační paměti

Poměrně často se můžeme v různých materiálech dočíst, že mechanismy určené pro ochranu operační paměti patří mezi několik poměrně moderních technologií uvedených na trh až společně se šestnáctibitovými a 32bitovými procesory. Ve skutečnosti to však není pravda, protože různé mechanismy správy paměti a dokonce i mechanismy pro podporu virtuální paměti můžeme najít i u sálových počítačů a superpočítačů vyráběných na přelomu padesátých a šedesátých let minulého století, což znamená, že se jedná o technologie minimálně 50 let staré. Základní mechanismus ochrany paměti před nežádoucím přepisem byl implementován i v superpočítači CDC 6600. Jednalo se o poměrně jednoduchý a tím pádem i rychlý mechanismus, jak je tomu ostatně u číslicových obvodů navržených Seymourem Crayem obvyklé. Každý proces byl v tomto počítači spouštěn instrukcí Exchange Jump, která mj. sloužila i k nastavení dvojice speciálních registrů pojmenovaných Reference Address (EA) a Field Length (FL).

Obrázek 7: Role speciálních registrů Reference Address (EA) a Field Length (FL).

Role těchto dvou speciálních registrů je velmi jednoduchá a v mnoha ohledech se podobá roli segmentových registrů, popř. deskriptorů použitých u některých moderních (i méně moderních :-) ) mikroprocesorů. V osmnáctibitovém registru Reference Address byla uložena počáteční adresa pro proces. Na základě této adresy a adresy uvedené v instrukčních slovech se počítala skutečná (fyzická) adresa ukazující do operační paměti – veškeré adresování tedy bylo ve skutečnosti relativní, i když programátor svůj program koncipoval tak, jakoby tento program používal paměť od adresy 0 (což ve skutečnosti znamenalo fyzickou adresu 0+RA). Programy tedy bylo možné realokovat do libovolné oblasti operační paměti. Druhý speciální osmnáctibitový registr nazvaný Field Length (FL) obsahoval délku paměťové oblasti vyhrazené procesu. Jednalo se skutečně o délku, nikoli o koncovou adresu této oblasti, což vedlo k nepatrnému zjednodušení obvodů určených pro detekci přístupu mimo nastavenou oblast (porovnávala se přímo adresa zadaná v instrukci s registrem FL, součet s registrem RA se mohl provádět paralelně s tímto testem).

Obrázek 8: Centrální procesorová jednotka a deset procesorů pro ovládání periferií.

5. Kontrola přístupu do správné oblasti operační paměti

Číslicové obvody počítače CDC 6600 automaticky kontrolovaly všechny přístupy do operační paměti i adresy, z nichž se načítaly strojové instrukce (aktuální hodnota čítače instrukcí byla uložena ve speciálním registru pojmenovaném P, který odpovídá dnešnímu registru pojmenovaném většinou PC). V případě, že se překročila vyhrazená oblast paměti, mohlo být vyvoláno přerušení obsloužené operačním systémem. Na rozdíl od moderních mikroprocesorů s MMU však počítač CDC 6600 neobsahoval klasické ringy, které by jednotlivé procesy rozdělovaly na běžné uživatelské programy a jádro systému, takže se teoreticky dala výše zmíněná instrukce Exchange Jump zavolat přímo z programu a provést tak změnu obsahu registrů Reference Address a Field Length.

Obrázek 9: Konzole s dvojicí displejů.

Ovšem důvod existence těchto registrů a technologií s nimi spojených (sčítačka pro převod relativní adresy na adresu fyzickou, kontrolní obvod atd.) spočíval především v umožnění relokace programů a detekce základních chyb v aplikacích, nikoli pro úplnou izolaci procesů – ostatně většina aplikací pro superpočítače byla vytvářena na zakázku a detekce instrukce Exchange Jump v objektovém kódu byla relativně snadná.

Obrázek 10: Ukázka využití jednoho z displejů pro zobrazení výsledků výpočtů.

6. Pracovní registry procesorové jednotky počítače CDC 6600

Kromě rozdělení operační paměti na samostatně pracující banky se dalšího urychlení počítače CDC 6600 dosáhlo použitím relativně velké sady pracovních registrů používaných pro adresování operandů nebo pro provádění výpočtů. Již v předchozí části tohoto seriálu jsme si řekli, že se procesorová jednotka CDC 6600 některými svými vlastnostmi podobala později vzniklým mikroprocesorům s architekturou RISC a relativně velký počet registrů je jednou z klíčových vlastností RISCu. Buďme však konkrétní – centrální procesorová jednotka počítače CDC 6600 obsahovala 24 registrů, které byly rozděleny do tří skupin po osmi registrech. Tyto tři skupiny registrů jsou vypsány v následující tabulce:

Pojmenování Počet registrů Bitová šířka Funkce
X0, X1 … X7 8 60 provádění aritmetických instrukcí
A0, A1 … A7 8 18 adresování
B0, B1 … B7 8 18 adresování, přičtení či odečtení od dalších typů registrů, počitadla smyček

Obrázek 11: Pracovní registry procesorové jednotky a jejich umístění v rámci architektury počítače CDC 6600.

Zajímavý je v kontextu porovnávání superpočítače CDC 6600 s procesory RISC taktéž fakt, že registr B0 byl obvodově nastavený takovým způsobem, že obsahoval nulu, tj. osmnáct nulových bitů. Díky tomu, že byla za všech okolností zaručena nulovost tohoto registru (zápis do něj se rovnal instrukci NOP), bylo možné zjednodušit instrukční sadu i některé adresovací režimy. Tento registr se například používal pro implicitní testy na nulu v podmíněných skocích EQ, NE, GE, LT – tyto instrukce vždy porovnaly obsah dvojice registrů Bi a Bj a na základě výsledků tohoto porovnání se skok následně provedl nebo naopak neprovedl (znalci modernějších assemblerů si mohou před názvy těchto instrukcí přidat prefix Jjump, nebo Bbranch).

Obrázek 12: Centrální procesorová jednotka, operační paměť a deset periferních procesorů v počítači CDC 6600.

7. Formát instrukcí počítače CDC 6600

Pojďme si nyní stručně popsat formát strojových instrukcí používaný superpočítačem CDC 6600 i počítači, které jsou od něho odvozeny. Všechny strojové instrukce bylo možné nezávisle na jejich funkci rozdělit do dvou kategorií – na instrukce zakódované do patnáctibitového pole a na instrukce zakódované do třicetibitového pole. Délky instrukcí (či přesněji řečeno šířky bitových polí použitých pro zakódování instrukcí) byly zvoleny takovým způsobem, aby bylo možné do jednoho 60bitového slova uložit dvě třicetibitové instrukce (30+30), dvě patnáctibitové instrukce a jednu třicetibitovou instrukci (30+15+15, 15+30+15, 15+15+30), popř. čtveřici patnáctibitových instrukcí (15+15+15+15). Dvojice, trojice či celá čtveřice instrukcí byla načtena z operační paměti současně, i když to samozřejmě nemuselo znamenat, že se všechny instrukce také musely provést (mohlo například dojít ke skoku do jiné oblasti operační paměti). Všechny možné kombinace umístění instrukcí různé délky v šedesátibitových slovech jsou zobrazeny na obrázku číslo 13.

Obrázek 13: Možnosti kombinace několika instrukcí v jednom šedesátibitovém paměťovém slovu.

Strojové instrukce s délkou patnáct bitů obsahovaly (samozřejmě kromě vlastního kódu prováděné operace) i indexy dvou zdrojových registrů a index registru cílového, což se opět nápadně podobá formátu používaném u některých procesorů typu RISC. Naproti tomu se u instrukcí s délkou třicet bitů nacházel pouze index jednoho zdrojového registru (a index registru cílového), ovšem druhý operand byl určen 18bitovou konstantou nebo 18bitovou adresou – viz též obrázky číslo 14 a 15. Některé instrukce pracovaly s adresními registry A0, A1 … A7, jiné s registry pro provádění aritmetických operací X0, X1 … X7 a zbylé instrukce jako své dva operandy používaly obsah vybraných dvou „počitadlových“ registrů B0, B1 … B7. Díky tomu, že typ instrukce byl uložen přímo v instrukčním kódu, mohly se pro uložení indexů registrů použít pouze tři bity (namísto teoretických bitů pět).

Obrázek 14: Formát instrukce uložené v 15 bitovém poli.

widgety

8. Obsah následující části seriálu

V následující části seriálu o historii vývoje výpočetní techniky dokončíme popis architektury superpočítače CDC 6600. Zaměříme se především na vysvětlení způsobu práce s numerickými hodnotami reprezentovanými v systému plovoucí řádové čárky (tečky), protože právě na základech položených v šedesátých letech minulého století při konstrukci mainframů a sálových počítačů vznikla později norma IEEE 754 využívaná dodnes jak při konstrukci matematických koprocesorů (jež jsou dnes většinou již součástí čipu s mikroprocesorem), tak i ve specifikacích různých programovacích jazyků (asi nejtypičtějším příkladem je programovací jazyk Java s výslovnými odkazy na IEEE 754).

Obrázek 15: Formát instrukce uložené v 30 bitovém poli.

9. Odkazy na Internetu

  1. CONTROL DATA 6400/6500/6600 COMPUTER SYSTEMS Reference Manual
    http://ed-thelen.org/comp-hist/CDC-6600-R-M.html#P2–1
  2. IBM 7302 Oil Core Memory
    http://www.pi­ercefuller.com/li­brary/img00085­.html?id=img00085
  3. IBM 7302 Air Core Memory
    http://www.pi­ercefuller.com/li­brary/img00090­.html?id=img00090
  4. Control Data Corporation (CDC) 6600: 1966–1977
    http://www.cis­l.ucar.edu/com­puters/gallery/cdc/6600­.jsp
  5. Control Data Corporation (CDC) 7600: 1971–1983
    http://www.cis­l.ucar.edu/com­puters/gallery/cdc/7600­.jsp
  6. John Mauchly
    http://en.wiki­pedia.org/wiki/Joh­n_Mauchly
  7. J. Presper Eckert
    http://en.wiki­pedia.org/wiki/J­._Presper_Eckert
  8. BINAC
    http://en.wiki­pedia.org/wiki/BI­NAC
  9. Description of the BINAC
    http://www.pa­losverdes.com/las­thurrah/binac-description.html
  10. UNIVersal Automatic Computer (UNIVAC)
    http://www.thoc­p.net/hardware/u­nivac.htm
  11. BUNCH
    http://en.wiki­pedia.org/wiki/BUN­CH
  12. Mainframe computer
    http://en.wiki­pedia.org/wiki/Ma­inframe_compu­ter
  13. Cray History
    http://www.cra­y.com/About/His­tory.aspx?404;http:­//www.cray.com:80/a­bout_cray/his­tory.html
  14. Cray Historical Timeline
    http://www.cra­y.com/Assets/PDF/a­bout/CrayTime­line.pdf
  15. Company: Cray Research, Inc. (Computer History)
    http://www.com­puterhistory.or­g/brochures/com­panies.php?al­pha=a-c&company=com-42b9d5d68b216
  16. General Electric GE-400
    http://www.feb-patrimoine.com/PRO­JET/ge400/ge-400.htm
  17. GE-400 Time-sharing information systems:
    http://www.com­puterhistory.or­g/collections/ac­cession/102646147
  18. GE 225 vs. IBM 1401
    http://ed-thelen.org/GE225-IBM1401.html
  19. A GE-225 is found
    http://ed-thelen.org/comp-hist/GE225.html
  20. G.E. 200 Series Computers
    http://www.smec­c.org/g_e__200_s­eries_computer­s.htm
  21. GE-200 series (Wikipedia)
    http://en.wiki­pedia.org/wiki/GE-200_series
  22. GE-400 series (Wikipedia)
    http://en.wiki­pedia.org/wiki/GE-400_series
  23. GE-600 series (Wikipedia)
    http://en.wiki­pedia.org/wiki/GE-600_series
  24. Mainframe – Introduction
    http://www.thoc­p.net/hardware/ma­inframe.htm
  25. Honeywell 800 (1958)
    http://www.cs­.clemson.edu/~mar­k/h800.html
  26. Real Machines with 24-bit and 48-bit words
    http://www.qu­adibloc.com/com­p/cp0303.htm
  27. Honeywell ARGUS
    http://en.wiki­pedia.org/wiki/Ho­neywell_ARGUS
  28. Honeywell Datamatic 1000
    http://www.smec­c.org/honeywe­ll_datamatic_1000­.htm
  29. Honeywell
    http://en.wiki­pedia.org/wiki/Ho­neywell
  30. Whatever Happened to IBM and the Seven Dwarfs? Dwarf Four: Honeywell
    http://www.dvo­rak.org/blog/ibm-and-the-seven-dwarfs-dwarf-four-honeywell/
  31. Datamatic 1000 by DATAmatic Corporation (1955)
    http://www.com­putermuseum.li/Tes­tpage/Datamatic-1000.html
  32. Burroughs – Third Generation Computers
    https://wiki.cc­.gatech.edu/fol­klore/index.php/Bu­rroughs_Third-Generation_Com­puters
  33. Burroughs B5000, B5500 and B5700 (original) documentation
    http://www.bit­savers.org/pdf/bu­rroughs/B5000_55­00_5700/
  34. Burroughs B6500 and B6700 (original) documentation
    http://www.bit­savers.org/pdf/bu­rroughs/B6500_67­00/
  35. Burroughs B8500 (original) documentation
    http://www.bit­savers.org/pdf/bu­rroughs/B8500/
  36. ERA 1101 Documents
    http://ed-thelen.org/comp-hist/ERA-1101-documents.html
  37. Ukázkový program pro UNIVAC 1101/ERA 1101
    https://wiki.cc­.gatech.edu/fol­klore/index.php/En­gineering_Rese­arch_Associates_an­d_the_Atlas_Com­puter_(UNIVAC_1101)
  38. UNIVAC I Computer System
    http://univac1­.0catch.com/
  39. UNIVAC I Computer System
    http://univac1­.0catch.com/y­ellowpage.htm
  40. UNIVAC (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­nivac
  41. UNIVAC I (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_I
  42. UNIVAC II – Universal Automatic Computer Model II
    http://ed-thelen.org/comp-hist/BRL61-u4.html
  43. UNIVAC II (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_II
  44. UNIVAC III (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_III
  45. UNIVAC 1101 (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_1101
  46. UNISYS History Newsletter
    https://wiki.cc­.gatech.edu/fol­klore/index.php/Ma­in_Page
  47. UNIVAC Solid State (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_Solid_Sta­te
  48. Bi-quinary coded decimal (Wikipedia)
    http://en.wiki­pedia.org/wiki/Bi-quinary_coded_de­cimal
  49. UNIVAC III Data Processing System
    http://ed-thelen.org/comp-hist/BRL61-u4.html#UNIVAC-III
  50. The UNIVAC III Computer
    https://wiki.cc­.gatech.edu/fol­klore/index.php/The_U­NIVAC_III_Com­puter
  51. UNIVAC III Photos
    http://jwstep­hens.com/univac3/pa­ge01.htm
  52. A History of Unisys Computers (kniha)
    http://www.lu­lu.com/produc­t/hardcover/a-history-of-unisys-computers/4627477
  53. UNIVAC III Instructions Reference Card
    http://www.bit­savers.org/pdf/u­nivac/univac3/UT-2455_UNIVACII­I_RefCd61.pdf
Našli jste v článku chybu?
Vitalia.cz: Dostal malý pivovar ze Slovenska do Tesca

Dostal malý pivovar ze Slovenska do Tesca

Podnikatel.cz: Byla finanční manažerka, teď cvičí jógu

Byla finanční manažerka, teď cvičí jógu

Lupa.cz: Další Češi si nechali vložit do těla čip

Další Češi si nechali vložit do těla čip

Vitalia.cz: Jak Ondra o astma přišel

Jak Ondra o astma přišel

120na80.cz: Co je padesátkrát sladší než cukr?

Co je padesátkrát sladší než cukr?

Lupa.cz: Patička e-mailu závazná jako vlastnoruční podpis?

Patička e-mailu závazná jako vlastnoruční podpis?

Lupa.cz: Jak se prodává firma za miliardu?

Jak se prodává firma za miliardu?

120na80.cz: Hrbatá prsa aneb mýty o implantátech

Hrbatá prsa aneb mýty o implantátech

Vitalia.cz: dTest odhalil ten nejlepší kečup

dTest odhalil ten nejlepší kečup

Podnikatel.cz: Znáte už 5 novinek k #EET

Znáte už 5 novinek k #EET

Vitalia.cz: Jaký je rozdíl mezi brambůrky a chipsy?

Jaký je rozdíl mezi brambůrky a chipsy?

DigiZone.cz: Funbox 4K v DVB-T2 má ostrý provoz

Funbox 4K v DVB-T2 má ostrý provoz

Vitalia.cz: Když všichni seli řepku, on vsadil na dýně

Když všichni seli řepku, on vsadil na dýně

Lupa.cz: Hackeři mají data z půlmiliardy účtů Yahoo

Hackeři mají data z půlmiliardy účtů Yahoo

DigiZone.cz: Mordparta: trochu podchlazený 87. revír

Mordparta: trochu podchlazený 87. revír

DigiZone.cz: Koncesionářské poplatky pro RTVS

Koncesionářské poplatky pro RTVS

Vitalia.cz: Tahák, jak vyzrát nad zápachem z úst

Tahák, jak vyzrát nad zápachem z úst

DigiZone.cz: O2 Sport zbrojí na derby pražských S

O2 Sport zbrojí na derby pražských S

Vitalia.cz: Jsou vegani a vyrábějí nemléko

Jsou vegani a vyrábějí nemléko

Lupa.cz: Jak levné procesory změnily svět?

Jak levné procesory změnily svět?