Hi,
sir_richard wrote:
* We really have to get a good DS/ES first before
touching any data.
*
* These two reads will either go in a register (with optimizations ON) or
* a stack variable (which is on SS:ESP, guaranteed to be good/valid).
*
* Because the assembly is marked volatile, the order of instructions is
* as-is, otherwise the optimizer could simply get rid of our DS/ES.
Timo Kreuzer wrote:
2.) Segements should be fixed up before entering C
code, as not doing so
may introduce possible compiler dependend breakages. It's also much
cleaner and there's no reason to do the same stuff later in inline assembly
instead of direcly in the asm entry point.
Ros Arm wrote:
Regarding #2, I unfortunately do not see the need to
add more assembly
when it is not needed. There are no subtle compiler breakages involved,
since it is impossible for the compiler to add a DS/ES access for no reason
at all (can you come up with an example?), this is part of the contract the
compiler has to make (if compilers did this, it would break a whole class of
embedded and real-mode software). Because the stack is safe, I think it's
worth avoiding the extra lines of assembly. The C inlines will produce
exactly the same code anyway.
Not as a guide to action, simply to note — there is no guarantee that
volatile asm statements (and code around them) will never be
reordered. As only two registers are needed to keep Ds and Es, it
seems to work there. But in a general case, GCC does not hesitate to
rearrange such stuff…