Welcome, Guest. Please login or register.


Author Topic: CoProcessor (Read 21570 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://lgb.hu/
Re: CoProcessor
« Reply #60 on: 2014.September.23. 17:21:57 »
Koszi, el is felejtettem nagy emulator irasi lelkesedesemben, hogy kereshetnek mas, reszletesebb leirast is :) Meglatjuk, mi sikerul. Azert tenyleg jo lenne egy mukodi "igazi" APU-hoz hasonlitani, ahhoz viszont tenyleg kene egy EP APU-val ... (vagy mas, de APU-val ...). Z80 opcode emulacio egyszerubb, van rakas mas emulator is, van rakas gep, amiben Z80 van, de az Am9511 azert nem feltetlen olyan elterjedt ma mar, hogy lehessen az igazi "vashoz" viszonyitani, illetve pl olyan emulatort/projectet sem talaltam, ahol Am9511-et emulalnak esetleg. Nem baj, igy nagyobb a kihivas :D

Amugy az is eszembe jutott, hogy ha mar van egy gep (EP), ahol buszke lehet az ember, hogy hasonlo gepekhez kepest OS is van (EXOS), akkor bele kene pakolni az APU detektalast is, es pl lekerdezhetove tenni (EXOS valtozo?). Vagy akar egy kis ROM, vagy mas ROM-ba bele (ZT, akarmi), esetleg olyan rutinokkal, amit meg is lehet hivni, es APU jelenlete eseten megcsinaltatja azzal, kulonben meg software-esen emulalja. Bar, lehet, elszaladt velem lo, hiszen nem lehet arra epiteni, hogy mindenkinek lesz ilyenje, mar annak is orulni kell, ha alap EP-je van az embernek igazabol is ...

Offline Povi

  • EP addict
  • *
  • Posts: 1848
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
    • http://povi.fw.hu
Re: CoProcessor
« Reply #61 on: 2014.September.23. 17:33:40 »
Quote from: lgb
Amugy az is eszembe jutott, hogy ha mar van egy gep (EP), ahol buszke lehet az ember, hogy hasonlo gepekhez kepest OS is van (EXOS), akkor bele kene pakolni az APU detektalast is, es pl lekerdezhetove tenni (EXOS valtozo?). Vagy akar egy kis ROM, vagy mas ROM-ba bele (ZT, akarmi), esetleg olyan rutinokkal, amit meg is lehet hivni, es APU jelenlete eseten megcsinaltatja azzal, kulonben meg software-esen emulalja. Bar, lehet, elszaladt velem lo, hiszen nem lehet arra epiteni, hogy mindenkinek lesz ilyenje, mar annak is orulni kell, ha alap EP-je van az embernek igazabol is ...
Erre én is gondoltam már, de egyelőre működjön az igazi "vas", aztán lehet fejleszteni... :-)
Igazából az IS-BASIC-be lehetne még belerakni, és mivel ez interpreter, a meglévő BASIC programok egyből gyorsabban futnának, ha van FPU. A Pascal esetében meg ugye újra kell fordítani a forráskódot, hogy az FPU rutinokat használhassuk.
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://lgb.hu/
Re: CoProcessor
« Reply #62 on: 2014.September.23. 21:51:12 »
http://ep.lgb.hu/jsep/demo.new/

Vigyazat, csak a demo.new-s jo, a sima demo-sban nincs APU kezdemeny se! Na ez a legelemibb, csak a fentebb beszelt Am9511 detektalo rutinra jo stuff, mas cmd-t nem nagyon ismer :) A default disk image-en rajta van a hp13.com is most, minden extra URL param nelkul igy betoltheto. A pascal ki is irja hogy Am9511 detected. Az emulator stop gombbal valo leallitasa utan a "debug ablakban" lehet is nezelodni, az APU: kezdetu sorokra erdemes figyelni nyilvan. Most majd inkabb aztan azokkal a commandokkal szorakozok, amit emlitettel, hogy HP APU-s "verzioja" jelenleg hasznalja.

Offline Povi

  • EP addict
  • *
  • Posts: 1848
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
    • http://povi.fw.hu
Re: CoProcessor
« Reply #63 on: 2014.September.23. 22:24:58 »
ezzel lehet esetleg tesztelni, hogy működik-e:

a fordítás előtt a compiler stack-et és a translate stack-et BF00H-ra kell állítani!!!

