Svenska ElektronikForumet

Fortsättning från tråden http://elektronikforumet.com/forum/view ... 13&t=70073

sodjan skrev "Tillkommer load/store av datat från/till "RAM"."

Men det gör det ju bara om de variablerna _måste_ sparas i RAM, och då faller ju dessutom finessen med att "inte modifiera" bort. Om de inte behöver sparas i RAM (för att registren räcker) så tillkommer ju ingen läsning/skrivning.

Jag kör ett exempel med "basic-syntax":
r1 och r2 behöver inte lagras i RAM eftersom när looparna är klara kan de variablerna förkastas. Inge läsning från eller skrivning till RAM behövs för looparna eller beräkningen (möjligen kan det krävas i "gör nåt"-grejen, men den ligger ju utanför diskussionen).

Nu petade jag in en multiplikation där men den var bara för att få ett mer konkret exempel. Valde 8 för att kunna göra den med skift om vi behöver skriva "riktig" kod. En sån loop är väl ganska typisk för att t.ex. mata ut en "buffert" till en display eller liknande?

Om det ska skrivas kodexempel så kan man väl få göra om det till:

r4=r1*8
r4=r4+r2

eftersom r4 inte behöver sparas mellan varven.

Och var ligger r1-4?
I molnet? Eller i RAM?

r1-r4 är register...

> Om de inte behöver sparas i RAM (för att registren räcker) så tillkommer ju ingen läsning/skrivning.

Det är ju som att köra en processormodell med enbart 32 bytes minne (oavsett vad det kallas)
Hur ska man kunna jämföra det med en processor med 512 eller 1024 bytes minne?
Om man inte tar med i bilden att "variablerna" kan ligga var som helst,
så blir det en lite begränsad "test".

För en PIC är det lite samma sak som att enbart köra med "unbanked" memory,
eftersom man du slipper att ladda bankregistret. 16 bytes på 16F1xxx serien.

Den stora skillnaden är som sagt att man på en PIC16F1938 kan göra allt mot
hela 1024 bytes minnet, inte enbart LD/ST som på en AVR. Det är lite som om
en AVR hade 1024 "register" r0 - r1023 där alla bit/arit/log instruktioner fungerar.

Säg att du i en applikation har 256 räknare som man ibland vill räkna ner.
På en PIC gör man DECF direkt mot räknarna (gärna indexerat om man vill
svepa över alla i en loop), på en AVR blir det LD/DEC/ST mot var och en
eftersom DEC inte fungerar mot "Data space". Den som är van vid det
upplever det kanske inte som konstigt.

Självklart fungerar inte detta när minnesstorlekarna växer, PIC24 har en "register file"
mer likt större arkitekturer. Men på PIC16 fungerar minnes arkitekturen väldigt bra.

Jag har inte sagt att man aldrig ska spara variabler i RAM, jag har sagt att det ger fördelar att INTE BEHÖVA spara alla variabler i RAM.

Att ha variabler i register går snabbare och gör det enklare att utveckla rekursiva funktioner (registren pushas enkelt på stacken), nackdelen är att om man kodar manuellt blir det lite jobbigare att hålla reda på vilka register som är "lediga". Men om man lägger alla variabler i RAM så kommer man att få samma nackdel: om du INTE håller reda på hur länge en variabel är "giltig" så kommer du att använda mer RAM än du behöver (eftersom utrymmet är reserverat för variabeln även när det inte behövs).

> ...jag har sagt att det ger fördelar att INTE BEHÖVA spara alla variabler i RAM.

Ja, då fungerar det i princip som på en PIC, det är klart det ger fördelar.
Men då har bara 16/32 (de är inte helt lika) register istället för alla 1024 bytes.

Det är just det där tänket att "spara variabler" som inte finns i PIC. Kan vara
svårt att föstå om man är inkörd på det kanske.

Dessutom behöver du tänka på och ta hänsyn till skillnaden mellan "Register File",
"I/O memory" och "Data Space". Vilka instruktioner som fungerar mot vad (for
Register File är det dessutom uppdelat på de 16 låga resp 16 höga). En PIC har
enbart en stor (vad som skulle kunna kallas) Register File där allt ligger inkl alla
kontrollregister och vanliga register. Det är exakt samma instruktioner för allt.

Det är också bl.a därför som en Mega har 131 instruktioner och en PIC 49, AVR'en
har så mycket dubblerat. T.ex "Data Transfer Instructions" är 10-12 instruktioner
beroende på vad det gäller för "minne" medan en PIC gör motsvarande med 2.

Men snälla nån, även en processor med register kan ju komma åt RAM.

