OldComp.cz http://www.oldcomp.cz/ |
|
Koprocesor a zpracovani floating point aritmetiky http://www.oldcomp.cz/viewtopic.php?f=133&t=6241 |
Stránka 3 z 4 |
Autor: | suksoft [ 31.05.2018, 11:09 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
microlan píše: ALU to stihne spočítat v době mezi zadáním a čtením výsledku, nebo se na to čeká? Co vim tak ta ALU je hodne rychla, nejpomalejsi vec je do ni dat data a pak zpet vybrat. Kdyz jsem na tom ale premyslel tak kdyz bude v unikarte emulovany nejaky koprocesor tak by slo vyuzivat ze bezne programy nevyuzivaji urcite instrukce. Umim si predstavit program: ED 70 IN --,(C) (viz http://www.z80.info/z80undoc.htm) ld de,1013 ; predavani ruznych nastaveni konstant nebo prikazu pro koprocesor ld de,1415 ld de,6677 in a,(port_unicarty) ; vraci zpet vypoctenou hodnotu Ted by mohl takto smerem do unikarty a do koprocesoru rychle davat konstanty a prikazy co ma s tim koprocesor delat a vlastni cteni zpet by bylo jiz pres IN. Samozrejme hodnota v registru by plnila se pres OUT. |
Autor: | hynek [ 31.05.2018, 12:29 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
U tohoto postupu bude potreba zajistit, aby to nerozbil prichod preruseni. |
Autor: | microlan [ 31.05.2018, 12:38 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
ld de, xxxx se používá docela často, ne? //Aha, když by to nebylo pro coprocesor, tak by se to sice spočítalo, jen by to nikdo nečet? |
Autor: | suksoft [ 31.05.2018, 12:48 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
hynek píše: U tohoto postupu bude potreba zajistit, aby to nerozbil prichod preruseni. Prichod preruseni obecne nevadi. Basic dosti casto vypne preruseni a dokonce si primapuje romku a spusti rutinku uvnitr romky, sice to neni prilis caste ale je to mozne. Takze kdyz rutinka pojede po DI, tak vse bude uplne bezproblemove. Kdyz se dobre naprogramuje unikarta, tak ani nebude vadit odskok na preruseni a navrat zpet pri EI. Unikarta jen bude muset kontrolovat zda PC se spravne inkrementuje a jak uvidi jinou ip adresu tak si musi zapamatovat ktera mela prijit a az v budoucnosti uvidi stejnou ip adresu tak pokracovat v cinnosti. Samozrejme toto ma omezeni ze nejde v preruseni pouzit stejnou rutinku ale to se neocekava. Mikes na TM presne ukazal kde jsou slabiny prenosu dat. Skoda ze asi nenapise nejaky clanek o tom co tam rikal. |
Autor: | suksoft [ 31.05.2018, 12:55 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
microlan píše: ld de, xxxx se používá docela často, ne? //Aha, když by to nebylo pro coprocesor, tak by se to sice spočítalo, jen by to nikdo nečet? Ta ld de,xxxx je "prochazejici" instrukce pro Z80 - jeji vyhoda je ze pres ni prejde (relativne rychle) a koprocesor soucasne vidi data. Prvni bajt sice zahodi ale nasledujici dva jsou jiz realne parametry co muze koprocesor vyuzit (prvni by sel asi take vyuzit min ld bc,xxxx ld de,xxxx ld hl,xxxx - tri kombinace). Podle mne neexistuje rychlejsi predani informaci do koprocesoru. Uznavam ze cist taktovyto program po prelozeni bude hrozne, protoze soucasti programu jsou i data a je to nelogicke ale kdyz budeme cist zdrojove kody, tak tam bude napsane co jaky parametr dela. |
Autor: | Mikes21 [ 31.05.2018, 14:54 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
Zajimave uvahy, zatim je to asi takhle: ALU pri zadani prikazu nahodi bit ze je BUSY a po dokonceni ho vrati na nulu. Rutina, ktera vycita data tak musi pockat, az ALU neni BUSY. Z toho pohledu je ALU pekna periferie, protoze se dobre emuluje a neni potreba blokovat wait nebo tak neco. To je, co se tyka vycitani vysledku z ALU. Ted se to pouziva asi takhle: Kód: CMDFP: out (ALU_CMD), a CMD_W: in a, (ALU_CMD) rl a jr nz, CMD_W ret ; PUSHFP: push hl ld b, 5 PUSH1: ld a, (hl) out (ALU_DATA), a inc hl djnz PUSH1 pop hl ret ; POPFP: push hl ld b, 5 POP1: in a, (ALU_DATA) ld (hl), a inc hl djnz POP1 pop hl ret Tri rutiny, jedna ulozi data na TOS, druha spusti operaci a treti vyzvedne vysledek. Takhle to volam: Kód: START: push bc ld hl, FP_PI call PUSHFP ld a, SQRT call CMDFP ld hl, DATA call POPFP pop bc jp 0e804h ; go monitor ; FP_PI: db 82h, 49h, 0fh, 0dah, 0a2h DATA: ds 5 To je vsechno. |
Autor: | Mikes21 [ 31.05.2018, 20:08 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
Respektive: Kód: PUSHFP: push hl ld bc, 5*256+ALU_DATA otir pop hl ret ; POPFP: push hl ld bc, 5*256+ALU_DATA inir pop hl ret coz by mohlo byt naprosto dostacujici a reseno standartne. Navic by jsi potreboval odnekud nacitat obsah registru. Takhle to je primo z/do pameti. |
Autor: | Mikes21 [ 02.06.2018, 19:53 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
Filozoficka otazka: Tak jsem stravil prijemny vecer ladenim ALU, ktera pracuje podobne jako hw koprocesory. Pritom vse pocita ve formatu cisla, ktery pouziva BASIC. Pripominam, ze pro Sharp je to asi jediny pouzivany format pro FP. Postupne patchuju BASIC, aby pro jednotlive funkce pouzival prave tuto emulovanou ALU. A ted k te otazce. Originalni hw ALU ma nekolik registru, tzv. STACK, kde uklada data a vraci zde vysledky mat. operaci. Potud, ok. Ale, kdyz dochazi k vypoctu nekterych slozitejsich funkci a algoritmus potrebuje nejaky mezivypocet, tak si 'pujci' registr na konci STACKu. Takovym zpusobem zustane tento registr v nedefinovanem stavu. Proc to tak je, je jasne. Otazkou je, jak to implementovat v 'novem' ALU. Udelat to tak, ze k tomu 'zapleveleni' nedojde nebo tam nahrat treba same nuly (nebo jinou hodnotu). Skratka co s tim? |
Autor: | suksoft [ 03.06.2018, 11:29 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
Jestli to Basicu nevadi tak at si klidne pujci (poskod) nejaky registr. Zkus to udelat dosti univerzalni at se treba v budoucnu muze udelat Basic co bude pouzivat realna cisla z Turbo Pascalu (6bajtove cislo). |
Autor: | Mikes21 [ 03.06.2018, 13:02 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
To, ze se cast TOSu 'pujci/poskodi' neni vlastnost BASICu. Ten o tom nic nevi. Tak to funguje v realnem ALU cipu. Pri jeho emulaci k tomuto side-efektu nedochazi. Co myslis, tim 'dost univerzalni'? Emulace ALU funguje na principu predavani cisel v BASIC formatu a ten je 5 bytu. Pokud by se mel pridat jiny format, tak bych to videl na jiny port, ktery by predaval cisla treba v 6-ti bytovem formatu, tak jak to ma TP. Ale treba sinus je porad sinus, to je dost univerzalni funkce Jinak cisla se v unikarte zpracovavaji v double rozsahu, coz je sice pro unikartu zaber, ale presnosti je tak az nad pomery. |
Autor: | Mikes21 [ 14.06.2018, 12:42 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
Tak se mi konecne podarilo uspesne dodelat emulovanou ALU, ktera pocita v Sharp formatu 40bitu pro realna cisla. Zaroven unikarta emuluje nektere matematicke operace. Konkretne: Kód: Sharp ALU - floating point 40bits ================ Code Instr. Cont. Description 00 NOP ABCD No Operation 01 SADD RCDU Add A and B 02 SSUB RCDU Substract A from B 03 SMUL RCDU Multiply A by B 04 SDIV RCDU Divide B by A. If exponenet = 0 then R = B 05 CHSS RBCD Sign Change of A 06 PTOS AABC Stack Push 07 POPS BCDA Stack Pop 08 XCHS BACD Exchange A and B 10 SQRT RBCU Square Root of A 12 SIN RBUU Sine of A (radians) 13 COS RBUU Cosine of A (radians) 14 TAN RBUU Tangent of A (radians) 15 ASIN RUUU Inverse Sine of A 16 ACOS RUUU Inverse Cosine of A 17 ATAN RBUU Inverse Tangent of A 18 LOG RBUU Common Logarithm (base 10) of A 19 LN RBUU Natural Logarithm of A 1A EXP RBUU eA Function 1B PWR RBUU B^A Power Function 2A PUPI RCUU Push PI onto Stack 7F INFO RABC Push ALU3 signature onto stack (only emulated) Zaroven jsem upravil BASIC (MZ-1Z016) tak, aby pres ALU pocital tyto funkce: Kód: SQR EXP LOG LN SIN (COS) TAN ATN x ^ y x * y x / y x + y (x - y) Rychlost je docela velke prekvapeni, protoze ARM v unikarte stihne vetsinu operaci jeste pred tim nez Sharp zacne vycitat vysledky. Plati to pro rutiny psane v assembleru. Jen nekdy potrebuje pockat par taktu nez shodi BUSY. Tim, ze to pocita operace typu "+-*/^", tak je to docela znat. I kdyz i tak je rezie BASIC interpretru docela velka. Byl by nekdo ochotny napsat par testovacich programku a porovnat rychlost v puvodnim BASICu a tom, ktery pouziva ALU? jen upozornuji, ze je k tomu potreba mit unikartu a v ni posledni verzi fw. Sw muzu klidne poskytnout. |
Autor: | Mikes21 [ 22.06.2018, 10:52 ] | |||
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky | |||
Pri cteni prispevku: danhard píše: Je to k tomu, že se podle toho testu se pozná, jestli je tam stejný algoritmus výpočtu. A když chci ukázat ty chyby, tak tam jsou Vůbec nejde o to, co je přesnější, ale o to, že je to stejné. Každá kalkulačka dává jiné výsledky: TI-51-III = 9.0077265 TI-57 = 9.0047464 TI-58 = 9.000004661 TI-59 = 9.000004661 TI-83 Plus = 8.99999997 TI-83 CE = 8.99999997 TI-89 = 9. TI-30X = 9.000002295 Víc jich od TI nemám, ale pěkně je to popsané zde http://www.datamath.org/Forensics.htm Diky za nej Tak jsem ho taky vyzkousel na Sharp BASICu. Na fotce 'Forensics1.png' je vysledek. Pri te prilezitosti jsem zjistil, ze v manualu https://www.scav.cz/sharp_mz-800/vse_o_MZ-800/vse_o_MZ-800-2_Basic_MZ-700.htm je chyba. Protoze BASIC nema funkce pro arcsin a arccos (a dalsi). Proto se musi pocitat jinak a funkce pro vypocet arccos uvedena jako Kód: Arcuscosinus ARCCOS(X)=ATN(X/SQR(-X*X+1))*PI/2 pritom spravne ma byt: Kód: ACos(X) = Atn(-X / Sqr(-X * X + 1)) + 2 * Atn(1) Napada me filozoficka otazka, kolik lidi o tom v te dobe vedelo a kdo na to mohl tehdy a nyni prijit? Na druhe fotce 'Forensics2.png' je vysledek upraveneho BASICu, ktery to pocita pres ALU. Ta je emulovana pres emulator nebo taky pres unikartu. Rozdil by mel byt zpusobeny prevodem na double a zpet v emulatoru. Jinak pekne cviceni ze stredoskolske matematiky.
|
Autor: | hynek [ 22.06.2018, 11:44 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
Mikes21 píše: Pri te prilezitosti jsem zjistil, ze v manualu https://www.scav.cz/sharp_mz-800/vse_o_MZ-800/vse_o_MZ-800-2_Basic_MZ-700.htm je chyba. Protoze BASIC nema funkce pro arcsin a arccos (a dalsi). Proto se musi pocitat jinak a funkce pro vypocet arccos uvedena jako Kód: Arcuscosinus ARCCOS(X)=ATN(X/SQR(-X*X+1))*PI/2 pritom spravne ma byt: Kód: ACos(X) = Atn(-X / Sqr(-X * X + 1)) + 2 * Atn(1) Takze kdyz upravim puvodni vzorecek, zmenim jen * na + a mel bych dostat spravny vysledek: Kód: Arcuscosinus ARCCOS(X)=ATN(X/SQR(-X*X+1))+PI/2 Pouzivat 2*ATN(1) misto konstanty PI/2 mi prijde ponekud neprehledne a mimo jine jako mrhani strojovym casem |
Autor: | danhard [ 22.06.2018, 11:59 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
hynek píše: Pouzivat 2*ATN(1) misto konstanty PI/2 mi prijde ponekud neprehledne a mimo jine jako mrhani strojovym casem To je dobré do strojů, které nemají PI jako konstantu explicitně dostupnou, ale mají geom. funkce. Ale na 10 míst si PI snad každej pamatuje, ne ? |
Autor: | Panda38 [ 22.06.2018, 12:21 ] |
Předmět příspěvku: | Re: Koprocesor a zpracovani floating point aritmetiky |
hynek píše: Takze kdyz upravim puvodni vzorecek, zmenim jen * na + a mel bych dostat spravny vysledek: Kód: Arcuscosinus ARCCOS(X)=ATN(X/SQR(-X*X+1))+PI/2 Ještě jsi zapomněl na mínus: Kód: Arcuscosinus ARCCOS(X)=PI/2-ATN(X/SQR(1-X*X))
|
Stránka 3 z 4 | Všechny časy jsou v UTC + 1 hodina [ Letní čas ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |