HW novinky: pustí se Intel do výroby ARMů pro Apple? (diskuse)

[Honz]

Pokud se x86 staně něčím, co bude převálcováno chytřejšími technologiemi, pak to bude jenom pozitivní... Vždyť vlastně jediný, kdo tvrdošíjně trvá na dekádami překonaných procesorových instrukcích, jsou Uindousáci, a těch je už dneska minimum...

[Ovocníček]

Další expert na CPU, vidím :)

[j]

Jednak neni nic prekonano - kazdy x86/64 CPU uz davno tohle jen emuluje, a nemluve o tom, ze aplikacni zakladna pro tyhle CPU je radove nasobne vetsi, nez pro jakoukoli jinou architekturu.

[Ovocníček]

Jinak co znám lidi, kteří se těmi různými ARMy zabývají (v práci...), tak v nich nějakou spásu nevidí. Na rozdíl od PC, které je nějak standardizované, bootuje nějakým definovaným způsobem a často se dá rozběhnout s nějakými generickými ovladači pro úložiště/grafiku (VESA), tak desky s ARM cpu jsou jeden horor. ()Mimochodem, současný ARM má taky docela dost bordelu kvůli obskurní zpětné kompatibilitě).

Žádná standardizovaná metoda jak bootovat (třebi RPi tuším bootuje přes grafické jádro, které musí mít svůj firmware), každý SoC je jiný (proprietární). Prakticky žádná z těch dostupných desek nejede s vanilla jádrem. Takže každý z těch výrobců má svůj valstní fork jádra, který musíte zprovoznit... no zkrátka eklhaft proti PC.

Budiž, možná že jsou ti stěžovači jenom zahořklí, a doufám, že se to postupně bude měnit k lepšímu. Ale že to s tím ARMem není žádná hipísácká idylka, to asi bude pravda.

[little.owl]

V podstate ano, je to bordel.

Nicmene u ARM64 se tomu ARM snazi predejit a licencovani uzivatele uz nebudou moci jadra tolik modifikovat, takze mira standardizace bude vetsi.

[Michal Kubeček]

No, uvidíme…

[Ovocníček]

A taky by armv8 měla být o něco vyčištěnější (ovšem dostupné procy budou vedle ní implementovat i armv7, takže bagáž tam bude i tak - ne že by mi to vadilo, důležité jsou praktické vlastnosti a výkon, to samé i u x86).

[little.owl]

Instrukcni sada byla a je u ARMv7 a i dalsich OK, tam bych zas tak problem nevidel. Problem je a byl integrace periferii, jejich mapovani, bootovani, mapovani iterruptu, memory controllery, implementace ruznych DMA, synchronizace casto i hybridnich jader a podobne veci. S embedded ARM se patlam jiz osum let a diky tomuhle binci bych stale volil x86_64 a rozhodne nebudu early adopter ARM64.

[omg]

zahorkli nejsou. je to presne tak. staci se podivat na parametry qemu pro emulaci armu a na historii libovolne arm distribuce pokud pujdou dohledat projektove informace z vytvareni arm portu.

[Miloslav Ponkrác]

„Jinak co znám lidi, kteří se těmi různými ARMy zabývají (v práci...), tak v nich nějakou spásu nevidí.“

Od té doby, co jsem začal dělat s ARMy jsem pochopil, že ARM na to nemá.

Že má mnoho vad by design a s kompatibilitou (i instrukční) mezi verzemi si taky nedělá problémy. Rychlost I/O operací a reakce na přerušení je přímo tragická.

x86 je dnes v podstatě emulátor – proces v podstatě emuluje x86 instrukce, architektura procesoru je na nich dost nenázvislá. Vyrobit nejvýkonnější ARM procesor by bylo velmi jednoduché – přidat do x86 procesor emulaci ARM instrukcí, 99,99 % x86 procesoru by zůstalo beze změny.

ARM má mnoho věcí odvozených ze zadrátování, tedy z původní architektury, kde se vykonávání instrukcí i veškerá činnost ARM procesoru rovnou zadrátovala do architektury. To je teď pro ARM obrovská koule na noze.