("A" parancs -> Alter)
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://lgb.hu/
Re: CoProcessor
« Reply #64 on: 2014.September.24. 14:58:53 »
Van egy erzesem, hogy vmit elrontok en az Am9511 format konvertalasnal. Mivel te foglalkoztal mar vele a pascal kapcsan, megtenned azt a szivesseget, hogy elkuldod azt a 32 bitet, ami pl a kovetkezo ertekek Am9511 float formatumra konvertalas utan adodik? Pelda: legyen mondjuk a PI a formatum altal lehetove tett max pontosaggal,    0.5    16    256    0.25    100.5    (tizedes pontkent ertendo a pont ...).

Ami amugy konkretan gyanus: elvileg a 2-es alapu binaris szamabrazolas pont annak kedvez, ha a ketto hatvanyarol van szo, megis, nekem akkor jonnek ki nem teljesen kerek ertekek (pl a 16 mint szam Am9511-re konvertalasa majd vissza ezt adja: 15.999999046325684. Ez ugye nem meglepo nehany esetben, amde pont a ketto egy hatvanyanal nekem fura (bar belekeveredtem mar abba is, hogy itt a mantissa maskepp van normalva mint pl a "szokasos" IEEE 32 bites float formatumnal es a mantissa MSB-je mindig 1 _kell_ hogy legyen kiveve a nullat, de akkor minden bit nulla az egesz 32 bites alakban amugy is).

Koszi szepen, ha ezzel tudsz segiteni :)

Offline Povi

  • EP addict
  • *
  • Posts: 1848
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 35.0.1916.153 Chrome 35.0.1916.153
    • View Profile
    • http://povi.fw.hu
Re: CoProcessor
« Reply #65 on: 2014.September.24. 15:07:29 »
0.5 = 0x00 0x80 0x00 0x00
16 = 0x05 0x80 0x00 0x00
256 = 0x09 0x80 0x00 0x00
0.25 = 0x7f 0x80 0x00 0x00
100.5 = 0x07 0xc9 0x00 0x00



*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://lgb.hu/
Re: CoProcessor
« Reply #66 on: 2014.September.24. 15:15:05 »
Koszi. Amugy nekem is van ra formulam, leirasom stb, csak vmiert nem akar osszejonni :) Erdekes modon a 100.5 az korrekt, pontosan igy nez ki nalam is, ahogy leirtad. Viszont ha egy szam a ketto hatvanya (lehet negativ hatvanya is, pl 0.5 vagy 0.25) az elegge masra jon ki. Szerintem vmi normalizalasi gond lesz ez itt nekem.

Offline Povi

  • EP addict
  • *
  • Posts: 1848
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 35.0.1916.153 Chrome 35.0.1916.153
    • View Profile
    • http://povi.fw.hu
Re: CoProcessor
« Reply #67 on: 2014.September.24. 15:25:44 »
Most már viszont kiváncsi vagyok, neked mi jött ki pl. 0.5-re és 16-ra :-)
Furcsa, hogy 100.5-re ugyanaz, kettő hatványainál meg tök más.
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://lgb.hu/
Re: CoProcessor
« Reply #68 on: 2014.September.24. 15:39:14 »
Quote from: Povi
Most már viszont kiváncsi vagyok, neked mi jött ki pl. 0.5-re és 16-ra :-)
Furcsa, hogy 100.5-re ugyanaz, kettő hatványainál meg tök más.

Szerintem az en hibam volt. JS numeric -> Am9511 float format konverzios algoritmusom egy remalom, de kb ezt csinalom (a szam elojelet most kiagyom, valojaban az abszoluterteket nezem, es az eredeti szam elojele alapjan a vegen allitom be):

Code: [Select]
exp = Math.ceil(Math.log2(data)); // meghatarozzuk a 2 hatvanyat
data = data / Math.pow(2, exp); // eredti szamot elosztjuk a megfelelo ketto hatvanyaval (exp-ben van, a Math.pow az a hatvanyozas) igy talan kijon az, amibol majd a mantissa lesz
data = (data * 16777216.0) | 0; // a mantissat skalazzuk 24 bitre, a | 0 egyreszt JS optimalizacio (logikai "vagy"), masreszt integer szeru hatast okoz JS-ben, ezt gyakran hasznaljak

