Svenska ElektronikForumet

Är det att den har hårdvaruinstruktioner för flyttal eller något annat "genialiskt" ?

Varierar väldigt mycket, men generellt är väl att det finns hårdvarustöd för diverse komplexa funktioner.

Så programmerar man med C-kod så ser man ingen skillnad?

Antar att det är lite lättare att hantera flyttal i assembler på en DSP iaf. Iom att man slipper implementera funktionerna via mjukvara själv.

En DSP brukar ha stöd för att effeiktivt kunna göra digitala filter. T.ex. är det vanligt med en mycket snabb instruktion för Multiply-and-Accumulate (MAC) på typ en klock-cykel eftersom den används flitigt olika sorters filter.
Sen är det vanligt med skilda bussar för instruktioner och för data för att öka prestanda i DSP. Nu finns ju många CPU med detta också...

I C-kod med rätt bibliotek, och om man använder rätt APIer/Funktioner så märks det (förhoppningsvis) inte.

Alla misstankar bekräftade då

Den är väldigt bra på digital signalbehandling. Det är därför den ofta används i filtersammahang. Studerar man opkoden/asseblerinstruktionerna så ser man att det finns stöd för såväl flyttal som stöd för fixpoint.

Om man vill att signalbehandlingen skall gå riktigt fort så duger det inte med C. Man måste optimera för hand och det brukar de stora pojkarna göra som önskar fullspeed.

Den där dspPIC verkar vara en kul liten tingest som jag aldrig har provat. Har håll mig till AD:s dsp:er hittills men när min fräs är klar skall jag hoppa på ett nytt projekt där det ingår en stor servomotor som jag tänkte försöka åstadkomma en egen drivare till och då tror jag att dspPIC skulle kunna funka bra. Mitt problem är att jag behöver skaffa litteratur som beskriver teori och funktion hos servomotorer först ty där har jag i stort sett ingen erfarenhet alls. Men den dagen den sorgen eller snarare glädjen.

Ett område som dsp:er brukar vara bra på är transformer som fft, dft med flera eftersom den är bra på flyttalsberäknigar och andra komponenter som ingår i transformer.

Det handlar väl om "profilering", d.v.s. vad den är optimerad för. Det är lite som att säga "vad skiljer mellan en speldator och en videoredigeringsdator?".

Jag har inte pysslat så mycket med "riktiga" DSP:er, men gjorde mitt exjobb (för 20 år sen) på en TMS 320-C80 som väl kan ses som lite representativ.

Den hade fem processorer inom en och samma kapsel, en Master Processor (RISC) och fyra stycken Parallel Processors (RISC).

Dessa PP:er hade en hel del "intressanta" instruktioner. De jobbade med 32-bitars register men det fanns funktioner för att hantera dessa som fyra stycken bytes, så en PP kunde alltså i princip göra fyra stycken 8-bitars additioner parallellt.

De hade också dubbla ALU:er, en enklare som användes för adressberäkningar och en "huvud-ALU". Varje PP hade eget minne (8 KB) och så fanns det även gemensamt minne (50 KB). Extern minnesaccess gjordes med särskilda instruktioner av en särskild controller och hade en viss latens.

Massa olika register, både dataregister och adressregister (både globala och lokala).

Hittade datablad, den hade visst en videocontroller också (men den använde jag aldrig, jag skrev ett filter).



Jag har sparat ett rätt intressant kodexempel (som man knappast hade fått med en kompilator, men ändå:) ) där man räknar ut kvadratiskt medelvärde på en klockcykel per invärde (i alla fall om det är mer än 4 invärden, eftersom det tar fyra instruktioner per varv i loopen:) ).

Förklarar varje instruktion för sig. (De där || betyder alltså att det är något som görs parallellt med det som står innan)
Först har vi en "splittad" subtraktion. Registren är 32-bitars men är delade så att det bara är bytevis subtraktion. m:et står för multiple och c står för att vi vill att multiple flags (mf-registrets) lägsta fyra bitar skall sättas som carry-flaggorna.

Sen har vi en unsigned halfword (uh) extract av det lägre (0) halfwordet.

Och slutligen en "fuskis". d5 används som ett dummyregister. Vi vill bara räkna upp adressregsitret med indexregistrer. Detta sköts av en av adressenheteerna, och behöver alltså inte ALUn. d5 får visserligen också värdet av a0, men det används alltså inte.
m:et står även här för multiple, d.v.s. att varje byte hanteras för sig.
@mf betyder Expanded Multiple Flags. De fyra lägsta bitarna i mf sattes till carry. Expansionen innebär att var och en av de bitarna fyller upp en byte.
Alltså, binärt: 0000000000000000000000000000abcd blir aaaaaaaabbbbbbbbccccccccdddddddd
Resultatet blir att absolutbeloppet för varje byte i d7 hamnar som bytes i d4.

Sen har vi en till halfword extract, den här gången det övre halfwordet (uh1=unsigned halfword 1).

Slutligen laddas d6 från adressen som a1 pekar på, och a1 räknas upp (det funkar precis som i C).
En unsigned split (m=multiple) multiply. Bytesen i d4 kvadreras alltså och blir i samma veva halfwords. Det är alltså bara de två lägsta bytesen som kvadreras.

