Welcome, Guest. Please login or register.


Author Topic: CoProcessor (Read 76909 times)

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #120 on: 2014.September.29. 16:15:34 »
na, ezt most nekem is értelmezni kell, de most úgy látom, mintha én értettem volna félre valamit, szóval, lehet, hogy rosszul értelmeztem a dolgot, és mégse hibát találtam... :oops:
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #121 on: 2014.September.29. 16:18:13 »
Quote from: Povi
na, ezt most nekem is értelmezni kell, de most úgy látom, mintha én értettem volna félre valamit, szóval, lehet, hogy rosszul értelmeztem a dolgot, és mégse hibát találtam... :oops:

Bocs, kozben editaltam is a hozzaszolasomat :) Nade most mar tenyleg megyek, bar ez erdekesebb mint 2 orat vezetni, ami most jon nekem :D

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #122 on: 2014.September.29. 20:14:09 »
Amugy talan pont te ajanlottad ezt: http://www.joelowens.org/z80/am9511algorithms.pdf

Nezd meg pl a POPS leirasat. the previous TOS rotates to the bottom of the stack. Szoval ez es hasonlok alapjan (bar igy nyiltan nem irtak le) gondoltam, hogy persze nem ugy kell elkepzelni, miszerint pop/push utan mindig tologatjak a memoriat. A papiron rajzolt stacknek van alja es teteje csak szemleltetes, ugy kell elkepzelni (z80-on is!), mint pl egy orat, ahoi a mutato a stack pointer. Mivel a pop kivesz ugyan vmit, de _nem_ ir a memoriaba, a stackban az ott marad, csak mivel a stack pointer tovabbmegy hozza kepest "negativ" iranyban van mar az az adat, tehat az egyszeru pelda alapjan ugy latszik mintha a stack aljara kerult volna. Sokkal jobb szemleltetes, az oras pelda, nincs a stacknek alja, korbeer. Z80-nal is push-olsz egy erteket, ha aztan pop-olod, megkapod, de ha utan meg egy "csomoszor" pop-olod ujra megkapod, hisz a stack pointer ujra odaer egyszer csak, miutan "korbeert" a memorian. Csak ugye senki nem szokott tobb tizezer dolgot pop-olni z80-nal, de az APU 16 byte-os stack "keruleten" ez joval hamarabb feltunik :)

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #123 on: 2014.September.29. 21:10:11 »
Közben rájöttem, mi volt az, amit én nem értettem...

Úgy gondoltam, hogy a dataport olvasásával mindig csak a TOS-t tudom kiolvasni, tehát ha 5 byte-ot olvasok, akkor az 5. ugyanaz lesz, mint amit először olvastam.
Ebből adódott a félreértésem...
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #124 on: 2014.September.29. 21:13:51 »
Viszont úgy néz ki, most tényleg találtam valamit... :oops:

Csináltam egy NAGYON egyszerű tesztet:
http://ep.lgb.hu/jsep/demo.new/?snapshot=http%3A%2F%2Fbeac.uw.hu%2Ftest7.ep128s&autostart=yes

csak egy ENTER-t kell nyomni az indításhoz

a parancsokat decimálisan kell beadni

próbáld ki ezt: 26 (PUPI)
majd 03 (COS)

a TOS-ban -1-nek kéne lennie: 0x81 0x80 0x00 0x00

ehelyett 0x80 0xff 0xff 0xff lesz

megint előjött az a hiba (alulról közelíti a kettő hatványát), amit már egyszer írtál
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #125 on: 2014.September.29. 21:22:16 »
persze lehet, hogy kerekítési hiba, mert 00-ra pontosan 1-et ad (0x01 0x80 0x00 0x00)
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #126 on: 2014.September.29. 21:32:55 »
Sajnos tartok tole, hogy a hiba nem ilyen egyszeru ... A problema az, hogy ha JS console-ba pl beirod: Math.cos(Math.PI)) akkor helyes valaszt kapsz, azonban az JS adattipus 64 bites float, raadasul lehet, vigyazni is probalnak ilyenekre. A PUPI a PI-t ugy nyomja stack-be, hogy a PI-t kozeliti (vegulis minden csak kozeliti ... a lenyeg hogy joval pontatlanabbul). Ha a PI-t lenyomjuk APU-nak, majd kerunk egy COS-t, akkor a PI-tol kisse eltero erteket hasznal, es mivel a cos-t viszont JS float-ra vegrehajtva csinalja, latszik mar a kulonbseg. Szoval igen, ez kerekitesi hiba, es valojaban nem az a nomralizacios problema ami volt egyszer nalam tenyleg. Ki kene deriteni, hogy igazi APU mit csinal ilyenkor. Sajnos lehet, hogy pontos APU emulaciohoz majd emulalni kene ahogy o dolgozik, es nem JS szinten csinalni ezeket, ahol az JS "tulzott pontossaga" mar problema barmilyen vicces is. Mellesleg a PUPI es erdekes tema. Nem tudom ugyanis, hogy egy igazi APU egesz pontosan mit tol le. Ugyanazt, amit en kitalaltam, vagy a mantissa pl kulonbozok a legkisebb helyiertekben mondjuk?

Szoval ezt lehet hibanak hivni, viszont akkor elvi hiba. Az APU pontos mukodeset (COS-t ugy szamolja ki ahogy az APU, ne hivja az JS Math.cos()-t) megvalositani nem lenne egyszeru annyira.

