User: Password:
|
|
Subscribe / Log in / New account

Inline i386 assembly

Inline i386 assembly

Posted Feb 19, 2005 15:39 UTC (Sat) by stock (guest, #5849)
Parent article: Some Thoughts on the Current State of 64-bit Computing

The big hurdle needed to take in order to move to a 64bit clean source code tree of a Linux distro is as mentioned the binary only applications like graphics drivers, audio and video codecs and things like flash plugins. Besides that numerous applications carry some inline i386 assembly inside its source code. For a example see the kwave project on kwave.sourceforge.net and my contribution to that on http://crashrecovery.org/mp3-ripkit/kwave/mdk101/ . Mostly assembly commands are used to "probe" for CPU capabilities :

         
diff -u -r kwave-0.7.2/libkwave/cputest.c          
kwave-0.7.2.amd64/libkwave/cputest.c          
--- kwave-0.7.2/libkwave/cputest.c	2004-12-30 04:09:35.000000000          
+0100          
+++ kwave-0.7.2.amd64/libkwave/cputest.c	2004-12-30          
04:31:16.791294000 +0100          
@@ -14,6 +14,14 @@          
  *   cleanly within this new environment          
  *   by Thomas Eschenbacher (Thomas.Eschenbacher@gmx.de)          
  *   had to include config.h and cputest.h          
+ *          
+ * 2004-12-30          
+ *   As is stated on http://www.tortall.net/projects/yasm/wiki/AMD64 :          
+ *   "Instructions that modify the stack (push, pop, call, ret, enter,          
+ *    and leave) are implicitly 64-bit. Their 32-bit counterparts are    
+ *    not available, but their 16-bit counterparts are."          
+ *   Adjusted the failing popl %0 commands when compiling on                
+ *   AMD64/X86_64 by Robert M. Stockmann (stock@stokkie.net)          
  */          
           
 #ifdef HAVE_CONFIG_H          
@@ -47,7 +55,11 @@          
                           /* See if CPUID instruction is supported ...          
*/          
                           /* ... Get copies of EFLAGS into eax and ecx          
*/          
                           "pushf\n\t"          
+#if defined(__x86_64__) || defined(__amd64__)          
+			  "popq %%rax\n\t"          
+#else          
                           "popl %0\n\t"          
+#endif          
                           "movl %0, %1\n\t"          
           
                           /* ... Toggle the ID bit in one copy and store          
*/          
@@ -58,7 +70,11 @@          
           
                           /* ... Get the (hopefully modified) EFLAGS */          
                           "pushf\n\t"          
-                          "popl %0\n\t"          
+#if defined(__x86_64__) || defined(__amd64__)          
+			  "popq %%rax\n\t"          
+#else          
+			  "popl %0\n\t"          
+#endif          
                           : "=a" (eax), "=c" (ecx)          
                           :          
                           : "cc"          
          
As one can see the devil is inside the dirty details. Then again, things like assembly optimizations on CPU's like AMD64 should never exceed finding CPU capabilities IMHO, as this iron is blinding fast as it is, one just needs to find its capabilties. e.g. Mplayer also has its complications with some inline assembly c-code. But again these problems can be solved.

Just remember that projects like openssl also stopped buggering about its optimized i386 assembly c-code in Intel EMT64 and AMD64 cpu's. The real problem currently is indeed inside things like 64bit drivers for Video cards and 3rd party applications like Adobe Acrobat reader. But that also should be a matter of time.


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds