OSDev.org

iansjack wrote:This seems to be an exceptionally easy thing to test practically. Why not do so, and post your results proving that it doesn't work, rather than throwing your toys out of the pram?

Speak English please!

Can someone actually summarize all of this and post it to the original thread, because the way it sits now, the thread makes no sense. I think the DI unsupported issue should be addressed by adding a reply stating that "Technically, DI is acceptable, as long as you are not in 64-bit mode. Compiling this code in 64-bit mode returns a compiler error."

Brendan wrote:The reason is that the specific section you've quoted is wrong in older versions of Intel's docs - 0x67 prefix effects address size (e.g. the size of the base and index registers in 64-bit code), and the REX.W effects operand size and not address size (and not base and index).

In newer versions of Intel's docs it's been changed; but it's still not 100% right (because it fails to mention the 0x67 prefix). Fortunately there's another section (e.g. "3.6.1 Operand Size and Address Size in 64-Bit Mode") which is correct for both the newer versions of the manual and the older versions of the manual, and is much clearer anyway.

Well, my last version of the manual was downloaded 30.07.14 (it is the file's timestamp). I look at it and see following sentence:

Intel® 64 and IA-32 Architectures Software Developer’s Manual wrote:Note that 16-bit addresses are not supported in 64-bit mode.

And next I look at the header, but it is as you have said:

Intel® 64 and IA-32 Architectures Software Developer’s Manual wrote:3.6.1 Operand Size and Address Size in 64-Bit Mode

I am still in doubts and trying to look carefully. But all new discoveries just show me the same thing - 16-bit addressing is not supported in 64-bit mode. Yet another proof is in the:

Table 3-4. Effective Operand- and Address-Size Attributes in 64-Bit Mode

where I see the row "Effective Address Size" and all values there are 32 or 64.

So, it seems to me that there are too many "specific sections" in different (by date) manuals to be so confident about manual's mistakes.

SpyderTL wrote:Can someone actually summarize all of this

Actually we need to test 16-bit indirect addressing on several different processors to show that it is not supported, because the manual is not taken seriously enough to be accepted as a proof. But in my experience the 64-bit mode is just some theoretic knowledge and I need to spend some time to get used to it. Also I need those different processors, but I have only one with 64-bit mode support

embryo wrote:

SpyderTL wrote:Can someone actually summarize all of this

But in my experience the 64-bit mode is just some theoretic knowledge and I need to spend some time to get used to it.

Are you saying that you have never actually done any 64-bit programming?

iansjack wrote:Are you saying that you have never actually done any 64-bit programming?

Well not in assembly yet... apart from OS code it hasn't been necessary to use asm so far.

embryo wrote:Actually we need to test 16-bit indirect addressing on several different processors to show that it is not supported

I don't think there is any way to encode a 16-bit address or SIB register in 64-bit mode, so you couldn't even test it.

I have verified that MASM will compile DI SIB offsets in 16-bit and 32-bit mode, but it gives a compile error in 64-bit mode, so I think that we can safely assume that the manual is correct when it says that 16-bit addresses are not available in 64-bit mode. And I think that we can assume that any code that compiles with MASM will run on both Intel and AMD 64-bit x86 processors.

But feel free to test it out yourself.

I'm just going to quote some disassembly to hopefully settle the matter: (i.e. 67h toggles to 32-bit addressing in long mode. Of course the whole original discussion was completely off topic because the post dealt with the matter of real mode, and if you attempt to assemble a 16-bit addressing mode in long mode your assembler will shout at you)

Owen wrote:Of course the whole original discussion was completely off topic because the post dealt with the matter of real mode

At the risk of making a long, pointless discussion even longer, and pointless-er...

I looked back a the original thread discussion (at least, what was left of it...) and the original post didn't specifically state that he was in 16-bit mode, although he did say he was working on a boot loader, and he did, eventually, post some code that made it pretty obvious. If you go back and look at just the original post, then embryo's response does become a little more relevant...

But, you are correct, there is no way to encode a 16-bit address or indirect register in long mode...

Hi,

SpyderTL wrote:But, you are correct, there is no way to encode a 16-bit address or indirect register in long mode...

In long mode you can use 16-bit addressing. In 64-bit code (e.g. excluding 16-bit and 32-bit code segments in long mode) you can't.


Cheers,

Brendan

iansjack wrote:Are you saying that you have never actually done any 64-bit programming?

Yes, my OS is happy using protected mode. 64-bits will be one of the next steps, but not now.

SpyderTL wrote:I don't think there is any way to encode a 16-bit address or SIB register in 64-bit mode, so you couldn't even test it.

It becomes even more interesting

I just compared two versions of Intel's manuals, one from 30.08.13 and second 30.07.14 (roughly a year later). And first tells us:

3.7.5.1 Specifying an Offset in 64-Bit Mode
The offset part of a memory address in 64-bit mode can be specified directly as a static value or through an address
computation made up of one or more of the following components:
• Displacement — An 8-bit, 16-bit, or 32-bit value.
• Base — The value in a 32-bit (or 64-bit if REX.W is set) general-purpose register.
• Index — The value in a 32-bit (or 64-bit if REX.W is set) general-purpose register.
• Scale factor —A value of 2, 4, or 8 that is multiplied by the index value.

While the second:

3.7.5.1 Specifying an Offset in 64-Bit Mode
The offset part of a memory address in 64-bit mode can be specified directly as a static value or through an address
computation made up of one or more of the following components:
• Displacement — An 8-bit, 16-bit, or 32-bit value.
• Base — The value in a 64-bit general-purpose register.
• Index — The value in a 64-bit general-purpose register.
• Scale factor —A value of 2, 4, or 8 that is multiplied by the index value.

Here we see, that Intel's writers actually had the mistake - they assumed that REX.W prefix should tell the processor not only about operand size, but also about the indirect addressing register size (and it in fact seems to agree with plain logic - register values here are actually just data, that is used to calculate address). But in the next edition the REX.W prefix is not mentioned any more and the only possible indirect addressing base and index register bit number now is 64. Does it mean that even 67h prefix doesn't work any more? Or more correctly - there is no guaranty, that it will always work.

So, the Intel's manuals are not very clear and even can change some important declarations as the time passes.

Hi,

embryo wrote:Here we see, that Intel's writers actually had the mistake - they assumed that REX.W prefix should tell the processor not only about operand size, but also about the indirect addressing register size (and it in fact seems to agree with plain logic - register values here are actually just data, that is used to calculate address). But in the next edition the REX.W prefix is not mentioned any more and the only possible indirect addressing base and index register bit number now is 64. Does it mean that even 67h prefix doesn't work any more? Or more correctly - there is no guaranty, that it will always work.

It means that the 67h prefix continues to work in the way that it's always (since the introduction of 64-bit code) been documented in most places by both Intel and AMD. Specifically, in 64-bit code you get 64-bit addressing as the default (without the 67h prefix), and 32-bit addressing with the prefix.

embryo wrote:So, the Intel's manuals are not very clear and even can change some important declarations as the time passes.

For all complex things there will be mistakes (including documentation, the CPUs themselves, and any non-trivial piece of software).


Cheers,

Brendan

Brendan wrote:in 64-bit code you get 64-bit addressing as the default (without the 67h prefix), and 32-bit addressing with the prefix.

Yes, but in previous version it was 32-bit default addressing (if there was no error in the manual).

Brendan wrote:For all complex things there will be mistakes (including documentation, the CPUs themselves, and any non-trivial piece of software).

Yes again