Var är det lämpligt att diskutera .asm kod?

[Icecap]

Det finns en anledning till att man kan välja att flytta bitsen MED eller UTAN Carry, det är just för att kunde shifta värden större än en byte.

[jesse]

Även addition och subtraktion kan man göra med eller utan carry.

Om du förstår hur det här fungerar kommer du att fatta hur carry kan användas.

Ska man bara addera två åttabitars tal så är det addition utan carry som gäller. Men om man adderar större tal som har två eller fler bytes, så behövs carry som minnessiffra från förra additionen. På samma sätt som man en gång lärde sig addera i lågstadiet.

add AL,BL ; // addera tal A-låg byte med tal B-låg-byte.
adc AH,BH ; // addera tal A-hög-byte med tal B-hög byte PLUS CARRY.

höga bytens värde multipliceras med 256. Så talet "tusen" (decimalt) får plats i två bytes genom att man har värdet 3 i höga byten och 232 i den låga byten. 3*256 + 232 = 1000.

Antag att vi ska addera 1000 med 500. Det blir 1500. En åttabitars processor löser problemet med add och adc så här:

AH = 3
AL = 232

BH = 1
BL = 244

ADD AL,BL .... adderar 232 och 244 - det blir 476, men det får inte plats i en byte - det blir stället 220 plus carry. Talet 220 läggs i AL.
ADC AH,BH .... adderar 3 och 1 sant lägger till carry = 1 från förra operationen. Det ger 3+1+1 = 5. Talet 5 läggs i AH.

svaret finns nu i AH:AL = 5*256+220 = 1500.

Lika enkelt är det om man vill addera två 32-bitars tal (= 4 bytes):

ADD A1,B1
ADC A2,B2
ADC A3,B3
ADC A4,B4

klart!

[1802]

Mycket nyttig läsning.

Men jag funderar på vad som händer om man börjar med bin 10000001 och ROL'ar ett antal ggr. Och lagrar i 4 byte eller mer. Blir det rätt när carry bitten kommer farande? I starten är det 6 nollor mellan ettorna. Men om carry är noll, blir det 7 nollor på andra varvet.

[Icecap]

Då du ju vägrar att rita på dina frågor ställer du frågor som är ganska "dimmiga". Du verkar helt klart behöva ta ett steg eller två tillbaka och försöka förstå det binära talsystemet och hur man räknar med det för det är synnerligt tydligt att du inte har det klart för dig.

[Walle]

Varför skulle antalet nollor MELLAN ettorna öka för att du skiftar? Se det så här: de ettor och nollor du har FLYTTAS höger eller vänster, beroende på vilket håll du skiftar. Absolut inget sätts in mitt i ditt tal.

[1802]

Carry bitten dyker ju upp, som en nionde bit. I alla fall här.

[Walle]

Men inte dyker den upp MELLAN de existerande bitarna du skiftar? För då gör du nåt galet..

[jesse]

Mycket nyttig läsning.

Men jag funderar på vad som händer om man börjar med bin 10000001 och ROL'ar ett antal ggr. Och lagrar i 4 byte eller mer. Blir det rätt när carry bitten kommer farande? I starten är det 6 nollor mellan ettorna. Men om carry är noll, blir det 7 nollor på andra varvet.

Det är bara att rita.
bin 1000 0001 = 129 decimalt (d) dvs. ( 128 + 1)

Så här ser det ut om du t.ex. ska shifta två bytes ett steg åt vänster: (multiplicera med två)

Kod: Markera allt

r17(hög) - carry - r16(låg)
7654 3210    C     7654 3210 <-bitnummer (position)
0000 0000    0     1000 0001 <- start
0000 0000    1     0000 0010 <- efter LSL r16
0000 0001    0     0000 0010 <- efter ROL r17

så bit 7 i r16 flyttas först till carry. (och en nolla läggs in i bit 0). sedan flyttas carry till bit 0 i r17 - men den biten kommer ju från bit7 i r16... carry kommer alltså inte "i mellan" - carry är bara "bärare" av den biten som ska flyttas till nästa byte.
resultatet är 0000 0001 0000 0010 bin = 258. (129 * 2 = 258) , så det blir rätt. inga extra "nollor" in i mellan.

ett försök att göra det mer "bildlikt": här skiftar vi två gånger åt vänster:

Kod: Markera allt

r17(hög)     r16(låg)
7654 3210  C  7654 3210 <-bitnummer (position)
------------------------------------
0000 0000  0  1000 0001 <- start = 129 (d)
              |       |
              /       /                 LSL r16
             /       |                  nollan i "carry" försvinner och ersätts med
            /        |                  bit7 i r16 (som råkar vara en etta)
           |         |
0000 0000  1  0000 0010 <- nytt tillstånd
           |         |
           /         |                 ROL r17
          /          |                  ettan i "carry" läggs in i bit0 i r17
         /           |                  
        |            |
0000 0001  0  0000 0010 <- efter ROL r17, nu har vi multiplicerat med två = 258
                     |
                     /                 LSL r16
                    |                  nollan i "carry" försvinner och ersätts med
                    |                  bit7 i r16 (som råkar vara en etta)
                    |
0000 0001  0  0000 0100 <- efter ROL r17, nu har vi multiplicerat med fyra = 516
        |
        /                       ROL r17
       |                        nollan i "carry" läggs in i bit0 i r17
0000 0010  0  0000 0100 <- efter ROL r17, nu har vi multiplicerat med fyra = 516

resultatet (i r17:r16) blir 0000 0010 0000 0100 = (512 + 4) = 516.

[1802]

Jag kanske har set fel men.
10000001
ROL
Blir 00000010 Bit 0 är carry
ROL
00000101 Ettan längst till höger är bit 7(tänk på att bit 0 finns också)från start talet.

Blev visst inte 7 nollor. Fel av mig. Men en ensam 0 på ett ställe.

[Walle]

Ja, det är ju den nollan som redan låg i carry. Eftersom det är binära tal det handlar om så MÅSTE ju carry vara antingen 1 eller 0, och eftersom du inte initialt satt carry till 1 så är den 0.

[eqlazer]

Eller det som carry blev vid föregående operation.

[1802]

%0101 blir 5 decimalt. 129*2=258 bin %1 00000011. 129*2*2=516 %10 00000100. Men 2 ROL ger %00000101. Rätta mig om jag har fel.

[sodjan]

> %0101 blir 5 decimalt.

"Är detsamma som", inte "blir". Men annars, ja.

> 129*2=258 bin %1 00000011.

Ja, och du har "tappat" en bit. Ett "overflow" som du måste hantera.

> 129*2*2=516 %10 00000100.

Ja, och du har tappat en bit till...

> Men 2 ROL ger %00000101.

ROL av vadå???

[1802]

Startvärde %10000001
ROL :rotate left på med carry på 6502
ROL
Blir %00000101
Jag trodde det skulle bli %00000110

[sodjan]

Du trodde fel.