Vlákno názorů k článku Čtyřicet let existence slavných mikroprocesorů řady Motorola 68000 od klokan - Jo, to byly časy, když jsem se na...

Jo, to byly časy, když jsem se na svém milovaném Atari ST poprvé pokoušel programovat v assembleru :) Mimochodem M68000 měl sice 32 bitovou instrukční sadu, ale interně (včetně ALU atd.) to byl čistě 16-bitový čip, proto, pokud si dobře vzpomínám, 32 bitové instrukce trvaly vždycky dvojnásobný počet taktů. Pravou 32bit architekturu přinesl až 68020. Jinak - jako všichni tehdejší náctiletí majitelé Amig a Atárek - jsem samozřejmě taky trval na tom, jak je instrukční sada m68k úžasněkrásná proti strašněohavnému x86, ale pravda je, že s odstupem měla i tahle architektura svoje "zvláštnosti". Mám na mysli např. ukazatel zásobníku SP, který se snažil vypadat jako obyčejný osmý adresový registr A7, ale přitom se "potichu" choval jinak - vždycky musel ukazovat na sudou adresu a automaticky se tak zaokrouhloval, takže instrukce sub.l #1,a6 sice dekrementovala A6 o jednu, ale sub.l #1,a7 dekrementovala A7 o dvě. Nebo "Move from SR", která se v 68010 najednou stala privilegovaná (samozřejmě měla být od začátku) a rozbila tak zpětnou kompatibilitu. Anebo 24-bitová adresová sběrnice, kde se nevynucovalo, aby horní oktet 32-bitového adresového registru byl 0, takže řada vývojářů tohohle "chytře" využívala ke značkování ukazatelů a při přechodu na plně 32 bitové CPU jako 68020 a 68030 se pak člověk nestačil divit (zvlášť uživatelé Macintoshe si s tímhle užili své...) A pak pozdější modely, které už nedokázaly držet krok se Intelem: 68040 se záměrně vykastrovanou FPU a chronickým problémem s přehříváním, 68060 kde FPU neměla pipeline...

> registr A7, ale přitom se "potichu" choval jinak - vždycky musel ukazovat na sudou adresu a automaticky se tak zaokrouhloval, takže instrukce sub.l #1,a6 sice dekrementovala A6 o jednu, ale sub.l #1,a7 dekrementovala A7 o dvě

To si pamatas trochu skreslene - samozrejme, ze A7 moze mat akukolvek hodnotu. Dokonca pri 020+ CPU mozes cez neparne A7 aj na stack ukladat. V com sa A7 lisilo bolo ukladanie na zasobnik:

move.b #1,-(a7) ; a7 sa znizi o 2
move.b (a7)+,d0 ; a7 sa zvysi o 2

aby sa implicitne umoznilo na 68000 (ktore neumoznuje ukladat na neparne adresy) ukladat aj bajtove parametre. Ale pri 020+ procesoroch je to uz len ciste ako vstavana optimalizacia, nie nutnost.

Ano, od 020 máš pravdu, tam šlo dokonce číst nebo ukládat 32bit slova i na libovolné liché adresy (bylo to pomalejší, ale šlo to) ale pokud si vzpomínám, na originálním 68k nešlo mít lichou hodnotu v A7. Možná se ale pletu, budu si to muset vyzkoušet ve FSUAE...

S tou Move from SR máš naprostou pravdu, ta měla být privilegovaná, protože z userspacu se některé údaje z vyššího bajtu SR číst neměly. Ale pořád to bylo na naučení assembleru lepší než ve stejné době na x86, kde si člověk musel pamatovat, že násobení jedině s dvojicí DX:AX (žádné 32bit registry), sice existuje LOOP, ale ten pracuje jen s CX, sice existuje možnost adresování přes bázovou adresu, ale ta musí být v BX (tedy jen část offsetu, segment ne, to je jiná pohádka :-), sice existuje možnost mít v adrese "displacement", ale to jen v SI nebo DI, většina dekadických instrukcí pracuje jen s AX atd. Vlastně ani nevím, proč si to ještě pořád pamatuju (potom tu sadu udělali ortogonálnější a x86-64 je už někde jinde, uznávám).

Původní x86 bylo kapitola sama o sobě, o tom žádná, ale osobně mi nepřišlo obtížné si pamatovat, co který registr dělá, protože to už je vlastně i v názvu: AX - akumulátor, BX - báze, CX - counter, DX - data, SI - segment index apod. Spíš mi na něm vadilo to segmentové adresování (při čistě 16bitových registrech to jinak asi ani nešlo, budiž!) a optimalizace kódu byla anabáze, aby člověk dostal správnou hodnotu do správného registru a nemusel při tom pořád dělat push a pop... I i386-i686 ještě trpělo nedostatkem registrů a x87 bylo "dílo". Musím ale říct, že x86-64 alias amd64 už mi připadá objektivně lepší, než m68k (samozřejmě nevíme, jak by hypotetické 68k-64 vypadalo dneska, kdyby existovalo...)

