Du skall inte heller göra hemmasnickrade fördröjningar på det sättet.
Det finns timers inbyggda i processorn som är mycket bättre till detta.
Swech
PIC, varför inte... går det....?
Re: PIC, varför inte... går det....?
I just detta fallet hoppar vi över Call.
Och läser jag databladen rätt så är en skip-if alltid två.
Antingen testet och instruktionen eller testet och en nop.
Vilket borde betyda att test-hoppa, som blir av, blir... tre...?
Och blir den inte av... två.
Swech ~ Det är ingen fördröjning.
Det är en hårt hållen interupt.
Och läser jag databladen rätt så är en skip-if alltid två.
Antingen testet och instruktionen eller testet och en nop.
Vilket borde betyda att test-hoppa, som blir av, blir... tre...?
Och blir den inte av... två.
Swech ~ Det är ingen fördröjning.
Det är en hårt hållen interupt.
Re: PIC, varför inte... går det....?
OK, något sådant här då?
Delay:
btfss LsenT - ger alltid två, test och nästa eller test och nop - 1&2
call doLeft - händer sällan, så försvinner in i nop ovan - 0
btfss RsenT - ger alltid två, test och nästa eller test och nop - 3&4
call doRight - händer sällan, så försvinner in i nop ovan - 0
decfsz DC1 - ger alltid två, test och nästa eller test och nop - 5
goto Delay - händer nästan alltid, så två härifrån - 6&7
decfsz DC2 - ger alltid två, test och nästa eller test och nop - 8
goto Delay - händer nästan alltid, så två härifrån - 9&10
Delay:
btfss LsenT - ger alltid två, test och nästa eller test och nop - 1&2
call doLeft - händer sällan, så försvinner in i nop ovan - 0
btfss RsenT - ger alltid två, test och nästa eller test och nop - 3&4
call doRight - händer sällan, så försvinner in i nop ovan - 0
decfsz DC1 - ger alltid två, test och nästa eller test och nop - 5
goto Delay - händer nästan alltid, så två härifrån - 6&7
decfsz DC2 - ger alltid två, test och nästa eller test och nop - 8
goto Delay - händer nästan alltid, så två härifrån - 9&10
Re: PIC, varför inte... går det....?
> Och läser jag databladen rätt så är en skip-if alltid två.
> Antingen testet och instruktionen eller testet och en nop.
Nej.
Det beror på om "instruktionen eller testet" är en 1 eller 2 cykel instruktion.
> Vilket borde betyda att test-hoppa, som blir av, blir... tre...?
> Och blir den inte av... två.
Ja, men då så, här beskriver du det ju annorlunda.
> Antingen testet och instruktionen eller testet och en nop.
Nej.
Det beror på om "instruktionen eller testet" är en 1 eller 2 cykel instruktion.
> Vilket borde betyda att test-hoppa, som blir av, blir... tre...?
> Och blir den inte av... två.
Ja, men då så, här beskriver du det ju annorlunda.
Re: PIC, varför inte... går det....?
Jag läser, lyssnar, läser, frågar, lyssnar, läser...
...åsså igen. Mest på vad just du skriver.
För även om vi kommunicerar på olika vis så fungerar bryggor och trappor mellan oss.
Vilket är väldigt trevligt.
I detta fallet är det kombinationen test och kliv som beskrivits lite olika.
Test med kliv ger 1+2=3.
Test utan kliv ger 2+0=2
Det var det där med antingen nästa instruktion ELLER nop som ställde till det.
...åsså igen. Mest på vad just du skriver.
För även om vi kommunicerar på olika vis så fungerar bryggor och trappor mellan oss.
Vilket är väldigt trevligt.
I detta fallet är det kombinationen test och kliv som beskrivits lite olika.
Test med kliv ger 1+2=3.
Test utan kliv ger 2+0=2
Det var det där med antingen nästa instruktion ELLER nop som ställde till det.
Re: PIC, varför inte... går det....?
Ja, det där låter OK... 
Och om det *inte* är en "andra instruktion" som ändrar
programräknaren (GOTO, CALL o.s.v) så blir det:
Test med kliv ger 1+1=2.
Test utan kliv ger 2+0=2
Men det är nog ganska vanligt att man har just en GOTO
efter "skip" instruktionerna.
Och om det *inte* är en "andra instruktion" som ändrar
programräknaren (GOTO, CALL o.s.v) så blir det:
Test med kliv ger 1+1=2.
Test utan kliv ger 2+0=2
Men det är nog ganska vanligt att man har just en GOTO
efter "skip" instruktionerna.
Re: PIC, varför inte... går det....?
Låt oss bestämma vad för bit kod vi pratar om:
btfss [file register bit]
goto [address label]
btfss med användande av efterföljande goto ger 1+0+2=3.
btfss utan att använda efterföljande goto ger 1+1+0=2
Vad jag verkligen saknar är motsvarande btfss/btfsc för decsz/incsz...
...något typ decsi/incsi, dvs skip if integer (heltal större än noll).
(Ja och jo, jag vet - noll är en integer. Hoppa.)
btfss [file register bit]
goto [address label]
btfss med användande av efterföljande goto ger 1+0+2=3.
btfss utan att använda efterföljande goto ger 1+1+0=2
Vad jag verkligen saknar är motsvarande btfss/btfsc för decsz/incsz...
...något typ decsi/incsi, dvs skip if integer (heltal större än noll).
(Ja och jo, jag vet - noll är en integer. Hoppa.)
Re: PIC, varför inte... går det....?
Det handlar ju om hur en processor är uppbyggd. Ska du jämföra med ett tal så behöver du en binär komparator. Men det är då enklare att använda ALU för det, d.v.s. man gör en subtraktion för att få reda på a är större eller mindre än b. ALU har flaggor för Zero, Carry och lite sånt som branch-instruktionerna använder.Erik M skrev: Vad jag verkligen saknar är motsvarande btfss/btfsc för decsz/incsz...
...något typ decsi/incsi, dvs skip if integer (heltal större än noll).
Re: PIC, varför inte... går det....?
Korrekt Nerre...
...vilket inte ändrar önskan.
Men tänker man i termer av en dubbel totem negation, då fungerar det.
Något i stil med decsnz - decrement (and) skip (if) not zero.
Att göra detta med kod är i det närmaste omöjligt då man inte kan jämföra ett File Register i sig mot något annat.
Man kan bara jämföra bitarna individuellt.
Jag har för mig jag sett XOR användas till att kolla om något är noll, men hittar inte igen det.
Men även om XOR ger ett Z på noll så går det ju inte att verifiera förrän man kollat varje bit av Z... Rätt?
Hm... Kan det vara så att man kollar carry bit istället? Med XOR då alltså.
Om jag nu alls förstått rätt...
...vilket inte ändrar önskan.
Men tänker man i termer av en dubbel totem negation, då fungerar det.
Något i stil med decsnz - decrement (and) skip (if) not zero.
Att göra detta med kod är i det närmaste omöjligt då man inte kan jämföra ett File Register i sig mot något annat.
Man kan bara jämföra bitarna individuellt.
Jag har för mig jag sett XOR användas till att kolla om något är noll, men hittar inte igen det.
Men även om XOR ger ett Z på noll så går det ju inte att verifiera förrän man kollat varje bit av Z... Rätt?
Hm... Kan det vara så att man kollar carry bit istället? Med XOR då alltså.
Om jag nu alls förstått rätt...
Senast redigerad av Erik M 21 april 2015, 13:23:21, redigerad totalt 1 gång.
Re: PIC, varför inte... går det....?
Assembler är ett lågnivåspråk, då är varje instruktion av naturen enkel av sig. För att uppnå det du vill får du helt enkelt lägga in en subtraktion före. Eller använda ett högnivåspråk.
Re: PIC, varför inte... går det....?
Jo Nerre,
Det är bara det att sz (skip if zero) har någon form av inbyggd reduktion av de åtta bitarna.
För att se om man kommit till noll.
Samma reduktion har då oxå, per deduktion, svar på frågan att man inte ännu nått noll.
Så funktionen i sig finns där ju redan...
Nu får man istället använda en dubbel GOTO.
Där den första endast existerar för att kliva över den andra...
Det är bara det att sz (skip if zero) har någon form av inbyggd reduktion av de åtta bitarna.
För att se om man kommit till noll.
Samma reduktion har då oxå, per deduktion, svar på frågan att man inte ännu nått noll.
Så funktionen i sig finns där ju redan...
Nu får man istället använda en dubbel GOTO.
Där den första endast existerar för att kliva över den andra...
Re: PIC, varför inte... går det....?
Att kolla om en byte är noll är enkelt: En 8-ingångars OR-grind.
Nu är jag inte helt insatt i PICens hoppinstruktioner, men i de flesta sammanhang brukar såna där villkorliga hopp just baseras på ett ALU-resultat. Men det går som sagt var också att använda en 8-ingångars OR-grind för att kolla zero.
Edit:
En annan aspekt är att antalet OP-koder är begränsat, det innebär att man kanske inte har utrymme för alla instruktioner man skulle vilja ha. Då får man rationalisera och eliminera instruktioner som inte används så frekvent och kanske kan ersättas av andra eller en sekvens av andra instruktioner.
Nu är jag inte helt insatt i PICens hoppinstruktioner, men i de flesta sammanhang brukar såna där villkorliga hopp just baseras på ett ALU-resultat. Men det går som sagt var också att använda en 8-ingångars OR-grind för att kolla zero.
Edit:
En annan aspekt är att antalet OP-koder är begränsat, det innebär att man kanske inte har utrymme för alla instruktioner man skulle vilja ha. Då får man rationalisera och eliminera instruktioner som inte används så frekvent och kanske kan ersättas av andra eller en sekvens av andra instruktioner.
Re: PIC, varför inte... går det....?
> Ska du jämföra med ett tal så behöver du en binär komparator.
Nu handlade du ju bara om ifall det är <> 0 eller = 0.
"Integer" har ingenting med detta att göra...
Och eftersom "skip if zero" är impementerat så hade det (som Eric säger)
varit lika enkelt att implentera "skip if not zero", så klart. Nu så är det inte
det och det är inte mer med det.
Det man kan göra är att kolla Z flaggen själv istället, alltså istället för:
så gör man något i stil med:
Nu handlade du ju bara om ifall det är <> 0 eller = 0.
"Integer" har ingenting med detta att göra...
Och eftersom "skip if zero" är impementerat så hade det (som Eric säger)
varit lika enkelt att implentera "skip if not zero", så klart. Nu så är det inte
det och det är inte mer med det.
Det man kan göra är att kolla Z flaggen själv istället, alltså istället för:
Kod: Markera allt
decfsz DC2
goto Delay ; Körs om DC2 <> 0Kod: Markera allt
decf DC2
btfsc status, z
goto Delay ; Körs om DC2 = 0
