Svenska ElektronikForumet

I de äldre PIC16/PIC12 modellerna måste man börja sin interrupt rutin
med att spara undan vissa register och avsluta med att återställa.
Här är ett exempel på hur en ISR kan se ut (från databladet till PIC16F628): Notera att detta enbart sparar WREG och STATUS, behöver man spara fler så blir det mer kod.

De nya modellerna sparas WREG, STATUS, BSR, FSR0L, FSR0H, FSR1L, FSR1H, FSR2H och PCLATH.
Och det sker alltså on-the-fly med automatik utan extra processortid.

> Ett lite enklare försök: Kan man rent programmeringsmässigt göra samma tidsbesparing på en
> äldre PIC genom att låta denna process ske i bakgrunden?

Nej.

Magnus_K skrev:@Nerre: Du får ursäkta mig men det här var lite för svårt. Normalt sett brukar jag göra mitt bästa att visa respekt och ge lite följdfrågor till ett så välskrivet och välmenat inlägg men det här förstod jag tyvärr inte mycket av.

Det var ett litet sidospår som kuriosa mest:) Poängen är att beroende på hur man konstruerar en processor kan den göra olika mycket per klockcykel.

Dels handlar det om hur mycket "tvärförbindelser" man har mellan olika delar. En äldre processor hade ju ofta en adressbuss och en databuss. Då måste först adressen till nästa instruktion läggas ut på adressbussen för att adressera programminnet, instruktionen läsas från minnet via databussen och sen lagras i ett instruktionsregister innan den kunde exekveras.

Men mikrocontrollers som har allt på ett chip har oftast dubbel uppsättning bussar. Då kan instruktionen i princip läsas direkt från programminnet samtidigt som föregående instruktion läser eller skriver till dataminnet.

TMS 320-C80 hade en ännu mer komplex arkitektur där det dels fanns en "vanlig" ALU och sen en enklare "adress-ALU" för adressberäkningar. Dessa kunde alltså jobba parallellt. Det innebar då att det fanns en massa "bussar" kors och tvärs mellan olika delar av processorn så data kan skickas direkt från ett ställe till ett annat utan att krocka med nåt annat.

Man kanske kan se det som en korridor med kontorsrum. Om alla rum bara har dörr mot korridoren så måste alla som springer mellan rummen samsas i korridoren. Men om rummen dels har dörrar mellan sig, och några av rummen har lönngångar mellan varandra så kan folk springa mellan rummen utan att krocka.

Sen påverkar pipelining. Pipelining handlar om att medans processorn är upptagen med att jobba internt (t.ex. göra en beräkning mellan register) så är data- och adressbuss lediga och kan passa på att hämta nästa instruktion. Den ligger då i pipelinen och kan exekveras direkt på nästa klockcykel istället för att det ska gå åt en cykel att hämta den.


Det finns också finesser som "barrel rotation". Om man ska skifta data ett visst antal steg åt höger eller vänster så kan man då antingen "loopa" och skifta ett steg i taget. Eller så har man 64 (för en byte) tvärförbindelser (8x8) för att i ett steg kunna rotera 1, 2, 3, 4, 5, 6, 7 eller 8 steg i ett enda svep. Men det kräver ju alltså en massa extra förbindelser (och därmed latchar).

P.S.
Det där där koden gör är alltså att den räknar ut A^2 + B^2 + C^2 + D^2 för de fyra bytesen i ett 32-bitars ord.
D.S.

@sodjan: Där ser man! Om jag förstår din postade kodsnutt rätt så är detta också bara maskinkoden för att spara undan/hämta tillbaka STATUS-registret? Tar man detta och multiplicerar med ett tiotal register så förstår jag att det går åt värdefull processortid.

Nu är det inte riktigt nyttigt för mitt psyke men jag läste lite mer om "Shadow register".
Jag har läst igenom detta kapitel i mitt datablad och bara för att man fått det förklarat på en enklare nivå så förstår jag nu precis allt dom skriver i databladet om det här registret. Kul!

I mitt sökande på mer information om just "Shadow register" och hur det verkligen sparar tid så hittade jag pdf'en som är bifogad nedan.