Bar van benne nemi JS furcsasag (pl a | 0) szerintem ertheto. Az elejen a data-ban van a szam, ebbol lesz az exp, es a data (ami a mantissa lesz). Itt volt egy problema: a ketto hatvanyainal pont az jott ki, hogy a mantissa erteke nem fert el 24 biten. Ezert, ha a vegen a data nem fer bele a 24 bitbe, akkor shiftelem egyet jobbra (magyaran osztom kettovel) es persze az exp-et novelem egyel. Igy most jonak tunik a ketto hatvanyaira _es_ barmi mas szamra is amivel hirtelen probaltam. Persze az aktualis rutin joval nagyobb ennel, mert ugye az exp felso bitjebe kell elojel, kezelni kell, ha az JS numeric eredmeny nem fer bele az Am9511 abrazolhato tartomanyba, az emlitett negativ szam kerdese, illetve nulla eset meg a fenti rutin elott kezelendo, mert a Math.log2 (2-es alapu logaritmus) nem fog orulni a nullanak :)

Igazabol nem tudom, hogy van-e normalisabb algoritmus erre, amit nekem sikerult itt osszeganyolni teljesen sajat otletek alapjan :)

A problemat az en hulyesegem okozta: tettem bele egy olyan ellenorzest, hogyha a data a vegen (mantissa) nem fer bele a neki kello helybe, akkor 24 bitnyi 1-essel helyettesitettem. Ezaltal allt elo az a vicces szitu, hogy pl a 16-ot Am9511-esitve, majd vissza, a 16-ot alulrol kozelito szamot kaptam es nem pontosan 16-ot :) Ezt az idiota kodreszletet csereltem ki a "shift jobbra a mantissa-ra, exp novelese egyel" megoldassal.

Azert, ha van hozzafuzni valod, hogy ezt hogy lehetne egyszerubben megoldani, ne tartsd vissza kerlek :)

Mas: most hany MHz-en fog menni az APU vegulis? :)
« Last Edit: 2014.September.24. 15:53:09 by lgb »

Offline Povi

  • EP addict
  • *
  • Posts: 1848
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
    • http://povi.fw.hu
Re: CoProcessor
« Reply #69 on: 2014.September.24. 16:27:28 »
Amit vettem, az 3MHz-es, de egyelőre 2MHz-en fog menni, az eredeti kapcsolás szerinti frekiosztó lesz bekötve. Ha működik, majd veszek egy 7490-est, aztán mehet 2.66-tal, vagy megoldom külső órajellel, és akkor 3Mhz. De létezik az IC-nek 4MHz-es változata is, az a maximum.
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 1848
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
    • http://povi.fw.hu
Re: CoProcessor
« Reply #70 on: 2014.September.24. 16:31:41 »
Quote from: lgb
Azert, ha van hozzafuzni valod, hogy ezt hogy lehetne egyszerubben megoldani, ne tartsd vissza kerlek :)


Én biztos úgy oldottam volna meg - bár nem tudom, JavaScript-ben mennyire lehet hozzáférni a natív 64 bites lebegőpontos formátumhoz - hogy azt konvertálnám át bittologatással, végül is ott már meg van a szám kettes alapon.
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://lgb.hu/
Re: CoProcessor
« Reply #71 on: 2014.September.24. 16:37:43 »
Quote from: Povi
Én biztos úgy oldottam volna meg - bár nem tudom, JavaScript-ben mennyire lehet hozzáférni a natív 64 bites lebegőpontos formátumhoz - hogy azt konvertálnám át bittologatással, végül is ott már meg van a szám kettes alapon.

Na igen, de ez a "baj" az JS-el ami az elonye is: platformfuggetlen. Azaz sima szamkent hasznalva nincs gond, de ha a szam belso felepitesehez fersz hozza (normal esetben nem lehet, de pl typedarray-n at igen, igaz akkor csak 32 bites float-hoz, ami ha mas mantissa/exp bit aranyt hasznal akar precizitas csokkenest is okozhatna az eredeti Am9511-hez kepest, vagy nem is olyan tag a szamtartomany es nem menne! Az JS nativ numeric formatuma nem gond, az 64 bites lebegopontos, boven eleg, viszont ahhoz nem tudsz bit szinten hozzaferni), akkor az mar akar hardware fuggo is lehet (big es little endian, de lehetnek akar mas elteresek is). Az ilyen platformfuggetlen cuccokat pont azert talaltak ki, hogy elfedje a gepi reprezentaciot, ami a web szempontjabol elony nyilvan, most viszont hatrany. Oszinten szolva, en is gondolkodtam rajta, hogy par ertekkel az emu teszteli az elejen hogy pl hova kerul a mantissa stb, es az alapjan dolgozik vele, de felek tole, hogy nem ilyen egyszeru es akar mas elteresek is lehetnek, hogy pl nem is ugyanannyi bit jut mantissa/exp-re, mashol tarolja az elojelet stb. Ha ezt mind le akarod kezelni, olyan programod lesz JS-ben, aminel lenyegesen egyszerubb az en matematikai eljarasom. Viszont, most elgondolkodtam, guglizok majd, hogy mennyire std az JS szamabrazolasa, es ha csak a byte order (big/little endian) kulonbozik, az meg siman kezelheto.

