Understanding the x64 code models (2012)(eli.thegreenplace.net)
eli.thegreenplace.net
Understanding the x64 code models (2012)
https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models
18 comments
Reminds me of the various models for the original 8086. Far pointers are gone, but having to use registers is a similar tradeoff.
ชวน3ผม
This article might benefit from a (reasonably visible) note somewhere that none of this is relevant to dynamically allocated memory. While it may be obvious/known to most of the target audience, it could easily be misunderstood by intermediate-level readers.
The article doesn’t address what happens if you pick the wrong (too small) model. I guess the static linker will catch certain cases, and the dynamic linker/loader will catch certain other cases, but will all cases be caught by one of those two, or can the compiled instructions end up being executed, leading to incorrect memory accesses?
> The article doesn’t address what happens if you pick the wrong (too small) model.
The (static) linker will realize that an address won't fit, or that it can't generate a required relocation, and will fail to generate an executable.
The (static) linker will realize that an address won't fit, or that it can't generate a required relocation, and will fail to generate an executable.
I wonder what busybox_x86-64 does.
https://busybox.net/downloads/binaries/1.35.0-i686-linux-mus...
https://busybox.net/downloads/binaries/1.35.0-i686-linux-mus...
That’s only for non-shared (static) symbols though, if my understanding is correct.
I've never seen any real-world example where the large code model is being used on x64. Perhaps it's because I've seen programs where that's necessary. Perhaps the mythical 1.5GB Facebook binary (in 2012) that requires BitTorrent would use a non-small code model?
Minor nitpick: the author uses "Linux" as a keyword and uses gcc for examples but refers to the architecture as x64, which is a very Microsoft thing and a bit of a misnomer.
...refers to the architecture as x64, which is a very Microsoft thing and a bit of a misnomer.
No, it is not. Various Linux distributions even refer to it as "x64" in various places:
https://access.redhat.com/ecosystem/software/1474383 https://developers.redhat.com/products/openjdk/download https://support.quest.com/download-install-detail/6109808
With that said, I personally use "amd64" which coincidentally, is the same thing Microsoft refers to it various places including Windows packaging itself:
https://docs.microsoft.com/en-us/windows/win32/midl/-amd64
This is definitely not a Microsoft thing.
No, it is not. Various Linux distributions even refer to it as "x64" in various places:
https://access.redhat.com/ecosystem/software/1474383 https://developers.redhat.com/products/openjdk/download https://support.quest.com/download-install-detail/6109808
With that said, I personally use "amd64" which coincidentally, is the same thing Microsoft refers to it various places including Windows packaging itself:
https://docs.microsoft.com/en-us/windows/win32/midl/-amd64
This is definitely not a Microsoft thing.
> but refers to the architecture as x64
What do you think the correct name is? I call it AMD64, as that's the name the authors gave it. But they also previously called it x86-64, so maybe that's valid.
x86_64, x64, etc, no idea why people had to come up with their own names beyond AMD64 or x86-64!
What do you think the correct name is? I call it AMD64, as that's the name the authors gave it. But they also previously called it x86-64, so maybe that's valid.
x86_64, x64, etc, no idea why people had to come up with their own names beyond AMD64 or x86-64!
While I default to AMD64, Intel 64 is the latest variant from the eponymous manufacturer.
There is some justification for Intel 64, as AMD suffered a series of mistakes and bad decisions, starting with the "Barcelona" Opterons, only recently emerging from these problems.
Intel has been the best-performing AMD64 implementation for much of this standard's time on the market, so a little revisionism must be excused.
There is some justification for Intel 64, as AMD suffered a series of mistakes and bad decisions, starting with the "Barcelona" Opterons, only recently emerging from these problems.
Intel has been the best-performing AMD64 implementation for much of this standard's time on the market, so a little revisionism must be excused.
Intel 64 ? You mean the Itanic ?
"Various names are used for the instruction set. Prior to the launch, x86-64 and x86_64 were used, while upon the release AMD named it AMD64. Intel initially used the names IA-32e and EM64T before finally settling on 'Intel 64' for its implementation. Some in the industry, including Apple, use x86-64 and x86_64, while others, notably Sun Microsystems (now Oracle Corporation) and Microsoft, use x64. The BSD family of OSs and several Linux distributions use AMD64, as does Microsoft Windows internally."
"The x86-64 architecture is distinct from the Intel Itanium architecture (formerly IA-64). The architectures are not compatible on the native instruction set level, and operating systems and applications compiled for one cannot be run on the other."
https://en.wikipedia.org/wiki/X86-64#cite_note-11
"The x86-64 architecture is distinct from the Intel Itanium architecture (formerly IA-64). The architectures are not compatible on the native instruction set level, and operating systems and applications compiled for one cannot be run on the other."
https://en.wikipedia.org/wiki/X86-64#cite_note-11
No that's IA-64 - that's something else entirely. Intel 64 != IA-64.
What are you talking about? It's either Intel 64 or IA-32e, anything else is a misnomer! /s
Don't forget EM64T!