ASM in Lazarus

[plusplus]

Code:

begin
  AInt := Args[i];
  asm push AInt; end;
end;

the code above works in all versions of delphi, I have set {$asmmode intel} but it seams the push is not working, does anyone have an opinion why that could be.

Cheers

PS: I am working x64 windows version of lazarus 0.9.30

[implementation]

What means "is not working"?

[plusplus]

Zitat:

Zitat von implementation (Beitrag 1114209)

What means "is not working"?

well its not pushing the value. I get always 0. Actually i get a silent access violation when I call push. its really weird. is there an alternative command for push in asm?

[JamesTKirk]

Zitat:

Zitat von plusplus (Beitrag 1114204)

Code:

begin
  AInt := Args[i];
  asm push AInt; end;
end;

the code above works in all versions of delphi, I have set {$asmmode intel} but it seams the push is not working, does anyone have an opinion why that could be.

Cheers

PS: I am working x64 windows version of lazarus 0.9.30

I don't have a x64 version available to test, put try to replace "push" with "pushq".

You might also want to read this regarding the calling convention used on 64-Bit Windows systems (also note the second last paragraph about "push" and "pop").

Regards,
Sven

[plusplus]

@JamesTKirk
Thank you man, but pushq is an invalid operand.

Below is actually the code that worked in Delphi, and I am trying to port it to Laz.
Weird thing is, x64 push raises a silent exception and on x86 it crashes the app. I have tried many variations and yet no result.

Please if anyone knows what is wrong, help me. Or if anyone has a diff solution for calling dll's dynamically with dynamic parms, please let me know.

I am trying to make this work on Lazaruz 0.90, for x64 and x86 on Win, Lin, and Mac.

Code:

function DynamicDllCallName(Dll: String; const Name: String; HasResult: Boolean; var Returned: Cardinal; const Parameters: array of Pointer): Boolean;
var
  prc: Pointer;
  x, n: Integer;
  p: Pointer;
  dllh: THandle;
begin
  dllh := GetModuleHandle(PChar(Dll));
  if dllh = 0 then begin
    dllh := LoadLibrary(PChar(Dll));
  end;
  if dllh <> 0 then begin
    prc := GetProcAddress(dllh, PChar(Name));
    if Assigned(prc) then begin
      n := High(Parameters);
      if n > -1 then begin
        x := n;
        repeat
          p := Parameters[x];
          asm
            PUSH p
          end;
          Dec(x);
        until x = -1;
      end;
      asm
        CALL prc
      end;
      if HasResult then begin
        asm
          MOV p, EAX
        end;
        Returned := Cardinal(p);
      end else begin
        Returned := 0;
      end;
    end else begin
      Returned := 0;
    end;
    Result := Assigned(prc);
  end else begin
    Result := false;
  end;
end;

[Namenloser]

You’re calling

Delphi-Quellcode:

push

right in the middle of your high level code – this is almost bound to cause problems because the asm code generated by the compiler from your source code most likely uses the stack, too. You were just lucky that it didn’t break before.

[plusplus]

Zitat:

Zitat von NamenLozer (Beitrag 1120912)

You’re calling

Delphi-Quellcode:

push

right in the middle of your high level code – this is almost bound to cause problems because the asm code generated by the compiler from your source code most likely uses the stack, too. You were just lucky that it didn’t break before.

Never had a problem from Delphi 3 on and upwards to Delphi XE, I haven't tested in XE2 but I am sure this code works there too.

I am trying to find a way to do the same in Lazarus. I also tried to make a simple call without any params
(so a simple

Delphi-Quellcode:

asm call proc; end;

)
and does not work either. I think this is a FPC bug.

[Namenloser]

Zitat:

Zitat von plusplus (Beitrag 1120930)

Never had a problem from Delphi 3 on and upwards to Delphi XE, I haven't tested in XE2 but I am sure this code works there too.

Maybe the Delphi compiler generates more optimized code that keeps everything in registers and avoids the stack for performance reasons?

Zitat:

Zitat von plusplus (Beitrag 1120930)

I am trying to find a way to do the same in Lazarus. I also tried to make a simple call without any params
(so a simple

Delphi-Quellcode:

asm call proc; end;

)
and does not work either. I think this is a FPC bug.

That’s strange. What kind of procedure are you calling and how is it declared? (calling convention?)

Also: Have you checked what instructions the FPC compiler actually generates? I don’t know if FPC/Lazarus comes with a debugger like the one included in Delphi where you can set a breakpoint somewhere in the source code and then switch to the cpu pane to see the generated asm code... that would be the easiest way. If there isn’t such a thing, you could always put an

Delphi-Quellcode:

asm int 3; end;

(which acts as a breakpoint) at the beginning of the routine and run it through an ordinary debugger (though it will be more difficult to figure out which opcodes correspond to which instruction in the source code that way). If it really is a bug in FPC, you may spot something here.

[jaenicke]

Zitat:

Zitat von plusplus (Beitrag 1120930)

Never had a problem from Delphi 3 on and upwards to Delphi XE, I haven't tested in XE2 but I am sure this code works there too.

Using 32-bit as target I think so too, but you won't be able to compile this for 64-Bit. Just because you can't put a few pieces assembler code in a procedure. You have to make the whole procedure use assembler in 64-Bit in XE2. ;-)

[JamesTKirk]

Zitat:

Zitat von plusplus (Beitrag 1120902)

Please if anyone knows what is wrong, help me. Or if anyone has a diff solution for calling dll's dynamically with dynamic parms, please let me know.

I am trying to make this work on Lazaruz 0.90, for x64 and x86 on Win, Lin, and Mac.

In that case I'd personally suggest you to take a look at the library libffi, which stands for Foreign Function Interface and seems to allow what you want to achive. As it's used by other projects like Java Native Access (an alternative to JNI) it should be mature enough and it also supports different processor and OS combinations. The only downside is that it seems that you'll need to manually compile it for Win32 and Win64 using the approbiate MinGW environment (the 32 and the 64 bit one).

Regards,
Sven