The DI not supported incident

Questions, comments, and suggestions about this site should go here.
User avatar
SpyderTL
Member
Member
Posts: 1074
Joined: Sun Sep 19, 2010 10:05 pm

Re: The DI not supported incident

Post by SpyderTL »

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! :mrgreen:

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."
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
embryo

Re: The DI not supported incident

Post by embryo »

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.
embryo

Re: The DI not supported incident

Post by embryo »

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 :(
User avatar
iansjack
Member
Member
Posts: 4682
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: The DI not supported incident

Post by iansjack »

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? :oops:
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: The DI not supported incident

Post by b.zaar »

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.
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
User avatar
SpyderTL
Member
Member
Posts: 1074
Joined: Sun Sep 19, 2010 10:05 pm

Re: The DI not supported incident

Post by SpyderTL »

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. :)
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
User avatar
Owen
Member
Member
Posts: 1700
Joined: Fri Jun 13, 2008 3:21 pm
Location: Cambridge, United Kingdom
Contact:

Re: The DI not supported incident

Post by Owen »

I'm just going to quote some disassembly to hopefully settle the matter:

Code: Select all

   0:   67 8b 44 24 08          addr32 mov 0x8(%esp),%eax
   5:   67 48 8b 44 24 08       addr32 mov 0x8(%esp),%rax
   b:   8b 44 24 08             mov    0x8(%rsp),%eax
   f:   48 8b 44 24 08          mov    0x8(%rsp),%rax
  14:   c3                      retq
(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)
User avatar
SpyderTL
Member
Member
Posts: 1074
Joined: Sun Sep 19, 2010 10:05 pm

Re: The DI not supported incident

Post by SpyderTL »

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...
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: The DI not supported incident

Post by Brendan »

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. 8)


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
embryo

Re: The DI not supported incident

Post by embryo »

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.
embryo

Re: The DI not supported incident

Post by embryo »

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.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: The DI not supported incident

Post by Brendan »

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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
embryo

Re: The DI not supported incident

Post by embryo »

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 :)
Post Reply