f



Resetting the Z and V flags

Is it permissable to use

movs r0,r0 to reset the Z flag?

and

cmp r0,r0 to reset the V flag?

-- 
Colin Ferris Cornwall UK
0
cferris (978)
7/8/2003 10:07:03 AM
comp.sys.acorn.programmer 2499 articles. 0 followers. Post Follow

11 Replies
373 Views

Similar Articles

[PageSpeed] 12

In message <bdb3bc0e4c.cferris@cferris.freeuk.com>
          cferris@freeRemoveuk.com.invalid wrote:

> Is it permissable to use
> 
> movs r0,r0 to reset the Z flag?

No, because it does not work. This instruction sets Z iff r0 == 0 and
only resets Z if r0 <> 0.

There are many ways to reset the Z flag, for example teq pc,#0 will do.
This changes the N flag, too, but leaves C and V alone.

> and
> 
> cmp r0,r0 to reset the V flag?

Yes. If you do not mind changing all the other flags as well (this will
leave you with nCZv).

Martin
-- 
---------------------------------------------------------------------
Martin Wuerthner       MW Software      martin@invalidMW-software.com
                                        remove "invalid" to reply
---------------------------------------------------------------------
0
martin7551 (398)
7/8/2003 11:45:52 AM
On Tue, 08 Jul 2003 19:14:42 GMT, Alex Waugh <alex@alexwaugh.com>
wrote:

>In message <11c0c50e4c.martin@mw-software.com>
>          Martin Wuerthner <martin@invalidMW-software.com.invalid> wrote:
>
>> In message <bdb3bc0e4c.cferris@cferris.freeuk.com>
>>           cferris@freeRemoveuk.com.invalid wrote:
>> 
>> > Is it permissable to use
>> > 
>> > movs r0,r0 to reset the Z flag?
>> 
>> No, because it does not work. This instruction sets Z iff r0 == 0 and
>> only resets Z if r0 <> 0.
>> 
>> There are many ways to reset the Z flag, for example teq pc,#0 will do.
>> This changes the N flag, too, but leaves C and V alone.
>
>No, TEQ will set C based on the carry out from the shifter.

Only if the shift is non-zero. For #0 it's zero.

It's a good one to remember because some constants (like
in TEQ rx,#const) will turn out barrel-shifted (e.g. 256)
while others won't (e.g. 128). I.e. the former (possibly
unexpectedly) corrupts (clears in this case) C, while the
latter doesn't.


John Kortink

-- 

Email    : kortink@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink

ViewFinder, the high performance graphics card for RISC PC's :
visit http://www.windfall.nl for more details and pricing.

0
kortink (350)
7/8/2003 7:58:40 PM
In message <ar7mgvohnlcd2na5bepn5jipmrksgr60ar@4ax.com>
          John Kortink <kortink@inter.nl.net> wrote:

> On Tue, 08 Jul 2003 19:14:42 GMT, Alex Waugh <alex@alexwaugh.com>
> wrote:
> 
> >In message <11c0c50e4c.martin@mw-software.com>
> >          Martin Wuerthner <martin@invalidMW-software.com.invalid> wrote:
> >
> >> In message <bdb3bc0e4c.cferris@cferris.freeuk.com>
> >>           cferris@freeRemoveuk.com.invalid wrote:
> >> 
> >> > Is it permissable to use
> >> > 
> >> > movs r0,r0 to reset the Z flag?
> >> 
> >> No, because it does not work. This instruction sets Z iff r0 == 0 and
> >> only resets Z if r0 <> 0.
> >> 
> >> There are many ways to reset the Z flag, for example teq pc,#0 will do.
> >> This changes the N flag, too, but leaves C and V alone.
> >
> >No, TEQ will set C based on the carry out from the shifter.
> 
> Only if the shift is non-zero. For #0 it's zero.

So it does, my apologies. The ARM ARM is not very obvious about this
behaviour.

Alex

-- 
Alex Waugh                                           alex@alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/

0
alex9270 (76)
7/8/2003 9:11:35 PM
John Kortink <kortink@inter.nl.net> wrote:

