OldComp.cz

Když jsou jen 2 registry, LOW a HIGH, stačí jen 1 kontrola na přetečení a získání carry. U delšího řetězce (nebo když se přičítá starý carry) může vzniknout nový carry jednak přičtením starého carry nebo přičtením čísla. V C se dvě dlouhá čísla (s více částmi) sečítají takto:
1) k prvnímu číslu se přičte předešlý carry z nižšího řádu (výsledek se uloží do pomocného registru 'a'): a = *s1 + carry;
2) otestuje se přetečení (nový carry) - nastalo pokud je výsledek 0 a carry bylo 1: carry = (a < carry) ? 1 : 0;
3) načte se druhé číslo (do 'b') a přičte se k mezivýsledku: b = *s2; a += b;
4) opět se otestuje přetečení porovnáním mezivýsledku s operandem 'b' a přičte se k carry operací OR (výsledné carry není nikdy 2): carry += (a < b) ? 1 : 0;
5) uložení mezivýsledku, zvýšení ukazatelů a pokračování v součtu dalším (vyšším) řádem čísla: *d = a; d++; s1++; s2++;

U toho RISC-V procesoru vypadá že je to pomalé, kvůli nutnosti použít další instrukci navíc, ale jednak to tvoří jen malou část z prováděného kódu, moc se to neprojeví, a jednak předpokládá se napojení vyšších jazyků a ty stejně neumí používat carry, využívají ho jen assemblerovské rutiny. Když dělám operace s dlouhými čísly v ARM nebo x64, tak rozdíl rychlosti ve výpočtu mezi C (bez carry) a optimalizovanou rutinou v assembleru (s carry) je jenom v jednotkách procent. ... Ale jinak vypadá že s tím RISC-V procesorem se dá pracovat docela rychle a efektivně, když ho člověk dobře zná - autor jádra RISC-V Hazard3 na RP2350 Luke Wren napsal float knihovny pro RISC-V, které zvládnou součet float čísel za 46 strojových taktů a násobení za 35, zatímco v ARMu M0++ to trvalo 80 taktů.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

To se budes muset zeptat autora tohoto odkazu ktery jsem uvadel https://litwr2.github.io/8080-8085-z80- ... -6502.html (podle koncovky je to asi jen kopie neceho na githubu, ale tohle me to naslo prvni...)
Vsechno co jsem psal diakritikou je automaticky preklad.
Omg! JSR == CALL?
Muj odhad je ze narazi na to, ze Z80 ma podminkove varianty CALL i RET.




Ten kod se lisi jen v tom ze misto dvou carry a nasledneho pricteni provadi pricteni do stejneho, to ale ten procesor neumoznuje ne?

A dosel jsem ke stejnemu zaveru, ze ten assembler prilis pripomina C, kde si v techto pripadech pripadas slepy a bez rukou...
Takze je to jen dalsi evoluce navrhu procesoru tak, aby byl bliz k C.
Proc tam pak mit neco co C neumi a za cele roky neprijalo do sve vybavy? A na assembler asi nikdo sahat nebude...
A vzhledem k tomu ze si nemyslim ze mit ten carry flag by byl az takovy problem v HW, tak je to naprosto umyslne.
To se pak spis muzeme divat na osmibity jako devitibity (z hlediska aritmetiky) kdyz maji carry...

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

U překladačů se vždy divím tomu, že ani nepoužívají flagy z poslední operace, ale testují registr znovu. Např. udělá dekrement registru, ale než udělá skok zpět do smyčky tak znovu otestuje zda je ten registr 0 (přestože tam má Z flag). Asi se s flagy kompilátorům špatně pracuje. Tak umět pracovat s carry přímo v jazyku, v to bych nedoufal, protože by překladač neuměl zajistit aby se flagy během kódu nezměnily.

Víc mi u překladačů chybí, že nepodporují násobení a dělení s jinou velikostí operandů než je výsledek, což většina procesorů umí. Např. vynásobit dvě 8-bitová čísla a chtít 16-bitový výsledek, procesor to udělá 1 instrukcí kdy má 16-bitový výsledek automaticky, ale v jazyku lze udělat jen 8-bit * 8-bit s 8-bit výsledkem, nebo přetypovat některý z operandů na 16-bit, což sice dá 16-bit výsledek, ale operace se dělá přes složitější 16-bitové násobení. Jedinou obcházkou je použít na to speciální funkci napsanou v assembleru.

