Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I read in wikipedia, that the x86-64 or amd64 (or how you want to call that ) has a virtual address space of 48bit. But all pointers have 64bit, haven't they? So, does the processor just ignore the higher 16bits? So that 0xFFFFFFFFFFFF equals 0xFFFFFFFFFF?
The high bits all have to be set to either all 1s or all 0s, the processor won't use them but will make sure they are all the same. If they aren't all the same then the CPU will raise a GPF.
Long mode defines 64 bits of virtual-address space, but processor implementations can support less. Although some processor implementations do not use all 64 bits of the virtual address, they all check bits 63 through the most-significant implemented bit to see if those bits are all zeros or all ones. An address that complies with this property is in canonical address form. In most cases, a virtual-memory reference that is not in canonical form causes a general-protection exception (#GP) to occur. However, implied stack references where the stack address is not in canonical form causes a stack exception (#SS) to occur. Implied stack references include all push and pop instructions, and any instruction using RSP or RBP as a base register.
By checking canonical-address form, the AMD64 architecture prevents software from exploiting unused high bits of pointers for other purposes. Software complying with canonical-address form on a specific processor implementation can run unchanged on long-mode implementations supporting larger virtual-address spaces.
AMD's AMD64 Architecture Programmer's Manual Volume 2: System Programming. Section 1.1.3 (Canonical Address Form). Page 45/500 of the PDF.
About the naming scheme, the story as I heard it is AMD called it "x86-64" originally but then Intel decided to rename "x86" to "IA-32". In response AMD renamed "x86-64" to "AMD64". Intel was eventually forced to choke on their own medicine ("IA-64" flopped) but being as hypocritical as they are, they decided to change "AMD64" to "EM64T" for use with their processors.
AR wrote:
The high bits all have to be set to either all 1s or all 0s, the processor won't use them but will make sure they are all the same. If they aren't all the same then the CPU will raise a GPF.
[tt]>_<[/tt] ouch ... that's certainly some awkward thing.
Pype.Clicker wrote:
[tt]>_<[/tt] ouch ... that's certainly some awkward thing.
I guess the idea is to lower the risk of wild pointers, which will hardly have all upper 16 bits set the same. But IMO they should have implemented full 64bit virtual addresses instead.
That feature is for binary compatibility most likely. ie. a 48bit program that uses the upper bits for some sort of flags would go nuts on a CPU that was truly 64bit. Of course, I personally would have demanded all zeros, not either all 1s or 0s.
hmm .. i see the idea. Imagine i'd like to exploit those bits so that a string will be
(&thestring) | STRING_TAG and an object is (&theobject) | OBJECT_TAG ... It would be tempting to use the high 15 "unused" bits so that they encode something (? la LISP machine), but as soon as one decide to make the virtual address space 49 bits rather than 48, you no longer can work with those programs ...
I'm a bit surprised, though, that there's no bit in control registers that enable/disable that canonical addresses enforcement. That'd be a good thing to be able to select whether you prefer 48-bits virtual addresses with type-carrying pointers or canonical addresses (potentially extensible to 64 bits address space)
I'm wondering why they didn't implement full 64-bit addressing in the first place. It's not like they've made 32-bit software portable to long mode or anything, is it?
Crazed123 wrote:
I'm wondering why they didn't implement full 64-bit addressing in the first place. It's not like they've made 32-bit software portable to long mode or anything, is it?
I think they just didn't see a need for more than 2^48 bytes of virtual address space (I know.....what for ). Maybe they just wanted to keep the page tables simpler, since in amd64's paging structures, you'd need one page table level for each 9bits of addresses (still 4kb pages). They targetted also home desktops, which hardly have 1GB of memory installed, using shorter addresses would produce less overhead with paging stuff.
But I believe the length of addresses is subject to change in the future, then they will probably add a control bit for 'legacy' (48bit) mode too.
48bit is still approximately 280TB of RAM. (Page tables are 4 levels, 512*512*512*512) The maximum size allowed in the specification is 52bit physical addressing, 48bit virtual addressing.
Additionally, AFAIK AMD CPUs support 48bits virtual addressing, 52bits physical addressing, IIRC Intel CPUs support less though.
) has a virtual address space of 48bit. But all pointers have 64bit, haven't they? So, does the processor just ignore the higher 16bits? So that 0xFFFFFFFFFFFF equals 0xFFFFFFFFFF?
). Maybe they just wanted to keep the page tables simpler, since in amd64's paging structures, you'd need one page table level for each 9bits of addresses (still 4kb pages). They targetted also home desktops, which hardly have 1GB of memory installed, using shorter addresses would produce less overhead with paging stuff.