Vlákno názorů k článku Navrhujeme a vyrábíme vlastní CPU: druhy instrukcí a přerušení od MilanV - Já se přiznám, že mě systém v této...

Já se přiznám, že mě systém v této instrukční sadě překvapil. Přijde mi to jako velmi, velmi zajímavé - princip je krásně jednoduchý a jednotný. Na druhou stranu asi by nebylo triviální v tom psát přímo, muselo by se minimálně přes makroassembler, protože v té záplavě LD a MV něco číst musí být velmi nepohodlné. Makra JMP, RTI, SUB apod. by čitelnosti hodně napomohla, myslím.

Jak by se např. kopíroval blok paměti o dané délce? Např. na 6502 byl adresní mód zákl. adresa plus registr X. Takže stačilo naplnit X požadovanou délkou, dekrementovat X a smyčka na zero flag už fungovala "sama". Tady sice krásně můžu inkrementovat nebo dekrementovat přímo registry obsahující src a dst, ale zase přijdu o tu "indikaci nulou". To budu muset použít další registr ukazatel konce a v každém kroku smyčky to s ním porovnávat??

Na druhou stranu asi by nebylo triviální v tom psát přímo, muselo by se minimálně přes makroassembler

O makroassembleru bude v dalších pokračováních. Nebo se podívejte na GitHub: definice základních maker (pseudoinstrukcí).

Jak by se např. kopíroval blok paměti o dané délce?

Asi jsem kopírování bloků paměti nepotřeboval, ale podprogram memset_b je podobný algoritmus. Kdyby v r2 byla adresa zdrojového bloku, tak by stačilo do cyklu přidat instrukce LD a INC1:

memcpy:
.testz r1
.retz
ld r10, r2
stob r0, r10
inc1 r2, r2
inc1 r0, r0
dec1 r1, r1
.jmp memset_b

Díky. A na ten další díl se opravdu těším. Nechcete je vydávat častěji? :)

Takhle musím "podvádět" a koukat napřed na github :) Moc pěkně jsou tam věci zdokumentované, všechna čest. Bohužel jsem zatím neměl dost času to pročíst pořádně, tak se právě těším na ten "sumář" vždy tady v seriálu.

Dál jsou moje úvahy, neberte to jako kritiku, ale jako důkaz toho, jak zajímavě jste to všechno podal, že jste mě přiměl se nad tím trochu víc zamyslet :)

S těmi makry jsem to tak nějak myslel. Jen tedy nevím, jestli implementace všeho je korektní. Např. ten nop pomocí mv nemění náhodou flagy?
Druhý problém je pak s disassemblerem: musí být mnohem složitější. Pokud bych po něm chtěl i převod na ta makra, tak už možná bude tak složitý, že se nevejde ani do celé paměti toho počítače (32kB) a bude muset běhat jen externě na nějakém "větším bráškovi". Zatímco na osmibitech zabíral tak neznatelně paměti, že se s většinou programů vešel do RAM naráz a umožňoval jejich základní debugging bez pomoci jiného stroje.

Kopírování paměti jste nepotřeboval? Asi jste na tom ještě nedělal nějak více grafiku, že? :) A opět: takto nějak jsem si tu smyčku představoval, a přijde mi to trošku jako "plýtvání" - možná je to ale tím, jak jsem "odkojený" M6502: kdybych na takovouto operaci potřeboval čtyři 16bitové registry, tak nevím, co bych tehdy dělal, krom pláče v koutě :) Musely mi stačit dva 8bitové, a z toho ani jeden plnohodnotný (univerzální). A ve smyčce jen tři instrukce místo sedmi. Ale to je právě asi tím úhlem pohledu: když o registry není nouze a jsou "přirozeně" 16bitové, tak se asi programuje jiným stylem...

Např. ten nop pomocí mv nemění náhodou flagy?

Instrukce MV (a podobně např. EXCH, LD, STO) nemění flagy. Z tohoto pohledu může být problematické makro set0 implementované pomocí XOR, které flagy nastavuje.

Druhý problém je pak s disassemblerem

Disassembler jsem vůbec neřešil.

...a bude muset běhat jen externě na nějakém "větším bráškovi"

Celé to mám postavené tak, že assembler a debugger běží vedle na Linuxu a komunikují přes sériový port. Navíc debugger je momentálně jediný způsob, jak do MB50 nahrát a spustit program.

Asi jste na tom ještě nedělal nějak více grafiku, že?

Ne, dělal jsem jen zobrazování textu. Tam je kopírování specifické, protože se kopíruje blok 8 B z fontu do videopaměti s krokem 32 B.

přijde mi to trošku jako "plýtvání" - možná je to ale tím, jak jsem "odkojený" M6502

Já jsem začínal na Z80. Ta má sice registrů víc, ale i tak je potřeba hodně přemýšlet a šetřit. Ale zrovna na kopírování bloků paměti tam byly speciální instrukce. Tady jsem snažil zjednodušit programování právě tím, že bude k dispozici hodně registrů a všechny s plnou šířkou slova.

Dál jsou moje úvahy, neberte to jako kritiku, ale jako důkaz toho, jak zajímavě jste to všechno podal, že jste mě přiměl se nad tím trochu víc zamyslet

Já (konstruktivní) kritiku vítám. A Vaše úvahy, dotazy a připomínky jdou k jádru věci. Já jsem nad návrhem taky docela dlouho přemýšlel, než jsem dospěl k řešení, které mi připadalo rozumné. To ale neznamená, že je nejlepší nebo jediné možné. Je tam dost kompromisů a taky občas pokusy udělat věci jinak, než je obvyklé. Určitě je tam i dost chyb, o některých vím, o jiných ne. Např. už minule se tu diskutovalo, že registr ia neměl být obecný registr, ale CSR. A taky už bylo zmíněno, že při pokusu o implementaci pipeliningu nebo dalších optimalizací známých z výkonnějších CPU by se nejspíš celý návrh na různých místech rozsypal.

Těch věcí tam bude víc:

- Třeba při programování na vyšší úrovni bude běžný zápis a čtení ze struktury. Na to je důležitá relativní adresace. Pokud mi něco neuniklo, tak aktuálně by bylo potřeba LDIS, ADD a LD/ST, místo jednoho LD/ST s relativním offsetem. Ta by taky eliminovala potřebu LDIS/DTSTO - ten příklad se stack se v jazycích vyšší úrovně stejně nepoužívá.
- Malé konstanty pro operace obecně. I když je třeba říct, že jednoduchý LDIS (či ekvivalent) výše tu potřebu trochu eliminuje.
- Na rozšíření by se dal eliminovat část conditions u FLAGS - reálně se používají stejně jen čtyři (? - carry, zero, overflow, ...).

Ale chápu to tak, že cílem bylo postavit jednoduchý CPU, který bude relativně jednoduché implementovat, což se asi podařilo.