PIC16F886 + ASM (asm nybörjarhjälp)

[vfr]

En CBLOCK gör precis det som en struct gör. Definierar fältens position utan att allokera någonting alls. Att man sedan kan få en allokering genom att kombinera structen med olika saker, är något helt annat. Dock inte med en typdef. En typdef allokerar inte heller någonting i sig.

[sodjan]

OK, typdef var fel. Jag menade att definera en variabel m.h.a av structen...

Grejen med en struct är att få en sammanhållande namn/begrepp för en samling
av data som på något sätt just hör samman. Ett CBLOCK gör ingenting för att hålla
samman de olika symbolerna, den bara ser till att de för olika värden. Det finns
inget övergripande namn eller symbol som direkt "pekar" mot ett CBLOCK t.ex.

> En CBLOCK gör precis det som en struct gör.

Nej, det gör den inte. V.v. och rör inte till det.

[bos]

CBLOCK kan närmast jämföras med en "struct" i C.

Jag tror du förväxlar med "enum".

[sodjan]

Ja, enum ligger nog lite närmare "sanningen" än struct.
Men, som sagt, bäst kanske är att inte jämföra med C alls...
Det behövs inte, CBLOCK (och allt annat) är väl beskrivet i dokumentationen.

[net4all]

Ja! Nu fungerar det!
Tack alla än en gång
("Supporten" här går inte att överträffa)

(Hmm, "relocatable mode" är alltså kort förklarat att man låter länkaren/assemblatorn sköta allts som har med adresser att göra?
Tex, variabler och placering av kod?
Så istället för att ge något en specifik adress så säger man oftast bara hur mycket plats det tar och vad det är? )

[bos]

Ja.

[vfr]

Jag tror du förväxlar med "enum".

Absolut inte. Enum har inget med detta att göra. Visserligen räknar den upp, men den har ingen som helst koppling till individuella fältstorlekar.

Liknelsen med struct är inte alls långsökt. Vad en struct ofta gör under ytan, är att definiera lablar för dom olika fälten innehållande offseten till fälten. Dessa används sedan tillsammans med basadressen för structen för att komma åt innehållet i individuella fält. D.v.s precis samma som CBLOCK.

Givetvis finns all dokumentation där den skall vara. Min avsikt med jämförelsen, var att jämföra med något som trådskaparen kände till.

[bos]

Enum har inget med detta att göra. Visserligen räknar den upp, men den har ingen som helst koppling till individuella fältstorlekar.

Och hur har CBLOCK koppling till fältstorlekar?

[vfr]

Den här länken gör en rätt bra jämförelse.

[bos]

TLDR. Jag litar på ditt omdöme.

Själv använder jag aldrig CBLOCK. Helt fel typ av programmeringsmetodik för min del.

[sodjan]

Som sagt, varken struct eller enum är igentligen bra jämförelser.

Det text som det länkades till är ett (ganska krystat) försök
att visa hur man kan åstakomma något som liknar "pointers" från
C i MPASM med hjälp av CBLOCK. Så vitt jag förstår så kan man
skapa samma sak med RES och lite "assembly-time calculations", i
princip på samma sätt som med de visade CBLOCK'en.
Detta gör ju inte CBLOCK *i sig* varken likt struct eller speciellt
lämpat att användas för att ange adresser till variabler.

Och som författaren till exemplen själv säger (ang "pointers") :
"...but they should be avoided unless absolutely necessary in the
PIC microcontroller. With a bit of thought about the application design,
they should not be required at all".

Dessutom föutsätter det länkade exemplet att man kör i "absolut mode",
vilket i sig inte är att rekomendera, och då faller hela exemplet. All ny
kod bör i dag skrivas i "relocatable mode".

> Själv använder jag aldrig CBLOCK. Helt fel typ av programmeringsmetodik för min del.

Jag vet inte vilken "metodik" du har, men jag ser inget problem i att
använda CBLOCK på det sätt det är tänkt, för att skapa ett antal
symboler med olika (stigande) värden, som de felkoder och processtatus
som jag visade i ett tidigare inlägg. Det finns inget bättre sätt att göra just
det än via CBLOCK. För att ange minnesadresser via CBLOCK är dock en
historisk relik som användes "förr i tiden"...