Re: Motorola VS Intel

[Martin Mares <mj@atrey.karlin.mff.cuni.cz>]

Hello, world!

>   Co se tyce dovednosti instrukci, jsou procesory vicemene ekvivalentni.
> Vyse uvedene je pouha demagogie - uved (prakticky) priklad.

   Bohuzel nikoliv -- Intel ma spoustu instrukci pevne spjatych s jednim
resp. malou mnozinou registru, takze jejich universalita velice ztraci,
nebot je treba spousta instrukci navic na presuny mezi temito registry
a, coz je horsi, casto take pro presuny mezi pameti a registry.

   Jinak priklady veci, ktere na MC680x0 jsou a na I80x86 ne (tento
seznam si necini naroky na kompletnost a je mozna jen veci me derave
pameti, ze jsem si nevzpomnel na nic uzitecneho, co by naopak na MC680x0
nebylo a na Intelu bylo): MOVEM, MOVE16, selektivni cache clear,
bit-field operations, predecrement/postincrement addressing, ADDQ/SUBQ,
prioritni interrupty, bus condition codes (a MOVEC k tomu)...

   Dalsi, i kdyz mozna na prvni pohled mirne spornou, vyhodou Motorolich
procesoru je pametove mapovane I/O, ktere tak umoznuje pristupovat
k I/O portum _libovolnymi_ instrukcemi -- napriklad takove nastaveni
konkretniho bitu na portu se docela hodi.

> > *Nesmyslne OP-kody. Spusta instrukci ma 8-bitovy Op-kod, vysledkem je,
> >  ze nasledne ulozeny 32bitovy ukazatel se cte z LICHE adresy! Slozitejsi
> >  Op-kody jsou pak ruzne dolepovany pridavnymi kody apod. Vysledkem je
> >  neskutecny chaos, ktery se obtizne rozsiruje.

>    Vetsina ma dvojbajtovy opkod. BTW: V uvedem prikladu se provedou
> pouze dve cteni. Intel si ty tri bajty "zapamatuje".

   Problem opkodu je v tom, ze instrukce, kterym byly puvodne (8086) prirazeny
1-bytove opkody, jiz davno nejsou ty nejpouzivanejsi, takze casto pouzivane
kody jsou znatelne delsi, nez by mohly byt. Navic spousta veci (16/32-bit verse
instrukci) je resena prefixy, jejichz defaultni hodnota je dana aktualnim
modem procesoru, pricemz lze ziskat budto mod, v nemz je vse 16-bitove, a tedy
32-bitove operace jsou velice dlouhe, nebo takovy, v nemz je vse defaultne
32-bitove, procez jsou zase neunosne dlouhe 16-bitove operace. Proto spousta
kompilatoru kompiluje do 32-bitoveho modu a 16-bitove operace radeji
nepouziva, i kdyz by (pravda, pokud by nebyly tak znevyhodneny svou delkou)
byly pro danou situaci daleko vyhodnejsi.

> > *Minimum adresovacich modu.Vypocet efektivni adresy se provadi asi 5
> >  zakladnimi mody. Zbytek se musi kombinovat, coz u tak nizkeho poctu
> >  registru vede k dalsimu hrabani do pameti.
>    Chybi lepsi postinkrement a predekrement, to ano. Ale adresnich
> modu je docela dost (Napr: [EBX+2*EAX+4] ).

   Adresnich modu je sice pomerne mnoho, ale podiva-li se clovek na to, jak
dlouha instrukce pak vznikne (viz predchozi odstavce), radeji dany mod
nepouzije, protoze jeho opis je kratsi a kdyz ne kratsi, casto rychlejsi.
Ostatne prave proto GCC polovinu techto modu vubec nepouziva.

> > *Neschopny pipeling. To cemu se rika zpracovani nekolika instrukci
> > soucasne
> >  je Intelu odepreno.Parovat se totiz daji jen tzv. jednoduche instrukce,
> >  kterych je jen hrstka a jejich soucasne pouziti za sebou v kodu je asi
> >  tak pravdepodobne jako ze Microsoft vytvori kvalitni operacni system.
>   Parovat se daji vsechny instrukce krome matematickeho koprocesoru
> a privilegovanych instrukci (kterych je malo).

   Hmmm... ani jedno, ani druhe neni podle meho nazoru tak docela pravda. Parovat se da
docela dost instrukci, ale prijit na to, ktere ano a ktere ne, je casto vykon
temer nadlidsky. Na programech, ktere nebyly specialne pro toto (mirne podivne
fungujici) parovani staveny, se temer zadne zrychleni neprojevi. Navic pravidla
pro parovani v P6 jsou jina nez v Pentiu, takze je nutno optimalizovat o dost jinak
-- kde jsi, kompatibilito?