Om jag förstår funktionen (och dig) rätt så finns det, i dessa MCU:er, en hårdvara, SUU (Shadow Update Unit), som typ dubbelbuffrar dessa specifika register och som arbetar vid sidan av den "vanliga" processorn. När en ISR startas/avslutas så sker den registerswitchningen samtidigt som SUU:n uppdaterar sitt register och på så sätt tar det ingen extra tid alls. Typ exakt så du skriver Även om jag missförstått en del så ska du ha tack för dina förklaringar!
Nej nu får nog fokus ligga i att kunna starta en ISR men det är något fruktansvärt givande att veta mer vad som ligger bakom. Och, å andra sidan, tillbaka till första inlägget och tidsoptimering. Detta sparar ju tid eftersom det kommer sluta med en ISR, oavsett om den initieras av en komparatorflagga eller ADC-flagga.

@Nerre: Den där jämförelsen med "kontorslandskapet" var bra! Lite mer på min nivå Jag ska ta mig en sängfösare ikväll och läsa om ditt inlägg och läsa lite just vilka bussar jag har på "mina" processorer. Vill helst pausa lite nu och smälta allt. Det ryker redan lite ur öronen. Jättetack för du tagit dig tid!

EDIT: Rättade svenskan

> Om jag förstår din postade kodsnutt rätt så är detta också bara maskinkoden för att spara
> undan/hämta tillbaka STATUS-registret?

Jag skrev: "Notera att detta enbart sparar WREG och STATUS...".
Så du har halvt rätt.

> Om jag förstår funktionen (och dig) rätt så finns det, i dessa MCU:er, en hårdvara, SUU (Shadow Update Unit),
> som typ dubbelbuffrar dessa specifika register och som arbetar vid sidan av den "vanliga" processorn.

Nja, nu ska vi inte göra det med komplicerat än vad det faktiskt är.

Det är inget speciellt med shadow registren, sök databladet efter "_SHAD".
Det är helt vanliga register som kan skrivas/läsas som alla andra, det är bara
det att processorn i vissa lägen gör det automatiskt, d.v.s dels när ett
interrupt inträffar (skrivs), dels när RETFIE utförs (läses).

Man skulle kunna skriva direkt till _SHAD registren i från ISR'en, det
skulle ge en del intressanta effekter i main koden...

Rent teoretiskt skulle man kunna ha en main rutin som i t.ex läser data via
ett av index registren FSR0 eller FSR1. Sen skulle man rent tekniskt kunna
ha ett interrupt som ändrar t.ex FSR0L_SHAD och FSR0H_SHAD och de kommer
automatiskt att användas av main efter avslut av ISR'en då de återladdas till FSR0.

Lite krystat blir det, men man *skulle* kunna trimma main rutinen maximalt
och inte behöva kod som kollar om indexet ska ändras när det inte behövs.

Upon exiting the Interrupt Service Routine, these registers are automatically restored.
Any modifications to these registers during the ISR will be lost. If modifications to any
of these registers are desired, the corresponding shadow register should be modified and
the value will be restored when exiting the ISR. The shadow registers are available in
Bank 31 and are readable and writable.

Så det är helt dokumenterat att det är OK att göra så...

Som lite extra överkurs, notera att även stacken kan läsas och skrivas, d.v.s att
det inne i ISR'en går att ändra returadressen, så att när RETFIE utförs så kommer
man tillbaka till en annan plats än där interruptet inträffade. Men det är lite
extrem programmering... Man skulle kunna tänka sig en applikation som
består av flera individuella delar som i sig måste vara mycket snabba när de
körs så att det får plats kod för att kolla om man ska byta rutin. En ISR som
manipulerar stacken skulle kunna byta rutin via t.ex en timer eller en extern
händelse. Lite extremt är det i alla fall...

Ja vad dum jag är. WREG är ju det där arbetsregistret. Har tidigare noterat, när jag försökt tolka maskinkod, att man ofta skriver hit och sen skiftar till rätt register. Det ser jag ju nu att det är det första som uträttas; flytta WREG till ett temp-register...

>Nja, nu ska vi inte göra det mer komplicerat än vad det faktiskt är.

Hmm, ser ju dessa register i BANK31 men lite magiska är dom nog. Dom är ju granne med WREG vilket måste innebära något gott?
Nej, dåligt skämt åsido. Då blev det lite för djup djupdykning med andra ord. Pdf:en som jag länkade till kanske avser hur "vissa" processorer jobbar.

