Parameterübergabe an Assemblerfuktionen?

[DualCoreCpu]

Hallo,

ich weiß, das eine Assemblerfunktion ihre Parameter in folgender Weise übernimmt:

Von links nach rechts

1. Parameter in EAX
2. Parameter in EDX
3. Parameter in ECX

Alle weiteren Variablen kommen auf den Stack.

So weit so gut. Das mag stimmen wenn die Länge der Parameter auch 32 Bit ist:

Delphi-Quellcode:

function myasmfunc(a: longint, b: longint): Longint; assemler;

Ist das aber auch so, wenn diese Parameter a und b nur 16 Bit groß sind oder gar nur Bytes?

Beim Rückgabewert einer Funktion tritt das gleiche Problem auf. Aber dort wäre, wenn das Funktionsergebnis in EAX zurückgegeben wird EAX halt bei kleineren Datenfeldern nur zum Teil fefüllt.

Aber kann ich wirklich sicher sein, das auch Bytes und 16 Bit Integers konsequent in den 3 Registern zurückgegeben werden, im Zewifelsfall eben nur zum Teil gefüllt?

[BerndS]

lässt sich mit einem einfachen Programm leicht überprüfen.

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

function Test(B: Byte; W: Word; I: Integer): LongInt;
begin
  Result := B + W + I;
end;

begin
  try
    writeln(Test(5, 50000, 1000000));
    { TODO -oUser -cConsole Main : Code hier einfügen }
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

CPU-Ansicht:

Code:

Project1.dpr.17: writeln(Test(5, 50000, 1000000));
0041C4B0 B940420F00       mov ecx,$000f4240
0041C4B5 66BA50C3         mov dx,$c350
0041C4B9 B005             mov al,$05
0041C4BB E814D5FFFF       call Test

[DualCoreCpu]

Danke @BerndS.

Dann brauch ich mir diesbezüglich keine Sorgen zu machen. :)

[TRomano]

Sorgen machen musst Du dir nur, wenn Du ein 64bit-Kompilat ersteellen willst. Da ist die Reihenfolge der Parameter nämlich eine andere ...

[DualCoreCpu]

Zitat:

Zitat von TRomano (Beitrag 1319974)

Sorgen machen musst Du dir nur, wenn Du ein 64bit-Kompilat ersteellen willst. Da ist die Reihenfolge der Parameter nämlich eine andere ...

Ok, danke für den Hinweis. :thumb:

Damit werd ich mich später beschäftigen. Jetzt erst mal 32Bit.

[Mavarik]

Nur aus reiner Neugier...

Was gibt es heute noch, dass man in ASM programmieren "muss"...

[Neutral General]

Zitat:

Zitat von Mavarik (Beitrag 1320112)

Nur aus reiner Neugier...

Was gibt es heute noch, dass man in ASM programmieren "muss"...

Zumindest mal Teile von Bootloadern/Betriebssystemen :stupid:
Ansonsten kann je nach Situation SSE hilfreich sein, was der Compiler nicht automatisch hinbekommt.

[SMO]

Zitat:

Zitat von Mavarik (Beitrag 1320112)

Was gibt es heute noch, dass man in ASM programmieren "muss"...

Jede Menge, wenn man an Leistung interessiert ist. Der Delphi-Compiler optimiert leider nicht gut genug.
Natürlich sollte man aufpassen, keine "premature optimization" durchzuführen. Aber wenn man eine rechenintensive Anwendung hat, kann es sich lohnen, mit einem Profiler nach den Engstellen zu suchen und diese in Assembly zu schreiben (mit SSE und allem Pipapo).
FL Studio zum Beispiel benutzt Delphi und jede Menge Inline Assembly für Audiosignalverarbeitung.

Außerdem geht manches in Assembly schlicht einfacher. Konvertierung zwischen Big- und Little-Endian zum Beispiel. Für 16 Bit Werte gibt's in Delphi immerhin noch die intrinsische Funktion "Swap". Für 32 Bit muss man sich selbst etwas basteln, aus shl/shr, and, or. In Intel Assembly gibt's dafür einen dedizierten Befehl: bswap. Ich warte schon seit Jahren, dass Delphi das auch mal als intrinsische Funktion zur Verfügung stellt (Swap32 oder so). Aber das wird wohl nichts mehr; und wenn ich in der Hilfe zu Swap (siehe oben) lese "Die Prozedur dient lediglich der Abwärtskompatibilität", kann ich nur den Kopf schütteln...

[BUG]

Das ist etwas was mit dem GCC super funktioniert. Ge-inlinte Funtionen mit eingebettetem Assembler, wobei man Angaben zu Eingabe- und Ausgabe-Registern machen kann, sogar ohne sich auf spezifische Register festzulegen :thumb:
Dank der besser spezifizierten AMD64/x64-ABI sollte es in Zukunft nur einfacher werden, Aufrufe zu implementieren.

Zitat:

Zitat von SMO (Beitrag 1320125)

Natürlich sollte man aufpassen, keine "premature optimization" durchzuführen.

Für das Backend macht es imho Sinn, die Zielarchitektur zu kennen bevor man mit dem Design loslegt. Das Anforderungen des Problems sollte bekannt sein, die Fähigkeiten der Hardware sollten bekannt sein. Damit kann man dann von vornherein sinnvolle Abstraktionen festlegen, die man dann später auch Optimieren kann. Als Anwendungsprogrammierer bekommt man das in Form von Bibliotheken serviert und muss das dann sinnvoll einsetzten; das Wissen über die Zielplattform sollte an der Stelle schon wegabstrahiert sein.
Die beiden Hüte kann sich natürlich auch ein und die selbe Person aufhaben.

[DualCoreCpu]

Zitat:

Zitat von Mavarik (Beitrag 1320112)

Nur aus reiner Neugier...

Was gibt es heute noch, dass man in ASM programmieren "muss"...

Schnelle Grafikroutinen für PC Spiele. Mathematische Funktionen für lanwierige Berechnungen. Es sei denn letzere werden schon auf Operatorebene passend optimiert.

Ich beschäftige mich gerade mit Ati Grain Gerometry http://www.antigrain.com.

Graeme Geldenhuys, der Macher des fpGUI Prokektes hat zur fpGUI die Pascal Version dieser Bibliothek dazu gepackt. Und bei einem Demo bin ich von der Darstellungsgeschewindigkeit regelrecht enttäuscht. Da könnte sich Assembelerprogrammierung noch lohnen.

Ansonsten Neugier, sehen wie die CPU unsere Programme verarbeitet.

Und natürlich die Compilerhersteller müssen wissen, welcher Code für das Hochsprachenkonstrukt erzeugt werden muss. Auch heute noch, es gibt ständig Compilererweiterungen.