Carry flag documentation in doc0856

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Everyone,

 

I'm trying to understand what the CPI command does with the C flag.

 

C: Rd7 •K7 +K7 •R7+ R7 •Rd7
Set if the absolute value of K is larger than the absolute value of Rd; cleared otherwise.

The first Rd7 has a line above it and the last Rd7 has a line above it.

 

Q1 - Why does it say "absolute" value?

Q2 - It does even look at bits 6-0, how does this work?

Q3 - What does the line mean?  NOT?

Q4 - The dot means AND, right?

Q5 - The plus means ADD, right?

 

A circle with a plus in it means exclusive or.

Or has a lowercase v for some reason.

Equal is an arrow.

 

Q6 - In the TST command it says the S flag is N ^ V (^ used for exclusive or).  Does it mean the N and V flags?  V is always 0.  What is the point of this.  Won't S always be just plain N?

 

Thanks,

 

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My DOC0856 seems to show something different to yours...

 

Note the inversion of some terms there.

 

Anyway CP on all micros is pretty much the same isn't it? It gets set when the "K" is larger than the Rd. It is not set if equal or less.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe my DOC0856 is older (Rev. 0856I–AVR–07/10) - when you say it shows something different, what do you mean?

 

Is there a way to make sense of the formula?  Why does it say "absolute" value?  Why doesn't it involve the other bits?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm talking about the line above Rd7. That means the inverse of that bit. You did not reflect that in the equation you typed.

 

Also the • is AND while + is OR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The are an error in some of manuals (I have a printed one from 1999 I think , I don't have it here).

 

CPI is the same as SUBI, where the result isn't used. (but I can't remember if it has the same error) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I'm talking about the line above Rd7. That means the inverse of that bit. You did not reflect that in the equation you typed.

 

I did two lines below the formula say that they have a line above them to avoid posting a graphic.

 

The real question is - how does that formula compare an entire byte?  If you are comparing the values 5 and 6, bit 7 will be 0 for both of them.  How does that formula compare them?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have five versions of that doc; earliest from rev. B 6/99.  All have the same CPI flag description at a quick glance.

 

Speaking of glances, isn't the Z flag description backwards?  Z should be set if the result of the formula is 1, right?

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch I think the "set if the result is $00" means the above result (Rd-k)=$00...  If Rd-k is $00 then Z=1, else Z=0

 

 

Any comments on the CPI C flag formula and how it takes other bits besides bit 7 into account???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that Z-flag formula is correct.

 

If all bits is zero then all complemented bits is 1, and 1*1*1*1*1*1*1*1 = 1

 

Or rewrite it with DeMorgan

~R7 * ~R6 * ~R5 * ~R4 * ~R3 * ~R2 * ~R1 * ~R0 = ~(R7 + R6 + R6 + R4 + R3 + R2 + R1 + R0) = "not any bit set"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that Z-flag formula is correct.

I also think the formula is correct.  It is the description that I think is not.

 

 

Set if the result is $00; cleared otherwise
 

Shouldn't it be "set if the result is 1..."?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The text below the Z formula doesn't refer to the Z formula but the original formula at the top (Rd-K).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aaah--I needed a more macro view. ;)

 

While I indeed poke around in the instruction set document from time to time, I can't remember doing detail work such that the actual flag formulas was important to me.  But that's just me. ;)  And the past decade or so all my work is in C with only occasional dips into #asm.  Once compilers became stable and reliable, I normally pay little attention to which flag is being used for e.g. BRxx.

 

Indeed, I never noticed the "why isn't looking at all the bits?" that is the topic here.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Indeed, I never noticed the "why isn't looking at all the bits?" that is the topic here.

 

I'm surprised that no one had a thought about this, but then it hit me -

 

Just like the Z flag evaluating the *result* of Rd-K, so is this C flag.  If it can see the result of the subtraction, it only HAS to look at the bit 7.

 

You can see they are differentiating between R and Rd, R being the RESULT.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Q1: The text regarding absolute value is wrong it should be unsigned instead of absolute. Unsigned describes the way the byte contend is converted to a number  (0 to 255).  This get clear if one takes into account that CP.. is the same as Sub/SBC except not storing the result. 
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can see they are differentiating between R and Rd, R being the RESULT.

You mean like "page 1" of the manual says? ;-)

 

However I think it is confusing beyond belief that some form of "R" is both input and output. It would have been better (perhaps) if they had called the it something like "O - Ouptut" ? (except that would presumably lead to "O" v "0" confusion)

 

I guess they were probably relying on no one ever bothering to read the bit info in such detail! :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ummm... guys.....    Hate to tell you this, but the documentation is completely bogus.

I learned this 15 years ago and was recently bitten by it today.  I was looking for verification of my earlier findings - but only found more confused people.

Here is a code example of an IO address coming in on PINC bus.  I'm tagging addresses 4-7 for an emulated floppy controller and 2-3 for a serial port emulator inside a Mega-162

 

   in    R31,pinC
   ANDI  R31,&H7F
   CPI   R31,8
;Look for Carry Set if above 7 -- go to cleanup
   BRCC  IORDClean
   CPi   R31,4
;Look for Carry Set if above 3 -- go to EE-Floppy
   BRCC  IORDFD
   subi  R31,2
   breq  IORData
   dec   R31
   BRNE  IORDClean
; 2) if Ctrl, Put status on A port.
   lds   R31,{PingR}
   inc   R31
   Sts   {PingR},R31
   LDI   R31,255
   out   DDRA,R31
   lds   R31,{ConStat}
   OUT   PORTA,R31
   rjmp  IORDClean
;

----  First thing you will notice is when I say -if carry is set...  then I use a BRCC for carry cleared branch.

It's part of that knowledge base you only get from hacking code into the wee hours of the morning.  This address ladder works with the BRCC commands, not the expected BRCS.

---- It's sad they never properly documented this, but then again, there are some similar errors with 8051 code I know enough to avoid.

Formerly ran the business AVRProject.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Here 6 years later I will repeat #5

 

 

All you need to remember is that CPI is SUBI, where the result isn't used. C is set if you have to borrow. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mu comment on Carry:

sMH16bCompare: ; in: btm10  atm10
    ; out: z set if equal, c set if btm lower
    cp btm0,atm0
    cpc btm1,atm1
    ret
; Use:
;   rcall sMH16bCompare
;   breq jequal
;   brlo jbtmlower