Fråga om GPR som pekar mellan banker

[sodjan]

Ja, för enkla register operationer (inte hantering av buffertar eller liknande)
så finns det ingen anledning att gå via FSR, helt rätt.

> ...eftersom FSR är tänkt att fungera som stackpekare.

"Stack" är ett begrepp som man kanske inte ska blanda in här.
Tala hellre om "buffert" eller "array" eller liknande.

> BANKSEL tar antingen 0 eller 1 instruktion, beroende på vad BSR pekar på.

BANKSEL har inte en susning om vad BSR pekar på, den sätter alltid bankbitarna
även om de i praktiken blir oförändrade. BANKSEL genererar alltid de rätta
instruktionerna för att byta till rätt bank enligt parametern till BANKSEL (vilket
så klart alltid är en adress, om än symbolisk).

> För att läsa/Skriva en IO-Port med FSR...

Ja, just det är *alltid* helt fel...

Men, nu så verkar det som att det handlar om en hypotetiskt arkitektur
och då spelar det ju ingen roll hur det faktiskt fungerar.

> Om man inte är "expert" på en "modern PIC-arkitektur" tror jag man har mycket att vinna på att programmera i C.

Rimligt moderna modeller kan mycket väl programmeras i C.
Bortsett från det så är det ändå aldrig fel att kunna det man håller på med...

[lillahuset]

Nej jag brukar läsa assembler, både för att lära mig något och för att ha lite koll på vad kompilatorn ställer till med.
Det känns ungefär lika viktigt som att kolla nätlistor i caden.

Lita inte på era verktyg!

[TomasL]

Att tillägga, gällande FSR.
Som jag skrev tidigare är FSR tänkt att användas som stackpekare, därför finns det ett antal specialfunktioner kopplade till just INDF/FSR, där FSR auto-incrementeras eller decrementeras vid användande av INDF.

Detta används normalt av C-kompilatorer, som alltid använder en stack för att lagra lokala variabler mm vid funktionsanrop.

Du kan naturligtvis använda dig av INDF/FSR, men jag tror ärligt talat att du krånglar till det för dig, mer än nödvändigt.

En sak med INDF/FSR som kan vara användbart är att läsa (dvs kopiera) tabeller lagrade i programminnet, då kan den automatiska inkrementeringen/decrementeringen vara praktisk., ä andra sidan, eftersom den processor ändå har så lite minne, så är det knappast en bra ide att kopiera över tabeller från ROM till RAM.

[TomasL]

BANKSEL har inte en susning om vad BSR pekar på, den sätter alltid bankbitarna
även om de i praktiken blir oförändrade. BANKSEL genererar alltid de rätta
instruktionerna för att byta till rätt bank enligt parametern till BANKSEL (vilket
så klart alltid är en adress, om än symbolisk).

Är du hundra på det, Assemblatorn har naturligtvis hundra koll på vad BSR har för värde, är rätt övertygad om att BANKSEL bara genererar instruktioner för att sätta BSR bara vid behov.

[Erik M]

Skriver man utan bekymmer om tidsaspekt är allting simplare än Assembler. Inget är dock, i något enda fall, bättre.

BANKSEL generar alltid de instruktioner som skulle behövas, även om så ej är fallet.
Vill man undvika den så får man själv hålla reda på att man befinner sig i korrekt bank.
Vilket i sin tur motverkar effektiv, som är vad hela denna diskussion handlar om, kod och exekvering av den.
Om överskottet sedan följer med över till HEX-filen låter jag vara osagt (till dess jag vet).

Helt klart är dock att min tanke på macron är riktig.
Sedan får jag se till att den oxå blir rätt.
Antagligen blir det till att skriva en fungerande kompilator, eller vilkendera det nu är...
...och, återigen antagligen, i Basic.
Spännande...

[sodjan]

> Är du hundra på det...

Ja.

> Assemblatorn har naturligtvis hundra koll på vad BSR har för värde.

Nej, den har noll koll.

> är rätt övertygad om att BANKSEL bara genererar instruktioner för att sätta BSR bara vid behov.

Denna ASM kod:

Kod: Markera allt

    movlw 0
    banksel TRISA
    movwf TRISA
    banksel TRISB
    movwf TRISB
    banksel TRISC
    movwf TRISC

skapar denna kod:

Kod: Markera allt

0000   3000           00187     movlw 0
0001   0021           00188     banksel TRISA
0002   008C           00189     movwf TRISA
0003   0021           00190     banksel TRISB
0004   008D           00191     movwf TRISB
0005   0021           00192     banksel TRISC
0006   008E           00193     movwf TRISC

instrutionen 0021 är "MOVLB 1" (Move Literal to BSR, Bank Select Register).

> Som jag skrev tidigare är FSR tänkt att användas som stackpekare.

En stack är *en* tänkbar användning, och det är mycket möjligt att C kompilatorn
använder FSR till det. Men som programmerare är det vanligare med buffrar för
t.ex. seriekommunikation eller liknande.

> En sak med INDF/FSR som kan vara användbart är att läsa (dvs kopiera) tabeller lagrade i programminnet.

Ja, läsa, men kopiera är ju inte alltid nödvändigt. Om tabellerna inte måste kunna ändras.
Det vanliga är nog att man har fasta look-up tabeller som inte ändras.

> ä andra sidan, eftersom den processor ändå har så lite minne, så är det knappast en
> bra ide att kopiera över tabeller från ROM till RAM.

Men det står inte i något motsatsförhållande till att använda FSR, så klart.

[sodjan]

> Om överskottet sedan följer med över till HEX-filen låter jag vara osagt (till dess jag vet).

Självklart gör det det.

> Helt klart är dock att min tanke på macron är riktig.

Lite oklart vilken "tanken" är här, men macron har så klart sitt
användningsområde, man får som sagt bara se upp med ett par
hakar med det, speciellt tillsammans med "skip" instruktionerna.

[Erik M]

HexMacro.inc skulle innehålla saker som ser ut såhär:

Set_TRISIO2 MACRO
1683h; BANKSEL. TRISIO
1505h; BSF TRISIO, TRISIO2
ENDM

Möjligen till och med:

Set_TRISIO2 MACRO
16831505h
ENDM

Eller helt enkelt:

Set_TRISIO2 equ 16831505h


Men redan...

Set_TRISIO2 equ 1505h
(BSF TRISIO, TRISIO2)

...är värt besväret.
(Just Set_TRISIO2 kan ju skrivas kortare, annorlunda etc.)

Åtminstone just nu och preliminärt.
Ovan använder jag PIC12F683.
(Mindre att bläddra i...)

Vi får se hur det blir...

[sodjan]

Hur skulle t.ex. "Set_TRISIO2 equ 1505h" sedan användas i koden?

[Swech]

Det normala är att man går över till C för att koden skall bli lättare att förstå / läsa.
Om man kör i assembler vilket jag själv gör till 100% så tar man till alla knep för
att få det hela mer lättläst och möjligt till att förstå.
Interessant att följa Ts sätt att få kod att bli mer svårbegriplig och jag har
fortfarande inte genomskådat vad syftet är... är det för att minska kodstorleken?

Swech

[sodjan]

Macron kan kanske minska storleken på *käll-* koden, men efter
assemblering blir det inte någon skillnad. Källkoden kan även
bli lite enklare att läsa, beroende på vad man gör.

För processorn spelar det igen roll om man använder macron eller inte.

[Erik M]

Källkoden förändras inte.

Vad som används som exempel visar inte hur det ser ut vid användande.
Exempelvis används Clear_TRISIO5 för att tydligt visa vad för funktion som avses.
I verkligheten att den troligen mer ut i stil med cTRI5.

Att gå över till, och därmed lägga till ännu fler felkällor, C, eller annat, är inte aktuellt.

Som sagt - vi får se vad, om alls, det blir något med detta.

Sedan kommer man ganska långt med hjälp av #define, även om den är begränsad.

[sodjan]

Källkoden ändras på två sätt. Först när man byter ut den gamla
koden till anropet av macrot. Sedan då MPASM byter tillbaka till
koden som macrot innehåller innan det assembleras.

I slutänden, om macrot innehåller exakt det som man hade skrivit
utan macrot, så blir det ingen skillnad, om det det som du menade.