Läste också det du citerar och nämner. Tycker det är helt fantastiskt att se/höra om hur djupt man verkligen kan gå. Rent spontant kan jag förstå om någon skulle vilja återgå till en annan rutin efter ISR:en, men hör vad du säger, extremt...

> Pdf:en som jag länkade till kanske avser hur "vissa" processorer jobbar...

Ja, jag läste det inte i detalj, men det verkade beskriva en mer gereralliserad
arkitektur med en extra "shadow" uppsättning av de vanliga registren. Det finns ju
även processorer som har t.ex 16 (bara för att nämna något) "register" som sedan
mappas mot en mycket större "register file" med t.ex 128 register. Då kan man
ha 8 olika delar (kalla det "trådar" om du vill) av applikationen igång och enkelt
skifta mellan dessa genom att bara peka om bas-adressen till de 16 registren.
SUN's Sparc fungerar lite på det sättet, om jag minns rätt...

Men å andra sidan så finns det ingen anledning att läsa konstiga PDF'er som
Google råkar hitta någonstans, databladet har allt du behöver veta...

Shadowregistren kan väl också förklaras med en jämförelse med ett kontor. Antag att du både har en vanlig arbetsuppgift och också emellanåt agerar receptionist de få tillfällen det behövs.

Att någon ringer på dörren motsvarar då en interrupt. Ditt vanliga kontor motsvarar de vanliga registren, och receptionistarbetsplatsen motsvarar shadow-registren. När du sitter i receptionen så ser du inte sakerna i ditt vanliga kontor, och hur mycket du än kluddar på anteckningsblocket framför dig i receptionen så kommer det inte påverka anteckningsblocket som ligger på skrivbordet i kontoret.

Har man inte shadowregister så får man istället stoppa undan det man håller på med för ögonblicket, och det gör man normalt på en stack. Man kan ungefär säga att man tar sakerna på skrivbordet och stoppar i en låda märkt "vanliga arbetet" och sen börjar man med något annat en kort stund, och när man är klar så tar man fram sakerna ur "vanliga arbetet"-lådan igen. Om man inte har shadowregister så kan man spara lite tid på att bara plocka undan så mycket man behöver för att få plats med interrupten. Jag har inte koll på hur registren ser ut i PIC (och har lite halvsvårt att förstå enstaka detaljer i assemblerkoden här i tråden utan att läsa på om PIC), men det är väl rätt vanligt att en riktigt simpel interuptrutin kan klara sig utan att behöva använda alla register.


Eftersom sidospår inte verkar vara helt ovälkomna i denna tråd så kan jag kanske utveckla lite det där med hur man gör om man INTE har en stack. En lite lagom märklig mikroprocessor från stenåldern är RCA's 1802. Den har ingen stack, men den har 16 registerpar och man kan välja vilket av dessa par som ska vara programräknare. Om man har t.ex. R0 som programräknare så gör man ett hopp till en subrutin genom att lägga adressen till subrutinen i R1 och så ökar man på ett på "vilket register är programräknare"-registret (som är 4-bitars, för att kunna peka ut ett av 16 register). Då kommer processorn fortsätta på den adress som ligger i R1, och köra subrutinen. När den är klar så räknar man ner "vilket register är programräknare"-registret, varpå processorn kommer fortsätta där den var före subrutinanropet. (Nu minns jag inte om man kan öka/minska "viket register är programräknare"-registret eller om man bara kan ladda fasta värden i det. Om man bara kan ladda fasta värden så kan man göra subrutiner som bara går att anropa i en "nivå"). Jag har aldrig jobbat med 1802, bara läst på lite eftersom den bland annat ingår i "Elektronik för alla"-bokseriens del 4. Den verkar användas i t.ex. datorn Comx 35, som också verkar vara lite märklig...

Som svar till:
>Eftersom sidospår inte verkar vara helt ovälkomna i denna tråd...
För min del är det bara att köra på! Jag försöker hänga med så långt jag kan.

Med risk att det här kommer bli en långdragen historia så kontrar jag ändå lite.
Jag har förstått det snarare som att när jag är på väg att gå att öppna så fortsätter jag skriva i mitt anteckningsblock, och skriver tills uppgiften är klar. Väl framme så kladdar jag lite i receptionsblocket innan det är dags att gå tillbaka igen. På så sätt blir det ingen tidsförlust då det ändå bara var en transportsträcka som måste göras.

