OldComp.cz
http://www.oldcomp.cz/

Koprocesor a zpracovani floating point aritmetiky
http://www.oldcomp.cz/viewtopic.php?f=133&t=6241
Stránka 34

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.

Přílohy:
Forensics1.png
Forensics1.png [ 18.04 KiB | Zobrazeno 7908 krát ]
Forensics2.png
Forensics2.png [ 18.04 KiB | Zobrazeno 7908 krát ]

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 ? :lol:

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 34 Všechny časy jsou v UTC + 1 hodina [ Letní čas ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/