how to replace inline assember for 64bit compiles?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 8 of 8

Thread: how to replace inline assember for 64bit compiles?

  1. #1
    Join Date
    Jun 2004
    Posts
    3

    Question how to replace inline assember for 64bit compiles?

    Im looking for a fast and easy way to convert/replace c++ inline assembler with something that work for VS 2003/2005 in 64bit compile mode.

    Since inline assembler isnt supported anymore for 64bit i run into big troubles on heavy optimized asm code.
    Putting all in a extern .asm file is an option but a pain to do. Using compiler intrinsics works but its kinda slow since the return type of every command is a __m64 or __m128 type (memory location) i cant tell the compiler to use temp registers and keep the data simple in the register and use the result from there direct for the next instructions... This is very problematic on hug dep. chains wich cause large memory load/stores beetwen every instruction.

    Anyone have a idea?

  2. #2
    Join Date
    Dec 2003
    Location
    Okla, US
    Posts
    126
    Sounds like you have a lot of assembly to translate.

    I don't know how you would go about correcting your problem. However, I believe the syntax of the assembly is MASM, I would also check out some MASM boards, such as http://board.win32asmcommunity.net and http://www.masmforum.com

    Maybe jonnin or Danny could be of more help than myself

    Good Luck,
    Last edited by gorshing; 06-19-2004 at 06:45 PM.
    gorshing
    newb

  3. #3
    Join Date
    Nov 2003
    Posts
    4,118
    This is a common scneario that repeats itself every decade or so when ahrdware arhcitecture changes radically. The sad news is that in most cases, an automated conversion won't do because the very reason for using inline assembly in the first place is performance, and automated conversion tools almost without exception performs rather poorly in prodcing the most optimized code of the equiavlent assembly. However, I'm sure that Microsoft has a few migration tools that can alleviate the problem so you want to check MSDN. I will also try to look for a more pinpointed advice because I'm intrigued by this issue, too. There's no doubt that such posts will become more frequent with the adoption of 64 bit hardware.
    There's one tip I can give you: most inline assembly code is in fact machine generated. It's produced by compiling ordinary C/C++ code and hand optimizing it afterwards. If you can locate the original sources that were used for generating the assembly code for 32 bit systems, your job might be easier.
    Danny Kalev

  4. #4
    Join Date
    Jun 2004
    Posts
    3
    yes my inline asm code is coded for max. performance and i cant replace it with intrinsics or c++ stuff. I still cant understand why MS dont support inline ASM for there 64bit compiler... its a puch in the face, since inline asm is realy nice (not perfect and safe) but its the easyest and fastest way to optimize loopholes.

    Btw u maybe know if gcc 3.4 can compile 64bit and allow the use of his own AT&T inline asm? Cause of the better register allocation and macro function this would be the best solution to me. U just define the variables as "r" general register and gcc loads them in 32bit in normal regs and can use the 8 add regs in 64 mode? U still have to write a seperate version to use the 8 add xmm regs but this is np, maybe some tricky #defines or macros can also work for the same inline asm block.

    For me its fairly easy to convert from intel syntax to at&t rather than writing a total new extern masm file.
    Last edited by Andy2222; 06-21-2004 at 09:12 AM.

  5. #5
    Join Date
    Dec 2003
    Posts
    3,366
    im still in 32 bit mode, and probably will be until pc104 has a 64 bit option, so im no help here

  6. #6
    Join Date
    Nov 2003
    Posts
    4,118
    i think there's a GCC 64 bit version but I'd rather look at Intel's compiler instead. MS disables inline assembly because of security reasons, I believe. Admittedly, inline asm gives you the best performance but it could also be the biggest threat to the system's stability (and security). Not that I agree with this policy of blocking asm altogether, but that's probably the reason behind this. Anyway, you do have other compilers, so try to see if they can give you what you want. Please keep us posted on your progress.
    Last edited by Danny; 06-21-2004 at 08:59 PM.
    Danny Kalev

  7. #7
    Join Date
    Jun 2004
    Posts
    3
    i gave up using intel 7.1 or 8.0 compiler for this project, me and some others already posted this at the intel forum, but for some projects the compiled code runs 20-40% slower than a simple VC6 blend compile... Since i dont have time to pinpoint every single intel compiler problem im using VC7.1/8.0 or gcc 3.4.
    The main reason i want to use VC over Gcc are the great new features in the upcoming Vc 8.0, like PGO and other stuff. I also like the easy to use and perfect debug modes Visual Studio offer..

    The strange thing is with vc or gcc compiles i never got such a huge performance drop and i also tested various settings with the intel compiler and i never got a faster compile out of the intel compiler compared to vc6 or gcc 3.4 ....

    PS: i dont think the intel compiler will allow AMD64 bit compiles :) u cant even run Vtune on AMD cpus...
    So i bet the best solution is to get gcc running with the code and convert all to gcc syntax. I dont think gcc will remove inline assembly for the 64bit mode? Yes i know inline assembly is a huge security risk but it should be the choice of the coder not MS if i wnat to use it.... or at least they need to fully optimize and upgrade there crappy intrinsic support...
    Last edited by Andy2222; 06-21-2004 at 09:35 PM.

  8. #8
    Join Date
    Dec 2003
    Posts
    3,366
    Yea its the "java"mentality of "the compiler knows best". ASM does not pose any threats because the OS is responsible for thwarting exploits. But the trend is to push hoards of "hands off" programmers through the schools, and protect the software industry by denying them access to "dangerous" programming elements (pointers, asm, direct hardware access, etc).

    The real reason behind some of the decisions, my opinion from watching for a long time, is that Intel and MS seem to have an unspoken agreement. MS offers bloat, so Intel can sell bigger, faster cpu's. MS gets to offer "new" versions of the same old thing (with more bloat) and Intel gets to sell new systems, lather, rinse, repeat...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center