Stačí chvíli dělat s ARMem a pak pochopíte, že ARM jako spasitel či snad dokonce náhrada x86 (cha cha cha) je jenom stejná bublina jako Kalousek jako nejlepší ministr financí.

ARM na to nemá. Je jenom otázkou času, kdy se to projeví naplno a pak bude ARM bojovat o holou existenci. Protože svět a trh je velmi nemilosrdný k technologiím, které byly glorifikovány, a pak se ukázaly jako nic moc.

[little.owl]

Rychlost I/O operací a reakce na přerušení je přímo tragická.

Really? Chcete mi treba tvrdit, ze treba standardni Cortex M3 ma pomalou odezvu na interrupty? Navic jak I/O, tak interrupt controller je do znacne miry implementacne zavisla vec a jsou SoC, ktere to implementuji velmi dobre.

ARM na to nemá.

Ma na to, ale je tam spousta ale.

[Miloslav Ponkrác]

„Chcete mi treba tvrdit, ze treba standardni Cortex M3 ma pomalou odezvu na interrupty?“

Ano, chci to tvrdit. A třeba ARM 7 ještě daleko horší.

„Navic jak I/O, tak interrupt controller je do znacne miry implementacne zavisla vec a jsou SoC, ktere to implementuji velmi dobre.“

Nejslabším článek řetězu je obvykle sám ARM procesor a jeho jádro.

[little.owl]

Fajn. Zrovna tyto dny pracuji na driverch bezicich na TI DaVinci video procesorech, jejichz VPSS pouziva dva Cortex M3. Doba odezvy na interrupt je 12 instrukcnich cyklu, zalezi na konkretni rozpracovane instrukci. Daleko vetsi problem z hlediska casovani predstavuji operace nad sdilenou cache a pristupy do pameti z ISR, ale to se da odladit.

Ano, chci to tvrdit.

Muzete to tedy nejak konkretne specifikovat?

A třeba ARM 7 ještě daleko horší.

Cortex M3 je ARMv7.

[pc2005]

Tak pokud myslí ARM 7 (ale verze jádra je ARMv3), tak by to asi pravda byla.

[little.owl]

To snad ne. ARMv3 je dvacet let stary vybehovy design.

[pc2005]

a reakce na přerušení je přímo tragická

To jsi ještě v žádné diskuzi nedokázal.

Vyrobit nejvýkonnější ARM procesor by bylo velmi jednoduché – přidat do x86 procesor emulaci ARM instrukcí, 99,99 % x86 procesoru by zůstalo beze změny.

Stejně jako použít hw ARMu na amulaci x86 .

To je teď pro ARM obrovská koule na noze.

Stejná jako pro x86 zachování kompatibility (které není rovno ).

Stačí chvíli dělat s ARMem a pak pochopíte, že ARM jako spasitel či snad dokonce náhrada x86 (cha cha cha)

Na druhou stranu, monopol Intelu a AMD ničí inovativnost. Samozřejmě, že pokud by se výroby chytil jen jeden výrobce nebo začal dělat ARM Holdings zagorku, tak to bude taky problém, ale teďka je to minimálně menší zlo .

[Miloslav Ponkrác]

„To jsi ještě v žádné diskuzi nedokázal.“

Taky jsem v žádné diskusi nedokázal třeba ani Pythagorovu větu, nebo Maxwellovy rovnice pro elektromagnetického pole.

---xxx---

