x86 D flag: what's its status thru the program?

x86 D flag: what's its status thru the program?

[Denis Zaitsev]

Is this Direction flag (for the movs instructions) has some assumed
value (say, as after cld)?  I ask because the many program sources
show interesting behaviour: from one side, this flag is always set
before the string insns (cld or std), but from the other side, if the
programs does std then it always does cld after.  So, nobody leaves it
set, but nevertheless, everybody set it clear.  Why?

Re: x86 D flag: what's its status thru the program?

[Lukasz Michal Rak]

	Hi all!

 The convention is that the D flag in IA32 is cleared. So if you call a
subroutine you have to clear D flag before making call. The subroutine can
change the state of D flag, but before returning the routine has to clear
the D flag.
 Hope I helped.

 Regards,

			Lukasz


> Is this Direction flag (for the movs instructions) has some assumed
> value (say, as after cld)?  I ask because the many program sources
> show interesting behaviour: from one side, this flag is always set
> before the string insns (cld or std), but from the other side, if the
> programs does std then it always does cld after.  So, nobody leaves it
> set, but nevertheless, everybody set it clear.  Why?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-gcc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: x86 D flag: what's its status thru the program?

[Denis Zaitsev]

On Mon, Jul 05, 2004 at 03:23:44PM +0200, Lukasz Michal Rak wrote:
> 
> 	Hi all!
> 
>  The convention is that the D flag in IA32 is cleared. So if you call a
> subroutine you have to clear D flag before making call.

Do you mean that 'I have to clear the D flag if I had set it somewhere
before?'  Else what is the sense of the convention?

> The subroutine can change the state of D flag, but before returning
> the routine has to clear the D flag.

If the subroutine can change the flag, that it will violate the
convention, won't it?  And what is the strength of the convention,
again?

>  Hope I helped.

Thanks, but I still don't understand something.  Again: if every
procedure keeps the flag clear at exit, then why the same every
procedure clears it at entry?  In a suspicion, that caller has changed
the flag against the rules?

>  Regards,
> 
> 			Lukasz
> 
> 
> > Is this Direction flag (for the movs instructions) has some assumed
> > value (say, as after cld)?  I ask because the many program sources
> > show interesting behaviour: from one side, this flag is always set
> > before the string insns (cld or std), but from the other side, if the
> > programs does std then it always does cld after.  So, nobody leaves it
> > set, but nevertheless, everybody set it clear.  Why?
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-gcc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 

Re: x86 D flag: what's its status thru the program?

[Lukasz Michal Rak]

> >  The convention is that the D flag in IA32 is cleared. So if you call a
> > subroutine you have to clear D flag before making call.
>
> Do you mean that 'I have to clear the D flag if I had set it somewhere
> before?'  Else what is the sense of the convention?
Yes. Other code may assume that D is cleared and for example after calling
your code will not check state of D flag, so if you will left D flag set
this may cause errors.

> > The subroutine can change the state of D flag, but before returning
> > the routine has to clear the D flag.
>
> If the subroutine can change the flag, that it will violate the
> convention, won't it?  And what is the strength of the convention,
> again?
>
Subroutine can change the D flag, but before exiting must clear it.

The convention should make you free from checking the state of flag
and clearing at the beginning of your code.

> >  Hope I helped.
>
> Thanks, but I still don't understand something.  Again: if every
> procedure keeps the flag clear at exit, then why the same every
> procedure clears it at entry?  In a suspicion, that caller has changed
> the flag against the rules?
Just to be sure that the D flag is cleared. The convetion is one thing and
reality other.


Lukasz

Re: x86 D flag: what's its status thru the program?

[Denis Zaitsev]

On Mon, Jul 05, 2004 at 07:19:06PM +0200, Lukasz Michal Rak wrote:
> > >  The convention is that the D flag in IA32 is cleared. So if you call a
> > > subroutine you have to clear D flag before making call.
> >
> > Do you mean that 'I have to clear the D flag if I had set it somewhere
> > before?'  Else what is the sense of the convention?
> Yes. Other code may assume that D is cleared and for example after calling
> your code will not check state of D flag, so if you will left D flag set
> this may cause errors.
> 
> > > The subroutine can change the state of D flag, but before returning
> > > the routine has to clear the D flag.
> >
> > If the subroutine can change the flag, that it will violate the
> > convention, won't it?  And what is the strength of the convention,
> > again?
> >
> Subroutine can change the D flag, but before exiting must clear it.
> 
> The convention should make you free from checking the state of flag
> and clearing at the beginning of your code.
> 
> > >  Hope I helped.
> >
> > Thanks, but I still don't understand something.  Again: if every
> > procedure keeps the flag clear at exit, then why the same every
> > procedure clears it at entry?  In a suspicion, that caller has changed
> > the flag against the rules?
> Just to be sure that the D flag is cleared. The convetion is one thing and
> reality other.

Ok.  Thanks!  It's the thing that I didn't understand.  BTW, where is
this convention documented, if either?

Re: x86 D flag: what's its status thru the program?

[Lukasz Michal Rak]

On Tue, 6 Jul 2004, Denis Zaitsev wrote:

> On Mon, Jul 05, 2004 at 07:19:06PM +0200, Lukasz Michal Rak wrote:
> > > >  The convention is that the D flag in IA32 is cleared. So if you call a
> > > > subroutine you have to clear D flag before making call.
> > >
> > > Do you mean that 'I have to clear the D flag if I had set it somewhere
> > > before?'  Else what is the sense of the convention?
> > Yes. Other code may assume that D is cleared and for example after calling
> > your code will not check state of D flag, so if you will left D flag set
> > this may cause errors.
> >
> > > > The subroutine can change the state of D flag, but before returning
> > > > the routine has to clear the D flag.
> > >
> > > If the subroutine can change the flag, that it will violate the
> > > convention, won't it?  And what is the strength of the convention,
> > > again?
> > >
> > Subroutine can change the D flag, but before exiting must clear it.
> >
> > The convention should make you free from checking the state of flag
> > and clearing at the beginning of your code.
> >
> > > >  Hope I helped.
> > >
> > > Thanks, but I still don't understand something.  Again: if every
> > > procedure keeps the flag clear at exit, then why the same every
> > > procedure clears it at entry?  In a suspicion, that caller has changed
> > > the flag against the rules?
> > Just to be sure that the D flag is cleared. The convetion is one thing and
> > reality other.
>
> Ok.  Thanks!  It's the thing that I didn't understand.  BTW, where is
> this convention documented, if either?
>
I don't know where it is documented. Maybe in some documents about C
calling convention. I let you know if I will find something.

		Lukasz

Re: x86 D flag: what's its status thru the program?

[Jim Wilson]

Denis Zaitsev wrote:
> 
> Ok.  Thanks!  It's the thing that I didn't understand.  BTW, where is
> this convention documented, if either?

The Linux Standard Base is a good source of info like this.  See
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/IA32/spec/rstandards.html#AEN34
Look at the one titled "System V Application Binary Interface - 
Intel386™ Architecture Processor Supplement, Fourth Edition".
http://www.caldera.com/developers/devspecs/abi386-4.pdf
Then search for EFLAGS in that document.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com