> On Tue, 08 Jul 2003 19:14:42 GMT, Alex Waugh <alex@alexwaugh.com>
> wrote:
> 
> >In message <11c0c50e4c.martin@mw-software.com>
> >          Martin Wuerthner <martin@invalidMW-software.com.invalid> wrote:
> >
> >> In message <bdb3bc0e4c.cferris@cferris.freeuk.com>
> >>           cferris@freeRemoveuk.com.invalid wrote:
> >> 
> >> > Is it permissable to use
> >> > 
> >> > movs r0,r0 to reset the Z flag?
> >> 
> >> No, because it does not work. This instruction sets Z iff r0 == 0 and
> >> only resets Z if r0 <> 0.
> >> 
> >> There are many ways to reset the Z flag, for example teq pc,#0 will do.
> >> This changes the N flag, too, but leaves C and V alone.
> >
> >No, TEQ will set C based on the carry out from the shifter.
> 
> Only if the shift is non-zero. For #0 it's zero.
> 
> It's a good one to remember because some constants (like
> in TEQ rx,#const) will turn out barrel-shifted (e.g. 256)
> while others won't (e.g. 128). I.e. the former (possibly
> unexpectedly) corrupts (clears in this case) C, while the
> latter doesn't.

In the vast majority of cases, but obscene programmers can pervert this ;-)

For example "TEQ rx, #128" can be written as "TEQ rx, #32,30" or "TEQ rx,
#8,28" or "TEQ rx, #2,26" with the difference that the special ones
guarantee to clear C as well as setting N and Z on the basis of the TEQ.

This is a perfectly good encoding of the instruction, but also one which all
good disassemblers will flag up specially or with flashing lights (where
available).  You might just need the carry flag in a known state in some
critical piece of code :)  

To explain to those who don't know, the constants in this sort of
instruction are encoded in a total 12 bits.  This cnstant is always encoded
as 8 significant bits with a 4-bit right rotate of an even number of bits
(i.e. the values 0-15 represent 0, 2, 4, 6, 8 ... 30)  For example with "TEQ
rx, #&FC000003" (which sets C), the constant is encoded as "&FF, rotate 6". 
Usually a disassembler will reverse the encoding to give you the proper
constant, but they should spot the "non-standard" encodings.

-- 
Stewart Brodie
0
7/8/2003 11:22:02 PM
On 8 Jul 2003 Matthew Phillips <mnews@sinenomine.freeserve.co.uk> wrote:

> In message <5ed7ee0e4c.ajw498@caramel.cp15.org>
>           Alex Waugh <alex@alexwaugh.com> wrote:
> 
> > In message <11c0c50e4c.martin@mw-software.com>
> >           Martin Wuerthner <martin@invalidMW-software.com.invalid> wrote:
> >
> > > There are many ways to reset the Z flag, for example teq pc,#0 will do.
> > > This changes the N flag, too, but leaves C and V alone.
> > 
> > No, TEQ will set C based on the carry out from the shifter. Only V is
> > unaffected.
> 
> Page 69 of the Acorn Assembler manual says that for logical operations
> (AND, BIC, EOR, MOV, MVN, ORR, TEQ, TST) the C flag will be unchanged if no
> shifting took place.

Use MSR for setting flags, you might actually have some clue what the
code does 5 minutes later.

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
0
news5843 (7461)
7/10/2003 12:26:36 AM
Martin Wuerthner <martin@invalidMW-software.com.invalid> wrote:

> The interesting thing about FNsetVi(cc%)/FNclearVi(cc%) is that they
> guarantee that cc% still holds after the instruction (apart from the case
> of calling FNsetVi(VC) or FNclearVi(VS), of course - in which case this is
> not possible and an error is generated during assembly).

And of course unless the condition is GE, GT, LT or LE - or are you saying
that the other flags are also manipulated to preserve these conditions?

The most important thing about the macros that we used was that the
resulting flags were identical for both 26-bit and 32-bit expansions
wherever possible.

-- 
Stewart Brodie
0
7/10/2003 11:48:19 AM
On Thu, 10 Jul 2003 12:36:10 +0100, Stewart Brodie
<stewart.brodie@ntlworld.com> wrote:

>John Kortink <kortink@inter.nl.net> wrote:
>
>> On Wed, 9 Jul 2003 00:22:02 +0100, Stewart Brodie
>> <stewart.brodie@ntlworld.com> wrote:
>> 
>> >[...]
>> >
>> >For example "TEQ rx, #128" can be written as "TEQ rx, #32,30" or "TEQ rx,
>> >#8,28" or "TEQ rx, #2,26" with the difference that the special ones
>> >guarantee to clear C as well as setting N and Z on the basis of the TEQ.
>> 
>> Of course, although encoding 4095 with a 'special' shift
>> remains a challenge ... ;-)
>
>You just can't encode it in the 8+4 style constant.

Oops. I meant 255. As in : there's no way of non-zero shifting
that one constant.


John Kortink

-- 

Email    : kortink@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink

ViewFinder, the high performance graphics card for RISC PC's :
visit http://www.windfall.nl for more details and pricing.

0
kortink (350)
7/10/2003 12:04:14 PM
On Thu, 10 Jul 2003 14:04:14 +0200, John Kortink
<kortink@inter.nl.net> wrote:

>On Thu, 10 Jul 2003 12:36:10 +0100, Stewart Brodie
><stewart.brodie@ntlworld.com> wrote:
>
>>John Kortink <kortink@inter.nl.net> wrote:
>>
>>> On Wed, 9 Jul 2003 00:22:02 +0100, Stewart Brodie
>>> <stewart.brodie@ntlworld.com> wrote:
>>> 
>>> >[...]
>>> >
>>> >For example "TEQ rx, #128" can be written as "TEQ rx, #32,30" or "TEQ rx,
>>> >#8,28" or "TEQ rx, #2,26" with the difference that the special ones
>>> >guarantee to clear C as well as setting N and Z on the basis of the TEQ.
>>> 
>>> Of course, although encoding 4095 with a 'special' shift
>>> remains a challenge ... ;-)
>>
>>You just can't encode it in the 8+4 style constant.
>
>Oops. I meant 255. As in : there's no way of non-zero shifting
>that one constant.

Well, 127 and 254 as well since the shift is a multiple of 2.


John Kortink

-- 

Email    : kortink@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink

ViewFinder, the high performance graphics card for RISC PC's :
visit http://www.windfall.nl for more details and pricing.

0
kortink (350)
7/10/2003 12:06:45 PM
On Thu, 10 Jul 2003 14:06:45 +0200, John Kortink
<kortink@inter.nl.net> wrote:

>On Thu, 10 Jul 2003 14:04:14 +0200, John Kortink
><kortink@inter.nl.net> wrote:
>
>>On Thu, 10 Jul 2003 12:36:10 +0100, Stewart Brodie
>><stewart.brodie@ntlworld.com> wrote:
>>
>>>John Kortink <kortink@inter.nl.net> wrote:
>>>
>>>> On Wed, 9 Jul 2003 00:22:02 +0100, Stewart Brodie
>>>> <stewart.brodie@ntlworld.com> wrote:
>>>> 
>>>> >[...]
>>>> >
>>>> >For example "TEQ rx, #128" can be written as "TEQ rx, #32,30" or "TEQ rx,
>>>> >#8,28" or "TEQ rx, #2,26" with the difference that the special ones
>>>> >guarantee to clear C as well as setting N and Z on the basis of the TEQ.
>>>> 
>>>> Of course, although encoding 4095 with a 'special' shift
>>>> remains a challenge ... ;-)
>>>
>>>You just can't encode it in the 8+4 style constant.
>>
>>Oops. I meant 255. As in : there's no way of non-zero shifting
>>that one constant.
>
>Well, 127 and 254 as well since the shift is a multiple of 2.

Or anything else with at least two 1's at distance 6 or 7 for
that matter.

;-)


John Kortink

-- 

Email    : kortink@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink

ViewFinder, the high performance graphics card for RISC PC's :
visit http://www.windfall.nl for more details and pricing.

0
kortink (350)
7/10/2003 12:12:26 PM
On Thu, 10 Jul 2003 15:36:12 +0200, Martin Wuerthner
<martin@invalidMW-software.com.invalid> wrote:

