anyone know assembly?

no

ye ye
:P
can u help me please
i need to change a packet and it`s size
but i have no ideea how

..
you need to be more specific then that

?? skeet

hi
does anyone know - on average - how many instructions are between a every actual use of the flags
-a
on Intel cpu's for most programs

thats a odd question, why do you need an average? It pretty much varies from one code to another..

hmm yes it does
it's for an emulator
it uses "lazy flags" which means the flags only get updated when they are needed
I want to store information about the instruction that did that
which is 32 bytes long
I can choose whether I don't copy and take it from the instruction cache (with risk of loosing the real instruction) or copy it entirely every time a flag is required

Does it take that much clocks to just update the last instruction that modified flags?

hmm
32 bytes need to be written...
instead of just 1 pointer to it
but it's for an emulator
indeed I dunno if it's really an issue
1 pointer is 4 bytes...

..yes an the more reason to not use a "lazy flags", and make it more reliable

hmm
lazy flags are used in emulators...
it's common practice
they're updated when they're needed

ah okay, well i've never done an emulator before

me neither I'm just reading the source code of Bochs
the concept is ok
it works...

but it would make common sense to me if you were to have this information for the user it should be 100% accurate

yes
if a flag is "asked" to the cpu, the flag will be correct
if it's not, internally the emulator may not be updating it
it happens in Bochs & Qemu (there it's called "conditional code optimization")

its on by default in Bochs?
i use Bochs quite a lot
if you ask me though flags get used pretty darn frequently

compile a few projects to asm, count instructions that use the flags?

it would have to be counted at runtime though, you need to take in account for loops and such

good point
that'd be even easier.. via ptrace

personally i would just do it the nonlazy way to start off, then possibly get into the optimizations when you get the basic emulator going

i'd think they'd be fairly disparate models and it'd end up being more of a rewrite than an optimization.
but yeah i've never written an emulator either

"lazy flag evaluation. Most x86 instructions set the condition code flags, but only a relatively small subset of instructions actually use these flags."
it's quite interesting how it works... basically it just saves the 2 operands, the result & the instruction of the last instruction that modified certain flags
and it updates the flags when needed
saving 2 ops, res, instruction is faster than updating all the flags (cmp if zero etc...)

hmm i just fail to see how that is faster then a simple AND/OR to your emulated flags. EFLAGs is only 32bits so I just dont see the gain
basically it just saves the 2 operands, the result & the instruction of the last instruction that modified certain flags <-- doing this seems like its more expensive then AND/OR
specifically "instruction that modified certain flags", i would say that the most used hit instruction that relies on the flags in your conditional jumps, its quite frequent enough that evaluating each time seems like a loss to me

'lo

alot of arithmetic instructions affect the OSZAP or OSZAPC flags...
to set the P (Parity Flag) you'd need to at least count the amount of bits
you'd also need to do the other operations
it's pretty well thought out... at least for emulators...
on actual cpu's I think it's hardwired to set the flags after every instruction

hmm thats a pain
is the emulator is to be run on x86 machines or..

hmm it's Bochs
but I seem to have it somewhat figured out now

i think its bascially, you have a set of emulated flags each pointing to the last instruction, when an instruction needs a flag it the emulator will then update the flags.. makes sense or i may be getting the whole idea wrong
actually you dont need to actually update the "flag" just need an to evaluate the flag to continue the emulation
i mean it the last instruction that affects the specific flag will update that flag's last instruction, so when an instruction requires that specific flag it will go back to evalute that specific flag only
if that makes any sense :P

yes that's it

bye all
oy

teh ashe

hi.

hello

hello