"Robert Redelmeier" <redelm@[EMAIL PROTECTED]
> wrote in message
news:_%bJj.18$Ce1.6@[EMAIL PROTECTED]
> Rod Pemberton <spamtrap@[EMAIL PROTECTED]
> wrote in part:
> > "Robert Redelmeier" <redelm@[EMAIL PROTECTED]
> wrote in message
> >> 'scuse me, but why are you _shocked_?
> >> DS doesn't _have_ 32 bits to push.
> >
> > Um..., it does push 32-bits for all three cpu's: ds plus
> > 16-bit zero for two and ds and lower 16-bits eflags for one.
> > Oh, sorry, my mistake. I should've said "I'm _shocked_
> > ... it doesn't push 32-bit value equivalent to ds for... "
>
> You're complaining about the upper fill?
This issue comes up when mixing 16-bit and 32-bit code in the same
segment.
The numerical results, IMO, should be equivalent. I.e, "Do no harm."
>From "db 0x66," my expectation is to see a "32-bit push". By "32-bit
push"
I expect not just any combination of 32-bits on the stack that might
include
16-bits from DS, but a 32-bit value that accurately represents the pushed
16-bit value of DS. I.e., zero filled for value preservation.
> Why is ZERO "more proper" than EFLAGS?
>
For "push imm8" - a 16-bit push of an 8-bit value in RM, "why is ZERO"
(via
sign extension) for the upper 8-bits "more proper" than AH, BH, CH, DH?
It's the same principle: value preservation. Without it, a processor is
useless...
> Why is ZERO "more proper" than EFLAGS?
>
Tell me where you see EFLAGS in the pseudo code for "push ds" (line is
"TEMP
= SRC"):
ELSE IF StackAddrSize = 32
THEN
IF OperandSize = 32
THEN
ESP <- (ESP - 4);
IF (SRC is FS or GS)
THEN
TEMP = ZeroExtend32(SRC);
ELSE IF (SRC is IMMEDIATE)
TEMP = SignExtend32(SRC); FI;
ELSE
TEMP = SRC;
FI;
SS:ESP <- TEMP; (* Push doubleword *)
ELSE (* OperandSize = 16*)
ESP <- (ESP - 2);
SS:ESP <- SRC; (* Push word *)
FI;
>From the pseudo code, although the 16-bit SRC in "TEMP = SRC" isn't zero
or
sign extended, one could claim that TEMP should _only_ contain a value of
DS
from the assignment, "="... and not contain additional garbage, such as
EFLAGS.
Rod Pemberton
|
