OldComp.cz

Násobička je užitečná, může ušetřit čas CPU, které násobit neumí.
CRC jsem použil u zařízení, které to mělo umět samo a CPU tam nebylo, řadič kazetopáskové paměti KPP800 pro ADT4500 tak, aby se choval stejně jako řadič pro 1/2" magnetopáskovou paměť.
Ušetřilo mi to asi 4 obvody, než kdybych to dělal diskrétně a musel jsem asi 3 obvody přidat, protože jsem to musel jinak obsluhovat

_________________
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

Sice jsem to napsal jinam ale sem se to tematicky hodí líp. Běhá mi už PP i s osazenou násobičkou tak jsem zkusil dobrat se z pohledu BFU nějakého měřitelného rozdílu mezi CPU a MH102 na jednoduchém příkladu. Protože čas počítání jednoho čísla se nedá snadno měřit, vytvořil jsem dvě dlouhé smyčky (cca 128 - 250 opakování) v Basicu a opakovaně počítal to samé násobení na CPU a násobičce, která běhala jen v jednobajtovém výsledku (do hodnoty 255) což je z Basicu velmi snadno dostupné - jen se pošle číslo na 2 vstupní porty a přečte výsledek na prvním portu výstupním. A výsledek se dostavil - i v Basicu je násobička na malá čísla (1-15) o 20% rychlejší než CPU. CPU smyčku dokončilo za 2.61 sekundy, s násobičkou trvala 2.11 sekundy.

Samozřejmě neřešil jsem negativní násobení apod. kdy se musí vstupy ošetřit, čistě jen číslo kladné krát číslo kladné. A měření probíhalo ručně se stopkami byť opakovaně abych zmenšil jeho chybu, tak bych to moc nebral jako kdovíjak přesné ale ten časový rozdíl tam pravidelně byl ve prospěch násobičky.

Pokud by někdo měl chuť prográmek rozšířit i pro větší hodnoty kdy se pro výsledek používají 2 bajty z dvou výstupních portů, bude myslím zajímavé porovnat i výsledky z opačného konce škály zda nedojde k dalšímu posunu ve prospěch násobičky nebo to naopak nezabije Basic svou "rychlostí." Můj osobní odhad je ten, že v Basicu řešit všechny výjimky a skládat výsledek do 16bitového čísla je tak komplikované, že bude urychlení veškeré žádné, možná i zpomalení... . Samozřejmě jako BFU neřeším to samé ale ve strojáku a bez Basicu, tam to asi bude poněkud lepší.

Myslim ze v basicu nema najmensi vyznam merat urychlenie programu nasobickou, a to ani pre to najprimitivnejsie nasobenie do 255*255, pretoze pokym basic dostane cisla do nasobicky a prevezme vysledok (a vysklada ho z dvoch bajtov na jedno slovo), tak by to mal "rucne" v ramci svojich rutiniek vynasobene este skor.

Ina vec by bola, keby priamo aritmeticke rutinky v basicu, pouzivane aj pre klasicke nasobenie v ramci vyrazu, podporovali nasobicku. Vtedy by bolo zaujimave porovnanie, ako rychlo sa vykonava ten isty basicovy program, ked interpreter pouziva a) CPU b) nasobicku.

No a v samotnom asembleri je to uplne jasne - slucka na bitove nasobenie dvoch osembitovych cisel trva dost dlho, tu naOUTovanie operandov do nasobicky a vyINovanie vysledku zaberie mnohonasobne mensi cas. Situacia sa trosku obrati, ked CPU na nasobenie pouzije rozne triky (napr. tabulky), vtedy su tie casy nasobenia pomocou CPU a nasobicky uz celkom porovnatelne.

skládat dvoubajtový výsledek v basicu je úplně jednoduché

VYSL=VY1+256*VY2, ale zabíjíš tím násobením 256 ten výpočet v násobičce...

A to asi je důvod proč to v tom Basicu nakonec nebylo - je tak pomalý a tahle násobička zároveň moc komplikovaná na ovládání, že se to u školních počítačů vůbec nevyplatí. Zejména když i bez násobičky (tehdy výrazně levněji) to CPU dovede dosáhnout v menším rozsahu podobného výsledku i na větších číslech, když se to umí.

I když takové paralelní počítání násobička + CPU by patrně mohlo urychlit "typově nezlobící" výpočty dost významně - CPU by ji krmil, připravoval data a ve volných chvílích obsluhoval periferie a násobička by počítala a počítala... Ale opět, úlohy co by ji opravdu vytížily se nejspíš neřešily na školních strojích.

Mě napadlo to číslo získat vyčtením bitů z obou portů a jejich tvrdým napsáním do 16bitové pozice přes PEEK/APOKE do paměti, nic bych nepřepočítával - je to rovnou hotové číslo.

no třeba IQ151 má na toto příkazy DPEEK (přečte 16 bit hodnotu), nebo PTR(proměnná) - dá adresu proměnné, ale teď jde ještě o formát čísel, jejich uložení v paměti které bude u PP01 určitě jiné než u všech dalších počítačů (proč by mělo být něco kompatibilního že...)

takže dodělávat podporu násobičky do Basicu určitě nemá velký smysl, spíš si napsat výpočtové rutiny ve strojáku a jen předat vstupy/výstupy