Pdf:en hade en förklaring som gjorde att jag kunde förstå att man inte förlorade tid att flytta data till stacken då dom typ redan fanns där.
Måste medge att jag inte riktigt förstått än hur dom gör med PIC:en. Det känns fortfarande som att om man inte kör med dubbla beräkningar/processer så måste dessa instruktioner klämmas in före/efter andra instruktioner, vilka då? Och när då?

Jag tror jag gett mig in på något jag inte kommer förstå i nuläget. Kanske lite "tidigt" att grotta i det här när jag inte har en direkt susning om hur övriga processorn jobbar.

Angående ditt kuriosa-stycke:
Hehe, här får man inte räkna fel. Det låter märkligt det du skriver men å andra sidan har jag ingen historik inom datavetenskap så på ett sätt kanske detta var ett otroligt effektivt sätt för processorn att arbeta?
Förresten, visst finns det en forum-medlem som heter "1802"? Vet inte om hon/han läser den här tråden men om namnet grundar sig på denna mikroprocessor så kanske denna har mer att berätta?
Mmmm, dessa "Elektronik för alla"-böckerna. Har inte fått tummen ur än men jag har bestämt mig för att få tag i en uppsättning för eller senare.
Har aldrig ens bläddrat i någon av dom men så mycket gott man får höra om dessa gamla böcker så har dom väckt "ska ha"-känslorna.

Z80 hade visserligen en stack, men den hade också dubbel uppsättning av de flesta register (tror de kallades "alternate registers"). Med en enda instruktion så "swappade" man mellan vanliga och alternate.

Detta var inget som jag nån gång såg nån använda (vilket på sätt och vis var lite slöseri), men just detta med snabb interrupthantering vore ju ett bra exempel på när det skulle kunna vara bra.

Jag spånade lite grann på att skriva nåt "multitaskande" och en tanke var då att använda en snabb NMI för att regelbundet hoppa till en rutin som "växlade task". Den taskväxlingsrutinen skulle då använda alternate registers för att på ett snyggt sätt kunna spara undan innevarande tasks register (inklusive stackpekare OCH programräknare) och lägga dit data för nästa task. Processerna skulle alltså inte behöva vara medvetna om att de switchades, så länge de gav f-n i att använda alternate registers så skulle de inte kunna "se" att de växlades bort.

Varje task hade då alltså egen stack (egen stackpekare), egen programräknare etc. Min tanke var att köra det på min SVI328 som hade bankswitching, då skulle man kunnat ha separata banker för olika tasks också. Men jag kom aldrig så långt som till att implementera det hela:) Främst eftersom jag inte hade nåt att koda assembler med på Spectravideon (det här var i början av 90-talet så jag hade redan Amiga och PC). Om jag inte minns fel så var det ett steg i mina planer att bygga en TNC för packet radio av min SVI328 (bygga ett eget kort med en Z80 SIO, jag hade ju Super Expandern med massa plats i).



Jag vet inte exakt hur de där shadow registers fungerar, men jag tror man behöver en grundläggande förståelse för hur register och sånt i en processor fungerar. De som har byggt egan CPU:er brukar förstå det:) Det handlar ju oftast om latchar/vippor, om man vid en skrivning öppnar latchen till flera register så kommer de att skrivas parallellt utan nån extra tidsåtgång. Det här hänger ihop med det där som jag pratade om med "bussar" kors och tvärs. När data läses eller skrives så handlar det ju om att man öppnar en latch för att lägga ut data från ett register på en buss, och sen öppnar man en annan latch för att det ska skrivas in i nästa register.

Om vi tar kontors-korridoren, men vi gör om den till ett rör. Dörrarna är kranar. För att skriva in data från ett register till en annan så öppnar du först "utloppskranen" (read-latchen) från källregistret, nu är dess innehåll i röret (=på bussen). Sen öppnar du "inloppskranen" (write-latchen) till målregistret, nu hamnar innehållet där. (Sen ska de stängas i omvänd ordning.) Du kan såklart öppna flera "inloppskranar" samtidigt för att få datat att hamna på flera ställen samtidigt.

> Att någon ringer på dörren motsvarar då en interrupt. Ditt vanliga kontor motsvarar de vanliga
> registren, och receptionistarbetsplatsen motsvarar shadow-registren. När du sitter i receptionen
> så ser du inte sakerna i ditt vanliga kontor, och hur mycket du än kluddar på anteckningsblocket
> framför dig i receptionen så kommer det inte påverka anteckningsblocket som ligger på skrivbordet
> i kontoret.

