I have a simple (but performance critical) algorithm in C (embedded in C++) to manipulate a data buffer... the algorithm 'naturally' uses 64-bit big-endian register values - and I'd like to optimise this using assembler to gain direct access to the carry flag and BSWAP and, hence, avoid having to manipulate the 64-bit values one byte at a time.
I want the solution to be portable between OS/Compilers - minimally supporting GNU g++ and Visual C++ - and between Linux and Windows respectively. For both platforms, obviously, I'm assuming a processor that supports the x86-64 instruction set.
I've found this document about inline assembler for MSVC/Windows, and several fragments via Google detailing an incompatible syntax for g++. I accept that I might need to implement this functionality separately in each dialect. I've not been able to find sufficiently detailed documentation on syntax/facilities to tackle this development.
What I'm looking for is clear documentation detailing the facilities available to me - both with MS and GNU tool sets. While I wrote some 32-bit assembler many years ago, I'm rusty - I'd benefit from a concise document detailing facilities are available at an assembly level.
A further complication is that I'd like to compile for windows using the Visual C++ Express Edition 2010... I recognise that this is a 32-bit compiler - but, I wondered, is it possible to embed 64-bit assembly into its executables? I only care about 64-bit performance in the section I plan to hand-code.
Can anyone offer any pointers (please pardon the pun...)?
There are many functions available for swapping endianess, for example from BSD sockets:
64 bits is less portable:
Don't resort to assembly every time something is not expressible in standard C++.
By definition, asm statements in C or C++ are not portable, in particular because they are tied to a particular instruction set. In particular, don't expect your code to run on ARM, if your assembler statements are for x86.
Besides, even on the same hardware platform like 64 bits x86-64 (that is, modern PC-s), different systems (e.g. Linux vs Windows) have different assembler syntax and different calling conventions. So you should have several variants of your code.
If using GCC, it offers you a lot of builtin functions which can help you. And probably (assuming a recent GCC, ie. a 4.6 version), it is able to optimize quite efficiently your function.
If performance is very important, and if your system have a GPU (that is a powerful graphic card), you might consider recoding numerical kernels in OpenCL or in CUDA.
Just to give you a taste of the obstacles that lie in your path, here is a simple inline assembler function, in two dialects. First, the Borland C++ Builder version (I think this compiles under MSVC++ too):
Now, the g++ version:
As you can see, the differences are major. And there is no way around them. These are from a large integer arithmetic library that I wrote for a 32-bit environment.
As for embedding 64-bit instructions in a 32-bit executable, I think this is forbidden. As I understand it, a 32-bit executable runs in 32-bit mode, any 64-bit instruction just generates a trap.
Inline assembler is not one of your possibilities: Win64 Visual C compilers do not support
__asm
, you'll need to use seperate [m|y|n]asm-compiled files.Unfortunately, MSVC++ doesn't support inline assembly in 64-bit code and it does not support __emit either. With MSVC++ you should either implement pieces of code in separate .asm files and compile and link them with the rest of the code or resort to dirty hacks like the following (implemented for 32-bit code as proof of concept):
Output:
0x40302010
I think you should be able to do the same not only with gcc but also Linux with about two minor differences (VirtualProtect() is one, calling conventions is the other).
EDIT: Here's how BSWAP can be done for 64-bit values in 64-bit mode on Windows (untested):
And the rest is trivial.