Portál AbcLinuxu, 15. května 2025 19:26
26.10.2010 17:23
mikirc | skóre: 19
| blog: MikiSoft
| Vsetín
26.10.2010 17:54
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
27.10.2010 21:55
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
, ještě bych poprosil o ARM verzi (stačí do budoucna...).
Btw 30x to by snad bylo i rychlejší než TCC :-O.
(nebo spíš 
). Vzhledem k nemožnosti 8bit přístupu k indexovým registrům pak už moc registrů na práci s daty není .
Pak taky když jsem si před prázdninama hrál a tvořil "parser" strojového kódu, tak se objevovaly takový vtipný věci jako dvojčata nebo i trojčata (různý opkód, stejná funkce).
Stroják x86 je naprostý luxus. A instrukční sada je poměrně dobře zvolena z hlediska C/C++.To bych bral teda spíš jako nevýhodu
.
Snad Vám dřevěnost ARM asm aspoň připomene to, že i Linux měnil binární rozhraní pro volání kernelu pro ARM, protože není snadné najít model, který by byl efektivní.Jj něco jsem o tom zaslechl...
Rychlost ARMu není kritická, ale jen proto, že ARM má pro většinu aplikací výkonu nazbyt. A jen tam dost velká neefektivita právě obcházení příliš chudých možností ARM instrukcí.No tak ARM je RISC, pokud je opkód hnusnej, ale aplikace běží rychlejc, tak je to i tak plus. Nehledě na to, že jak jsem psal cokoliv bude IMHO lepší než x86. Jinak instrukce ARMu chudé nejsou, zvlášť když má ARM někde 4 emulační módy (jazelle, thumb atd.).
loop existuje, stejně se na čemkoliv modernějším nevyplatí.
ARM je samozřejmě daleko elegantnější, ale dnešní implementace x86ky jsou proklatě dobré, takže téměř všechny nevýhody architektury obejdou. Za to se samozřejmě platí mnohem větší komplikovaností a tím pádem i spotřebou procesoru.
. Je docela možný, že 64bit je o něco lepší, ale pořád musí být kompatibilní s tou starou architekturou. V případě toho zpětně nekompatibilního módu bych uvažoval spíš o jiné architektuře už.
Jinak ještě k té strojové optimalizaci kódu kompilátorem. Nepoužívá náhodou x86 instrukční sada už někde od P2 překlad na RISC mikrokód? Rozhodně se mě nezdá, že by konverze C→CISC x86→RISC mikrokód byla v principu nějak účinnější než C→RISC ARM.
Pouzivani mikroinstrukci tak jak to dela i386 sice usnadnuje praci tvurcum kompilatoru, ale
1) Ukazuje ubastlenost puvodni i386 instrukcni sady. proc by ji jinak bylo potreba prekladat? A proc jit napul cesty? Konec koncu JIT preklad javy nebo pythonu je principielne to same (a pripada mi ironicke ze jedno povazujete za super vec a druhe za ztelesneni Satana).
2) Stoji tranzistory. Proc v iPhone neni Atom misto ARMu? Protoze Atom musi venovat tranzistory (tedy plochu cipu a spotrebu) prekladu instrukcni sady i386 do neceho rozumneho, zatimco ARM ma ty instrukce v rozumne podobe od zacatku. A proto muze mit pri stejne funkcnosti mene tranzistoru (tj. mensi plochu cipu a spotrebu).
). S jinými VM by to mohlo jít snazší, třeba Parrot vypadá nadějněji.
Ad 2: To samozřejmě ano – proto se ARM skvěle hodí na různé embedded aplikace, ve kterých záleží na každém miliwattu příkonu. Ale pokud chcete stavět opravdu výkonný procesor, tak vám obvykle záleží na jiných věcech a ukazuje se, že x86 (poměrně překvapivě, když uvážíme, jaký děsný bastl to je) se na to hodí docela dobře.
x86 je od začátku dělaná tak, že je to v zásadě virtuální stroj, který emuluje nějakou sadu instrukcí. x86 instrukce se nevykonávají přímo, ale emulují uvnitř cpu. x86 instrukce jsou rozloženy do mikroinstrukcí, které se pochopitelně mohou měnit a zdokonalovat s každým modelem cpu.To je pak s podivem, že je instrukční sada tak neortogonální. Jinak imho je lepší updatovat kompilátor než updatovat procesor.
Rozdíl mezi x86 a ARM je jednoduchý: ARM přenáší na programátora omezení hw a low level přístup. ARM sada je dělaná tak, aby elektronika byla co nejjednodušší a zákonitě přenáší řadu omezení na asm programátora, či na kompilátor – jinak to nejde.Rozhodně, to je podstata RISC. CPU pak může jet mnohem rychleji.
x86 sada naproti nemá téměř žádný vztah ke skutečné architektuře cpu. x86 cpu si dělá své vlastní vnitřní mikroinstrukce (které jsou tím pádem efektivnější a rychlejší, protože jsou dělány pouze s ohledem na co nejlepší míru architektuře cpu, a asm programátor je nikdy neuvidí, tudíž se nemusí ohýbat = zpomalovat pro něho).Tak to se mě nezdá, minimálně nese zpětnou kompatibilitu (s periferiemi) někde až z dob 8080. Což například znamená věci jako 8bit přístup... Když jsem porovnával třeba čítače/časovače OMAPu s čítači/časovači PC, tak to bylo nebe a dudy
.
Jinak by teda mělo být možný sestavit v kompilátoru ten převod C→ARM asm, stejně jako to dělá mikrokód v x86.
x86 je od začátku dělaná tak, že je to v zásadě virtuální stroj, který emuluje nějakou sadu instrukcí.To není pravda. První procesory řady x86 sice měly mikroinstrukce, ale instruční sada byla velmi těsně svázána s architekturou procesoru.
překlad instrukcí se děje paralelně a narázTo sice ano, ale se spoustou omezení (instrukce na sobě závisejí; kvůli proměnlivým délkám instrukcí je těžké dekódovat několik instrukcí dopředu atd.). Některým procesorům řady x86 se běžně stávalo (třeba u AMD K6), že vykonávání instrukcí bylo bržděné rychlostí dekodérů.
x86 sada naproti nemá téměř žádný vztah ke skutečné architektuře cpu.Dnes už ne. Je totiž navržena podle dávno již neexistující architektury CPU a dodnes na autory překladačů přenáší omezení té dávné architektury.
Máte příjemný asm pro programátoraCože? To asi každý programujeme na jiné x86
Taky nechápu proč se nemůže do segmentovejch registrů zapisovat přímo.Na segmentové registry zapomeňte. To je dědictví minulosti, které už dneska nikdo soudný nepoužívá. Ve 64-bitovém módu prakticky neexistují. (Dobře, existuje jedna výjimka, a to používání GS k relativní adresaci per-thread dat.) Takových obskurností se v x86 za těch 30 let značně křivolakého vývoje nahromadila spousta.
Loop není sám, zajímavý je třeba REP, který podle CX opakuje následující instrukci (používá se na kopírování paměť-paměť).To je pravda, ale naštěstí hustota takových přesunů v kódu je poměrně malá, takže to při alokaci registrů moc velkou paseku nenapáchá.
Pak jak se začaly přidávat věci jako MMX, SSE, tak se musely dít věciA děly
Ale třeba takové SSE je docela hezky ortogonální instrukční sada. (Jen kdyby uměla počítat zbytky po dělení … to by se implementovala reziduová aritmetika …)
Nepoužívá náhodou x86 instrukční sada už někde od P2 překlad na RISC mikrokód?On to není mikrokód v tom klasickém smyslu, spíš sada jednodušších instrukcí.
Rozhodně se mě nezdá, že by konverze C→CISC x86→RISC mikrokód byla v principu nějak účinnější než C→RISC ARM.Ta konverze má jednu velkou výhodu, totiž že strojový kód x86 vychází výrazně kompaktnější než u ARMu, což šetří paměť a hlavně místo v cache. (Ostatně u ARMů to už také objevili a vymysleli Thumb.) (Svatý Tučnáku, ono to asi vypadá, že si myslím, že x86 se mi líbí! No to opravdu ne, ošklivější instrukční sadu aby jeden pohledal. Jen už jsem po letech pochopil, že to zase takové zlo není a že vytvořit něco, co by bylo natolik lepší, že by to mělo šanci nad x86 na trhu vyhrát, nedovedu.)
Na segmentové registry zapomeňte. To je dědictví minulosti, které už dneska nikdo soudný nepoužívá. Ve 64-bitovém módu prakticky neexistují.Aha, já se k 64bitu ještě nedostal a když to porovnám třeba právě s OMAPem, tak se asi ani nedostanu
.
To je pravda, ale naštěstí hustota takových přesunů v kódu je poměrně malá, takže to při alokaci registrů moc velkou paseku nenapáchá.Jo ovšem pokud člověk neprogramuje BIOS, kde je vše 16bitové a ještě třeba neexistuje paměť
.
Jen už jsem po letech pochopil, že to zase takové zlo není a že vytvořit něco, co by bylo natolik lepší, že by to mělo šanci nad x86 na trhu vyhrát, nedovedu.Tak to není problém, stačí vytvořit něco co bude levnější a rychlejší
, třeba ten ARM s thumbem a jazelle má dost šancí.
Jo ovšem pokud člověk neprogramuje BIOS, kde je vše 16bitové a ještě třeba neexistuje paměťMíst v BIOSu, kde by paměť neexistovala, je naprosté minimum. Obvykle se používá nádherný trik: L2 cache se přepne do módu, kdy nekomunikuje s RAMkou a nic nevyhazuje, takže do ní můžete zapisovat jako do RAMky, i když ještě není inicializovaný řadič paměti.
Tak to není problém, stačí vytvořit něco co bude levnější a rychlejšíMoc bych mu to přál. Ale realistická část mého já tomu moc velké šance nedává. Hlavně proto, že rychlejší sotva bude; jediné, v čem má šanci vyhrát, je spotřeba.
. Škoda, že spousta těch ARMů nemá nějakou pořádnou sběrnici (třeba PCI) nebo ještě lépe CPU2CPU.
Jo o tý cache vím, ale nezdá se mě to moc regulérní, ten komp tuším L2 nemusí mít vůbec.Pssst, už je rok 2010
L2 cache bývá v x86kovém světě už pěkných pár let uvnitř procesoru.
. Jinak jasný na novým kompu bych prostě nainstaloval coreboot a hotovo. Ono taky ty nový procíky jsou blbě dokumentovaný, osobně by mě třeba zajímal assembler mikrocode patchů.
28.10.2010 06:52
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Já Vám klidně napíšu kompilátor, který Vám to zkompiluje 30× rychleji a spotřebuje ještě méně paměti.Ja chcem ten kompilátor. Inak vás nikto nebude brať vážne po takých šplechoch. Optimalizáciu mám na háku, tú mi spravý gcc.
27.10.2010 10:11
Vykook | skóre: 23
| blog: Tomas
Jojo, ponkrac je ztelesnenim humoru. Takovej linuxovej Hulan.
Ponkrac o sobe taky rad mluvi ve treti osobne.
.
.
Jako autor zmíněného článku se musím ohradit. Výsledkem testu bylo, že kompilace v LLVM (resp. vzniklá binárka) je rychlejší pouze bez optimalizací. Při provádění optimalizací, což je důležité, dominuje GCC. (U vysoce optimalizovatelné kódu GCC vytvořilo téměř dvakrát rychlejší kód.) To je vcelku logické; GCC je mnohem robustnější produkt, který využívá mnohem více pomocných dat...
Proto je pro praxi výhodnější GCC. Vysokou rychlost kompilace bez optimalizací ocení asi jen úplní začátečníci a ctrl-v programátoři, kteří intenzivně zkouší, zda program už bude fungovat.
28.10.2010 19:45
Shadow | skóre: 25
| blog: Brainstorm
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.