Názory k článku Konkurence procesorů s mikroprogramovým řadičem - architektura RISC

Kedze chybala nasobicka v cipe: Znamena to, ze prekladac musel nasobicku implementovat "rucne"?

A to asi nebude floating point nasobicka, ze?

Myslim ze si to pletete s ARMem. Ja tedy znam pouze R3000 kde je shift samostatna instrukce, ale necekam ze by R2000 byla nejak zasadne jina. V ARMu je shift soucasti adresniho modu. Na jednu stranu to dela spolu s instrukcemi ldm a stm hustsi kod (srovnatelny s x86, naproti tomu MIPS vychazi tak 3* delsi oproti x86), na druhou stranu ma ALU delsi kritickou cestu nez u MIPS, coz komplikuje vnitrni fungovani tech novych ARMu (>500MHz takt) -- je potreba delsi pipeline. V jednom kroku se dela shift, v dalsim ALU.

Nikdy jsem pro MIPS primo neprogramoval, takze nevim. V seznamu instrukci jsem ale nevidel cokoliv jako ADD r0, r1, r2 shl 4, a tez v blokovem schematu procesoru neni barrel shifter predrazen ALU, jako to ma ARM, z cehoz vyvozuji ze to neni mozne napsat, a ze bity v instrukcnim kodu jsou takto alokovany jen proto, aby se zjednodusilo dekodovani instrukce.

Díky za další zajímavý článek.
Osobně musím říct, že co jsem přišel do styku s různými CPU, tak nejlepší mi přišel assembler MC68000 (Amiga). Jen mi tehdy trošku přišlo škoda, že je bigendian.
Možná by neškodilo napsal samostatný článek věnovaný problému endianity. Jak se to seběhlo :-), kdy se která hodí atd.

Zajímavý. Mně se právě big endian líbil. Přišel mi logičtější. Vono načíst ze souboru řetězec "JFIF" a muset ho porovnávat na "FIFJ" mi přijde strašlivý. Jediná výhoda little endianu je snad, pokud bych sčítal po bajtech dvou nebo čtyřbajtový čísla, ale jenom u procesoru, kterej neumí indexovat. Nevím nevím, faktický vítězství little endianu považuju za strašlivou tragédii pro lidstvo a zpomalení vývoje vo desítky let :-)

Proč je x86 little endian jsem někde četl. Zdědila to po 8080, ta po 8008 a ta po Datapointu 2200, kterýho první verze neměla RAM, ale posuvnej registr a tudíž sčítání delších čísel za pomocí dekrementace by zabralo neúměrně moc času, protože se musel posuvnej registr protočit skoro celej dokola.
6502 to podle mě vzala taky vod 8080, ARM to vzal vod 6502.

Jojo. Tady to je: http://silicongenesis.stanford.edu/transcripts/mazor.htm

Přímo odstavec, kde Stan Mazor říká, že little endian byl omyl :-)

SM: Well, one that's kind of interesting is this Little Indian, Big Indian thing. It's turned out that when I was at Intel, I defined the 8008 instruction set and the 8008 addressing modes and I did it in a strange way which we ended up calling Little Indian, which means the low address comes first. And I did that because the DataPoint machine was bit serial and I was trying to do something compatible for them, although I knew it was backwards at the time. Well, as it turned out, they never used any so that by making the Little Indian first was kind of a mistake. And the Intel 8080 and 8086 also were then Little Indian. So we have something in the industry where the Intel way has been more or less the wrong way and we did it for the wrong reason. And that's one of the…
RW: And you're responsible.
SM: And I'm the guy that did it and it was my mistake.
RW: They didn't give you an award for that.

Jojo, pokud mám číslo 32 bitů a ukazatel je jenom na 16 bitů tak tu chybu na little endianu může odhalit až uživatel. Na big endianu je to hned :-)
Koukám, že ARM je stejně jako PowerPC nebo MIPS bi-endian.

MIPS může být obojí.

Me zas prijde logictejsi little endian. Ale az na druhy pohled, kdyz si uvedomim jak jsme vlastne prisli k pozicni cislene soustave. Ti ucenci, kteri ji ve stredoveku privezli z arabie ji okopirovali doslova, tedy i se smerem zapisu, ignorujic ze puvodni uzivatele psali z naseho pohledu pozpatku.

