Re: twos complement and the CF (carry flag)





On Jan 29, 11:18 am, Herbert Kleebauer <k...@xxxxxxxxx> wrote:
LuB wrote:

I am a newbie ... self-studying Kip Irvine's 4th edition assembly
book. I may have mistyped an example program into my compiler - but
assuming not ...

I've got a basic handle on binary numbers and twos complement notation
- but I have a question about the CARRY FLAG.

Since the CF is really only relevant for unsigned operations ??? I
assume it looks at each transaction as though it were being carried
out on unsigned values.

So, since "sub" is implemented as adding the twos complement, why does
the CF=1 (carry flag get set to 1) when subtracting 90h from 80h and
not when adding 70h to 80h?

Assuming byte size,
the valid range of numbers is

for unsigned numbers: 0 - 255
for signed numbers: -128 - +127 (2th complement)

If you add or subtract unsigned numbers and the result is outside 0 - 255
the Carry is set. If you add or subtract signed numbers and the result is
outside -128 - +127 the Overflow flag is set.

Good. That makes intuitive sense.

Aren't they the same from an unsigned perspective? Nothing gets
carried ... what is the CPU doing when subtracting 90h from 80h that
it knows to mark the CF=1?

80h + 70h = F0h, CF=0
that is
1000 0000 + 0111 0000 = 1111 0000

128 + 112 = 240 is within 0-255 so Carry is not set
-128 + 112 = -16 is within -128 - +127 so Overflow is not set

Intutiviely, that does indeed makes sense.

Now, my post is really more in regards to 'literally' - how does the
CPU determine whether or not to set the CARRY FLAG if it ADDs
everything.

IE: how can it distinguish between 80h+70h and 80h-90h if it rewrites
80h-90h as 80h+70h. Suddenly, 80h-90h falls within a viable range -
since, 80h+70h does not LITERALLY carry a 1 (when I do it on paper).

It is clear to me that 80h + 80h sets the CARRY BIT since, when I do
this manually - I literally end up with a 1 bit in the 2^9 position.
(1000 0000 + 1000 0000 = 1 0000 0000).

But to literally add 80h + 70h on paper never results in a 1 in the
2^9 position. Since SUB is rewritten as ADD, what is it about the
'sub' method that makes it 'smart' enough to set the CARRY FLAG when
the resulting ADD operation did not, indeed carry a bit? I just can't
see how it 'literally' does it in this particular case.

but

80h - 90h = F0h, CF=1
that is
90h => 1001 0000 => 0110 1111 + 0000 0001 => 0111 0000
so
80h - 90h = 80h + 70h = F0h. 128 - 144 = -16 is outside 0 - 255 so Carry is set
-128 - (-112) = -16 is within -128 - +127 so Overflow is not set

Why does the CARRY FLAG = 1?

Or do mean the generating hardware? For a subtraction the Carry
generated by the adder has to be inverted to produce the correct Carry.


Ahhhhhh, do you mean ... when using SUB we must invert the resulting
CARRY FLAG? IE: if CARRY FLAG=0, then invert that ... so CARRY FLAG=1.

So, 80h - 70h we all know is 1 and the CF=0. And


1000 0000 1000 0000 1000 0000
- 0111 0000 = 1000 1111 + 1 = 1001 0000
---------------------------------------
1 | 0001 0000 = 1 | 10

Here, the rewrite of SUB as ADD indeed carry's a bit - but, since we
are SUBing, we invert that - so CF=0 for 80h - 70h (which is correct I
believe)


And now back to the original example, 80h - 90h.

1000 0000 1000 0000 1000 0000
- 1001 0000 = 0110 1111 + 1 = 0111 0000
---------------------------------------
0 | 1111 0000 = F0

Here, CF=0, but since we are using 'SUB', we invert that so that CARRY
FLAG = 1.


Is that right? Seems to work in both of these cases and I'd never
thought of it that way ... but it 'literally' works on paper.


Again, thanks in advance for your input,

-Luther

.



Relevant Pages

  • RE: Stopping a macro
    ... My guess is that the schedule sub is ... I'm reading up on "Change" events to see if putting the flag in a range ... why don't you set a flag and let Macro1 run according to this flag. ...
    (microsoft.public.excel.programming)
  • Re: OPENARGS problem
    ... > openfrm and opens the correct form, but I get an error message in the ... > Public Sub OPENFRM() ... > Dim stdocname As String ... > Dim FLAG As String ...
    (microsoft.public.access.formscoding)
  • RE: Update SQL Error
    ... I am doing it this way because I have 9 flag fields and I don't want to have ... Private Sub btn_ClFlag_Click ... Dim flgFieldNo As String ...
    (microsoft.public.access.formscoding)
  • RE: Stopping a macro
    ... I'm reading up on "Change" events to see if putting the flag in a range ... If you wanna show us the code for the schedule sub, ... Sub Update1() ... why don't you set a flag and let Macro1 run according to this flag. ...
    (microsoft.public.excel.programming)
  • AfterUpdate
    ... No to Yes if the record has been changed and the user is on the network ... Private Sub Form_AfterUpdate ... 'If your're not on the server, AND the flag is set to "Yes" ...
    (microsoft.public.access.modulesdaovba)