OldComp.cz

Podle použitého interního formátu. Ale asi bude interně počítat s 10-bajtovými čísly, což vychází na asi 180 čísel pro zásobník a registry.

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

Zamyslel jsem se nad překódováním signálů v patici k MH102 a vyšel mi z toho tento zachumlanec:



Případně by se daly některé signály ušetřit v závislosti kolik portů by se použilo. Když by se použily dva porty - obecný vstup a výstup, nemusel by být potřeba signál W/ a RD/. Vstup by měl na začátku bajt s příznakem FR a potom případně ještě bajty DATA v závislosti na funkci. Výstup by byl čistě pro vyčítání výsledků a počet bajtů a jejich vnitřní organizace by byla spojena s danou operací. To by si už musela hlídat ta knihovna a program. Dva volné signály by se mohly případně použít na něco dalšího (4barevné podsvícení RGB diodami ).

A dal by se použít asi i port jediný, v takovém případě by se signály W/ a RD/ musely použít ale zjednodušilo by to dekodér adres, očuchával by jen jednu adresní kombinaci a třeba by to trošku zrychlilo často se střídající zápisy a čtení .

Je to jen návrh kostry základní komunikace, možná jsem na něco zapoměl nebo napsal nějakou blbost.

To mi připadá hodně uhozené.
Samotný výběr portu nemá význam, u 8080 to může být zrovnatak adresa paměti, nebo I/O prostoru.
Až se součinem s RD, nebo WR, u 8080 ve významu IORD, IOWR to dá tu správnou informaci pro čtení, zápis portu.

Prosím Vás, nepište sem takové ujeté elaboráty a dejte sem funkční komunikaci mezi tím počítadlem a FPU s ATmega

A0 to může ulehčit, ale stejně komunikujete s FPU přes jeden port, A0 je jen příznak, co se přenáší.
Při čtení musí být v bufferu portu už připravená data (nebo status) před čtením portu.

Proto bych se soustředil na komunikaci jen přes jeden port.

_________________
Diagnóza: Touretteův syndrom, Koprolálie, Dyslexie, Obsedantně kompulzivní porucha.
Kalkulačky: Privileg PR56, TI51-III, TI57, TI58, TI59, TI83, TI-83 Premium CE, TI89
Počítadla: BOBO64, ZX48 plus, DG-88, Didaktik-M, C16, C64C, Amiga 500+, MZ800, MUPID C2A2

Osobně bych tu komunikaci viděl tak že bude mít ta MH1020 dva porty, kdy:

A0 = log 0
Bude pro přenos dat, tj. pošle se nejprve funkce (FNx) či pomocná funkce (PFx) a podle toho co to bylo, za funkci se přenesou i případná data na stejném portu. Při zápisu to je v pohodě aneb FPU bude čekat na příkaz tak bude stihat odebírat data ale, jakmile se bude ‚čekat na výsledek tak to bude chtít nějak indikovat a na to tam bude druhý výstupní port aneb teď už správně stavový port/slovo. (něco podobného je například u 8272)

A0 = log 1
Při zápisu (nezáleží na datech) dojde k resetu FPU (obdobně je to např. u DSM-1 s MH1012) aneb nastavení do výchozího stavu.
Při čtení tam bude stav, ve kterém se FPU nachází. Pokut tam bude 00H je vše v pořádku a očekává příkaz. Bit 0 v log1 bude udávat, že je zaneprázdněná a počítá. Bit 7 v log1 by mohl udávat, že příkaz není kompletní, tj. jsou k přenosu ještě data (bez rozdílu kterým směrem) bit 6 by mohl udávat, zda se očekává zápis (druhý byte funkce či operand/y) nebo čtení (výsledek). Bity 1 až 5 budou udávat kód chyby, kdy 0 bude bez chyb, bude k dispozici 31 chybových kódů.

Ano budou potřeba tři budiče/záchytné registry a to dva pro čtení a jeden pro zápis, plus příslušná logika, na straně ATmegy se bude muset naprogramovat něco jako sběrnice aneb má málo vývodu.

Aby šlo zrušit chybový stav ale chovat data v registrech zásobníku tak v pomocných funkcích bude „ horký reset“

Pomocné funkce by modli vypadat:
PF 0 přesun mezi registry obdoba instrukce „MOV“
PF 1 přehození mezi registry obdoba instrukce „XCHG“
PF 2 převod mezi jednoduchou a dvojitou přesností
PF 3 přepnutí na registrový režim, (výchozí nastavení)
PF 4 přepnutí na zásobníkový režim
PF 5 zrušení chybového stavu (horký reset)
PF 6 nahraj více operandů *
PF 7 přečti více registru ***
PF 8 nahraj více funkcí **
PF 9 spusť znovu nahranou sadu funkcí


PF 28 do akumulátoru nahraj konstantu „0“ ****
PF 29 do akumulátoru nahraj konstantu „1“ ****
PF 30 do akumulátoru nahraj konstantu „e“ ****
PF 31 do akumulátoru nahraj konstantu „Pí“ ****

*) druhy byte bude udávat kolik operandu se bude nahrávat kdy byt 7 bude, udávat, zda to bude do zásobníku (log 1) či do registru (log 0), zda jde o operandy v jednoduché či dvojité přesnosti tak to bude určovat bit6 v pomocné funkce, tím pádem půjde nahrát až 128 operandu do zásobníku (do registru to bude jen 16 včetně akumulátoru).

**) druhy byte bude udávat kolik byte se bude přenášet. Následovat pak budou příkazy, tak jak by se posílali normálně jen je FPU nevykoná hned, bude je vykonávat až po obdržení posledního byte. Pokut bude zadána funkce vyžadující přenos např. mezi výsledky tak to bude dávat FPU najevo promoci stavového registru a bitu 6 a 7.