„Stejná jako pro x86 zachování kompatibility (které není rovno“

x86 je schopno velké flexibility. Dokázala už několikrát slušně změnit instrukční sadu poměrně dost revolučně.

---xxx---

„Na druhou stranu, monopol Intelu a AMD ničí inovativnost. Samozřejmě, že pokud by se výroby chytil jen jeden výrobce nebo začal dělat ARM Holdings zagorku, tak to bude taky problém, ale teďka je to minimálně menší zlo“

Na menší či větší zlo vám kašle pes.

Přežije to co bude životaschopnější. I když to bude větší zlo. Tak to bylo, je a bude.

[pc2005]

Na pythagorovu větu je objektivní odkaz. Tragická odezva je subjektivní termín. Já bych za tragickou odezvu na přerušení považoval třeba zpoždění větší než 1us, jinak by to tragická odezva nebyla.

Dokázala už několikrát slušně změnit instrukční sadu poměrně dost revolučně.

Pořád podporuje staré módy a šílené instrukce jako BCD operace. To mi přijde jako evoluce než revoluce.

Přežije to co bude životaschopnější. I když to bude větší zlo. Tak to bylo, je a bude.

A tady se mírně vkrádá otázka proč bych měl to větší zlo podporovat že? Zvlášť když má člověk svobodnou vůli (+- megaflame o svobodné vůli) to změnit. Pokud si to řekne víc lidí, tak se změní vstupy funkce pro posouzení, co je víc životaschopnější. Takže ve finále to pak může být i jen o tom jak moc "fanoušků" bude mít která architektura.

Navíc když říkáš, že se smiřuješ s tím, že může vyhrát i větší zlo, tak vyhrát může klidně i ARM. Už i jen jeho existence a pocit dominantního hráče, že může být ohrožen, může mít příznivý vliv na produkty dominantního hráče. Tipoval bych u Intelu masivní snižování spotřeby x86 a orientace (pokus) do lowpower aplikací.

Jinak pokud se člověk nebojí přejít, tak v případě krize může i odejít od ARMu. A protože má ARM lepší podporu debuggingu (x86 má JTAG až od některých verzí 486 a to ještě jen boundary scan, core2duo deska od intelu, navíc průmyslová nemá žádný JTAG header...) a tedy hobbyistů (ble to je slovo), tak to může dopomoct k vývoji mnohem lepší a životaschopnější platformy než x86 a ARM dohromady.

[multi]

ARM i u Intelu? Pokud by pak Apple nasadil ARMy ve svych pocitacich. Tak by intel X86 treba zdrazil a pak by se to mohlo pekne rozjet i na ostatnich PC a pak by to byl konecne poradny krebicek do Windows rakve.

[marek]

A vy si naozaj myslíte že M$ nemá dostatok peňazi na to, aby migroval svoj OS na iné platformy? Prípadne začal vyvíjať nový OS?

[dave_007]

Neee!

Pokud je skutecne pravdou (opravdu je to tak?), ze Window$ jsou napsany v assembleru, muze jakekoliv portovani na jiny HW predstavovat pomerne neprijemny technicky problem. Ovsem ...

... nejem si jisty, zda jsem situaci pochopil spravne. Pred par mesici jsem cetl zpravu, ze M$ uz ma pripravene Window$ 8 pro tablety. Uz si ovsem nevybavuji, zda tim mysleli tablety s ARMem, nebo jen tablety obecne.

Je mi zhola jedno, zda x86 umre ci ne. Dulezite je, ze je zde ARM - otevrena, rozvijejici se, funkcni a ziva alternativa k Intelu a AMD.

[mimi.vx]

pěkné pověry ... windows jeli na nějakých šesti architekturách ...

 

x86

x86_64

ia64 aka itanium

mips32

ARM7r2

SPARC

....

 

nyní fungují na třech .. x86 a x86_64  plus win8 ve verzi RT na ARM ...

[Ovocníček]

A ještě Alpha a PowerPC, z těch extra hipster-friendly :)

[Trident]

SPARCova verze NT nikdy vydana nebyla byt se na ni pracovalo. Takze to bude nejaka urban legend. Alpha s NTckama bylo celkem casty nasazeni kdyz prisel NT boom. Cedo s instalackama bych jeste nekde nasel. Na armku a "malym" mipsu jely mj. uz Windows CE a nasledne mobile. Na itaniu jsem widle nikdy nevidel. Jen HP-UX a VMS.

[Michal Kubeček]

Na itaniu jsem widle nikdy nevidel. Jen HP-UX a VMS.

To, že jste je neviděl, ale neznamená, že se nepoužívaly. Koneckonců SLES také nezmiňujete a používá se dodnes…

[Vykook]

Windows 8 RT jedou na ARMu.

[trekker.dk]

otevrena, rozvijejici se, funkcni a ziva alternativa k Intelu a AMD

... napsáno v příspěvku pod článkem, ve kterém je zmíněno, že Intel i AMD vyrábí ARM čipy.

[Jendа]

Jak to s tím souvisí?

