OSDev.org

The Place to Start for Operating System Developers
It is currently Wed May 24, 2017 11:34 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: The DI not supported incident
PostPosted: Wed Oct 08, 2014 2:42 pm 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 993
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: VGA Mode 13h

"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Thu Oct 09, 2014 4:17 am 
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:
Quote:
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.


Top
  
 
 Post subject: Re: The DI not supported incident
PostPosted: Thu Oct 09, 2014 4:23 am 
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 :(


Top
  
 
 Post subject: Re: The DI not supported incident
PostPosted: Thu Oct 09, 2014 4:55 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 2789
Location: Chichester, UK
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:


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Thu Oct 09, 2014 5:22 am 
Offline
Member
Member
User avatar

Joined: Wed May 21, 2008 4:33 am
Posts: 294
Location: Mars MTC +6:00
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 (probably)

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Thu Oct 09, 2014 6:19 am 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 993
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: VGA Mode 13h

"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Thu Oct 09, 2014 9:35 am 
Offline
Member
Member
User avatar

Joined: Fri Jun 13, 2008 3:21 pm
Posts: 1700
Location: Cambridge, United Kingdom
I'm just going to quote some disassembly to hopefully settle the matter:
Code:
   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)


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Thu Oct 09, 2014 11:58 am 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 993
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: VGA Mode 13h

"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Fri Oct 10, 2014 1:12 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7896
Location: At his keyboard!
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.


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Fri Oct 10, 2014 3:34 am 
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.


Top
  
 
 Post subject: Re: The DI not supported incident
PostPosted: Fri Oct 10, 2014 3:53 am 
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:
Quote:
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:
Quote:
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.


Top
  
 
 Post subject: Re: The DI not supported incident
PostPosted: Fri Oct 10, 2014 10:29 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7896
Location: At his keyboard!
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.


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Sat Oct 11, 2014 3:10 am 
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 :)


Top
  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group