Jag tycker att jämförelsen det haltar...
Din förklaring bygger på att man faktiskt jobbar mot shadow registren, det gör man inte.
(*OM* vi fortfarande talar om PIC här, inte något slags generell bild!)

> Man kan ungefär säga att man tar sakerna på skrivbordet och stoppar i en låda märkt
> "vanliga arbetet" och sen börjar man med något annat en kort stund, och när man är
> klar så tar man fram sakerna ur "vanliga arbetet"-lådan igen.

Ja, *det* liknar PIC'ens shadow register.

> ...så måste dessa instruktioner klämmas in före/efter andra instruktioner,

Tänker du på att lagra under och att hämta tillbaka till/från _SHAD registren?
Det behovs inga "instruktioner" till det, det är inbyggt i hårdvaran i interrupt logiken.
Så det sker "på nolltid" utan att processorn behöver göra något extra. Det är inget
som "kläms in" mellan något annat. Ta RETFIE t.ex. I tidigare PICs så gjorde den ett
per olika saker, satte GIE och återställer programräknaren från stacken. I de nya
modellerna gör RETFIE helt enkelt bara lite mer. Men det är så hårdvaran är
byggd och är inget som tar någon extra tid.

Med PICens shadowregister har du bara EN låda att lägga ner sakerna i väl?

Har man flera lådor så är det ju mer likt en stack.

Ja, men man har bara en avbrottsnivå också.
Returstacken däremot är 16 nivåer. Allså subrutinnivåer.

Om man *vill* hantera flera interrupt nivåer så kan man spara
unden _SHED registren från ISR'en och enabla GIE. Men det blir
lite rörigt och det är nog väldigt sällan som det skulle behövas.

Skrivningen till _SHAD registren sker alltså parallelt och mycket
snabbare än ett antal PUSH till en stack. Alltså i princip utan
tidstillägg eftersom det sker i hårdvaran direkt.

@Nerre: Synd att det aldrig blev någon controller till din packet radio. Har du sysslat mycket med just "packet radio"-tekniken?
Hade faktiskt aldrig hört talas om det förrän nu men läste ikapp lite.

Nerre skrev:Om vi tar kontors-korridoren, men vi gör om den till ett rör. Dörrarna är kranar. För att skriva in data från ett register till en annan så öppnar du först "utloppskranen" (read-latchen) från källregistret, nu är dess innehåll i röret (=på bussen). Sen öppnar du "inloppskranen" (write-latchen) till målregistret, nu hamnar innehållet där. (Sen ska de stängas i omvänd ordning.) Du kan såklart öppna flera "inloppskranar" samtidigt för att få datat att hamna på flera ställen samtidigt.

Kan vi inte bestämma att det är så här det fungerar? Det var lättbegripligt.
Var gång man öppnar write-latchen till ett av de förutbestämda registren så per automatik öppnas samtidigt latcharna till shadow-registren. På så sätt arbetar man alltid mot de "vanliga" registren men shadow-registren är alltid uppdaterade.


@sodjan: Mmm, jag tror även det du förklarar stämmer rätt bra med ovan. Vi får nog inse att ni inte kommer längre med mig i det här!

Nej, jag har faktiskt knappt kört nån packet radio alls. Men jag är radioamatör sen gymnasietiden och när jag blev döv så blev det ju lite begränsat med saker man kunde göra så jag började titta lite på det, men kom aldrig så långt. På den tiden var jag ung och fattig och tyckte att färdigköpta TNC var ovanligt dyra:) Och så var det ju roligare att bygga nåt själv, fick ju läsa på lite om synkron kommunikation t.ex. och det var när jag insåg att Z80 SIO verkade ha stöd för synkron kommunikation som jag tänkte att jag kunde damma av min gamla SVI328 som bara låg undanstoppad:)

Z80 var jag ju rätt bra på sen ABC80-tiden liksom.

> ...men shadow-registren är alltid uppdaterade.

De uppdateras bara just då interruptet inträffar.
Och de kopieras tillbaka av instruktionen RETFIE.

Om de uppdaterades hela tiden så fanns det ju inget
sparat för RETFIE att kopiera tillbaka...