Man använder register så mycket det går, för det går fortare och och är effektivare, sen använder man RAM för sånt som inte får plats i registren.

Det är samma sak som att man i en vanlig dator i första hand använder RAM, men räcker inte RAM till får man spara ner på disk.


Sen att AVR har olika instruktioner beroende på vilken del av adressrymden man accessar är ju en helt annan sak. Det har ju inte direkt att göra med att den har många register.

Jag gissar att det handlar om att man velat eliminera behovet av mikrokod och att processorn primärt är avsedd att få sin kod skriven av en kompilator (som automatiskt fixar att det är rätt instruktion).

Jag diskuterar inte instruktionsuppsättning här, jag diskuterar variabler i register kontra variabler i RAM.

Du väljer ett område att diskutera som passar dig men som i sig är ganska ointressant.

> Man använder register så mycket det går, för det går fortare och och är effektivare,
> sen använder man RAM för sånt som inte får plats i registren.

Och jag säger att det där är AVR-specifikt. Och då är det ju att sparka
in öppna dörrar, det är ju självklart att man gör så på en AVR, har någon
sagt något annat? Man *måste* ju göra det på en AVR (vilket är just
min poäng i det hela!).

Och du medger alltså inte att det hade varit bättre om du hade haft 1024
"register" som hade kunnat användas "fortare och effektivare" ?
Då slipper du ju hela hanteringen mellan dina register och RAM.

> Det är samma sak som att man i en vanlig dator i första hand använder RAM,
> men räcker inte RAM till får man spara ner på disk.

Även en "vanlig dator" har register i processorn. Ingen skillnad mot (t.ex) AVR.

> Jag diskuterar inte instruktionsuppsättning här, jag diskuterar variabler i register kontra variabler i RAM.

Det hänger ihop. Och det senare är ju ointressant och ganska självklart. Om man nu
ändå har en arkitektur med uppdelning mellan olika minnestyper (typ AVR) så är det ju
självklart att man får/kan (och ibland måste) optimera användningen av dom. Eller i
alla fall tänka på att det är uppdelat. Har man inte det så slipper man det. Det är allt.

Men OK, jag hade missförstått tråden från början. Det du vill diskutera är
inte rellevant för PIC eftersom "problemet" inte finns där. Helt OK.

Det verkar vara du som har tappat spåret:)

Såvitt jag vet är det du som menar att det är bättre att jobba direkt mot RAM än med register (men jag kanske har missuppfattat dig totalt?).

Jag säger att det enda som möjligen är bättre är att det är enklare med adressering, men det är långsammare OCH mindre flexibelt.

Att det går fortare och är effektivare med register är inget för bara AVR: ett register sitter I processorn, det adresseras i princip genom att sätta en bit i processorns kontrollregister hög. Det gör att register kan adresseras inom en och samma klockcykel. På en PIC tar en instruktionscykel 4 klockcykler: Avkodkning, hämtning, bearbetning, lagring. På en AVR tar en instruktionscykel 1 klockcykel, dock tar RAM-access två instruktionscykler.

Om vi tittar på dina exempel från andra tråden:

AVR:
LOAD r1-ram r1
LOAD r2-ram r2
r3=r2+r1
STORE r3 r3-ram

Det tar sju klockcykler.

PIC:
MOVF r1, W
ADDWF r2, W
MOVWF r3

Tar 12 klockcykler.

För r2=r2+r1 är det enklare:
MOVF r1, W
ADDWF r2, F

Tar 8 klockcykler.

Så visst hade det varit bättre med 1024 register, OM de hade gått lika snabbt att accessa som RAM. Men poängen är att de gör inte det.


Just detta att AVR bara tar en klockcykel per instruktion är väl också anledningen till att den har flera instruktioner, men som sagt var, instruktionsuppsättningen är inte riktigt relevant.

För att accessa RAM så är det nästintill omöjligt att undvika att det behövs flera klockcykler. Adressen måste ut på bussen, minnets datautgångar måste aktiveras, sen ska processorns dataingångar latcha in datat. Och omvänt vid skrivning, adressen ska ut på bussen, processorns datautgångar latcha ut datat och sen ska det latchas in i minnet. Detta oavsett om det görs med en eller fem instruktioner.


Den här artikeln handlar visserligen inte om mikrocontrollers, men den tar ganska bra upp varför man behöver både register och RAM och varför man har cache på moderna processorer.

https://www.mikeash.com/pyblog/friday-q ... -slow.html

> (men jag kanske har missuppfattat dig totalt?).

Kanske...

> Såvitt jag vet är det du som menar att det är bättre att jobba direkt mot RAM än med register...

Nej, det säger jag inte. Och det är dessutom bara semantik...