ealu (extended ALU) är en lite speciall sak. Operationen anges i d0-registret (den är satt tidigare), och opkoden innehåller alltså bara information om att det är en ealu-operation och vilka register som skall användas. Den används för relativt komplexa operationer, men det går alltså inte att skriva vad som helst inom parantesen, det måste vara nån av de operationer som stöds. MEN man kan välja vilka register man vill.
>>u16 betyder 16 steg unsigned shift right (precis som i C). d3 är laddad med noll! Orsaken förklaras nedan, men resultatet blir i alla fall en halfword extract (övre halvordet från d4 hamnar i d7).

En "vanlig" halfword extract (0 = lower) och en adressaritmetisk beräkning (öka a0 med x0).
En kvadrering till, precis som ovan.

Och ännu en ealu. Nu är grejen att den här ealun har SAMMA operationskod som den förra (det syns på formeln inom parantesen). Vi använder alltså samma d0, men har andra register (de stod ju i opkoden). Det var alltså anledningen till att vi hade d3 som nollregister tidigare. Här används den inte som halfword extract, utan den summerar kvadrerade värden (de blev ju halfwords när de kvadrerades).

Sen har vi en adressaritmetisk pryl igen, och en load från minnet. Nu råkar bägge två ha samma destination, vilket ser lite konstigt ut. Som tur är (jo,
det visste de som skrev det här:) ) så finns det nåt som heter Write Priority. Det fungerar som så att Global Transfer (och det är det här, eftersom a8 är ett
globalt adressregister) har högre prioritet än ALU-operationer. Bägge prylarna utförs alltså, men bara den ena skriver till destinationen.

MAC och sånt är rätt vanligt nu för tiden även i "vanliga" mikrokontrollers, så nu får man nog säga att skillnaden på DSP mot andra processorer dels att dom kan göra ett par fler saker per klockcykel. Dels att dom har lite mer innovativa sätt att adressera minnet, till exempel är det normalt inget problem att göra ett par uträkningar och räkna upp datapekaren i samma instruktion (det kan visserligen många processorer också, men inte på ett lika flexibelt sätt). Dels har dom lite mer passande sätt att komma åt minnet, så att instruktioner och data kan gå olika vägar och hamna i olika cachar (också en sak många processorer kan, men i det här fallet är cachen även ofta optimerad för data i ringbuffrar).

En sak jag aldrig nånsin har sett på en vanlig processor (men velat haft många gånger) är mättande aritmetik. Alltså att om du skulle göra
0x7fff+1 på en 16-bitar signed så blir resultatet fortfarande 0x7fff. Nu är det ju inte riktigt bara så det fungerar, men ni förstår principen. Det är riktigt användbart, och sparar felhantering något så grymt mycket, om man ska försöka göra filter eller servon i fixed point-matte.

Har du några exempel på kretsar som implementerar mättande aritmetik?, hoppas sådan instruktion sätter carry flagga eller liknande dock så att man kan kolla hur det gick.

Xilinx fpgaer har "dsp"-block som kan programmeras att ha mättande aritmetik vill jag minnas. I en fpga kan du ju implementera din egen DSP-processor och skräddarsy instruktionssetet.

Nja, grejen är att man är inte det minsta intresserad av om det mättade i dom applikationerna jag nämde. Är det fullt så är det fullt, det finns ingen anledning att göra nåt speciellt om det händer.

MMX-instruktionerna på x86 kan faktiskt göra mättande aritmetik. Jag har använt det i ett dataspel för att göra genomskinliga explosioner. Instruktionerna jobbar på 64-bitarsregister som man kan välja att använda som 8 åttabitarstal, 4 sextonbitarstal eller 2 trettiotvåbitarstal.

De utökningar av instruktionsupsättningen som gjorts efter MMX tror jag också innehåller liknande instruktioner men det finns också vektoriserad flyttalsberäkning. Då används dessutom 128-bitarsregister om jag inte minns fel.

Intel propsade på SSE också. Det lät bra tills man läste att det återanvände register så att man var tvungen att ladda om registren pga att dess dubbelanvändning. Först med SSE3 har jag för mig att SSE instruktionerna använde eget register-RAM.

MMX-registren mm0-mm7 delar utrymme med flyttalsstacken st0-st7 så det blir ineffektivt att ha kod som gör flyttalsberäkningar och använder MMX-registren samtidigt. Efter att ha använt MMX-registren krävs att man återställer till flyttalsläge med EMMS-instruktionen också.

Vad jag förstått så gjordes detta för att operativsystemens context-switch inte skulle behöva ändras för den nya processorn i och med att de redan sparas i egenskap av flyttalsregister.

I mitt fall var det inget problem att använda MMX-registren eftersom slingan som ritar explosionerna inte använder flyttal. Andra delar av programmet använder flyttal men om jag kommer ihåg rätt så kräver inte anropskonventionerna att flyttalsstacken bevaras över funktionsanrop.

SSE-registren är å andra sidan helt på 128 bitar och kräver därför operativsystemsstöd för att olika programs data inte skall blandas ihop! Den första versionen stöder dock inte heltal utan bara flyttal.