>In message <gemini.3f0d528300517370%stewart.brodie@ntlworld.com>
>          Stewart Brodie <stewart.brodie@ntlworld.com> wrote:
>
>> Martin Wuerthner <martin@invalidMW-software.com.invalid> wrote:
>> 
>> > The interesting thing about FNsetVi(cc%)/FNclearVi(cc%) is that they
>> > guarantee that cc% still holds after the instruction (apart from the case
>> > of calling FNsetVi(VC) or FNclearVi(VS), of course - in which case this is
>> > not possible and an error is generated during assembly).
>> 
>> And of course unless the condition is GE, GT, LT or LE - or are you saying
>> that the other flags are also manipulated to preserve these conditions?
>
>Yes, that is the point. The macro setVi(cc%) guarantees two things:
>* V is set
>* cc% still holds
>This can always be done, except when cc% is VC, for obvious reasons.

Interesting. I work with similar macro's as well (altough these
are 'expanded' as a preprocessing step by feeding source through
my library system, rather than generated by a BASIC function) but
I only use them to automatically generate exit code. For every
flag, I specify set, clear, preserve (via a stacked r14 in that
case), or return (i.e. 'as is'). With shorthands for often used
ones (like 'preserve all' or 'return all') and facilities to
elegantly return r0 on errors, etc.. Personally I've never
found it necessary to use similar flag-setting code for things
other than function exits, but I suppose it's a matter of taste.


John Kortink

-- 

Email    : kortink@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink

ViewFinder, the high performance graphics card for RISC PC's :
visit http://www.windfall.nl for more details and pricing.

0
kortink (350)
7/10/2003 2:11:20 PM
In message <o2sqgvcab0pdsmme0r9jioms2rhifga1i9@4ax.com>
          John Kortink <kortink@inter.nl.net> wrote:

> On Thu, 10 Jul 2003 15:36:12 +0200, Martin Wuerthner
> <martin@invalidMW-software.com.invalid> wrote:
> 
> >In message <gemini.3f0d528300517370%stewart.brodie@ntlworld.com>
> >          Stewart Brodie <stewart.brodie@ntlworld.com> wrote:
> >
> >> Martin Wuerthner <martin@invalidMW-software.com.invalid> wrote:
> >> 
> > > > The interesting thing about FNsetVi(cc%)/FNclearVi(cc%) is that
> > > > they guarantee that cc% still holds after the instruction (apart
> > > > from the case of calling FNsetVi(VC) or FNclearVi(VS), of course -
> > > > in which case this is not possible and an error is generated
> > > > during assembly).
> >> 
> > > And of course unless the condition is GE, GT, LT or LE - or are you
> > > saying that the other flags are also manipulated to preserve these
> > > conditions?
> >
> >Yes, that is the point. The macro setVi(cc%) guarantees two things:
> >* V is set
> >* cc% still holds
> >This can always be done, except when cc% is VC, for obvious reasons.
> 
> Interesting. I work with similar macro's as well (altough these
> are 'expanded' as a preprocessing step by feeding source through
> my library system, rather than generated by a BASIC function) but
> I only use them to automatically generate exit code. For every
> flag, I specify set, clear, preserve (via a stacked r14 in that
> case), or return (i.e. 'as is'). With shorthands for often used
> ones (like 'preserve all' or 'return all') and facilities to
> elegantly return r0 on errors, etc.. Personally I've never
> found it necessary to use similar flag-setting code for things
> other than function exits, but I suppose it's a matter of taste.

Yes, I agree that exit macros are really the main purpose and SetVi mainly
works the way it does to allow me to implement the exit macros elegantly,
e.g., FNexitVS(cc%) is SetVi(cc%) followed by FNexit(cc%).

However, I have abandoned flag preservation altogether except in very few
circumstances. It is just too much bother in 32-bit mode. Finding and
fixing all the places that depended on this in the several megabytes of
ArtWorks source code was not fun.

Martin
-- 
---------------------------------------------------------------------
Martin Wuerthner       MW Software      martin@invalidMW-software.com
                                        remove "invalid" to reply
---------------------------------------------------------------------
0
martin7551 (398)
7/15/2003 12:56:32 PM
Reply: