I've written a small standalone assembly language application for 64 bit Linux. I wrote it with NASM, but YASM should work, too.
The program prints first a zero terminated C string and after that some values (32 bit unsigned integer, 64 bit unsigned integer, REAL 4 value, REAL 8 value). At the end it displays a CPU register dump. I'm currently working at the co-processor dump (the old FPU and the new XMM registers).
For linking information, please read the readme.txt, it's part of the archive.
Basically it is not so easy to develop for both platforms (Win64 and Linux64) in parallel, because the underlying ABIs are different. The current version of the 64 bit Linux ABI can be found here: http://www.x86-64.org/documentation/ (http://www.x86-64.org/documentation/)
Gunther
Gunther, interesting and informative example! :t
Is the libc linked statically, or as "import library"? It's interesting that, for instance, the format-specifier strings are passed as a 32 bit pointers inside of the 64 bit space. If the libc linked as the import library, it should calculate the effective offset, or it lies "near", in the +/- 2 GB address range?
Hi Alex,
Quote from: Antariy on July 14, 2012, 11:21:13 AMGunther, interesting and informative example! :t
Thank you, Alex.
Quote from: Antariy on July 14, 2012, 11:21:13 AMIs the libc linked statically, or as "import library"? It's interesting that, for instance, the format-specifier strings are passed as a 32 bit pointers inside of the 64 bit space. If the libc linked as the import library, it should calculate the effective offset, or it lies "near", in the +/- 2 GB address range?
The archive contains both variants. So, the truth is: I was to lazy to write my own I/O procedures; therefore the application uses libc. Your question about the address space is interesting. I think we've to check that with a look into the present libc source code.
Gunther
Quote from: Gunther on July 15, 2012, 04:34:30 AM
Your question about the address space is interesting.
See this thread in the old forum (http://www.masmforum.com/board/index.php?PHPSESSID=786dd40408172108b65a5a36b09c88c0&topic=18556.0)
Quotethey have created a special ABI called x32 which allows programs to use 32-bit pointers while still being able to utilize the 64-bit extended registers from standard 64bit mode. Using 64-bit address references makes the code larger and thus fills up the cpu caches faster, so by using 32-bit adress references while still using the extra registers from 64-bit mode they were apparently able to get the same code to run ~15% faster in x32 abi mode compared to pure 64bit mode
Jochen,
Quote from: jj2007 on July 15, 2012, 04:44:36 AM
See this thread in the old forum (http://www.masmforum.com/board/index.php?PHPSESSID=786dd40408172108b65a5a36b09c88c0&topic=18556.0)
thank you for that hint; that's the answer of the question.
Gunther
Quote from: jj2007 on July 15, 2012, 04:44:36 AM
See this thread in the old forum (http://www.masmforum.com/board/index.php?PHPSESSID=786dd40408172108b65a5a36b09c88c0&topic=18556.0)
Thank you, Jochen :t
Yeah, it seem they are locate an import runtime in the "near" space of +/- 2 GB range relatively to the program's (calling) code.
Hi Alex,
Quote from: Antariy on July 15, 2012, 08:13:50 AM
Thank you, Jochen :t
Yeah, it seem they are locate an import runtime in the "near" space of +/- 2 GB range relatively to the program's (calling) code.
according to the above link, yes. Right or wrong: in the next time I'll check that question again with the libc sources.
Gunther