Allerdings hab ich keine Ahnung, wie ich das realisieren soll.
Mein erster Gedanke war, einfach per "DUB" Speicher zu reservieren und dann einen String nach dem anderen dort plazieren.
Das Problem ist aber, dass die Strings nicht gleich lang sind, dh. ich kann sie nicht ansprechen mit Array + 4, etc.
Ich hoffe ihr wisst was ich meine?
Die Beschreibung der verwendeten Marcos findest du in \masm32\help\hlhelp.chm.
Wirf auch mal einen Blick in asmintro.chm, masm32.chm, masmlib.chm und opcodes.chm.
Normalerweise verwendet man einfach die passenden Datentypen, oder man richtet die Daten mit Alignment an passenden Adressen aus, beispielsweise mit align 16.
Oder legt die Strings für + 10h oder so einzeln an, bzw. belegt sie vor.
Mit Befehlen wie z.B.
Assembler Code:
Doppelwort_Stringtangas DD 66 DUP (0)
Assembler Code:
Doppelwort_Stringtangas DD 66 DUP (0)
Assembler Code:
Doppelwort_Stringtangas DD 66 DUP (0)
kann man sich Stringarrays in Doppelwortgröße anlegen. Vorsicht Verwechslungsgefahr: DW meint NICHT Doppelwort.
Dann gibt es noch diverse anderen Assemblerhilfen(direktiven) wie STRUC oder UNION die bei solchen Sachen helfen, oder eben wie masm oben schon beschreibt.
Tja, dann versuch erstmal, die Aufgabe in C zu lösen, oder C++, oder wie auch immer in einer Dir vertrauten Programmiersprache.
Dann schreibe ein wenig Testcode, mit dem die Funktion getestet wird, gängige "Use cases", illegale Parameter und was Dir noch so einfällt.
Dann versuche, die Funktion in Assembler zu implementieren und parallel mit dem Testcode zu testen...
Sollte es bereits an der Implementierung in C scheitern - dann gehe und zocke lieber Battle Field oder WoW o.ä.
@nachtfeuer:
Ja, sowas kam mir auch in etwa in den Sinn. Da ich aber gerade erst mit ASM anfange, wollte ich direkt die "standard" bzw. beste Methode benutzen.
@abc.w:
Wie gesagt, ich suche die beste Methode für ASM.
Der letzte Satz ist übrigens sehr hilfreich
@masm:
Habs mir jetzt mal genauer angeschaut. Das dynamische Array hat mir sehr geholfen
@abc.w:
Wie gesagt, ich suche die beste Methode für ASM.
Der letzte Satz ist übrigens sehr hilfreich
Ich habe Dir die beste Methode gezeigt. Es gibt keine bessere. Zum Schluss hast Du zwei Implementierungen, einmal in einer Hochsprache und einmal in Assembler. Die beiden kannst Du vergleichen - je nach dem, was Du genau vorhast - "Optimize for size" oder "Optimize for speed".
Siehe es auch noch so: Mit dieser Methode sparst Du Zeit und gehst an das Problem objektiv heran und du kannst nachweisen, dass Du etwas verbessert (oder auch verschlechtert) hast.
@abc.w:
In C++ hab ich das schon einmal gehabt, an sich der gleiche Ansatz wie der von masm. Hab nur gedacht, dass man das in ASM noch etwas "eleganter" lösen könnte...
@masm:
Hab deine Lösung jetzt "übernommen" und modifiziert.
Möchte ich jetzt ungern posten, da der Code einfach durch zahlreiche Experimente ziemlich wild aussieht.
Bin nur etwas von den masm32 Macros abgewichen, dh. ich hab z.B. anstatt "alloc(...)" -> VirtualAlloc bzw HeapAlloc verwendet.
Wenn ich nun die Elemente aus dem dynamischen Array ausgeben will, werden die mir falsch herum ausgegeben, d.h. LIFO.
Kann man natürlich leicht umgehen, aber woran liegt das ?
Noch etwas:
Rein von der Performance wäre es doch sinnvoller, einen großen Block zu reservieren (und ggf. später noch vergrößern), anstatt für jedes Element neuen Speicher zu reservieren, oder sehe ich das falsch?
Bin nur etwas von den masm32 Macros abgewichen, dh. ich hab z.B. anstatt "alloc(...)" -> VirtualAlloc bzw HeapAlloc verwendet.
Ist richtig so, HeapAlloc sollte man verwenden – alloc() liest sich in Beispiel halt besser ;-)
GutenAbend schrieb:
Wenn ich nun die Elemente aus dem dynamischen Array ausgeben will, werden die mir falsch herum ausgegeben, d.h. LIFO.
Kann man natürlich leicht umgehen, aber woran liegt das ?
Das liegt daran, wie du die Strings ein- und/oder ausgibst.
GutenAbend schrieb:
Noch etwas:
Rein von der Performance wäre es doch sinnvoller, einen großen Block zu reservieren (und ggf. später noch vergrößern), anstatt für jedes Element neuen Speicher zu reservieren, oder sehe ich das falsch?
ja, das ist Sinnvoll und deswegen macht es der Heap-Manager für dich.
Vergleich mal deine Schleifen - der unterschied sollte dir auffallen.
Ganz wichtig: Die Register EAX,ECX und EDX werden durch WinAPI-Funktionen geändert - nur ESI,EDI und EBX bleiben unberührt (Win/Intel ABI). Wenn der Inhalt dieser Register gebraucht wird, musst du sie vor einem API-Aufruf z.B. auf dem Stack oder in einer lokalen Variablen sichern (EDX->Zeile 33-45)
Oh verdammt!
Nein sorry, das ist meine "optimierte" Methode. So wird alles korrekt ausgegeben...
Wenn ich diese Schleife "korrigiere", tritt eben dieser falsche Effekt auf...
Oh verdammt!
Nein sorry, das ist meine "optimierte" Methode. So wird alles korrekt ausgegeben...
Wenn ich diese Schleife "korrigiere", tritt eben dieser falsche Effekt auf...
So lange Du keinen Testcode hast, kannst "optimieren" bis zum Umfallen. Danach kann man den Quellcode ausdrucken und als Klopapier benutzen - ehrlich.
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.