Running 32-bit assembler code on 64-bit lazarus (Linux)

[MainMeat]

Hi Everyone,

I have a function from the faststrings.pas unit that I use within my code. (http://www.swissdelphicenter.ch/torry/showcode.php?id=1857)

 I want to try and compile my code on a 64-bit lazarus platform but this function causes an Exception when called. Compiling on a 32-bit version of Lazarus and running the code has not issues. My assembler knowledge is somewhat minimal and I was wondering if someone can please guide me as to what I need todo to get this section of code to compile and run on a 64-bit CentOS linux platform:

Code: [Select]

procedure FastCharMove(const Source; var Dest; Count : Integer);
begin
  {$ASMMODE intel}
  asm
  //Note:  When this function is called, the parameters are passed as follows
  //ECX = Count
  //EAX = Const Source
  //EDX = Var Dest

        cmp   ECX,0
        Je    @JustQuit

        push  ESI
        push  EDI

        mov   ESI, EAX
        mov   EDI, EDX

    @Loop:
        Mov   AL, [ESI]
        Inc   ESI
        mov   [EDI], AL
        Inc   EDI
        Dec   ECX
        Jnz   @Loop

        pop   EDI
        pop   ESI
    @JustQuit:
  end;
end;


Any help is appreciated as always

[Bart]

I do not have an anwer, but a question: Is this faster than standard fpc system.move()?

Bart

[MainMeat]

Bart,

This code comes from Kylix days where MidStr was slower and this assembler function did make a significant difference in copying data within strings.

Do you know if MidStr in FreePascal is improved - because then I simply continue using it and need not worry about assembler code maintenance.

In the meantime, if there are any assembler knowledge out there, please feel free to give your inputs!

[Bart]

I do know that in Delphi many asm procedures/functions have been replaced by plain pascal, without speed loss (in many cases speed gain), probably because the compiler generates better optomized asm code...

Bart

[Bart]

Just tested FastCharMove against System.Move on win32 (fpc 2.6.0).
Moving 1024*1024*256 bytes:

FastCharMove: 328 (TickCounts)
System.Move: 78 (TickCounts)

I would ditch the FastCharMove.
As an advantage System.Move is portable to all supported OS's and architectures.

Bart

[Leledumbo]

The function assumes 32-bit (Object Pascal / Delphi) fastcall calling convention, which is why it crashes on 64-bit. I don't have any document pointing to the corresponding ABI but AFAIK 64-bit has only 1 convention.

My test using both Windows.GetTickCount and SysUtils.Now + DateUtils.MilliSecondSpan shows the same result as Bart. Indeed System.Move is faster than this FastCharMove, with portability as a bonus.

[Rekumkacz]

And now for something completely different.

In the code, I want to reuse are registers esi and edi . The program compiles, but appears
"access violation" error

How to eat this cake?

[howardpc]

Does your code restore the values esi and edi held before you filled them with different values?

[Laksen]

It's dereferencing a 32bit pointer. If your pointer is pointing to 0xFFFFFFFF12345678 you will be trying to read 0x0000000012345678.

You eat the cake by either using Pascal or learning assembly