If I push the damn flags onto the stack, they damn-well be
there when I pop them off. Not so with the GCC Compiler. It
looks as though it secretly "levels" the stack and I don't
know why. If so, it is broken and should be fixed instead
of work-arounds everywhere in the code.
Gcc must know precisely how the stack is layed out in order to know
where local values on the stack are, and where it can stick
temporaries for when register contention is larger than can fit
completely in the register set during a block of code.
If you change the stack pointer (which pushfl and popfl both do) you
change where all those offsets are. Currently there is no way to tell
GCC "I changed the stack behind your back, please change your offsets
so you can still get to the variable slots on there"
It is not a trivial thing to implement either. GCC would have to do
basic block analysis for all code paths from a pushfl to a popfl and
vice versa, make sure it does the adjustments in all the right places
etc. Consider the complexity of outputting the correct code for:
a:
if(condition)
pushfl
do some
other
stuff
b:
if(some other condition not known at time 'a' is run)
popfl
You can code up millions of examples like this, the "I changed the
stack" GCC extension you'd have to write would need to handle all of
them. At best, the above example would require two, yes two, versions
of the code path between "a" and "b" to be output, how could this be
more efficient than just doing it the way it is done now? It isn't.
If anything the Intel is broken for not providing any other way to get
the EFLAGS other than the one which exists and changes the stack frame
on you.
---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><