Hlavní navigace

Vlákno názorů k článku Mikroprocesory s architekturou ARM od Rax - V článku se motají dvě věci. První je...

  • Článek je starý, nové názory již nelze přidávat.
  • 12. 3. 2012 1:14

    Rax (neregistrovaný) ---.net.upcbroadband.cz

    V článku se motají dvě věci. První je situace v 80-tých letech, kdy byly tranzistory drahé a pomalé, 5 MHz procesor se tak dal provozovat s SRAM napřímo. Z této situace těžil RISC, protože pracuje s jednoduššími instrukcemi než CISC. Druhá je situace v dnešní době, kdy tranzistory jsou rychlé a velmi levné, ale rychlá paměť SRAM k nim je drahá a běžná DRAM je 10x-100x tak pomalá než by bylo potřeba. Z této situace těží CISC, protože má vyšší hustotu kódu.
    Proto bude zajímavé sledovat co se stane v budoucnu, zda se objeví nějaká rychlá a levná RAM nebo což je pravděpodobnější výrobci CISC přejdou na 22 a 15 nm a konkurenční výhoda ARMu malá spotřeba bude ta tam.

  • 12. 3. 2012 9:03

    zimiston (neregistrovaný) ---.251.broadband13.iol.cz

    Tahle úvaha předpokládá, že CISC (x86) má nějak dobře optimalizované kódování instrukcí. Ve skutečnosti rozdíl mezi RISC a CISC není až zas tak propastný, protože x86 (i x64) má kódování ušité horkou jehlou, kdy protahovali osmibit (8080) do délky. 8086 nebyl pro Intel prioritou, proto dopadnul, jak dopadnul. U x86 na jedné straně zabírají jednobajtové kódy nepoužívané (nebo minimálně používané) nesmysly typu DAA, XLAT, LAHF. CISCy komplexnější instrukce dnes už moc nepoužívají, protože se špatně optimalizují. Podívejte se na tabulku instrukcí u nejnovějších Intelů. Na některé se prostě vykašlali a trvají x taktů. A z x64 jich většinu vyházeli.
    Na druhé straně RISCy mají občas instrukce (např. u ARMu podmíněný součet r1 a r2 s uložením do r3), které na x86 musíte nahradit několika (minimálně třemi v praxi spíš více) instrukcemi.
    A mrkněte se někdy co vám leze z assembleru na x86, když překládáte céčkový kód. Protože má x86 málo registrů, tak je to samý PUSH, POP, čtení, zápis do lokálních tmp proměnných. Tohle všechno je u RISCů silně redukované.
    Navíc má ARM i 16bitové kódování Thumb, které zkracuje délku kódu.
    Navíc moderní x86 procesory do instrukční cache neodkládají x86 kód, ale tzv. microops, což je x86 přeložený do RISCových instrukcí.
    Navíc např. Alpha (délka instrukce 32 bitů) nebo Itanium (41 bitů) vznikaly v době, když se o pomalosti pamětí dávno vědělo, takže tohle konstruktéři zjevně jako problém nevnímali.
    No a taky moc nechápu, proč AMD, když už stvořilo nekompatibilní x64 aspoň trošku nezoptimalizovalo délku instrukcí a dokonce přidalo další prefixy, jednobajtové blbosti typu LAHF zachovalo...

  • 12. 3. 2012 10:35

    Pavel Tišnovský

    8086 je v podstate strasne zlo napachane na cele IT :-) Cela jedna generace programatoru vyrostla s nazorem, ze assembler a vlastne cely procesor je neco silene tajemneho (no pohled na tlustou knizku s intrukcemi 8086 jim dava za pravdu), puvodni instrukcni sada se horko tezko nahrazuje mircoops a vyvojari prekladacu taky maji tezkou pracicku s optimalizacemi. Navic prapodivny obchodni model, ne, budoucnost bude nekde jinde ;-)

  • 12. 3. 2012 10:22

    Pavel Tišnovský

    Jasne, to je stary problem "klasickych RISCU", presne toto pisu v osme kapitole o instrukcni sade Thumb, ktera na tento zvetsujici se rozdil reagovala. Pozdejsi ARMy uz mely vyrovnavaci pamet, nektere uniformni (I+D), nektere mely rozdelenou cache na I a D.

    Pokud si muzu tipnout, rekl bych, ze v budoucnu to bude RISC procesor s nejakou obdobou prekladaneho bajtkodu (Jazelle nebo tak), ovsem predpokladam, ze i386 konecne umre (coz mela uz davno a ano, duvody jsou zrejme).

  • 12. 3. 2012 13:57

    Sten (neregistrovaný) 93.185.48.---

    Netvrdil bych to. Zaprvé CISC sada x86 je velice špatně optimalizovaná, takže pro využití výhod CISCu by bylo potřeba navrhnout sadu úplně novou (Intel to zkusil s Itaniem, což je EPIC, tedy ještě účinnější, než CISC, ale na trhu neuspěl) a zadruhé ARM je od zavedení Thumb-2 a NEONu jakýsi CISC/RISC hybrid, aniž by jakkoliv utrpěla zpětná kompatilibita (jako trpěla s Itaniem).

  • 12. 3. 2012 14:08

    klusacek (neregistrovaný) ---.net.upcbroadband.cz

    Uz i non-Thumb ARM je hustotou kodu dost blizky i386, na rozdil treba od MIPSu, kde mi tataz vec prelozena pro SGI vychazela zhruba 2.5* delsi nez na Intelech.

    Navic zapominate ze velkost kodu ovlivnuji spis zapnute optimalizace v kompilatoru (inlining, loop-unrolling/SW-pipelining), nez instrukcni sada. Zrovna treba SW-pipelining zavisi na latencich instrukci konktetni implementace CPU. Takze treba na ARM7 kde je to jedno SW-pipelining kod neprodlouzi, kdezto kdyz nechate optimalizovat pro nejaky novy Cortex s dlouhou pipeline, tak muze dojit k nekolikanasobnemu prodlouzeni kodu --- ale nastesti se to tyka jen hot-spotu, jinde nema cenu takovou optimalizaci zapinat, takze ve vysledku to nebude az tak hrozne.