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).
cdq ; eax here always positive

setnz dl
ror ecx, n
sub edx, 1 ; copy zero to carry
rcl ecx, 1
rol ecx, n-1

It would be interesting to me if someone have another approach.
Posted on 2003-03-27 02:35:22 by masquer

pop eax
ror eax, 7
rcl ecx, n
One thing to remember(Just in case someone will forget). Rotation starts at 0th bit. So, if N == 7, rotating the value of the carry flag will set at 6th bit of ecx. :)
Posted on 2003-03-27 04:14:15 by arkane

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).
Posted on 2003-03-27 04:23:44 by masquer
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).
Posted on 2003-03-27 11:07:55 by arkane

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, n

one less instruction. :)
Posted on 2003-03-27 20:38:58 by bitRAKE

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 :)
Posted on 2003-03-28 01:44:55 by masquer
10 bytes solution:

btr ecx,N
je @F
bts ecx,N
Posted on 2003-03-28 20:09:56 by The Svin
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.
Posted on 2003-03-28 21:28:04 by bitRAKE

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:
Posted on 2003-03-31 19:44:22 by realvampire

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?


P.S.: In case of the Zero flag leaves unchanged (not undefined) the je @F must be jne @F
Posted on 2003-04-01 10:00:21 by Crick
Then check it in debuger with different values.
Posted on 2003-04-01 14:51:08 by The Svin
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?

Posted on 2003-04-02 00:12:46 by Crick
Latest Intel manuals states the values are undefined.
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.
Posted on 2003-04-02 11:30:42 by The Svin
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.
Posted on 2003-04-02 17:29:29 by iblis
Intel says words.
Some of them far from facts.
Latest talks of smsw proved it.
Posted on 2003-04-02 17:41:17 by The Svin
too bad if they decide to change the inner workings and code fails.
Posted on 2003-04-03 00:33:25 by f0dder
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.
Posted on 2003-04-03 10:52:13 by The Svin
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".
Posted on 2003-04-03 11:05:27 by f0dder
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.
Posted on 2003-04-03 12:57:30 by iblis