![]() |
AW: XE2: ASM und Pascal gemischt?
Oder besser: Typen dafür definieren und diesen nutzen.
|
AW: XE2: ASM und Pascal gemischt?
Zitat:
Ok, ich sehe es, aber wo liegt da der große Vorteil? Die paar Mikrosekunden Zeitersparnis? |
AW: XE2: ASM und Pascal gemischt?
Zitat:
|
AW: XE2: ASM und Pascal gemischt?
Seit XE2 gilt mehr denn je: weg mit dem Assembler-Zeugs! Pascal ist mittlerweile genauso schnell. Und es entfällt das ständige Neuschreiben beim Portieren. Die beste Performance erreicht man durch gescheite Algorithmen, nicht durch Assembler.
|
AW: XE2: ASM und Pascal gemischt?
Assembler hat für gewisse Bereiche und Probleme durchaus seine Berechtigung. Der heutige 0815 Programmier sollte darauf verzichten und lieber den Compiler optimierten Code erzeugen lassen, wobei sich das Verzichten ohnehin oft durch die fehlenden Kenntnisse erübrigt. Assemblerunterstützung war ursprünglich nicht für Win64 im XE2 geplant und die Lösung zur Nutzung von Assembler wäre dann das Einbinden von Objektdateien von z.B. NASM gewesen. Das es Assemblerunterstützung doch gibt, liegt daran das die entsprechende Nachfrage besteht.
|
AW: XE2: ASM und Pascal gemischt?
Zitat:
|
AW: XE2: ASM und Pascal gemischt?
Zitat:
Es gibt aber nicht viele Fälle, bei denen der relativ kleine Performancegewinn wirklich ins Gewicht fällt. In diesen Fällen kann es sich aber dann durchaus lohnen Assembler einzusetzen, auch wenn das heißt, dass man den Code für verschiedene Plattformen mehrfach schreiben muss. Das ist dann aber auch nicht so schlimm, weil es eben nicht so viele Fälle sind. |
AW: XE2: ASM und Pascal gemischt?
Zitat:
Aber wie Sebastian Jaenicke schon schreibt. Es muss sich schon lohnen, wenn man in die ASM-Kiste greift... ;) Hatte gehofft, der Compiler würde den überflüssigen Aufruf zu 'nem Jump optimieren, tut er aber nicht. |
AW: XE2: ASM und Pascal gemischt?
- Lade alles statisch.
- Lade doch alle Adressen gleich zu Beginn und springe danach direkt hin, ohne den Wrapper. oder - Lade überall erstmal Laderoutinen rein und tausche diese, beim ersten Aufruf, aus.
Delphi-Quellcode:
Ich weiß jetzt nicht, wie das mit Konstanten in Mac oder 64 Bit aussieht, aber früher hätte ich eventuell eine typisierte Konstante mißhandelt, anstatt der globalen Variable (da diese grungsätzlich erstmal schreibgeschützt ist, was sich aber verbiegen läßt)
interface
var SQLite3_Open: function(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl; implementation function _SQLite3_Open(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl; begin LoadProcAddress(SQLite3_Open, 'sqlite3_open'); Result := SQLite3_Open(filename, db); end; initialization SQLite3_Open := _SQLite3_Open; |
AW: XE2: ASM und Pascal gemischt?
Dieser ASM-Trick wird häufig verwendet (z.B. Jedi-Projekt). Es gibt drei Vorteile:
1) Es braucht nicht jedesmal eine individuelle global variable deklariert zu werden. Wenn man nur eine Funktion wrappen muss spielt das keine Rolle, aber bei 150 Funktionen macht einen dieses ständige Copy&Paste schon ganz schön müde. 2) Die Parameter, die sich ja sowieso schon auf dem Stack befinden, werden nicht nochmal auf den Stack kopiert 3) Ein sicherlich zu vernachlässigender Zeitvorteil beim Sprung/Rücksprung in die eigentliche Routine Wenn der Compiler eine Aufrufkonvention unterstützen würde, bei der die Parameter nicht nochmals kopiert werden müssten, könnte man sich den Umweg über Assembler sparen. Ich würde mir so etwas wünschen (entsprechend des Aufrufs "inherited;"):
Delphi-Quellcode:
var
_SQLite3_Open: FARPROC; function SQLite3_Open(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl; begin if _SQLite3_Open = nil then LoadProcAddress(_SQLite3_Open, 'sqlite3_open'); _SQLite3_Open; end; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz