Re: C'Mon, this *isn't* Rocket Science


hutch-- wrote:
> The semantic shift here does not solve the problem by twiddling the
> context of te word "preserve", on x86 hardware, preserve a register
> means save it somewhere and "restore" a register means copying back
> that value to the changed register.

No, it does not. See my other post.
Saving and restoring registers is *not* the same as preserving those
registers. Saving and restoring is an *active* operation, preserving
may be *passive*.

>
> Now this attempt at a semantic shift leads to direct ambiguity with
> what is involved with register preservation. By the definition being
> peddled here "preserve" is ambiguous as in the following examples.
>
> Item proc args etc ....
> ; code
> ret
> item endp
>
> item2 proc args etc ....
> push ebx
> push esi
> push edi
> ; code
> pop edi
> pop esi
> pop ebx
> ret
> item2 endp
>
> Which one has "preserved" registers and which one has not ?

The one that ensures that the registers maintain all the same values on
exit that they had on entry. That could be both of the above, neither
of the above, or all of the above depending entirely on the code and
which registers you need preserved.

>
> Now if someone could help f0dder change his definition in two things he
> could resolve the problem where he has kept misadvising learner
> programmers for years.

I'm afraid I have to agree with Donkey and f0dder on this one. You're
the one who needs to use the definition of "preserve" in it's more
traditional manner. Please see my other post for details.


>
> 1. Return to the operating system UNCHANGED the registers it expects to
> remain unchanged (ebx esp ebp esi edi).

Their values are preserved.

> If this means having to
> PRESERVE them so you can use them, then fine.

What you really mean to say here is "if this means having to save and
restore them..."

Preserve is a *passive* term. You can preserve things by doing nothing
(assuming no other changes are made to those things). Save and restore
is an *active* term. You must do something to *save* the registers
(e.g., push their values) and you must do something to *restore* their
values (e.g., pop them). You're simply confusing the term "preserve"
with "save and restore".


>
> 2. FORGET CALLBACKS, they are no difference to any other interaction
> with the operating system, WndProc, DlgProc, subclasses, Hook
> procedures and the inverse when calling an API function.

This is absolutely correct.

>
> The only requirement is that you preserve registers on the basis of
> NEED ALONE.

Well, that statement is ambiguous.
Again, if you do nothing to a register in a procedure, you've preserved
it's value.

To preserve a register whose value you've changed in a procedure,
you're probably going to need to save and restore that value
(technically, you don't need to save it if you know what it's value
always is on entry, you can simply restore that known value prior to
leaving; for example, "preserving" the direction flag my simply consist
of a CLD instruction as the Intel ABI suggests that you keep the
direction flag clear *except* in the code sequence where you need it
set).


>
> Prefixing the following nonsense with a set of conditions does not
> solve the problem.
>
> > *) in callback routines, such as wndprocs, you must preserve EBX, ESI,
> EDI, EBP, ESP.
>
> The difference is the imperative "must" which is different to "can" or
> "might" or on the basis of "need alone", it asserts an imperative based
> on the form of a callback and this is nonsense.

Agreed. Register preservation (under Intel ABI) is mostly free of
context. Doesn't matter what kind of routine it is (well, interrupt
service routines *do* matter, but you generally don't get to write
those yourself under Windows).

But that doesn't change the fact that you're confusing the term
"preserve" with "save and restore".
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Donkey Strikes Again !
    ... > Noting that Donkey cannot censure or close posting in this newsgroup, ... > As with f0dder, I would expect Donkey to correct this technical mistake ... explicitly save a register value and explicitly restore that value ...
    (alt.lang.asm)
  • Re: [Patch 00/12] Hardware Breakpoint Interfaces
    ... bp can be NULL due to lazy debug register switching ... the breakpoint structure for bp 0 will be deallocated. ... so we have to restore the old settings. ...
    (Linux-Kernel)
  • Re: Why the push and mov when main starts?
    ... If ESI and EDI has to be preserved.... ... If you don't honour this register preservation rule, ... /* I'm assuming here that ESI register is not modified because OS ABI ...
    (comp.lang.asm.x86)
  • Re: CMon, this *isnt* Rocket Science
    ... context of te word "preserve", on x86 hardware, preserve a register ... push ebx ... push esi ... push edi ...
    (alt.lang.asm)
  • Re: Restoring SQL UDFs
    ... you are saying that we should restore the HLL ... Create Procedure to register them. ... restores on the test machines the UDFs don't turn up in QSYS2/SYSFUNCS. ... HLL service programs first, and then restore QSYS2/SYSFUNCS? ...
    (comp.sys.ibm.as400.misc)
Loading