Du är också fast i AVR-tänket där "RAM" är något "utanför" processorn som
med nödvändighet är långsammare än "register". Släpp det!

Om man har den uppdelade arkitekturen som i AVR, så har du ju helt rätt, så klart!
Om man har den "renare" arkitekturen i t.ex en PIC så är ju frågan inte rellevant.

> På en PIC tar en instruktionscykel 4 klockcykler: Avkodkning, hämtning, bearbetning,
> lagring. På en AVR tar en instruktionscykel 1 klockcykel...

Helt rätt, men det har med med andra saker att göra, inte med uppdelningen av minnet
i olika "slags" minne.

> men det är långsammare OCH mindre flexibelt.

Hastigheten beror på helt andra saker och hur 17 kan det vara mer "flexiblet"
att behöva hålla reda på "Register File", "I/O memory" och "Data Space" istället
för ett gemensamt addressområde som innehåller allt och som hanteras på en
gemensamt sätt med samma instruktioner? På en PIC finns det 1024 register
där du kan göra bit set/clear/test, på en AVR finns det 32 (eller 16?), hur
kan det vara mer flexibelt? Spontant känns det begränsande.



> Den här artikeln handlar visserligen inte om mikrocontrollers,
> Why Registers Are Fast and RAM Is Slow...

Exakt, och en PIC har enbart "register" och inget "RAM"...
(Semantik igen...)

Att de sen har olika lösningar för sina interna klockor är en helt annan sak
och har inte direkt med tråden att göra. Jag har aldrig sagt att en PIC alltid
är snabbare, bara att arkiteikturen är renare/rakare och mer konsekvent.

Du läste inte sidan jag länkade till?

Ett register adresserar man genom att sätt en bit hög (detta görs av instruktionsavkodningen).

RAM adresserar man genom att först lägga ut en adress på adressbussen, sen öppna två latchar i tur och ordning (beroende på om man ska läsa eller skriva). Det går inte att komma undan att det kräver flera "steg".

Detta gäller normal alla processorer, oavsett om det är PIC, AVR, ARM, x86 eller nån annan.


Sen kan RAM finnas på flera nivåer. Jag gjorde mitt exjobb på en TMS320-c80, den har dels internt RAM men kan även accessa externt RAM. Skillnaden är dock att externt RAM tar mycket längre tid att accessa. Men den har även register. Registren var självklart snabbast att jobba med, därefter internt RAM (privat snabbare än delat, den har flera "kärnor" med privat och delat internt RAM) och långsammast var externt RAM.


PIC är konstruerad med få register för att vara billig (det är billigare med RAM än register).

Nerre: en PIC har varje RAM-adress som register! Du är tydligen inte insatt i PIC men det du säger är ganska enkelt fel!
En PIC har en ackumulator samt en massa register med specialfunktioner, om vi låter dom vara därhän är resten av RAM-minnet i en PIC enbart register i den bemärkelse du anser.

EN AVR har du 32(?) register och allt ut över det är RAM, i PIC med t.ex. 1024 BYTE minne är alla 1024 bytes register!

RAM och register är uppbyggda på olika sätt. Att de kan innehålla samma typ av data betyder inte att de är uppbyggda på samma sätt.

Det verkar vara den biten ni har svårt att förstå. Det är anledningen till att man inte tillverkar processorer med 1024 register: Det skulle bli alldeles för dyrt.

Antalet register är alltså en kompromiss mellan hastighet och pris.

Det är också därför man förser processorer med cache, det är snabbare än vanligt RAM men billigare än register.


Varför har en PIC en ackumulator om det inte behövs register? Varför är inte ackumulatorn ersatt av en RAM-adress?

> Du läste inte sidan jag länkade till?

Jag kollade lite snabbt. Skåpmant, inget nytt.
Han verkar vända sig till nybörjare, jag har studerat
datorarkitekturer i 30 år, så inget nytt där.

Ackumulatorn i en PIC är, precis som i AVR, en RAM-byte. I de nyare PIC är den rent faktisk adresserbar!

Och förklara gärna vad skillnaden mellan en RAM-cell och ett register är, jag ser nämligen ingen! Rent faktisk är registerna i en AVR bara ett 32(!) byte RAM-minne som går på egen adress & databuss. Det är inget speciellt med det, ett register håller ett värde, inget annat! Det samma gäller en RAM-byte.

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.

I t.ex Z80 finns det register A, B, C, D, E, H, L, IX, IY, SP & STATUS. Men det finns även A', B', C', D', H', L', IX', IY, SP & STATUS'. Och de växlas med en enda kommando och växlingen sker vid att byta en adressbit i den RAM som håller registerna, inget annat.