Re: Some confusion on Stack operation
- From: Herbert Kleebauer <klee@xxxxxxxxx>
- Date: Thu, 09 Mar 2006 12:12:58 +0100
Rod Pemberton wrote:
"Herbert Kleebauer" <klee@xxxxxxxxx> wrote in message
Rod Pemberton wrote:
Technically, yes. But 32-bit protected mode is known as protected mode (PM)
and 16-bit protected mod is called virtual 8086 (V86).
No. From the x86 manual:
The IA-32 processors function most efficiently when executing 32-bit program modules. They
can, however, also execute 16-bit program modules, in any of the following ways:
. In real-address mode.
. In virtual-8086 mode.
. System management mode (SMM).
. As a protected-mode task, when the code, data, and stack segments for the task are all
configured as a 16-bit segments.
. By integrating 16-bit and 32-bit segments into a single protected-mode task.
. By integrating 16-bit operations into 32-bit code segments.
Which was taken out of context:
How can it be "out of context"? It lists 6 ways to execute 16 bit instructions
in an 386+. In the context of this discussion the 5th method (By integrating
16-bit and 32-bit segments into a single protected-mode task) is the interesting
one (and maybe the 4th).
We can cross the fourth off the
list, since it's unlikely the anyone would ever create a dedicated 16-bit PM
OS.
May I quote your statement which was the start of this discussion: "and 16-bit
protected mod is called virtual 8086 (V86)". At least now you say, there is a
16-bit protected mode (which has nothing to do with V86 mode), but it is
unlikely that it is used.
That leaves the fifth case:That's correct
a 16-bit TSS which Intel supports but obsoleted.That's wrong, the fifth case is: "By integrating 16-bit and 32-bit segments
into a single protected-mode task."
Here are the warnings and obsoletion from "IA-32 Intel(C) Architecture
Software Developer's Manual Volume 3A: System Programming Guide, Part 1,
Order Number: 253668-018, Jan 2006"
1) Warning #1
"CHAPTER 16 8086 EMULATION"
"Intel Architecture processors (beginning with the Intel386 processor)
provide two ways to
execute new or legacy programs that are assembled and/or compiled to run on
an Intel 8086
processor:
* Real-address mode.
* Virtual-8086 mode."
That's out of context. We are speaking about 16 bit protected mode and
not 16 bit real mode (8086) code executed by a 386+
2) Warning #2
"17.27.4. Using A 16-Bit TSS with 32-Bit Constructs
3) Warning #3
"6.6 16-BIT TASK-STATE SEGMENT (TSS)
That's all warnings for point 4. But you already recognized:
> That leaves the fifth case
Read chapter 16.4 from the above quoted manual.
That's not true. There is nothing in the Intel spec's that requires an
assembler to differentiate between 'push ax' and 'push eax'. The actual
instruction coding is the same. The assembler must generate the same
instruction sequence for both. However, it can apply a size override prefix
to do more of what the user expects.
'push ax' and 'push eax' are completely different instructions and if an
assembler generates the same opcode for both instructions, then the
assembler is "broken".
Incorrect, as previously stated.
You mean you have previously incorrectly stated it. The Hardware of the 386+
is able to push the 16 bit content of AX onto the stack (decrementing the
stack pointer by 2) and is also able to push the 32 bit content of EAX onto
the stack (decrementing the stack pointer by 4) in a single instruction
and independent from the current processor mode (16 or 32 bit). Each of
this two CPU instruction has it's own opcode (but the opcodes are different
in 16 and 32 bit mode). An assembler converts a symbolic representation
of this opcode into the binary opcode. And the symbolic representation
for this two instructions are:
push ax
push eax
Because the opcode is different in 16 and 32 bit mode, the assembler has
to generate the correct opcode for the used mode. But independent from
the mode, it always has to generate two different opcodes for the two
different instructions or the assembler "is broken". Still waiting for
a listing of such a broken assembler.
I do know some assemblers won't generate 'push eax' for 16-bit mode.
Sure, any assembler which only supports 86/286 but not 386+ CPU's.
And, I
know some do and some don't insert instruction prefixes for various
instructions.
Sure, for "various instructions", but not for "push ax"/"push eax"
(or it is broken).
FF /6 PUSH r/m16
FF /6 PUSH r/m32
You shouldn't stop reading after a few lines, read the complete
specification of the push instruction:
Operation
IF StackAddrSize = 32
THEN
IF OperandSize = 32
THEN
ESP <- ESP - 4;
SS:ESP <- SRC; (* push doubleword *)
ELSE (* OperandSize = 16*)
ESP <- ESP - 2;
SS:ESP <- SRC; (* push word *)
FI;
ELSE (* StackAddrSize = 16*)
IF OperandSize = 16
THEN
SP <- SP - 2;
SS:SP <- SRC; (* push word *)
ELSE (* OperandSize = 32*)
SP <- SP - 4;
SS:SP <- SRC; (* push doubleword *)
FI;
FI;
You shouldn't post without understanding what that means. That supports my
case, not yours.
What that says is:
1) if the default mode is 16-bit, "50+ rw PUSH r16" or "50+ rd PUSH r32",
will push 16-bits and decrement SP by 2.
2) if the default mode is 32-bit, "50+ rw PUSH r16" or "50+ rd PUSH r32",
will push 32-bits and decrement ESP by 4.
3) if the default mode is 16-bit and if "50+ rw PUSH r16" or "50+ rd PUSH
r32" is prefixed with an size overide prefix, it will push 32-bits and
decrement SP by 4.
4) if the default mode is 32-bit and if "50+ rw PUSH r16" or "50+ rd PUSH
r32" is prefixed with an size overide prefix, it will push 16-bits and
decrement ESP by 2.
Can you please give me the exact lines where this is said? You must be
reading something between the lines. The description of the operation
(which I posted) only describes what happens when the operand size is
16 or 32. And for this description in doesn't matter whether the operand
size is 32 because we have a 32 bit code segment and the opcode 0x50
or because we have a 16 bit code segment an the opcode 0x66 0x50.
And the information in the two lines you posted:
FF /6 PUSH r/m16
FF /6 PUSH r/m32
is, that the opcode FF /6 can be the assembler instruction "PUSH r/m16"
but it can also be the instruction "PUSH r/m32". Whether it is the one or
the other depends on the code segment (16 or 32 bit). But it surely does
not mean, that an assembler always can encode both instructions ("PUSH r/m16"
and "PUSH r/m32") with the opcode FF /6. And if an assembler does so, than
it is broken.
"The PUSHA (push all) and PUSHAD (push all double) mnemonics reference the same opcode.
The PUSHA instruction is intended for use when the operand-size attribute is 16 and the
PUSHAD instruction for when the operand-size attribute is 32. Some assemblers may force the
operand size to 16 when PUSHA is used and to 32 when PUSHAD is used. Others may treat
these mnemonics as synonyms (PUSHA/PUSHAD) and use the current setting of the operandsize
attribute to determine the size of values to be pushed from the stack, regardless of the
mnemonic used."
With other words: Some assemblers do it correct, others are broken.
All I asked you is, to show us a listing generated by such a broken
assembler.
32-bit PM, not V86 mode.
There is also a "16-bit PM, not V86 mode".
Obsolete or unused.
Because it is obsolete or unused doesn't mean that it doesn't exist.
Your original statement (which was the start of this discussion): "and 16-bit
protected mod is called virtual 8086 (V86)" simple is wrong.
I think it's the opposite: 32-bit rmode *does NOT* exist... but it would
be extremely useful (imagine a 32 bit real mode DOS).
(You're responding to Frank's comments.)
Yes, and this is called write combining. Most modern CPU's support this.
Then it shouldn't be a problem for you, to show us a concrete
example (post the generated listing).
I don't have waste my time doing so. Intel agrees with me.
Don't think Intel agrees with you.
.
- References:
- Some confusion on Stack operation
- From: zhangyue.zl@xxxxxxxxx
- Re: Some confusion on Stack operation
- From: Rod Pemberton
- Re: Some confusion on Stack operation
- From: Frank Kotler
- Re: Some confusion on Stack operation
- From: Rod Pemberton
- Re: Some confusion on Stack operation
- From: Herbert Kleebauer
- Re: Some confusion on Stack operation
- From: Rod Pemberton
- Some confusion on Stack operation
- Prev by Date: Re: newbie: I/O with nasm
- Next by Date: Re: Some confusion on Stack operation
- Previous by thread: Re: Some confusion on Stack operation
- Next by thread: WriteProfileString help
- Index(es):
Relevant Pages
|
Loading