Jj proto si to taky ještě pamatuji. Ale mě spíš šlo o tu druhou informaci - že člověk pořád musel mít data ve správném registru, takže pořád nějaké push, pop (jak píšeš), mov atd. Instrukce (některé) tedy sice byly kratší, ovšem bylo jich nutno napsat/vygenerovat víc, než na Motorole.

PS: nejvíc mě to trápilo v kategorii 128B intros, ale asi na to narazili i lidi, co se snažili dostat celý program do jediného segmentu (což se těsně podařilo Volkovu 4.x, pětka už byla větší).

No právě, vždycky to bylo zajímavé srovnání. Na jednu stranu x86 neumožňovalo si držet tolik věcí v registrech, jako na 68k a vyžadovalo víc přesunů, na druhou stranu ale hodně základních instrukcí (včetně těch push/pop, pokud se nepletu) zabíralo jediný oktet (na 68k byla min. délka instrukce 2 oktety a u 32bitových immediate operandů min. 6 oktetů) a mělo zase instrukce jako rep, nebo přímý přístup do AH, BH atd., což mu zase 68k mohlo závidět. Tehdy to byly nádherné flamewary :) Ale pokud jde o ty CPU, osobně tvrdím, že Motorola za dobu své činnosti v oblasti procesorů vydala dva majstrštyky, M68030 a DSP56000. Oba to byly na svou dobu úžasné a fantasticky navržené čipy, které se v různých podobách používají v podstatě dodnes. S původním 68000 mám krásné vzpomínky, ale asi bych se k němu doopravdy vracet už nechtěl...

SI = source index, DI = destination index,...

Jasně, pravda, díky.

Tak on měl v době 68040 a i486 Intel mnohem víc peněz z IBM PC, takže si mohli dovolit tu jejich divnou ISA optimalizovat metodami brute force (několik sčítaček a tak) a samozřejmě se také projevila economy of scale. Tam už Motorola relativně zpomalovala a možná za to může i architektura Amigy a ST čka. To byly skvělé stroje na určité typy her, kde se využily bitplany, ale takový Doom s kompletním SW renderingem už byl doména PCček, které to prostě utáhly hrubou výpočetní silou.

To je trochu jiný problém. Samozřejmě, že i486 měla úplně jiný výkon, než 68k, ale taky už patří do jiné doby. Jenže ani Amiga nebo ST se silnějším procesorem jako A4000 nebo Falcon by takový Doom moc nezvládali kvůli planární grafice. PC mělo VGA, kde 1 pixel = 1 bajt, což bylo ideální pro rychlé softwarové renderování. Na Amize a Atari to bylo o dost složitější, Amigacký přístup sice značně usnadňoval zase rychlou 2D animaci pomocí spritů a blitteru, ale na tohle byl dost pekelný. Pokud si vzpomínám, na CD32 byl nějaký custom chip, který prováděl konverzi lineárního framebufferu na planární a díky tomu mohli mít verzi Doomu, která jinak na ostatních Amigách nefungovala.

Dlužno ale říct, že nějací šílenci to nevzdali a ještě v 90 letech vyvinuli hru Substation, což je Doom-like FPS pro Atari ST. Díky geniálně vyvedenému grafickému designu se obešli bez mapovaných textur a hra tak funguje na obyčejném STE s 8MHz a přitom vypadá dobře!

Proto jsem taky porovnával i486 s 680_4_0, které byly použity v +- stejné době. Takže tyto čipy spolu přímo soutěžily, ale jak píšeš, projevily se další vlastnosti těch platforem.

(BTW Doom používal x-mode, tedy ne zcela klasický mode 13. díky tomu bylo možné si na i386 přepnout nižší rozlišení v horizontálním směru. Ale ten algoritmus IMO vykresloval po sloupcích, takže to bylo jedno, jak jsou za sebou sloupce umístěny).

Ty čipy byly při stejné frekvenci dost dobře porovnatelné, 68040 dokonce vycházela líp, hlavně u FP (až 3x): https://textfiles.meulie.net/computers/486vs040.txt

JENŽE - to je ten kámen úrazu, protože se frekvence u Motorol nezvyšovala tak dobře, jako u x86 (přehřívání atd.), takže to Intel nakonec vyhrával hrubou silou (DX2, DX4).

S tou CD32 je to tak, tu C2P konverzi dělal čip AKIKO. Údajně měla tato HW podpora fungovat na CD32 automaticky při použití WriteChunkyPixels v graphics.library

Škoda, že se to nedostalo už do A1200.

Ten Amiga DOOM je k vidění např. zde: https://youtu.be/B4fzMaadcHk?t=458

Ono je spíš škoda, že chipset AGA neuměl normální chunky grafiku, pak by žádný Akiko nebyl potřeba.

Jenže ani Amiga nebo ST se silnějším procesorem jako A4000 nebo Falcon by takový Doom moc nezvládali kvůli planární grafice.

Že by? https://youtu.be/RiE0Y1su-9g