Presne tak. Pokial vobec robis 256*VY2 alebo viacprikazovu manipulaciu typu POKE a,IN x : POKE a+1,IN x+1 : LET vysledok=DPEEK a (s predchadzajucimi viacerymi OUTami na zapis operandov) tak to uz fakt je v tom basicu rychlejsie priamo pomocou CPU vypocitat nejake A*B.
No pozor, toto plati len v pripade, ak interpreter basicu o nasobicke vobec nevie a obsluhuje ju priamo basicovy program. Ale pokial by nasobicku vyuzivali priamo aritmeticke rutiny v tom interpretri, tak by to mohlo vyrazne urychlit vsetky vypocty zalozene na nasobeni (teda aj vsetky vedecke funkcie SIN,COS,TAN,EXP,LN...).
Aky volny cas ?!?!
Ta nasobicka pracuje v podstate "nekonecnou" rychlostou - CPU do nej naOUTuje data, a okamzite si moze INovat vysledok. Na ziadne valanie si suniek tu priestor nie je
Prave naopak, podpora nasobicky priamo v aritmetickych rutinach interpretra MA velky zmysel !
Co prave zmysel vobec nema, vymyslat si vlastne vypoctove rutinky v strojaku a zdrzovat sa predavanim parametrov medzi basicom a strojakom, ktore to cele (obvykle) spomali este viac, nez normalne klasicke nasobenie priamo v basicu LET C=A*B.

a jak teda pomůže celočíslená násobička při výpočtu SIN 45° nebo COS (PI/3) ?

Při softwarovém výpočtu float čísel se používají integer operace (klidně i na úrovni bajtu), tak hardwarová integer násobička může znatelně urychlit výpočet sin, cos, i když je jen 8-bitová. V řadách se intenzivně používá násobení mantisy.

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

Presne ako napisal Panda38, pri nasobeni float cisel sa nasobia mantisy, a toto nasobenie moze HW nasobicka mnohonasobne urychlit. Dalej, spominane vedecke funkcie sa pocitaju pomocou polynomickeho rozvoja (vid napr. cebysevove polynomy) a vypocet hodnoty takeho polynomu, tam sa to float nasobeniami len tak hemzi

To zní skoro jako závazek k socialistickému úkolu spáchat takovou rutinku . Emulátor násobičku obsahuje, stejně tak i dostatek externí RAM zavěšené na I41 tak by asi nebyl problém s velikostí a testování v něm je jistě pohodlnější než na živém železu... Upravovat Basic aby výpočty házel na násobičku by asi byla velice náročná věc když se ani neví z čeho vzniknul, natož aby k němu byly zdrojáky.

U řady se dá použít i ve funkci hw děličky, převedením dělení konstantou na rychlejší násobení převrácenou hodnotou.

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

To se divím že to vzhledem k zaměření toho počítače neosazovali běžně a ten Basic nenapsali rovnou aby ji používal, vždyť by takhle ty výpočty urychlili o pořádný kus... A to samé i u IQ-151(to se vyrábělo až do roku 1990, skoro se tomu vzhledem k parametrům nechce věřit), velké přípravy a ve finále taky nic.

Dal jsem si tu "práci" a ověřil, kolik že té rychlosti získáme implementací násobičky do systému s i8080 (konkrétně PMD-85 verze 2A). Mějme program


V praxi připadá, zejména v akademickém BASICu, jeden podobný výpočet typu SIN na mnohem delší kus kódu, tedy vliv urychlení výpočtu bude mnohem méně významný, na druhou stranu by to šlo zapsat do jednoho řádku a něco režie ušetřit, ale pro řádový odhad tento příklad stačí.

Ta smyčka se vykoná za 28664 taktů (cca 17ms), z toho výpočet SIN trvá 12384 taktů (cca 7ms). I kdyby násobička provedla výpočet v nulovém čase (jakože zdaleka ne!), poběží smyčka 1,75x rychleji. Ano, ten koeficient je 1,75. A to je asi praktická odpověď. Cena versus výkon, který nikdo neocení.

Tím nijak nesnižuji význam násobičky. Mohou existovat úlohy, kde se naplno uplatní a zaplatí. Ale ne v BASICu.

Já bych věděl, kde by vytáhla drápky - ovladače plotrů a jejich grafika. Tam se to doslova hemží siny a cosiny kde to musí být opravdu přesně a ne jen herní šalba a klam . Výpočty Bézierových křivek, to je samá mocnina na x tou, sin a cos.

Je jasné že čím víc matematiky, tím víc rychlosti navíc. To samé platilo pro všechna FPU že integer úloha s textem jim moc vyniknout nedala. A násobička zdaleka není FPU... Přesto urychlení vědeckých výpočtů řekněme o polovinu ať má taky nějakou režii v režimu 1:1 není zlé. Ovšem vzato v úvahu že takových časově náročných kroků může být také mnoho za sebou (většinou se s tou hodnotou dále pracuje) může koeficient nastavit úplně jinak. Zkus spočítat takových sinů 360 za sebou abys měl jemnou sinusoidu, jaká úspora času tam vznikne, nebo s tím dělej další operace jako u složitější rovnice . To je zase druhý extrém kdy se bude násobička používat skoro pořád. Tam to asi jen 1.75x nebude. Realita se bude pohybovat mezi nulou a tou maximální hodnotou urychlení v závislosti na úloze, zobecnění na jednom příkladu je ošidné.