Kicsit mas tema: visszaterve a stack-hez: ami PDF volt, erdekes modon APU neha megsemmisiti a stack melyebb reszen levo dolgokat, gondolom azert, mert pl COS stb kiszamitasahoz kell neki temporary tarolohely. Na ez egyaltalan nincs emulalva, es kulonben sincs info, pontosan mit tesz oda amivel megsemmisiti ... Mivel a specifikacio szerint is kb undefined hogy mi lesz ott, veguils nem szabad szamitani ra, es az elozo ertek megtartasa is belefer az undefined-be :D Erdemes a PDF-en megnezni az egyes APU command-oknal a stack abrakat ... Ahol at van huzva, az jelzi, hogy annak erteke elveszik mert az APU ideiglenes atmeneti szamitasoknal (mikozben kiszamolja a COS-t pl) hasznalja.

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #127 on: 2014.September.29. 21:49:23 »
úgy tűnik, tényleg kerekítési hiba lesz SIN(2pi)-re 0xeb 0xa2 0x21 0x68 az eredmény a 0 helyett
ezzel a parancssorral lehet előcsalni:
10, 23, 16, 26, 18, 02
EXP, PTOF, FADD, PUPI, FMUL, SIN
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #128 on: 2014.September.29. 21:59:37 »
Quote from: Povi
úgy tűnik, tényleg kerekítési hiba lesz SIN(2pi)-re 0xeb 0xa2 0x21 0x68 az eredmény a 0 helyett

Ujra felmerul a kerdes, mit csinal az igazi APU :)

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #129 on: 2014.September.29. 22:07:59 »
A leírás szerint a négyzetgyök kivételével mindent Chebyshev polynomials módszerrel számol ki.
A szinus és koszinusz esetében 6 tagú a sorozat.
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #130 on: 2014.September.29. 22:10:47 »
Quote from: Povi
A leírás szerint a négyzetgyök kivételével mindent Chebyshev polynomials módszerrel számol ki.
A szinus és koszinusz esetében 6 tagú a sorozat.

Ja, csak kinek van kedve ezt lekodolni JS-ben :-D

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #131 on: 2014.September.29. 22:15:34 »
Szerintem nem is kell, ez legyen a legnagyobb gond, hogy nem túl pontos... :mrgreen:
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2290
  • Country: hu
    • http://povi.fw.hu
Re: CoProcessor
« Reply #132 on: 2014.September.30. 18:56:11 »
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #133 on: 2014.September.30. 19:38:42 »
Quote from: Povi
még nem teljes teszt, de érdekes...
http://ep.lgb.hu/jsep/demo.new/?disk=http%3A%2F%2Fbeac.uw.hu%2Ffloppy_a2&mem=128&zt=no&autostart=yes&skiplogo=yes

a test.com fájlt kell indítani

Kiraly, alakul :D Azert en varom mar, hogy igazi APU-n is megnezzuk, az mit csinal :) Mindenesetre ha legalabb kb csinal vmit, es nem syntax error az mar jo eredmeny az emulatoromban igy elsore (na jo nem elsore mert volt mar par kor). Az sqrt kapcsan: igazbol nem derul ki mindig leirasbol, hogy mit csinal az APU hibas adatok eseten. Marmint pl -2 negyzetgyoke. Az ok, hogy hiba a status byte-ban, de mi lesz az eredmennyel? En pl itt azt vettem, hogy megcsinalja mintha pozitiv lenne (2) de beallitja a status-ban a megfelelo bitet. Mert ugye hiba bit eseten az eredmenyt akkor sem szabad "nezni" ui akkor az nem minosul validnak. A leirasban nehany command-nal kiternek arra mi lesz a stackben ha hibas az input, de sajna nem mindenhol ...

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: CoProcessor
« Reply #134 on: 2014.September.30. 20:25:55 »
Kozben gondolkodtam ... Az AM9511 jo, dehat nehez beszerezni, kell neki +12V, egyebek, volt errol mar szo. Biztos, hogy nincs vmi 8 bites kornyezetben egyszeruen hasznalhato FPU? Az um-FPU elso korben kiesik mert SPI, most a kulcsszo, hogy egyszeruen bekotheto, mint a "jo oreg APU (9511)". Azt olvasni, hogy az Intel is licencelte es talan 8231 vagy hasonlo neven arulta. Az ha teljesen kompatibilis, szinten jo lenne, foleg, ha pl egyszerubb beszerezni, mint AMD-s tarsat. Pl viszont van 8232 is az inteltol, elonyei hogy 64 bites precizitas, meg IEEE 754 szerinti. Hatranya, hogy kb alapmuveletek vannak, tehat ilyen cos/sin stb az nincs. Adatlap szerint sajna ennek is kell +12V, pedig rulZ lenne, ha nem kene.

Igazabol nem tudom, van-e mas ertelmes lehetoseg ... A 8087 stb elvetve, tulsagosan x86 centrikus. Habar erdemes lehetne jobban megnezni, hatha megy vhogy. Ha jol remlik, vmi prefix byte alapjan ismeri fel, hogy neki szol vmi, tehat ugye nem az x86-os CPU kozi vele egy porton, ahogy pl az EP/APU eseten. Nem tudom ezt mennyire lenne bonyolult athidalni esetleg, maskepp kezelve, es eszszeru komplexitas aran megoldhato-e ...