Re: All error or bugs found in RosAsm


Rod Pemberton wrote:
....
How often would this be the case? What kind of algo would require
maintaining a flag-status for more than a few instructions?

In general, I'm not sure it'd be wise to maintain the "flag-status for
more
than a few instructions" on x86. While there are a large number of
instructions which preserve or modify flags on x86, there are also many
instructions which are listed as having undefined effects on various
flags... To me, the fact that many x86 instructions have undefined
effects
on flags indicates there is a possibility one of those instructions could
modify your flag.

Programmers should be aware of what the CPU does on certain instructions :)

Except for CF, it's also inconvenient to use the x86 flags. The CF is
easy
to modify since it is used by many instructions and has instructions to
directly modify it's value. But, the CF being easy to modify can be both
a
benefit (easy to set conditions) and a problem (difficult to preserve it's
state without PUSHF/POPF).

Yes, to preserve flag status:
PUSHF/POPF are slowest, LAHF/SAHF are a bit faster and fastest seem to
be SETcc, but best would be to not alter the flags while needed.

Also, the most important flag, ZF, isn't so easy to modify since it lacks
instructions to directly set or modify its value. And, the ZF is modified
by a few instructions you wouldn't expect: INC DEC. You wouldn't expect
them to modify ZF, since it's very likely one would want to use them in
loops with REP with LOOP without them affecting the ZF used by the loop...
Of course, the flag INC and DEC should've modified, CF, isn't modified by
them... It's fortunate that one can use the CF as the ZF via NEG, but
that
destroys your register value.

Unfortunately shift-instructions will modify the flags, so my cc-vector,
still used on some places, is detoured and restricted to
(I once had also merged the Carry-bit into this vector branch):

CMP ...,... ;or call DIV/etc...
MOV eax,00xx_0000h ;load hi-word address
LAHF
MOV al,ah ;mask: Sign=b7 Zero=b6
AND al,C0h
MOV ah,20h ;just an address-part
JMP eax ; and even many penalties from register stalls
; it is quite faster than a set of cc-branches
___
xx2000: ;c=0 s=0 z=0 ;">" ">0"
;c=1 ;"<"
xx2040: ;c=0 s=0 z=1 ;"=" "=0"
:c=1 ;after my DIV "result=0 but rem<>0"
xx2080: ;c=0 s=1 z=0 ;"-" after INC/DEC only
;c=1 ;"<0"
xx20C0: ;c=0 s=1 z=1 ;used by my calc "value NEGated indicator"
;c=1 ;rare to happen, used as error indicator.

Anyway, you really should avoid all direct use of flags on x86 since their
usage is slow and interferes with the instruction decoders.

I only particular agree here.
SAHF and modifying EFL on stack are bad solutions, but any simple
XOR/OR/CMP combination can setup many flag variants w/o STC/CLC.
Flags are there to hold meaningful information, so why not use it ?
__
wolfgang



.

Quantcast