Jo, kdyby tam třeba bylo napsáno, že ARM čipy vyrábí pouze Intel a AMD, to by byla jiná…

[omg]

tahle situace je stejne trzne neudrzitelna. jestli bude pokracovat, tak celkem urcite zasahne regulator a naridi rozdeleni intelu a oddeleni vyroby do samostatne spolecnosti.

[Jendа]

Ne, že by to něčemu pomohlo…

[Mti.]

Tou otevrenou architekturou myslite u ARMu doufam jen prodavanou licenci na jadro a nic vic. Jinak by jeden mohl zvazovat, jestli uz zrusili tu blbost s vynucenym trusted computingem (nadavalo se tu nedavno) nebo presvedcili vyrobce k dodani drivedu ke grafikam bastlenym s cipem. (driverum, ne tlumocnikovi k blobu jak u Raspberyyho)

O napsanosti windows v asm bych si dovolil taky pochybovat. U linuxu a podobnych bys taky mohl tvrdit, ze velke casti jsou v asm... no jsou, ale az jako soucast optimalizace pro platformu a vetsinou existuje obecne reseni v c nebo cem co je psane, jako fallback. ... a jak je to prenositelne.

[pc2005]

V Linuxu (jádru) je v assembleru jen hodně málo částí. Jedná se hlavně o wrappery okolo skoků přerušení a vyjímek, rebootu (protože ty jde v gcc udělat hodně blbě, třeba takový ty legrácky s plněním deskriptorů, prvotního MMU apod.). Pak už jen kritické sekce (atomické operace) a speciální instrukce (třeba práce s MMU), protože ty kompilátor ani jazyk C v Linuxu nepodporuje nebo by v C kódu byly moc pomalý (ale i přesto jsou generický varianty třeba spinlocku v čistě C). Třeba na architektuře Microblaze jsou jenom cca 4-5 soubory, kde je assembler a to ani ne všude v .S zdrojácích.

[Miloslav Ponkrác]

Zkuste přeportovat linux kernel na nějakou platformu (procesor), kde ještě nebyl kernel portován.

Uvidíte tu srandovní přenositelnost. A uvidíte, kolik multiplatformně závislého tam je.

Hodně se nasmějete.

Ne, že by za to mohl Linux, kterého se tímto nechci dotknout. Ale ono už z principu operační systém obsahuje dost nepřenositelných věcí, jen to není jen asm.

Navíc příliš přenositelný operační systém nemůže být nejefektivnější na dané platformě. Je to stejné jako když příliš přenositelná rodina gcc kompilátoru prostě špatně optimalizuje a generuje velmi výrazně horší a pomalejší kód, než specializované dobře udělané kompilátory psané pro konkrétní platformy.

Mimochodem, Windows prokázalo větší flexibilitu v přenosu. Běhalo na 16bitových, 32bitových i 64bitových platformách. A to často značně odlišných. Dokonce virtualizuje i hw podporu do samostatné vrstvy.

[pc2005]

Zkuste přeportovat linux kernel na nějakou platformu (procesor)

Zhruba...

Uvidíte tu srandovní přenositelnost. A uvidíte, kolik multiplatformně závislého tam je.

V zásadě to je OK.

Hodně se nasmějete.

Ne, že by za to mohl Linux, kterého se tímto nechci dotknout. Ale ono už z principu operační systém obsahuje dost nepřenositelných věcí, jen to není jen asm.

Tak určitě jo (assembler c64x je vtipnej ), ale je to často jen o stylu kódu okolí nebo výchozí (nejbližší podobné) platformy/architektury. Naopak mě překvapilo, že se kotel věcí řeší nezávisle na architektuře a univerzálně (tedy v init/ nebo kernel/ a ne arch/). Navíc pokud jsem v init/ nebo kernel/ narazil na prosakující ifdey z arch/, tak to bylo hlavně z x86 (ale nevyhledával jsem to).

Samozřejmě některé věci na některých arch/ jsou řešeny jako hack.

Navíc příliš přenositelný operační systém nemůže být nejefektivnější na dané platformě. Je to stejné jako když příliš přenositelná rodina gcc kompilátoru prostě špatně optimalizuje a generuje velmi výrazně horší a pomalejší kód, než specializované dobře udělané kompilátory psané pro konkrétní platformy.