> > *Debilni mnemonika. To sice neni chyba hardwaru, ale naprosto to
> > znemoznuje
> >  trochu rozumne programovani. Priklad CMPXCHG8 - to je instrukce co ?
> >  Jednotlive prefixy a suffixy instrukci jsou vymysleny tak nelogicky, ze
> >  si je clovek musi pamatovat vsechny.
>   To neni vec procesoru ale assembleru.

   ACK. BTW nikdy jsem zminenou instrukci CMPXCHG8 nevidel pouzitou.

> > *Neschopnost presouvani dat. U Intelu zcela chybi adresni mod na
> >  presouvani z pameti do pameti, ci prace s obema operandy v pameti.
> >  Retezcove instrukce, ktere to umeji jsou neskutecne pomale, coz jejich
> >  pouziti vylucuje.
>   Zas tak pomale nejsou. MOVS je rychlejsi nez pres registry.

   Ano, MOVS je v _trivialnich_ pripadech rychlejsi nez pres registry. Lec
potrebuje-li clovek napr. s prenasenymi daty neco delat, je jiz rychlejsi
pouzit prime instrukce MOV/INC nez LODS/STOS (s nimi to vyjde o dost
pomalejsi). Viz copy_and_checksum a podobne funkce v ix86-ove implementaci
Linuxu.

> > *Slozite deleni/nasobeni. Tyto instrukce maji u Intelu takova omezeni,
> >  ze samotnemu vypoctu musi predchazet cela rada pripravnych praci
> > spojena
> >  s presouvanim z registru do registru apod. protoze na tyto operace jsou
> >  napevno prideleny registry.
>    IMUL funguje pro obecne registry. (IMUL EAX,EBX,ECX)

   Yes, ale jak je takova instrukce dlouha? Na druhou stranu, jak casto
bezny program potrebuje nasobit?

> > *Neexistence podminenych smycek. Vetsinu casu CPU stravi v nejake smycce
> >  u Pentia je zakladni instrukce LOOP pomalejsi, nez "sub cx,1 ; jne
>   Pokud pises takto, tak se nedivim. Pouzivej DEC CX. BTW: Existuje
> LOOPZ a LOOPNZ.

   Ano, LOOPZ a LOOPNZ existuji, ale jednak je casto treba nejaka uplne jina
podminka, jednak je LOOP skutecne o dost pomalejsi nez DEC/JNZ a mam pocit, ze
dokonce i nez SUB/JNZ (opet viz kod Linuxoveho jadra).

> >  mod 8086 :-))) ,ktere se musi v pripade Microsoftich systemu neustale
> >  prepinat, coz je neskutecne pomale.
>   Prepinani trva asi 200-500 taktu. Je to (na 200MHz) moc? (To je
> ovsem vcetne obnoveni registru atd.)

   Ano, to je docela dost. Zejmena proto, ze se to dela i pri kazdem interruptu,
coz vyrazne zhorsuje real-timove moznosti procesoru.

> > *Neschopne MMU. Sice o nem moc nevim, ale pri porovnani se schopnostmi
> > MMU
> >  Motoroly je to uplne srandovni.
>   Co chybi? Ochrana pameti na urovni strankovani je docela dobra.

   Chybi napriklad solidni stromove strankovani, transparentni translace,
rozumne volitelna velikost stranky, rizeni cacheovatelnosti bloku, pokracovani
od poloviny instrukce pri exceptionu a oddelene MMU pro instrukce a data.

> > *32-bitove registry. Samozrejmost u 32-bitoveho CPU, ale naprosty
> > nedostatek
> >  v pripade konkurovani RISCum.Take to silne zpochybnuje 64-bitovost
> > techto
> >  procesoru.
>   Motorola (680x0)( ma 64-bit?

   Ne. Az na nektere instrukce, ktere mohou pracovat s dosti sirokym rozsahem
velikosti dat -- napriklad MOVEM (na Intelu neex.), MOVE16 (velice sikovna
vec umoznujici pri presunu velkych bloku obejit datovou cache a tak zabranit
jejimu pripadnemu nesmyslnemu vyprazdneni).

> > *Vysoka vyrobni cena, chybovost a naprosta impotence jasne odsuzuji
> >  Pentiovou radu k zaniku.
> > 
>   Vyrobni cena je nizsi nez u Motorol apod. Je to take dano objemem
> vyroby, to je fakt.

   _Vyrobni_ cena je, rekl bych, nizsi u Motorol, ale naklady na vyvoj,
ktere ma Motorola o neco (ale ne zase o tolik) nizsi, jsou rozpousteny
do mensiho poctu vyrovenych kusu, cimz vznikne celkove vyssi prodejni cena.

>   Intel nepovazuji za nejlepsi, sam vim jak spatne se na nej
> v porovnani s Motorolou programuje, ale dovolil jsem si (po konzultaci
> s lidmi jenz Intel OPRAVDU znaji) provest opravu.

   Ja nepovazuji ani Intel, ani Motorolu za nejlepsi, sam jsem na obojim
programoval v assembleru asi tak 8 let a dovolil jsem si timto provest
drobnou opravu opravy...

					Have a nice day
								Martin