Pro ne tedy bude little-endian prirozeny zpusob. Je to docela pochopitelne kdyz uvazime hypotezu ze pozicni soustava vznikla zaroven s algoritmem scitani (jako `datova struktura' pro jeho efektivni implementaci). Bezne scitani (bez zrychleneho prenosu) postupuje od nizsich radu a je tedy prirozene, ze ten kdo toto vymyslel, to zacal zapisovat v poradi ve kterem normalne psal.

6502 byla little-endian zamerne, protoze ji to umoznilo byt rychlejsi nez 6800 pri indexovych adresovych rezimech. Zatimco se nacital vyssi byte offsetu, nizsi uz byl v CPU a mohl se k nemu pricitat obsah 8bit indexoveho registru. Usetril se tim 1 takt.

Jak uz jste psal, ma little endian vyhodu pri implementaci aritmetiky dlouhych cisel. Taky v pripade pouziti pointeru nekdy byva prijemne (i kdyz neportabilni), ze nejnizsi cislice je na stale stejne adrese at uz ten pouinter ma typ i16* nebo i32*.

Jedina nevyhoda je, pokud si debuggerem binarne prohlizite obsah pameti -- v tom pripade ale postaci vzit se do uvazovani typickeho gramotneho araba a mate vyhrano. V tom pripade tez doporucuji kreslit si bity ve slove (napr. v I/O registrech periferie) od nejnizsiho po nejvyssi z leva do prava a mate to logicke jak jste chtel ;)

No názory na to jsou různý :-)
No, asi to Arabovi může připadat přirozený... O ukazatelích __int16* vs __int32* si spíš myslím, že to může zakrývat chybu v programu, na kterou se přijde až pozdě. Výhoda při aritmetice dlouhých čísel je pouze u starých procesorů, které neumějí indexovat (tak někde na úrovni i8080). Jinak mám v jednom registru začátek čísla a ve druhém index, pomocí kterého ho pozpátku procházím. Prostě ten evropskej způsob myšlení je ve mě až příliš zakořeněnej a na první pozici očekávám vyšší (důležitější) řády. Flamů na tohle téma asi byly tisíce a tisíce :-)

Cteni pole pozpatku je na nekterych CPU (napr. K6) pomalejsi nez cteni od nizsich adres k vyssim.

Jinak mate pravdu, ze hadat se o to, jestli je lepsi little nebo big endian je asi tak dulezite, zda je lepsi jezdit vpravo nebo vlevo.

Mimochodem ještě bych opravil názor ohledně arabských číslic. Ty byly převzaty (okopírovány doslova) z indických číslic a indové psali zleva doprava, takže napřed ty vyšší, důležité řády. Evropani to pak další převzetím "doslova" pouze zpět obrátili k původnímu pořadí. Mimochodem staré evropské zápisy (latinské, řecké) mají taky napřed ty vyšší řády, čínské taky, egyptské taky. A to hlavně z důvodu toho, že v řeči taky říkáme prvně tisíce, stovky, desítky a pak až jednotky. Akorát němci si v nějakým deliriu přehodili jednotky a desítky, ale zbytek taky říkají dobře. Takže přirozenost je prvně koukat na vyšší řády.

68000 neni spatna, ale ja za nejpeknejsi assembler (vhodny pro vyuku) povazuju instrukcni sadu ARMu, pripadne jeste MIPS. 68000 obsahuje spoustu zbytecnych instrukci a navic to podivne rozdeleni registru na adresove a datove, coz pri prvnim setkani s assemblerem zbytecne odvadi pozornost nepatricnym smerem. I tak je ale 68000 daleko lepsi nez x86.

Instrukční sada řadiče byla v akademické sféře natolik redukována, že vznikl jednoinstrukční procesor. Zlé jazyky tvrdí, že onou instrukcí je NOP, ale není to pravda.

Vaše články si vždy, když mám čas, rád přečtu. Ty o řezových CPU se mi až tak moc názorně napsané nezdály, ale tento se povedl opravdu velmi pěkně. Doufám, že nebudete nic mít proti linkování z předmětu Architektury počítačů, který se jak (nám síly a schopnosti stačí) snažíme zavést na ČVUT FEL.

https://edux.feld.cvut.cz/courses/A0B36APO/lectures/12/start

Pro doplnění zdrojů bych ještě doporučil k zhlédnutí text
John Bayko (Tau): Great Microprocessors of the Past and Present

http://www.cpushack.com/CPU/cpu.html

Bohužel již není od roku 2003 inovovaný, ale lepší průhled vývojem myšlení návrhářů CPU jsem zatím nikde nepotkal. Výklad je komprimovaný akorát tak, jak mi to vyhovuje, takže pro někoho bez obecné znalosti může být na přečtení celkem obtížný.

Doufám, že mi vyjde čas navštívit Retrofet na Strahově a budu velice rád, pokud se tam třeba potkáme.

S pozdravem,

Pavel Píša