***) druhy byte bude udávat kolik registru se přenese. Tj. např. 5 udá, že se přenese registr 0 (akumulátor) až 5. Zda půjde, o operandy v jednoduché či dvojité přesnosti tak to bude určovat bit6 v pomocné funkce.

****) Akumulátor bude současně registr 0 tak vrchol zásobníku takže pokut nebude zapnut zásobníkový režim tak se obsah akumulátoru přepíše, při zapnutém zásobníkovém režimu se nejprve obsah akumulátoru přenese do zásobníku a následně se do akumulátoru nahraje konstanta. (to samé bude platit o funkcích, co budou zapisovat to akumulátoru).

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

http://www.sapi.cz/

Chci se pochlubit zajímavou metodou převodu integer čísla na text, kterou jsem zprovoznil v ATmega koprocesoru. Nevím zda existuje, zatím jsem se s ní nikde nesetkal. Běžně se používají tyto metody:

1) Klasika - číslo se dělí 10, vynásobí 10 a odečte, ke získání 1 nejnižší číslice. Takový převod u64 na text v ATmega zabere asi 22 tisíc clocků.

2) Optimalizace - dělení 10 se nahradí násobením převrácenou hodnotou 1/10, vynásobí 10 a odečte. Převod u64 na ATmega zabere asi 12 tisíc clocků.

3) Tady to dělám jinak. Integer číslo nejdříve převedu na desetinné vyjádření < 1.0 vynásobením u64 čísla u72 konstantou 1e-20 * 2^136. Pak už jen stačí násobit 10x, což je rychlá operace, a v celé části čísla vylézají číslice. Převod u64 na ATmega zabere 2700 clocků, tedy 8x rychleji než klasická metoda. Druhá výhoda - číslice se generují od začátku a ne odzadu jako je tomu u klasických metod (tj. není potřeba mezibuffer). ... U ATmega koprocesoru s 20 MHz vychází převod u64 na text na 140 us.

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

Vida, na co se při takovém šťourání v počítačové matematice dá narazit . Jsem rád, že práce postupuje kupředu, s tímhle stejně nepomůžu. V mezidobí si alespoň odmáznu resty s tiskárnami, kabely a ROM moduly aby byla připravená půda pro FPU až bude aktuální .

To mi vychadza na 8,7112285931760246646623899502533e+20. Preco prave touto hodnotou ?
A samotne to "vylézají číslice" trva ako dlho ? Za tolko taktov si schopny zistit celociselnu cast floating-point cisla ?

A este mozno jedna podotazka - na kolko platnych cislic je presna mantisa ?

Ano číslo je 871122859317602466467. A proč takové - u64 má max. 20 dekadických číslic. Aby se dalo dekódovat 20 číslic a číslo bylo vždy < 1, musí se nejdříve vynásobit číslem 1e-20. Aby se převedlo na binární vyjádření u64, musí se násobit číslem 2^64. A aby se dostalo do rozsahu celého čísla u72, musí se násobit ještě 2^72. Z toho vychází násobící konstanta 1e-20*2^136. Konstanta se zaokrouhlí nahoru na celá čísla (aby se výsledek zaokrouhloval správě). Konstanta má rozměr u72 (tj. 72 bitů), protože musí mít větší rozsah než u64, aby byla dosažena požadovaná přesnost 20 číslic.

Vynásobení čísla u64 konstantou u72 zabere 470 taktů (23 us). Násobení výsledku číslem 10, aby se dostala 1 číslice, zabere 107 taktů (5 us).

Tohle se ale týká operací s celými čísly, ne floating point. Koprocesor bude mít samostatnou obsluhu pro násobení a dělení celých čísel (tuto část mám už hotovou) a zvlášť operace pro floating point. U floating point bude mantisa interně počítaná na 19 číslic (extended double precision), exportovaná do volitelných formátů.

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

Potom ale celkom nerozumiem co myslis tym ze sa cisla sa prevadzaju na desatinne vyjadrenie mensie ako 1, pricom pracujes len s celymi cislami.

To je desetinné číslo vyjádřené celým číslem. Podobně jako mantisa floating čísla je desetinné číslo < 1 vyjádřené celým číslem (desetinné číslo vynásobené 2^64). Číslo "1.0" by zde bylo vyjádřeno hodnotou 0x10000000000000000, vše co je menší tak je < 1.0.

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

Ahaaa, vdaka, uz tomu rozumiem ! Ty proste rozsah 0..2^64 jednoducho vynasobenim "bulharskou konstantou" namapujes na rozsah 0..0x10000000000000000 a potom uz len nasobis desiatimi. Pokial mas priamo HW podporu nasobenia 64 bitovych cisel, tak to ide raz-dva

Přesněji hw bajtové násobení 10x, ale i to je rychlé, protože to znamená jen 9x instrukce mul s pár součty.

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

Bulharská konstanta je základ

Násobíš to jako (4+1)x2 ?

_________________
Diagnóza: Touretteův syndrom, Koprolálie, Dyslexie, Obsedantně kompulzivní porucha.
Kalkulačky: Privileg PR56, TI51-III, TI57, TI58, TI59, TI83, TI-83 Premium CE, TI89
Počítadla: BOBO64, ZX48 plus, DG-88, Didaktik-M, C16, C64C, Amiga 500+, MZ800, MUPID C2A2

A přitom samotní Bulhaři o její existenci nemají vůbec tušení! Když jsem jednoho konfrontoval s tímto bulharským národním pokladem, chtěl se urazit...

U ATmegy je rychlejší použít hw bajtové násobení instrukcí mul (je na 2 takty).

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