Register eller RAM
Re: Register eller RAM
Detta med att använda RAM som register gäller inte PIC32, då dessa är uppbyggda som en traditionell processor.
Re: Register eller RAM
Ett problem i en diskussion som denna är väl att en term så som "register" inte har någon entydig strikt definition, och därför kan man väl diskutera huruvida RAM:et också är register i all oändlighet utan att komma någon vart. Då blir det väl snarare en tävling om vem som skriker högst. Vore det inte lämpligt att enas om en definition och sedan utifrån den avgöra vad som är register och inte?
Jag skulle nog vilja få det till att processorregister avser något inuti processorkärnan som har en särställning i instruktionsuppsättningen med mer funktionalitet än normala minnesplatser. Kallar man hela RAM:et för register har man låtit ett användbart ord tappa hela sin betydelse skulle jag vilja anse.
I fallet med PIC:en med tanke på att W-registret har en särställning genom att ALU:ns ena ingång är hårdkopplad till ackumulatorn W skulle jag nog snarare säga att W-registret är det enda standardregistret som finns i arkitekturen. Det går väl inte att i en instruktion säga minnesplats1 = minnesplats2 + minnesplats3 som exempel? Man måste väl säga W <- minnesplats2, W <- W+minnesplats3 och sedan minnesplats1 <- W i tur och ordning?
Att PIC:en kan köra de flesta instruktionerna "direkt mot RAM:et" är ju inte direkt någon ovanlig grej heller -- x86-arkitekturen som används i PC:n är likadan! Men normalt säger man inte att maskinen har flera gigabyte med register trots det. Det brukar beskrivas som
http://en.wikipedia.org/wiki/Register_m ... chitecture
snarare än
http://en.wikipedia.org/wiki/Load/store_architecture
som AVR och ARM är exempel på.
Men bara för att hela RAM:et i PC:n går att använda direkt i de flesta instruktionerna skulle jag som sagt inte påstå att min dator har flera gigabyte med register just eftersom de "faktiska" registren har en särställning i instruktionsuppsättningen. Bortsett från eventuella hastighetsskillnader finns även begränsningen att t.ex. additionsinstruktionen inte kan arbeta mot mer än en minnesadress precis som PIC:en verkar fungera. Däremot kan man addera värdet i ett register till ett annat.
I mikrokontrollrar behöver ju inte minnet alltid vara särskilt mycket långsammare än ett dedikerat inbyggt register i processorn tack vare att hastigheten är så låg och minnet är så litet, men om man kallar hela sitt RAM för register så har man väl låtit ordet tappa sin funktion. Vad skall man då kalla t.ex. W som har en särställning i instruktionsuppsättningen? Eller instruktionspekaren?
Sedan bör man väl tänka på att "register" ofta används i två ganska olika betydelser där det ena är
http://en.wikipedia.org/wiki/Processor_register
och det andra, som mer liknar en minnesplats sett från processorn, är
http://en.wikipedia.org/wiki/Hardware_register
Men med tanke på att det inte verkar finnas någon strikt definition av vad register exakt betyder så är det väl inte heller fel att kalla hela minnet i PIC:en för register. Om tillverkaren valt att göra det är det väl för att skryta om att de flesta instruktionerna kan arbeta mot värden direkt i RAM, och det kan ju vara trevligt om man skriver i assembler.
En annan processor som fungerar på ett liknande sätt med endast ett fåtal standardregister är 6502 som användes i bland annat C64 och NES där de flesta instruktionerna arbetar på ackumulator och minne.
Jag skulle nog vilja få det till att processorregister avser något inuti processorkärnan som har en särställning i instruktionsuppsättningen med mer funktionalitet än normala minnesplatser. Kallar man hela RAM:et för register har man låtit ett användbart ord tappa hela sin betydelse skulle jag vilja anse.
I fallet med PIC:en med tanke på att W-registret har en särställning genom att ALU:ns ena ingång är hårdkopplad till ackumulatorn W skulle jag nog snarare säga att W-registret är det enda standardregistret som finns i arkitekturen. Det går väl inte att i en instruktion säga minnesplats1 = minnesplats2 + minnesplats3 som exempel? Man måste väl säga W <- minnesplats2, W <- W+minnesplats3 och sedan minnesplats1 <- W i tur och ordning?
Att PIC:en kan köra de flesta instruktionerna "direkt mot RAM:et" är ju inte direkt någon ovanlig grej heller -- x86-arkitekturen som används i PC:n är likadan! Men normalt säger man inte att maskinen har flera gigabyte med register trots det. Det brukar beskrivas som
http://en.wikipedia.org/wiki/Register_m ... chitecture
snarare än
http://en.wikipedia.org/wiki/Load/store_architecture
som AVR och ARM är exempel på.
Men bara för att hela RAM:et i PC:n går att använda direkt i de flesta instruktionerna skulle jag som sagt inte påstå att min dator har flera gigabyte med register just eftersom de "faktiska" registren har en särställning i instruktionsuppsättningen. Bortsett från eventuella hastighetsskillnader finns även begränsningen att t.ex. additionsinstruktionen inte kan arbeta mot mer än en minnesadress precis som PIC:en verkar fungera. Däremot kan man addera värdet i ett register till ett annat.
I mikrokontrollrar behöver ju inte minnet alltid vara särskilt mycket långsammare än ett dedikerat inbyggt register i processorn tack vare att hastigheten är så låg och minnet är så litet, men om man kallar hela sitt RAM för register så har man väl låtit ordet tappa sin funktion. Vad skall man då kalla t.ex. W som har en särställning i instruktionsuppsättningen? Eller instruktionspekaren?
Sedan bör man väl tänka på att "register" ofta används i två ganska olika betydelser där det ena är
http://en.wikipedia.org/wiki/Processor_register
och det andra, som mer liknar en minnesplats sett från processorn, är
http://en.wikipedia.org/wiki/Hardware_register
Men med tanke på att det inte verkar finnas någon strikt definition av vad register exakt betyder så är det väl inte heller fel att kalla hela minnet i PIC:en för register. Om tillverkaren valt att göra det är det väl för att skryta om att de flesta instruktionerna kan arbeta mot värden direkt i RAM, och det kan ju vara trevligt om man skriver i assembler.
En annan processor som fungerar på ett liknande sätt med endast ett fåtal standardregister är 6502 som användes i bland annat C64 och NES där de flesta instruktionerna arbetar på ackumulator och minne.
Re: Register eller RAM
> Detta gäller normal alla processorer, oavsett om det är PIC, AVR, ARM, x86 eller nån annan.
Man kan inte direkt jämföra PIC/AVR (20-30 MHz), ARM (hundratals MHz) och "stora"
processorer som går i flera GHz och har långsammare externa minnesbussar. Det är
väl självklart att man har olika arkitekturer i de fallen! AVR har en arkitektur som
liknar de från de stora processorerna utan att det ger någon direkt fördel, det
bara tillför extra komplexitet i arkitekturen.
> Ett problem i en diskussion som denna är väl att en term så som "register" inte har någon entydig strikt definition,
Exakt, det är därför som jag föredrar att kalla det "minne" lite mer generellt.
Det intressanta är att jämföra en AVR med 1024 bytes "minne" med en PIC
med 1024 bytes "minne". Och då anser jag att PIC har en "renare" arkitekur,
vilket även återspeglas i den enklare instruktionsuppsättningen.
> Vad skall man då kalla t.ex. W som har en särställning i instruktionsuppsättningen?
Ja, det kallas ju "Working Register" och visst, det har några unika funktioner. Man samtidigt
ligger W i minnesmappen (WREG på PIC16F1xxx serien) och man kan alltså använda alla
instruktioner som jobbar direkt mot vanliga "register" även mot W, om man vill. T.ex
Bit Set/Clear File (BCF/BSF) jobbar inte mot W, men fungerar bra mot WREG.
Men du har helt rätt i (och som jag skrev tidigare) att det hela mest är semantik.
Det är ointressant vad det kallas, det som är intressant är funktionen och arkitekturen.
> Det går väl inte att i en instruktion säga minnesplats1 = minnesplats2 + minnesplats3
> som exempel? Man måste väl säga W <- minnesplats2, W <- W+minnesplats3 och
> sedan minnesplats1 <- W i tur och ordning?
Korrekt, men det fungerar å andra sidan så generellt över hela minnet. På en AVR
fungerar det enbart direkt *OM* datat redan ligger i ett antal "register". Om alla tre
platserna ligger i det som på AVR kallas "Data Space" så tillkommer 2 LD och 1 ST.
Sen så har vi inte alls nämnt att på vissa AVR'er så ligger vissa kontrollregister utanför
"I/O Memory" och kan bara adresseras via "Data Space". D.v.s att för vissa register
använder man IN/OUT och för andra LDx/STx. I/O memory är begränsat till 64 adresser.
Dessutom är I/O memory delat i två delar där vissa instruktiner enbart fungerar mot den
låga delen, t.ex bit-test instruktionerna som man ofta använder för att kolla status på
olika delar. Ett bra exempel är USART registren som beroende på modell kan ligga i lägre
eller högre delen av I/O Memory.Denna tråd är väl ett bra exempel på den förvirringen:
http://www.avrfreaks.net/index.php?name ... 1&start=20
Ovanstående problem med att göra att SBIS enbart fungerar mot *halva* I/O Memory (0-31),
och på (t.ex) Mega88 hade USART registren glidit upp i övre halvan av I/O memory. D.v.s att
bit-testerna inte längre fungerar och man måste ta omvägen över att först kopiera USART
registret till ett "register" (förvirrande? ). Det betyder också att kod inte är porterbar,
om man inte kör ett par speciella macron som Atmel erbjuder.
Ovanstående är fullständigt okänt på PIC, det är en adressmapp som är gemensam för allt.
Man kan inte direkt jämföra PIC/AVR (20-30 MHz), ARM (hundratals MHz) och "stora"
processorer som går i flera GHz och har långsammare externa minnesbussar. Det är
väl självklart att man har olika arkitekturer i de fallen! AVR har en arkitektur som
liknar de från de stora processorerna utan att det ger någon direkt fördel, det
bara tillför extra komplexitet i arkitekturen.
> Ett problem i en diskussion som denna är väl att en term så som "register" inte har någon entydig strikt definition,
Exakt, det är därför som jag föredrar att kalla det "minne" lite mer generellt.
Det intressanta är att jämföra en AVR med 1024 bytes "minne" med en PIC
med 1024 bytes "minne". Och då anser jag att PIC har en "renare" arkitekur,
vilket även återspeglas i den enklare instruktionsuppsättningen.
> Vad skall man då kalla t.ex. W som har en särställning i instruktionsuppsättningen?
Ja, det kallas ju "Working Register" och visst, det har några unika funktioner. Man samtidigt
ligger W i minnesmappen (WREG på PIC16F1xxx serien) och man kan alltså använda alla
instruktioner som jobbar direkt mot vanliga "register" även mot W, om man vill. T.ex
Bit Set/Clear File (BCF/BSF) jobbar inte mot W, men fungerar bra mot WREG.
Men du har helt rätt i (och som jag skrev tidigare) att det hela mest är semantik.
Det är ointressant vad det kallas, det som är intressant är funktionen och arkitekturen.
> Det går väl inte att i en instruktion säga minnesplats1 = minnesplats2 + minnesplats3
> som exempel? Man måste väl säga W <- minnesplats2, W <- W+minnesplats3 och
> sedan minnesplats1 <- W i tur och ordning?
Korrekt, men det fungerar å andra sidan så generellt över hela minnet. På en AVR
fungerar det enbart direkt *OM* datat redan ligger i ett antal "register". Om alla tre
platserna ligger i det som på AVR kallas "Data Space" så tillkommer 2 LD och 1 ST.
Sen så har vi inte alls nämnt att på vissa AVR'er så ligger vissa kontrollregister utanför
"I/O Memory" och kan bara adresseras via "Data Space". D.v.s att för vissa register
använder man IN/OUT och för andra LDx/STx. I/O memory är begränsat till 64 adresser.
Dessutom är I/O memory delat i två delar där vissa instruktiner enbart fungerar mot den
låga delen, t.ex bit-test instruktionerna som man ofta använder för att kolla status på
olika delar. Ett bra exempel är USART registren som beroende på modell kan ligga i lägre
eller högre delen av I/O Memory.Denna tråd är väl ett bra exempel på den förvirringen:
http://www.avrfreaks.net/index.php?name ... 1&start=20
Ovanstående problem med att göra att SBIS enbart fungerar mot *halva* I/O Memory (0-31),
och på (t.ex) Mega88 hade USART registren glidit upp i övre halvan av I/O memory. D.v.s att
bit-testerna inte längre fungerar och man måste ta omvägen över att först kopiera USART
registret till ett "register" (förvirrande?
). Det betyder också att kod inte är porterbar,om man inte kör ett par speciella macron som Atmel erbjuder.
Ovanstående är fullständigt okänt på PIC, det är en adressmapp som är gemensam för allt.
Re: Register eller RAM
Nu är jag inte så insatt hur det fungerar på PIC, men på AVR är det ju så att programminnet utgör ytterligare en adressrymd skild från dataområdet, och det blir lätt lite stökigt när man vill programmera i C eftersom de måste kommas åt på olika sätt... Även på x86 finns en uppdelning mellan IO-space (in och out-instruktioner) samt data/programminne (vilka dock hör till samma adressrymd). x86 liknar också PIC i det att de flesta instruktioner som kan arbeta direkt mot externt minne också kan arbeta mot de åtta standardregistren (eax,ebc,ecx,edx,esi,edi,ebp,esp).
Fördelen med en load-store arkitektur där RAM endast går att komma åt via speciella instruktioner är väl det att det med inte alltför komplicerad hårdvara går att få alla beräkningar som arbetar på register att gå på en klockcykel och det blir en fördel då mellanresultat, slingkontrollvariabler och liknande kan ligga i dessa register. En arkitektur med endast en ackumulator som t.ex. PIC:en eller 6502 ger ju å andra sidan en enkel hårdvara för processorkärnan men har nackdelen att nästan alla kontrollvariabler och mellanresultat måste skickas fram och tillbaka till RAM vilket ofta kräver fler klockcykler för samma beräkning. Men det går ju ibland att kompensera för genom att köra klockan snabbare på "små" processorer!
På ARM finns bara en adressrymd utöver processorregistren, och det är ju trevligt när man programmerar i C! Vad som hamnar i RAM och vad som hamnar i register är ju något som kompilatorn väljer men det är ju i alla fall transparent för programmeraren.
Fördelen med en load-store arkitektur där RAM endast går att komma åt via speciella instruktioner är väl det att det med inte alltför komplicerad hårdvara går att få alla beräkningar som arbetar på register att gå på en klockcykel och det blir en fördel då mellanresultat, slingkontrollvariabler och liknande kan ligga i dessa register. En arkitektur med endast en ackumulator som t.ex. PIC:en eller 6502 ger ju å andra sidan en enkel hårdvara för processorkärnan men har nackdelen att nästan alla kontrollvariabler och mellanresultat måste skickas fram och tillbaka till RAM vilket ofta kräver fler klockcykler för samma beräkning. Men det går ju ibland att kompensera för genom att köra klockan snabbare på "små" processorer!
På ARM finns bara en adressrymd utöver processorregistren, och det är ju trevligt när man programmerar i C!
Vad som hamnar i RAM och vad som hamnar i register är ju något som kompilatorn väljer men det är ju i alla fall transparent för programmeraren.Re: Register eller RAM
> Nu är jag inte så insatt hur det fungerar på PIC,...
Program och data är separerade, både AVR och PIC är Harvard arkitekturer:
http://en.wikipedia.org/wiki/Harvard_architecture
> måste skickas fram och tillbaka till RAM
Nu så gäller ju diskutionen mikrokontrollers där allt ligger i samma "chip" och
där (som du sa tidigare) gränsdragningen är hårfin mellan "register" och "RAM".
Att jämföra med större arkitekturer är svårt. Där har man externa minnesbussar o.s.v.
Alla moderna RISC arkitekturer är normalt av load/store typ. Det är som du
säger lättare att optimera och att bygga logik för OOO processering t.ex.
> Även på x86 finns en uppdelning mellan IO-space (in och out-instruktioner)
Och? Ytterligare en skit-arkitektur...
Ett exempel på en snygg RISC arkitektur utan allt för mycket "bagage" vid
designen är DEC's Alpha: http://en.wikipedia.org/wiki/DEC_Alpha.
Program och data är separerade, både AVR och PIC är Harvard arkitekturer:
http://en.wikipedia.org/wiki/Harvard_architecture
> måste skickas fram och tillbaka till RAM
Nu så gäller ju diskutionen mikrokontrollers där allt ligger i samma "chip" och
där (som du sa tidigare) gränsdragningen är hårfin mellan "register" och "RAM".
Att jämföra med större arkitekturer är svårt. Där har man externa minnesbussar o.s.v.
Alla moderna RISC arkitekturer är normalt av load/store typ. Det är som du
säger lättare att optimera och att bygga logik för OOO processering t.ex.
> Även på x86 finns en uppdelning mellan IO-space (in och out-instruktioner)
Och?
Ytterligare en skit-arkitektur... Ett exempel på en snygg RISC arkitektur utan allt för mycket "bagage" vid
designen är DEC's Alpha: http://en.wikipedia.org/wiki/DEC_Alpha.
Re: Register eller RAM
Och hur många register har t.ex. en modern Intel i7? Om register är billigt och enkelt borde den väl ha 1-2 meg register?Icecap skrev: Ett begränsat antal registre är däremot den gamla struktur där minne kostade mycket och man fick spara, nu kan man göra så många register man vill - vilket PIC gör fullt ut.
Re: Register eller RAM
I Harvard-strukturen är det rätt men blanda inte runt och jämför en von Neumann med en Harvard.
Sedan är det väl ingen som har påstådd att x86 är en bra struktur eller hur?
Sedan är det väl ingen som har påstådd att x86 är en bra struktur eller hur?
-
Swech
- EF Sponsor
- Inlägg: 4741
- Blev medlem: 6 november 2006, 21:43:35
- Ort: Munkedal, Sverige (Sweden)
- Kontakt:
Re: Register eller RAM
Om man nu skall kalla RAM på en PIC för Register så blir det
att PIC har en ackumulator W och x antal register.
Eftersom det inte går att addera två "register" med varandra på en PIC utan
att blanda in W men det däremot går att addera två
"register" på AVR så blir det ju så att man får säga att
AVR har 16 st W samt en massa RAM
Sedan så är det endast 128 "register" som man kan nå på en PIC utan att behöva
greja med banksel bitarna. Så att säga att man helt fritt kan greja med alla sina
"register" är inte riktigt sant. Det går men det innebär banksel pysslande också.
Sodjan - det här med att ibland använda sig av IN/OUT alt. LD/ST är i sig inget konstigt.
Det är AVRens svar på Banksel. Skillnaden är att LD/ST alltid fungerar
så om man har problem med IN/OUT så kan man ALLTID köra LD/ST över hela minnet.
"Straffet" för detta är att LD/ST tar dubbelt så stort programminne.
Dubbla index register som det hänvisades till i en annan tråd finns tydligen bara på
Enhanced midrange PIC
Baseline och midrange har endast ett.
Så flytta kod mellan olika PIC kan vara nog så förvirrande då en PIC16xxx inte
klarar samma kod som en annan PIC16yyy
Det man kan notera är att ju mer avancerade PIC blir destå mer lika AVR
och även andra processorer blir de i sin uppbyggnad.
De unika delarna hos PIC finns kvar men det som tillkommit är det som
man tydligen ansett saknats hos dem.
I dagsläget skulle jag säkert kunna bli vän med enhanced mid range eller PIC18
Swech
att PIC har en ackumulator W och x antal register.
Eftersom det inte går att addera två "register" med varandra på en PIC utan
att blanda in W men det däremot går att addera två
"register" på AVR så blir det ju så att man får säga att
AVR har 16 st W samt en massa RAM
Sedan så är det endast 128 "register" som man kan nå på en PIC utan att behöva
greja med banksel bitarna. Så att säga att man helt fritt kan greja med alla sina
"register" är inte riktigt sant. Det går men det innebär banksel pysslande också.
Sodjan - det här med att ibland använda sig av IN/OUT alt. LD/ST är i sig inget konstigt.
Det är AVRens svar på Banksel. Skillnaden är att LD/ST alltid fungerar
så om man har problem med IN/OUT så kan man ALLTID köra LD/ST över hela minnet.
"Straffet" för detta är att LD/ST tar dubbelt så stort programminne.
Dubbla index register som det hänvisades till i en annan tråd finns tydligen bara på
Enhanced midrange PIC
Baseline och midrange har endast ett.
Så flytta kod mellan olika PIC kan vara nog så förvirrande då en PIC16xxx inte
klarar samma kod som en annan PIC16yyy
Det man kan notera är att ju mer avancerade PIC blir destå mer lika AVR
och även andra processorer blir de i sin uppbyggnad.
De unika delarna hos PIC finns kvar men det som tillkommit är det som
man tydligen ansett saknats hos dem.
I dagsläget skulle jag säkert kunna bli vän med enhanced mid range eller PIC18
Swech
Re: Register eller RAM
> IN/OUT alt. LD/ST är i sig inget konstigt.
> Det är AVRens svar på Banksel.
Nej, det är en effekt av en inkonsekvent arkitektur där vissa
instruktioner bara fungerar mot halva "I/O Memory" och där en
del "I/O register" ligger utanför "I/O Memory"...
Och bankhanteringen är 100% konsekvent. BANKSEL plus en instruktion
kan aldrig gå fel oavsett vad det är som du accessar.
> Dubbla index register som det hänvisades till i en annan tråd finns tydligen bara på
> Enhanced midrange PIC, Baseline och midrange har endast ett.
Finns ingen anledning idag att köra något "mindre" än PIC16F1xxx serien.
Finns även PIC12F1xxx i 8-pin kapsel med samma arkitektur. 16F1xxx har
även ungefär halva priset mot motsvarande äldre modeller.
> Så flytta kod mellan olika PIC kan vara nog så förvirrande då en PIC16xxx inte
> klarar samma kod som en annan PIC16yyy
De nyare PIC16F1xxx klarar i princip samma kod som de äldre (sen
så kan man modifiera för att ta del av de effektivare funktionerna).
Alla PIC16F1xxx/PIC12F1xxx kör i princip samma kod. Det är bara
de små PIC10 i SOT23-6 kapsel som inte har nya arkitekturen.
> Skillnaden är att LD/ST alltid fungerar...
Probemet är ju att det *enbart* är LD/ST som fungerar (i vissa fall)...
> Det man kan notera är att ju mer avancerade PIC blir destå mer lika AVR
> och även andra processorer blir de i sin uppbyggnad.
Som tur är behåller de sin rena/raka arkitektur där "allt kan göras med allt".
Och de undviker ju att kopiera den splittrade minnesarkitekturen.
Visst, för den som är uppfostrad med större datorer så kanske AVR'en arkitektur känns
"normal", men den är inte speciellt snygg och inte det smidigaste för en mikrokontroller.
Men som sagt, det kanske i alla fall känns som en "dator"...
> Det är AVRens svar på Banksel.
Nej, det är en effekt av en inkonsekvent arkitektur där vissa
instruktioner bara fungerar mot halva "I/O Memory" och där en
del "I/O register" ligger utanför "I/O Memory"...
Och bankhanteringen är 100% konsekvent. BANKSEL plus en instruktion
kan aldrig gå fel oavsett vad det är som du accessar.
> Dubbla index register som det hänvisades till i en annan tråd finns tydligen bara på
> Enhanced midrange PIC, Baseline och midrange har endast ett.
Finns ingen anledning idag att köra något "mindre" än PIC16F1xxx serien.
Finns även PIC12F1xxx i 8-pin kapsel med samma arkitektur. 16F1xxx har
även ungefär halva priset mot motsvarande äldre modeller.
> Så flytta kod mellan olika PIC kan vara nog så förvirrande då en PIC16xxx inte
> klarar samma kod som en annan PIC16yyy
De nyare PIC16F1xxx klarar i princip samma kod som de äldre (sen
så kan man modifiera för att ta del av de effektivare funktionerna).
Alla PIC16F1xxx/PIC12F1xxx kör i princip samma kod. Det är bara
de små PIC10 i SOT23-6 kapsel som inte har nya arkitekturen.
> Skillnaden är att LD/ST alltid fungerar...
Probemet är ju att det *enbart* är LD/ST som fungerar (i vissa fall)...
> Det man kan notera är att ju mer avancerade PIC blir destå mer lika AVR
> och även andra processorer blir de i sin uppbyggnad.
Som tur är behåller de sin rena/raka arkitektur där "allt kan göras med allt".
Och de undviker ju att kopiera den splittrade minnesarkitekturen.
Visst, för den som är uppfostrad med större datorer så kanske AVR'en arkitektur känns
"normal", men den är inte speciellt snygg och inte det smidigaste för en mikrokontroller.
Men som sagt, det kanske i alla fall känns som en "dator"...
Re: Register eller RAM
> Nu så gäller ju diskutionen mikrokontrollers där allt ligger i samma "chip" och
> där (som du sa tidigare) gränsdragningen är hårfin mellan "register" och "RAM".
Jo så är det ju, och särskilt på en liten PIC är ju hela RAM:et "nära" kärnan, men tar man en lite större och snabbare mikrokontroller som t.ex. följande ARM från ST:
så är ju minnet relativt stort, och kan till skillnad från processorregistren dessutom styras från DMA-styrenheterna så det börjar samlas upp en del fördröjning där. Det finns också ett mindre RAM-minne (som kan göras batteribackat separat från huvudminnet om jag inte minns fel) ännu längre bort från kärnan. Det finns också stöd för externt minne i vissa modeller.
Minnesaccesser till internt huvud-RAM och Flash kan visserligen göras på en cykel utan wait-states, men tar man t.ex. additionsinstruktionen som också tar endast en klockcykel som exempel så kan den använda upp till tre olika register (två källor och en destination) för beräkningen i samma klockcykel. Detta åstadkoms genom att registerfilen är kopplad till ALU:n med tre separata (men visserligen enkelriktade) bussar på följande sätt:
Att lyckas med något liknande över hela RAM-minnet vore nog omöjligt eller åtminstone väldigt opraktiskt. Att registerfilen är relativt liten gör det ju möjligt att göra den snabb och att förse den med många separata datavägar till andra delar av kärnan utan att det blir alldeles för utrymmeskrävande. PIC:en kräver väl minst 4 klockcykler per instruktion så den har ju tid att använda minnet flera gånger, men det kräver ju då också att hela minnet är snabbt i förhållande till den önskade instruktionsexekveringshastigheten.
> Och? Ytterligare en skit-arkitektur...
Ja det är ju inte lite trolleri de moderna x86-processorerna måste göra för att få bra prestanda med den instruktionsuppsättning de har...
Bilagorna kommer från:
http://www.arm.com/files/pdf/CortexM3_Uni_Intro.pdf
http://www.st.com/web/en/resource/techn ... 191185.pdf
> där (som du sa tidigare) gränsdragningen är hårfin mellan "register" och "RAM".
Jo så är det ju, och särskilt på en liten PIC är ju hela RAM:et "nära" kärnan, men tar man en lite större och snabbare mikrokontroller som t.ex. följande ARM från ST:
så är ju minnet relativt stort, och kan till skillnad från processorregistren dessutom styras från DMA-styrenheterna så det börjar samlas upp en del fördröjning där. Det finns också ett mindre RAM-minne (som kan göras batteribackat separat från huvudminnet om jag inte minns fel) ännu längre bort från kärnan. Det finns också stöd för externt minne i vissa modeller.
Minnesaccesser till internt huvud-RAM och Flash kan visserligen göras på en cykel utan wait-states, men tar man t.ex. additionsinstruktionen som också tar endast en klockcykel som exempel så kan den använda upp till tre olika register (två källor och en destination) för beräkningen i samma klockcykel. Detta åstadkoms genom att registerfilen är kopplad till ALU:n med tre separata (men visserligen enkelriktade) bussar på följande sätt:
Att lyckas med något liknande över hela RAM-minnet vore nog omöjligt eller åtminstone väldigt opraktiskt.
Att registerfilen är relativt liten gör det ju möjligt att göra den snabb och att förse den med många separata datavägar till andra delar av kärnan utan att det blir alldeles för utrymmeskrävande. PIC:en kräver väl minst 4 klockcykler per instruktion så den har ju tid att använda minnet flera gånger, men det kräver ju då också att hela minnet är snabbt i förhållande till den önskade instruktionsexekveringshastigheten.> Och?
Ytterligare en skit-arkitektur... Ja det är ju inte lite trolleri de moderna x86-processorerna måste göra för att få bra prestanda med den instruktionsuppsättning de har...
Bilagorna kommer från:
http://www.arm.com/files/pdf/CortexM3_Uni_Intro.pdf
http://www.st.com/web/en/resource/techn ... 191185.pdf
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: Register eller RAM
Absolut! Snackar vi ARM så är det ju en helt annan sak. Eller PIC32 eller
vilken liknande (eller "större") arkitektur som helst. Men nu så var det
ju (väl?) inte det. Om det nu inte var en rent allmän tråd om hur man
använder "register" kontra "RAM" bäst. Den frågan är rellevant för AVR
men inte för PIC16/18.
> och särskilt på en liten PIC är ju hela RAM:et "nära" kärnan,
Eller en "liten" AVR (vad nu "liten" är)...
vilken liknande (eller "större") arkitektur som helst. Men nu så var det
ju (väl?) inte det. Om det nu inte var en rent allmän tråd om hur man
använder "register" kontra "RAM" bäst. Den frågan är rellevant för AVR
men inte för PIC16/18.
> och särskilt på en liten PIC är ju hela RAM:et "nära" kärnan,
Eller en "liten" AVR (vad nu "liten" är)...
Re: Register eller RAM
Att nåt ligger på samma chip som själva processorkärnan är inte samma sak som att det ligger I processorkärnan.
Det ena är fysisk placering, det andra är var det finns i arkitekturen och hur det adresseras.
Skillnaden mellan AVR och PIC när det gäller att jobba mot RAM är ju obefintlig när det gäller vad processorn gör. Skillnaden är hur man skriver koden, på AVR måste man i de lägena "manuellt" säga till processorn att hämta från RAM och lagra till RAM.
PIC kör alltså alla instruktioner som read-modify-write, på AVR måste man göra read och write "manuellt" i de fall man behöver det (men om man bara jobbar med register, t.ex. i en loop, så kan man skippa read och write).
Det ena är fysisk placering, det andra är var det finns i arkitekturen och hur det adresseras.
Skillnaden mellan AVR och PIC när det gäller att jobba mot RAM är ju obefintlig när det gäller vad processorn gör. Skillnaden är hur man skriver koden, på AVR måste man i de lägena "manuellt" säga till processorn att hämta från RAM och lagra till RAM.
PIC kör alltså alla instruktioner som read-modify-write, på AVR måste man göra read och write "manuellt" i de fall man behöver det (men om man bara jobbar med register, t.ex. i en loop, så kan man skippa read och write).
Re: Register eller RAM
> PIC kör alltså alla instruktioner som read-modify-write,
Nej. Bara de instruktioner som gör det...
T.ex "set/clear bit", dec/inc och liknande.
> ...men om man bara jobbar med register, t.ex. i en loop, så kan man skippa read och write.
RMW görs i alla alla fall av t.ex en bit- eller logisk operation. Om man gör en OR mot
ett register måste hela registret läsas, OR'en utföras och resultatet skrivas tillbaka.
Alltså inte med separata instruktioner utan "under huven", så att säga.
> Skillnaden mellan AVR och PIC när det gäller att jobba mot RAM är ju obefintlig när det gäller vad processorn gör.
Lite svårtolkat vad du menar. En PIC(16) har ju inget "RAM" där man (som på AVR) *endast*
kan göra load/store. Så skillnaden är ju väldigt stor istället. Som jag sa tidigare, det är lite
som om en AVR hade register r0 - r1023 istället där *alla* instruktioner fungerar mot allt.
Nej. Bara de instruktioner som gör det...
T.ex "set/clear bit", dec/inc och liknande.
> ...men om man bara jobbar med register, t.ex. i en loop, så kan man skippa read och write.
RMW görs i alla alla fall av t.ex en bit- eller logisk operation. Om man gör en OR mot
ett register måste hela registret läsas, OR'en utföras och resultatet skrivas tillbaka.
Alltså inte med separata instruktioner utan "under huven", så att säga.
> Skillnaden mellan AVR och PIC när det gäller att jobba mot RAM är ju obefintlig när det gäller vad processorn gör.
Lite svårtolkat vad du menar. En PIC(16) har ju inget "RAM" där man (som på AVR) *endast*
kan göra load/store. Så skillnaden är ju väldigt stor istället. Som jag sa tidigare, det är lite
som om en AVR hade register r0 - r1023 istället där *alla* instruktioner fungerar mot allt.
Re: Register eller RAM
Jag får göra en pedagogisk förklaring, vi tar addition av två variabler till en tredje enligt ditt tidigare exempel
Även om vi tar den kortare PIC-koden från ditt exempel så händer samma saker:
Visst, det blir mindre att skriva på PIC, för just det exemplet. Men ta mitt exempel med loopen istället (från början av den här tråden).
Kod: Markera allt
AVR PIC Vad händer?
=====================================================================
LOAD r1-ram r1 MOVF r1, W Data läses från RAM
LOAD r2-ram r2 ADDWF r2, W Data läses från RAM
r3=r2+r1 (i samma instruktion) En addition genomförs i ALU
STORE r3 r3-ram MOVWF r3 Data lagras i RAM
Kod: Markera allt
AVR PIC Vad händer?
=====================================================================
LOAD r1-ram r1 MOVF r1, W Data läses från RAM
LOAD r2-ram r2 ADDWF r2, F Data läses från RAM
r3=r2+r1 (i samma instruktion) En addition genomförs i ALU
STORE r3 r3-ram (i samma instruktion) Data lagras i RAM
Re: Register eller RAM
Det andra exemplet ska ju vara r2=r2+r1, det blev lite fel när jag kopierade...
Jag här inte helt med på vad detta "förklarar" som har med ditt
föra inlägg om read-modify-write att göra. Jag förstår fullt skillnaderna
mellan AVR'ens (mer traditionella) arkitektur och den som PIC har valt.
Och jag menar att register/RAM uppdelningen är lite klumpigare
när det gäller så små "datorer" som dessa processorer utgör.
Och igen, min poäng är fortfarande att PIC'en kan göra detta
(t.ex en ADD) mot hela 1024 bytes minnet. Man behöver inte
flytta *allt* som ska (t.ex) adderas till "register" först.
Jag här inte helt med på vad detta "förklarar" som har med ditt
föra inlägg om read-modify-write att göra. Jag förstår fullt skillnaderna
mellan AVR'ens (mer traditionella) arkitektur och den som PIC har valt.
Och jag menar att register/RAM uppdelningen är lite klumpigare
när det gäller så små "datorer" som dessa processorer utgör.
Och igen, min poäng är fortfarande att PIC'en kan göra detta
(t.ex en ADD) mot hela 1024 bytes minnet. Man behöver inte
flytta *allt* som ska (t.ex) adderas till "register" först.
