Na tle poprawy kolokwium DSP, kurs ETEK00043W
E00-49a/b
PON 15-19
K
2
2013-01-19 15:09
1
1 / 2
COŚ DZIWNEGO W INTERPRETACJI KONWERSJI;
Było pytanie, które prowadziło do konwersji na HEX U2, i2q4 liczby -0.09375, która była wynikiem
mnożenia dwóch liczb. Kodowanie miało być wykonane najpierw na 6-ciu bitach krótkiego rejestru, a
potem wynik podany w formie, w jakiej wystąpi w 12-bitowym akumulatorze tego „uproszczonego 6-
cio bitowego procesora”. I tu pojawiły się zadziwiające odpowiedzi w rodzaju „przekroczenie
zakresu…” czy „nie mieści się w reprezentacji…”.
Przyznam, że podważa to wiarę w rozumienie spraw, ale spróbujmy „rozebrać” problem;
1. U2, 12q4 pozwala kodować liczby z zakresu <-2, +1,9375>. Skąd zatem podejrzenie o
„przekroczeniu zakresu” ?. Przecież ta wartość jest z pobliża zera, zatem ze środka
reprezentowanego przedziału wartości liczb. (patrz ilustracja w p.3b.)
2. A teraz bliżej do kodowania. -0,09375 * 2^4 = -1,5 i używając np. kalkulatora konwersja
=na HEX=> 0x3F, czyli 11 111. Jednak, ponieważ wartość wypada dokładnie w środku
pomiędzy bitami akceptowalna jest również odpowiedź 0x3E (albo też zapis odpowiednio
0xFF lub 0xFE)
3. I parę słów bliższego objaśnienia by nie zarzucono skrótów i ogólników
a. LSB dla tego kodowania wynosi 2^-4 = 1/16 = 0,0625
b. Zatem mamy układ „na pionowo ustawionej osi liczbowej”
(bo tak wygodniej zmajstrować tabelkę )
DEC
BIN
HEX
Uwagi
+1,9375 01 1111
0x1F
+MAX
…
…
…
…
+0,0625 00 0001
0x01
+1 LSB
0
00 0000
0
-0,0625 11 1111
0x3F
-1 LSB
<--------
? -0.09375
To wartość w środku
-0,125
11 1110
0x3E
-2 LSB
…
…
…
…
-2
10 0000
0x80
-MAX
c. Nasza kodowana wartość trafia idealnie w środek między bitami, zatem każda uwaga
o „kłopocie z rozdzielczością” jest zasadna
d. Nie są zaś umotywowane uwagi o „niemożliwości reprezentacji”, bo przecież w
rzeczywistości, choćby przetwarzania A/C, do rzadkości należy „trafienie idealnie w
