31–40 of 54 posts
Earlier quoted context omitted.
AFAIK the reason for amd64 being what it is are intels lawyers.
That makes little sense, could you elaborate? AMD could have done anything they wanted with amd64 instruction encodings.
Earlier quoted context omitted.
> As you might imagine code size is a significant challenge for Facebook Maybe I'm missing something obvious, but why is code size a big concern for Facebook's server code?
"Because Facebook's entire code base is compiled down to a single binary executable, the company's deployment process is quite different from what you'd normally expect in a PHP environment. Rossi told me that the binary, which represents the entire Facebook application, is approximately 1.5GB in size." http://arstechnica.com/business/2012/04/exclusive-a-behind-t...
Earlier quoted context omitted.
> It's all RISC under the hood anyway, why not give us access to it? Presumably because it doesn't matter that much, so it isn't worth the investment for Intel. It feels to me like people have trouble accepting that both of these are true: (1) RISC vs. x86 doesn't matter that much in practice; (2) technically speaking, RISC is a superior design to x86.
> Presumably because it doesn't matter that much, so it isn't worth the investment for Intel. Intel invested in a new instruction set (IA64). AMD did not. The market chose AMD's offering.
The lesson I take from history is that there is no need to maintain ISA compatibility as long as the old mode is accessible on a process level.
"The C calling convention on x86 systems specifies that callees need to save certain registers."
Practically speaking is this the prologue that that C run time - crt0.o provides automatically/implicitly?
Earlier quoted context omitted.
This. In today's world it is easy to support multiple instruction sets in the same silicon using the same registers and ALU. So why in the name of all that is holy does the x86 not have a nice clean 64-bit instruction set that you can swap in? It's all RISC under the hood anyway, why not give us access to it? The only explanation I can think of is that Intel wants to keep things complicated as a barrier to entry for…
Related to this is the PPC615, an IBM project in the mid-90s, socket compatible with the original Pentium, and ran x86-32, PPC32, and PPC64 natively. (It got scrapped because all the signs looked like Intel was going to push IA-64 heavily, and rely on it's backwards compatibility for x86-32, hence an expectation x86-32 was soon to be legacy.)
I had a question about this statement in the artcile: "The C calling convention on x86 systems specifies that callees need to save certain registers." Practically speaking is this the prologue that that C run time - crt0.o provides automatically/implicitly?
crt0.o is the glue between how the kernel loads a program into memory and how main() expects things to work. it does basic setup tasks that can vary between platforms, but is generally things like collecting command line arguments and setting up the stack. it will also invoke exit() if main() returns, since that's how the kernel expects the process to be destroyed
I had a question about this statement in the artcile: "The C calling convention on x86 systems specifies that callees need to save certain registers." Practically speaking is this the prologue that that C run time - crt0.o provides automatically/implicitly?
I had a question about this statement in the artcile: "The C calling convention on x86 systems specifies that callees need to save certain registers." Practically speaking is this the prologue that that C run time - crt0.o provides automatically/implicitly?
no, the compiler does this when generating code for functions and function calls crt0.o is the glue between how the kernel loads a program into memory and how main() expects things to work. it does basic setup tasks that can vary between platforms, but is generally things like collecting command line arguments and setting up the stack. it will also invoke exit() if main() returns, since that's how the kernel expects…
When you say "how the kernel loads a program into memory" I assume you are referring to ld-linux.so.2? Is that correct?
I imagine then that ld-linux.so.2 calls __start in crt0.o and crt0.o jumps to main(). Is this correct?
Earlier quoted context omitted.
That makes little sense, could you elaborate? AMD could have done anything they wanted with amd64 instruction encodings.
Well, not lawyers directly. More through lack of cooperation (due to competitive mentality). http://www.agner.org/optimize/blog/read.php?i=25
Earlier quoted context omitted.
> Presumably because it doesn't matter that much, so it isn't worth the investment for Intel. Intel invested in a new instruction set (IA64). AMD did not. The market chose AMD's offering.
And the market also chose ARM's AArch64 instruction set, despite the ARM installed base being wider than x86 and a backwards incompatible break from the past. The secret? Supporting both ISAs and switching instruction sets on exceptions. The lesson I take from history is that there is no need to maintain ISA compatibility as long as the old mode is accessible on a process level.
The secret is that Apple controls their hardware/appstore and android apps are ISA independent.