Embed assembler to manipulate 64-bit registers in

2020-02-01 16:00发布

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...)?

5条回答
劫难
2楼-- · 2020-02-01 16:08

There are many functions available for swapping endianess, for example from BSD sockets:

uint32_t htonl(uint32_t hostlong);
uint16_t htons(uint16_t hostshort);
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort);

64 bits is less portable:

unsigned __int64 _byteswap_uint64(unsigned __int64); // Visual C++
int64_t __builtin_bswap64 (int64_t x). // GCC

Don't resort to assembly every time something is not expressible in standard C++.

查看更多
Bombasti
3楼-- · 2020-02-01 16:17

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.

查看更多
相关推荐>>
4楼-- · 2020-02-01 16:18

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):

int BNASM_AddScalar (DWORD* result, DWORD x)
  {
  int carry = 0 ;
  __asm
    {
    mov     ebx,result
    xor     eax,eax
    mov     ecx,x
    add     [ebx],ecx
    adc     carry,eax    // Return the carry flag
    }
  return carry ;
  }

Now, the g++ version:

int BNASM_AddScalar (DWORD* result, DWORD x)
  {
  int carry = 0 ;
  asm volatile (
"    addl    %%ecx,(%%edx)\n"
"    adcl    $0,%%eax\n"    // Return the carry flag
: "+a"(carry)         // Output (and input): carry in eax
: "d"(result), "c"(x) // Input: result in edx and x in ecx
) ;
  return carry ;
  }

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.

查看更多
一夜七次
5楼-- · 2020-02-01 16:23

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.

查看更多
唯我独甜
6楼-- · 2020-02-01 16:31

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):

#include <windows.h>
#include <stdio.h>

unsigned char BswapData[] =
{
  0x0F, 0xC9, // bswap ecx
  0x89, 0xC8, // mov   eax, ecx
  0xC3        // ret
};

unsigned long (__fastcall *Bswap)(unsigned long) =
  (unsigned long (__fastcall *)(unsigned long))BswapData;

int main(void)
{
  DWORD dummy;
  VirtualProtect(BswapData, sizeof(BswapData), PAGE_EXECUTE_READWRITE, &dummy);
  printf("0x%lX\n", Bswap(0x10203040));
  return 0;
}

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):

unsigned char BswapData64[] =
{
  0x48, 0x0F, 0xC9, // bswap rcx
  0x48, 0x89, 0xC8, // mov   rax, rcx
  0xC3              // ret
};

unsigned long long (*Bswap64)(unsigned long long) =
  (unsigned long long (*)(unsigned long long))BswapData64;

And the rest is trivial.

查看更多
登录 后发表回答