Asi souhlas, globální extrém efektivity bude nějakej hnusnej assemblerovskej blob, co se sám modifikuje na opkód úrovni.

Mimochodem, Windows prokázalo větší flexibilitu v přenosu. Běhalo na 16bitových, 32bitových i 64bitových platformách. A to často značně odlišných. Dokonce virtualizuje i hw podporu do samostatné vrstvy.

Linux byl vyvinut pro procesor 386 a výš. Tedy 32bit. I dnešní verze dokáže běžet aspoň na i486 (nevím zda už tu 386 podporu neodstranili, jak se spekulovalo). Můžeš poslední verzi windows (8) pustit na i486? Pokud vím tak už XP na 486 nešly (možná i něco z NT větve). V současném 64bit OS můžeš po menším přizpůsobení spustit přímo binárku z 90. let (IMHO). Každopádně případné změny lze doemuloval emulační vrstvou typu dosbox/wine/qemu apod.. Ale obvykle není potřeba provozovat tak staré binárky a proto maj skoro všichni i686 nebo dokonce x86-64.

BTW

Navíc příliš přenositelný operační systém nemůže být nejefektivnější na dané platformě.

a

Mimochodem, Windows prokázalo větší flexibilitu v přenosu. Běhalo na 16bitových, 32bitových i 64bitových platformách. A to často značně odlišných. Dokonce virtualizuje i hw podporu do samostatné vrstvy.

Znamená, že windows je méně efektivnější než linux .

P.S. Opravdu se musíme přesvědčovat o tom, kterou nejhorší architekturu linux nebo windows podporují? To mě přijde jako zbytečně moc zdržující (když i já jsem už schopen zkompilovat toolchain za 77minut ).

[mimi.vx]

nějakou náhodou letošní widle jsou i na ARM ....

[Jendа]

Nemá. Nejde o Windows, ale o všechny ty aplikace.

[mankind_boost]

+1 Proto teď u Win8 propagujou JS/HTML aplikace

[radix]

A dlouho predtim .NET

[omg]

s tim rozdilem, ze do js/html vlacku naskoci postupne vsichni flashari nejpozdeji behem pristich tri let.

[Miloslav Ponkrác]

Budoucnost obvykle podobné předpovědi roztrhá na kusy a změní ve žvásty.

[pc2005]

V linuxu jo. Flash v linuxu se přestal vyvíjet.

[hw]

Nová technologie Sharpem vyvinutá umožňuje vyrábět oproti dosavadní ještě menší obrazové body a ještě rychleji je spínat, při použití IGZO totiž tranzistory umí až 40× vyšší hybnost elektronů.

Co je tohle za nesmysl? Co znamená, že tranzistory umí až 40× vyšší hybnost elektronů? To jako tranzistory mění elektronovou konfiguraci (moment hybnosti, magnetický moment hybnosti, spinový moment hybnosti) volných elektronů v hradle?

Ono je to trochu jinak. Žádná hybnost, ale pohyblivost nosičů náboje v polovodičovém materiálu IGZO je zhruba 10× až 40× vyšší než v amorfním křemíku, který se v běžných TFT pro hradlo používá. Další výhodou je lepší transparentnost pro viditelné světlo. Docela slušný přehled o IGZO je třeba zde.

[nosense.cz]

Teď mě napadlo co vlastně Intelu brání vzít instrukční sadu ARM (jako kdysi vzalo AMD programovací model x86 od Intelu) a vytvořit vlastní ARM compatible procesor. Zdá se mi to jako vhodná strategie pro případ úpadku x86. Trochu mi totiž smrdí, že vývoj jádra ARM je soustředěn v jedné společnosti. V případě ovládnutí trhu architekturou ARM jim nic nebrání pořádně nastřelit cenu licence za ARM jádro a pěkně si na úkor všech ostatních namastit kapsu.

[hw]

ARM má všechny novější instrukční sady patentované. Poslední nepatentovaná (a tedy volně implementovatelná) instrukční sada je ARM v2a. To je instrukční sada historické generace ARM7 (neplést s poměrně moderní řadou ARM Cortex A7). Nějaké open-source implementace ARM v2a jsou k dispozici třeba na OpenCores.

[nosense.cz]

A já měl za to, že rozhraní patentovat nelze. Viz např. spory Java vs Dalvik.

[Ovocníček]

Spor Oracle vs Google o rozhraní Javy se týkal copyrightu, ne patentů. A i tak si ale myslím, že copyrightovatelnost tam měla být přiznána - třeba to ještě vyšší instance přehodnotí :)

[Stefan]

Intel vlastni vsetky licencie na ARM este z cias ked vyrabal Strong ARM a XScale procesory pre Pocket PC. Takze ziadne partizanske akcie nepotrebuje.

Okrem toho, ak uz ma patenty licencovane, fakticky tym uznal ARM ako majitela a urcite sa zaviazal, ze po skonceni zmluvy nebude vyrabat ziadne ARM procesory. Pravnici Intelu by nemali sancu.

[nosense.cz]

V tom případě mě zaráží, že se AMD vůbec dostalo k výrobě konkurenčních procesorů x86 architektury. Nějak v tom nevidím rozdíl. Možná mi ale něco uniklo. V době uvedení I80480 mi přece jen byl teprve 1 rok. :)

[pc2005]

Tak 8086 vyráběli i rusáci.

[Jendа]

Znám zařízení s MHB 8088, stále funkční .

[pc2005]

Wow, fakt 8088? Jsem myslel, že TESLA x86 už nestihla. Kde a jaký?

[Michal Kubeček]

Nejspíš PP-06, tam ho písemné zdroje uvádějí, ale bohužel se mi nedaří najít fotku, kde by šel přečíst popis na procesoru. :-( Pak se ještě vyráběl PC 16 NB (NB jako Nový Bor - pamětníci si jistě vzpomenou na jiný "skvělý" tamní produkt), ale tam se podle všeho dávala nějaká ruská kopie.

[Jendа]

Nikoli, jedná se o ďábelský device Tesla LKM 220.

[tydýt]

Ha, Jenda má fusekle v sandálech, blé. Ale jinak děláte tam strašný kraviny, ještě že mám prágl tak daleko, to bych u Vás v brmlabu byl pečenej vařenej.

[Jendа]

LOL

[little.owl]

PP06.

Tak na tom jsem jako skolak zacinal.

[Michal Kubeček]

Tuhle stránku jsem našel - jenže podle té fotky to vypadá, že tam - alespoň u tohoto kusu - byl pravý Intel. A nechce se mi moc věřit, že by je dávali do všech…

[pc2005]

Ale tam je x86 od intelu, ne? Já myslel přímo 8086 (nebo 8088) vyrobenou v TESLA závodech. Sice se různě na netu píše, že se používaly, ale žádnou fotku s logem jsem neviděl. Je fakt, že pokud by TESLA vydržela pár let dýl, tak by asi něco usmolila .

[hw]

Je to procesor vyrobený v MHS, což byla společná firma francouzské Mantry a amerického Harrise. Časem je koupil Temic, později Vishay a dnes je to součást Atmelu.

Jinak co si pamatuji z doby před 89, tak Tesla vyráběla pouze 8048, 8051 a 8080. 8086 se vyráběla v SSSR.

[Jendа]

Vždyť to je i na Wikipédii.

[pc2005]

No to právě není na fotce je 8080 což je osmibiťák. Architektura x86 by to byla buď 8088 nebo 8086. Právě jsem byl mírně zmaten, protože i jinde jsem našel 8088, ale na obrázku byla dál 8080.

[Bystroushaak]

PP06.

Tak na tom jsem jako skolak zacinal.

Au. Krutá stránka, zkoušel jsem si projít to muzeum, ale najednou mě začaly ukrutně pálit oči.

[Jendа]

Jinak tohle taky vypadá zajímavě, ale bohužel teď nejsem na lince, kde bych to mohl stáhnout.

A vůbec, dovoluji si upozornit, že Vánoční DSP bude věnováno právě technologii Tesly 80. let. Záznam bude, stream kvůli technickým problémům asi ne.

[Bystroushaak]

Jinak tohle taky vypadá zajímavě, ale bohužel teď nejsem na lince, kde bych to mohl stáhnout.

Díky za link, vypadá to super.