U RISC-V procesorů se přímo chlubí tím, že jsou "flag-less" a flagy vůbec nepoužívají. Zda to má nějakou výhodu v implementaci netuším. Možná je důvodem to, aby to bylo blíž vyšším jazykům, překladač se nemusí obtěžovat řešením flagů (které stejně neumí efektivně používat).

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Jo mas pravdu, pro programatora neni to co produkuje prekladac transparentni tak nepozna co se delo s priznaky (zero, carry)...
A nebo z druhe strany pokud se nadefinuje vse tak, aby byly priznaky transparentni, tzn stejny stav jako programovani v assembleru, tak to zase omezuje prekladac v optimalizacich a zvysuje nauceni pro programatora...

ale ciste teoreticky...

neco jako +c -c +c= -c=

rl = al+ bl;
rh = ah +c bh;

nebo

rl = al- bl;
rh = ah -c bh;

S tim ze proste mezi tim NESMI byt jina operace jinak je hodnota "c" nedefinovana...

Nebo jeste univerzalneji neco jako __carry_flag, __zero_flag

nebo

Kde by si to mohl i prekladac ohlidat a vypsat varovani kdyz se mu neco nezda... (napriklad to bylo pouzito v nejakem slozitem vyrazu kde neni jasne kdy do toho priznak vstupuje na rozdil od prosteho odcitani a pricitani) nebo cilova architektura to nepodporuje...
Vyzadovalo by to trosku nejakou znalost i od programatora, ale nemyslim ze by to bylo slozite pochopit. A uznavam... je to sice vykone jako motorova pila ale i stejne nebezpecne...

Skoro me prijde, ze uz to nekdo musel vymyslet...
gcc ma ruzne specialni makra, kde se pouzivaji nejake instrukce... takze na cely vypocet rl a rh by bylo jedno makro a tim zapoudris a vyresis tu nebezpecnou cast...
Zase kolik veci chces napriklad s carry? Scitni, odcitani, rotace a posuny, if, nacteni do promenne a... ?
Jen je skoda ze proste ty makra nejsou STANDARTNI...
Aspon standartni makro pro nacteni do promenne!!!
Zbytek by si optimaloval PREKLADAC co s tou promennou delas....

I kdyz to asi jde i ted pres ruzny podivny kod jako...


..a ted si to prekladaci najdi co jsem chtel delat...

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

Tam som ziadne vysvetlenie, preco sa to malo chovat inak, nenasiel. Takze je to na tebe, ked si to uz odcitoval
Si nevedel ?!?! Predpokladal som, ze ked porovnavas tie instrukcne subory, ze toto vies.
A ked si pozries tu velku tabulku na tom odkaze, tak tam uvidis ze JSR a CALL je to iste a tak isto aj RTS a RET je to iste.
To urcite nie, podmienene CALLy a RETy tam ma osetrene osobitne pomocou podmieneneho obskocenia klasickeho JSR a RTS.

Dalsia pikoska: Pri "rozsirovani" instrukcii z 8080 na x86 ako prve padli za obet tieto podmienene CALLy a RETy. Proste, aj na x86 sa musia emulovat tak ze sa podmienenym skokom obskoci nepodmieneny CALL a RET...

PS: Ked tak pozeram tu obrovsku tabulku ako emulovat instrukcie Z80 na 6502 tak musim skonstatovat ze by na tom este chcelo popracovat. Vela veci nepojde, pretoze 6502 emulacne rutinky castokrat menia flagy inak nez povodne Z80 instrukcie - hlavne tie ktore na Z80 flagy vobec nemenia.

Ono toho až tak moc využitelného není, a tam kde to je potřeba se použije funkce v assembleru nebo inline assembler. Jedna z věcí co se mi na GCC nejvíc líbí je, že má skvělý inline assembler - kdy se dají definovat i vstupně výstupní parametry a tak se dá do kódu vložit třeba jen jediná instrukce a GCC si sám zvolí které registry nejoptimálněji použít a jak předat parametry. Takže např. rotovat registr není v C problém a je to jedna instrukce.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Z80
CALL nn ulozi na SP hodnotu PC+3 (call ma 3 bajty)
Podrobnejsi popis:


6502 (SP je vlastne osmibitove s hi adresou 0x01)
JSR ulozi na adresu SP hodnotu PC+2, tedy navratovou adresu minus 1 (jsr ma 3 bajty)
Podrobnejsi popis:


Z80
RET vlozi do PC hodnotu na zasobniku
Podrobnejsi popis:


6502 (SP je vlastne 8bitove s hi adresou 0x01)
RET vlozi do PC hodnotu na zasobniku a pricte 1
Podrobnejsi popis:


Tohle muzes povazovat za maly rozdil a zaroven na neprekonatelny rozdil kdyz si zacnes trosku vic hrat s RET.
PS: Doufam ze me jen netrolis abych se neco naucil...