Offline Povi

  • EP addict
  • *
  • Posts: 1848
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
    • http://povi.fw.hu
Re: CoProcessor
« Reply #72 on: 2014.September.24. 16:38:49 »
Sőt, ha jól nézem, akkor lenne a legegyszerűbb a konvertálás, ha 32 bites lenne a JavaScript-es ábrázolás. Ott 23 biten van a mantissza, azt egy az egyben át lehetne venni, az Am9511 alsó 23 bitjére, a mantissza MSB-jét 1-re állítjuk, majd a kitevőt növeljük eggyel. (persze még játszani kell egy kicsit, mert vizsgálni kell, vajon belefér-e a kitevő 7 bitbe)
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 1848
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 34.0.1847.116 Chrome 34.0.1847.116
    • View Profile
    • http://povi.fw.hu
Re: CoProcessor
« Reply #73 on: 2014.September.24. 16:43:22 »
Quote from: lgb
Na igen, de ez a "baj" az JS-el ami az elonye is: platformfuggetlen. Azaz sima szamkent hasznalva nincs gond, de ha a szam belso felepitesehez fersz hozza (normal esetben nem lehet, de pl typedarray-n at igen, igaz akkor csak 32 bites float-hoz, ami ha mas mantissa/exp bit aranyt hasznal akar precizitas csokkenest is okozhatna az eredeti Am9511-hez kepest, ulonbozik, az meg siman kezelheto.
Na, akkor talán mégis csak ez a megoldás! :-)

Az IEE754 23 biten ábrázolj a mantisszát, de mégis 24 bites a pontossága, mert úgy veszi, hogy a 24. bit az mindig 1. :-) Vagyis 1.011110110... stb. formában. Az AM9511 pedig csak 23 bit pontosságú, szóval nem veszítenék pontosságot (itt ugye 0.111001000 stb, ahol a 2-1 helyiértéken lévő bit mindig = 1.
*** Speicherplatz zu klein

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 32.0 Firefox 32.0
    • View Profile
    • http://lgb.hu/
Re: CoProcessor
« Reply #74 on: 2014.September.24. 16:44:37 »
Quote from: Povi
Sőt, ha jól nézem, akkor lenne a legegyszerűbb a konvertálás, ha 32 bites lenne a JavaScript-es ábrázolás. Ott 23 biten van a mantissza, azt egy az egyben át lehetne venni, az Am9511 alsó 23 bitjére, a mantissza MSB-jét 1-re állítjuk, majd a kitevőt növeljük eggyel. (persze még játszani kell egy kicsit, mert vizsgálni kell, vajon belefér-e a kitevő 7 bitbe)

JS numeric tipusa 64 bites, de ahhoz nem lehet hozzaferni belsoleg. Ahogy irtam, TypedArray Float32 van, az 32 bites, es hozza is tudsz ferni byte-onkent is. Ezzel az a gond, hogy ez platformfuggo (a szamabrazolas), a standard azt irja, hogy a Float32 az adott hw-n nativ szamabrazolas, eleve a big/little endian biztos jatszik, de sajnos mas elteresek is lehetnek :(

A bit szinten valo machinalassal valo konverzio valoban jobb lenne, es pl a pascal-ban valo alkotasod soran realis is: elvegre adott az Am9511 formatuma, es a pascal altal Ep-n hasznalt szinten formatum. Az en esetemben mar gond van, mert az egyik oldalon az JS van, ami mas-mas hw-n futva akar mas is lehet (az endian kerdes amugy a legnepszerubb problema: pl okostelefonok stb eseten - mondjuk ARM CPU - mas a bytesorrend mint egy x86 CPU-n futo browser eseten). Valojaban az JS TypedArray pont azert van kitalalva, hogy performancia miatt nativ byte szinten is hozzaferj a dolgokhoz, csak innentol ugye a te feleloseged, hogy lehet egy csomo lehetoseg mas-mas platformon.