Seems like messing with bits are very popular today :) Here is mine.
The task is simple - I need to put ZeroFlag in n-th bit field position in 32-bit register (i.e. ecx).
It would be interesting to me if someone have another approach.
The task is simple - I need to put ZeroFlag in n-th bit field position in 32-bit register (i.e. ecx).
cdq ; eax here always positive
setnz dl
ror ecx, n
sub edx, 1 ; copy zero to carry
rcl ecx, 1
rol ecx, n-1It would be interesting to me if someone have another approach.
pushfd
pop eax
ror eax, 7
rcl ecx, narkane
Thanks for your attention, but I don't mean to change EFlags. All I need is just "copy" ZeroFlag to my own bit field resided in one of the 32-bit register (ecx in my sample).
Thanks for your attention, but I don't mean to change EFlags. All I need is just "copy" ZeroFlag to my own bit field resided in one of the 32-bit register (ecx in my sample).
I don't mean to change EFlags
honestly, I don't really understand what you mean by this. :)
I'll explain my code. :)
pushfd ;push the EFLAGS on the the stack.
pop eax ;EAX now contains the value of the EFLAGS register
ror eax, 7 ;since the Zero flag resides on the 6th bit position on
;the EFLAGS, rotate right 7 times. If the ZF is set to 1,
;ror will set the CF flag to 1, otherwise 0.
rcl ecx, n ;rotate left through the CF flag. Whatever the value of the CF,
;rcl will set the bit in ECX at n-1
;position - (start counting at 0th bit). lahf
ror ecx, n + 1 ; rol ecx, 32 - (n+1) ; msb is lost (below)
shl ah, 2 ; shr ah, 7 ; bt eax, 8+6 ; etc...
rcl ecx, 1 ; adc ecx, ecx ; msb is lost
rol ecx, none less instruction. :)
arkane
I don't really understand what you mean by this
"Mea culpa", I was mistakenly thought you misunderstand me, sorry ;) Everything is correct
bitRAKE and arkane
Thanks both, very nice solution. I wonder at I'm missing eflags rotating :)
I don't really understand what you mean by this
"Mea culpa", I was mistakenly thought you misunderstand me, sorry ;) Everything is correct
bitRAKE and arkane
Thanks both, very nice solution. I wonder at I'm missing eflags rotating :)
10 bytes solution:
btr ecx,N
je @F
bts ecx,N
@@:
Nice Svin. I always get caught up in trying to find a non-branching solution and forget the short answer with a branch - my size optimization suffers for it. In the future I hope to not neglect this type of solution in my analysis.
10 bytes solution:
btr ecx,N
je @F
bts ecx,N
@@:
On Win32 Size doesnt matter. Except If we'd like to made a Com file. :stupid:
10 bytes solution:
btr ecx,N
je @F
bts ecx,N
@@:
I don't understand this solution.
If the goal is to copy the zero flag into bit n of any general register, btr & bts leaves the Zero flag UNDEFINED and the je @F instr. will jump based on this UNDEFINED Zero flag.
am I wrong?
Crick
P.S.: In case of the Zero flag leaves unchanged (not undefined) the je @F must be jne @F
Then check it in debuger with different values.
I'd checked it before post. But the question is:
Is the Zero Flag Undefined after BTR & BTS instr. as Intel said or it remains unchanged (ALWAYS) ?
Anybody knows that?
Crick
Is the Zero Flag Undefined after BTR & BTS instr. as Intel said or it remains unchanged (ALWAYS) ?
Anybody knows that?
Crick
Latest Intel manuals states the values are undefined.
Posted on 2003-04-02 00:19:07 by bitRAKE
Posted on 2003-04-02 00:19:07 by bitRAKE
P.S.: In case of the Zero flag leaves unchanged (not undefined) the je @F must be jne @F
Oh, no! You are right :)
Thanx, for the note.
So better to be safe than sorry. If Intel says it's undefined then add a PUSHF and POPF to Svin's code. Only two bites more.
Intel says words.
Some of them far from facts.
Latest talks of smsw proved it.
Some of them far from facts.
Latest talks of smsw proved it.
too bad if they decide to change the inner workings and code fails.
Only in future models.
For Pplain to P4 it will work.
So you may treat it as code good for PP-P4.
As to future models they(Intel) can change something else and document it. Nevertheless in the case the code written for previous models will not be compatable.
That was for example in the past about ESP.
So what difference that they documented it? -
yet all code based on previous esp behavior appeared to be useless.
Whether it is documented or not - Intel doesn't give any garantee to you to stick in the future with that.
M$ docs has lots of example wrong statements in their docs, so what? They don't take responsibility for it anyway.
We are low level coders. The term appeared to be unknown to you using assembly just for fun as also unkown to you specifics of our job too, you educated as HLL code to write less efficient but universal code. In past I had job that needed to be compatable just with (for example) i486DX, and neither me nor my employer would care for other stones. The other things were important, and it seems that you have no idea of those things, why one may need low level coder.
Several people here since creation of the Algo section
have tried to keep this section extrimly practicall and
keep all useless philosophy appart from it.
That's why a lot of interesting code appeared here exlusivly, that had not been seen in books or other sources before.
So if you have offer some ideas or questions realated to Algos -
you are wellcome. Other ideas - for crusaders section.
For Pplain to P4 it will work.
So you may treat it as code good for PP-P4.
As to future models they(Intel) can change something else and document it. Nevertheless in the case the code written for previous models will not be compatable.
That was for example in the past about ESP.
So what difference that they documented it? -
yet all code based on previous esp behavior appeared to be useless.
Whether it is documented or not - Intel doesn't give any garantee to you to stick in the future with that.
M$ docs has lots of example wrong statements in their docs, so what? They don't take responsibility for it anyway.
We are low level coders. The term appeared to be unknown to you using assembly just for fun as also unkown to you specifics of our job too, you educated as HLL code to write less efficient but universal code. In past I had job that needed to be compatable just with (for example) i486DX, and neither me nor my employer would care for other stones. The other things were important, and it seems that you have no idea of those things, why one may need low level coder.
Several people here since creation of the Algo section
have tried to keep this section extrimly practicall and
keep all useless philosophy appart from it.
That's why a lot of interesting code appeared here exlusivly, that had not been seen in books or other sources before.
So if you have offer some ideas or questions realated to Algos -
you are wellcome. Other ideas - for crusaders section.
svin, writing model-specific code (or in this case code that doesn't nazily follow the "rules") is quite fine, as long as you're aware of this, and have those specific needs. I doubt this particular behaviour of this particular opcode will be changed in the future, but still...
As to future models they(Intel) can change something else and document it. Nevertheless in the case the code written for previous models will not be compatable.
If they _change_ previously documented behaviour (of "big" magnitude), can they call it IA-32 then?
Anyway, please understand my intentions. It's not to "attack" you or anything like it, I respect your work and think you do pretty clever stuff. However, in the past I've had to deal with software (binaries) that were written with very broad assumptions about specs, violating specifications (ignoring stride/pitch of video buffers, using port I/O on win32 (9x)). Most of this done as optimizations (or from clueless programmers, I dunno). While fixing bugs like this can be interesting projects sometimes, they can also be annoying when you need to "get this piece of software working NOW".
As to future models they(Intel) can change something else and document it. Nevertheless in the case the code written for previous models will not be compatable.
If they _change_ previously documented behaviour (of "big" magnitude), can they call it IA-32 then?
Anyway, please understand my intentions. It's not to "attack" you or anything like it, I respect your work and think you do pretty clever stuff. However, in the past I've had to deal with software (binaries) that were written with very broad assumptions about specs, violating specifications (ignoring stride/pitch of video buffers, using port I/O on win32 (9x)). Most of this done as optimizations (or from clueless programmers, I dunno). While fixing bugs like this can be interesting projects sometimes, they can also be annoying when you need to "get this piece of software working NOW".
That's why I suggested adding a PUSHF and a POPF. Only 2 more bytes, which unless one is obsessive about size, doesn't make much difference.