To nasobeni by mel ale prekladac odvodit sam z toho kodu ne?
Pokud jsou vstupem 2 osmibitove hodnoty a ty je pretypujes na 16 bitove, abys mel 16 bitovy vysledek, tak by to melo byt docela patrne.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

Měl by, ale takovou optimalizaci nedělá. Má jen funkce kde je vstup stejný jako výstup, a ty použije. Nesetkal jsem se s překladačem který by to uměl, musela na to být jedině napsaná funkce v assembleru. Což je docela škoda, když to procesory často umí. Stejně jako překladače nemají funkce pro bitové rotace, přestože to procesory často umí (i když novější CPU už také ne), mají funkci jen pro bitový posun.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Aha, mas pravdu, tento rozdiel nejak usiel mojej pozornosti. Alebo skor som nan uz zabudol, lebo na 6502 som zatial nepotreboval explicitne pracovat s navratovou adresou.

Taka pikoska - aj tu je 6502 dost nekonzistentna, pretoze napriklad navrat z prerusenia - RTI po obnoveni PC zo zasobnka toto PC neinkrementuje:

RTS vlozi do PC hodnotu na zasobniku a pricte 1

RTI vlozi do PC hodnotu na zasobniku a NEPRICTE 1
Osobne v tom vidim tak trosku absenciu snahy o nejaku optimalizaciu, t.j. ze pre oba returny, resp. samotny proces obnovy PC zo zasobnika mohla byt vyuzita jedna oblast kremika. Alebo na to mozno aj je jedna oblast kremika, ale nasledne rozlisenie, ci 16-bitovo inkrementnut PC alebo nie, musi zaberat dalsiu cast kremika.


PS: Explicitnu pracu s navratovou adresou vyuzivam napriklad v mojom obvyklom programe na vypis textov:
Pouzitie podprogramu v aplikacii:

8080 a potažmo i Z80 má PC (čítač instrukcí) i SP (ukazatel zásobníku) jako běžné (16 bit) registry, přičtení či odečtení jedničky k těmto registrům se řeší tak že se vystaví aktuální adresa do výstupního registru a následně se načte nazpět ale přes 16 bit sčítačku která ale umí jen +1, 0 a -1. Takže na začátku každého strojového cyklu je v PC i SP následující adresa. Stejnou sčítačku používají i instrukce INX a DCX (přičtení a odečtení jedničky od párového registru) a proto tyto instrukce nenastavují žádné příznaky, aneb jdou úplně mimo ALU. Prohození párových registrů HL a DE je řešeno tak že se prohodí výběrově signály pro dané páry registrů … po startu CPU se klopný obvod nastaví náhodně.

RETI u Z80 je kvůli tomu aby se shodila žádost o přerušení u obvodu, co ji vyvolal aneb u obvodů rodiny Z80 je řadič přerušení součástí daného obvodu. Obvod co vyvolal přerušení, poslouchá na sběrnici a čeká, až přijde RETI. Po jeho příchodu shodí požadavek na přerušení. Rozdíl je v tom že RETI má prefix ale RET ne, z pohledu vykonávaní kódu jsou ty instrukce úplně stejné jen RETI trvá déle.

Pikantnost 8080 je v tom že ji během přerušení jde vnutit jakákoli instrukce, aneb soudruzi v INTELu něco trochu nedomysleli. Podle původní dokumentace 8080 je k přerušení určená jen a pouze instrukce RST xx. Rozdíl ve vykonání instrukce RST v kódu nebo přerušení je v drobnostech. Během přerušení se instrukce vyžádá pomocí INTA místo MR a není inkrementován čítač instrukcí aneb sčítačka je nastavena na přičtení nuly. Osmi kanálový řadič přerušení je v tomto případě řešen pomocí obvodů 3214 a 3212. Kdežto 8259 používá onu „chybu“ a vnutí CPU instrukci CALL, kdy 8080 si celou instrukci vyžádá pomocí INTA. Adresa v PC se nezmění, aneb po celou dobu načítání instrukce se k PC přičítala nula. V obou případech se musí zrušit požadavek na přerušení a to se provede pomocí instrukce OUT, aneb se řadiči oznámí, aby zrušil požadavek na přerušení.

Z80 simuluje původní přerušovací módy 8080, ale už neobsahuje danou chybu, aneb jakýkoli přijatý byte si vyloží jako instrukci RST … spíše rovnou jako adresu kam se má skočit. Tudíž 8259 nejde použít s Z80 … vlastně jde … je to trochu divočina ale jde to, více zde. Oba systémy přerušení tj. Z80 a 8259 mají svoje klady a zápory.

Hups … trochu mimo téma …

_________________
Ne všichni jsme měli z češtiny za jedna, aneb jsem dyslektik a dysgrafik.

http://www.sapi.cz/