Array zur Laufzeit
-
Der Compiler meint bei erzeugen u.a.
call operator new (00401060)
Was soll den das heißen?mfg A-lex
-
; hier eine funktion in nasm synthax (tasm/masm ist aber ähnlich): function: mov ebp,esp ; ebp hat jetzt die aktuelle addresse des esp gemerkt sub esp,4 ; da der stack nach unten wächst im gegensatz zum code, daten usw ; musst Du den speicherbereich abziehen. sub esp,4 fordert ; 4 byte auf dem stack an. Jetzt kannst du auf ss:esp ; 4 byte daten ablegen mov esp,ebp ; so stellst du esp wider her wenn du denn buffer nicht ; mehr brauchst! alternativ: add esp,4 ; .... ret
-
Ein push ebp davor wär auch nicht schlecht...
-
Ringding schrieb:
Auf dem Heap: call malloc
Ich weis die Frage hatten wir schon mal von mir aus gestellt, dennoch:
Nun man hat mir mal erklärt, dass der heap nicht wirklich etwas ist, was
unter die direkte verwaltung der cpu fällt sondern eine OS spezifische sache ist,
welche nur durch die entsprechende api aufrufe (des Betriebssystems) zu lösen ist.Doch wie haben es dann die Betriebssytementwikler dann gelöst?
-
Das OS hat direkten Zugriff auf einen großen Haufen an ungeordnetem Speicher. Es muss halt "einfach" durch geeignete Datenstrukturen und Algorithmen Ordnung reinbringen.
-
Wenn ich eine Array einer Strucktur in den Stack bringen will muss ich ja:
; Strucktur ETWAS STRUCT eins dd ? zwei dd ? ETWAS ENDS ; Code mov eax,sizeof ETWAS mov ebx,5 ; Anzahl der Array-Elemente mul ebx sub esp,eax
Und wie lese/schreibe ich z.B. das 3 Element?
mfg A-lex
-
A-lex schrieb:
Wenn ich eine Array einer Strucktur in den Stack bringen will muss ich ja:
; Strucktur ETWAS STRUCT eins dd ? zwei dd ? ETWAS ENDS ; Code mov eax,sizeof ETWAS mov ebx,5 ; Anzahl der Array-Elemente mul ebx sub esp,eax
Und wie lese/schreibe ich z.B. das 3 Element?
mfg A-lex
Junge, du kotzt mich langsam an! Lern C oder nenn mal einen Triftigen Grund wieso du jegliche WinAPI scheiße in Assembler machen willst!!!! Willste so einen Scheiß schreiben wie die Idioten von Ristrict Area?
Sag einfach mal einen Aktzeptablen Grund.
-
wie wärs stattdessen so zu schreiben:
; Strucktur ETWAS STRUCT eins dd ? zwei dd ? ETWAS ENDS ; Code sub esp,sizeof ETWAS *5
wird noch zur assemblierung berechnet
und auslesen:das ist unser array [eins, zwei][eins,zwei][eins, zwei][eins,zwei][eins, zwei]
wir wollen jetzt das dritte Element ansprechen:
dazu müssten wir vom Anfang an durchgehen und zwei Elemente "überspringen".
Wenn man mit "gewönlichen" Indizien arbeitet (also das erste Element hat I=1) dann darf man nicht vergessen dass unser array bei "Index" 0 anfängt. Möchte man also z.B das vierte Element ansprechen muss man mit (4-1) den "wirklichen" index berechnen. Aber die Elementnummer reicht ja nicht - man muss ja auch die Adresse des elemts haben. Diese kann man insofern berechenen als dass uns ja der Arrayanfang bekannt ist (ESP, bzw eventuell in irgendeiner VAriable gesichert).
Nehmen wir an das Array fängt bei 12000 an, dann müsste ja unser drittes Element bei:12000+8+8 liegen (jeweils die größe von ETWAS Struct)
je nach dem ob man jetzt z.B in einer Schleife initialisiert oder fest vorgegeben das 3 element lesen/schreiben will gibt es einige Methoden, die sich im Prinzip nur dadurch unterscheiden ob man schon zur Assemblierung den Elementindex angibt oder erst später berechnet:mov eax, Wert mov [esp+sizeof ETWAS*2],eax
oder auch:
mov ebx,Wert mov eax,sizeof ETWAS mul Index mov [esp+eax],ebx
das Auslesen funktioniert genauso, nur eben die letzte Zeile ändern
Hier kann man natürlich einiges optimieren, z.B MUL ist überflüssig wenn man als Index direkt die sizeof ETWAS nimmt und entsprechend nicht um eins erhöht sondern um die Größe des Elements.
Wenn noch interesse besteht könnte ich mal nach einer Schablone für Array(verwaltung) auf dem Stack suchen wobei auch solche Arrays wie [-4..+4] möglich sind.
-
@ todo@work
todo@work schrieb:
Lern C
Ich kann C++
todo@work schrieb:
Ristrict Area
Wer sind die?
todo@work schrieb:
nenn mal einen Triftigen Grund wieso du jegliche WinAPI scheiße in Assembler machen willst!!!!
Wenn es nach dir gehen würde, gäb es nur eine Programmiersprache und zwar C(++).
Wenn man erstmal die Syntax gelernt hat (ist für einen Anfänger nicht leicht; Ich glaube du bist da gescheitert, sonst wärest du nicht so schlecht drauf, wenn du den Namen hörst) dann gibt es einige Vorteile in ASM z.B. muss man sich nicht so viele Gedanken über die Variablen-Typen machen, denn man muss für HWND, HDC, HBITMAP usw. nur DWORD schreiben, denn man unterscheidet nur in der Größe des Typen. (Strukturen sind eine Ausnahme)...
Wenn man es weiter macht landen wir mal in der beliebten Diskusion: Meine Programmiersprache ist besser als deine...mfg A-lex
-
wo ist das ein argument? in C oder sonst was sind HWNDs nichts weiter als void* und fertig, da pinkelst du dich wegen an? OMFG.
Das was du bietest sind keine passablen argumente.
Achja: Wenn es nach mir gehen würde gäbe es auch assembler, aber nur für sinnvolle dinge und nicht für Scrollbars und sonstigem Kram den du hier andauernd fragst wie jemand der alles in den arsch gedrückt bekommen will.
-
Also das war nur ein Beispiel. Die Hauptargumente sind die Größe und vor allem die Schnelligkeit.
Ähm.. Wieso regst du dich eigentlich auf? Ich rege mich ja auch nicht auf, wenn irgendjemand irgendwo etwas macht, was ich nicht machen würde. Oder hast du Spass dran?
Noch mal zu meiner Frage: was ist die "Ristrict Area"?
PS: Damit wir uns nicht falsch verstehen: Die Fragen über die WinApi waren nur um Assembler besser zu verstehen. Mit Assembler kann man dann z.B. seine C(++) Programme tunen.
mfg A-lex
-
A-lex schrieb:
Hauptargumente sind die Größe und vor allem die Schnelligkeit.
Das sind keine Argumente mehr.
Hol dir einen anständigen Compiler der gut Optimiert dann hat sich die sache erledigt. Der VC++7.1 kann wenn es um Fensterprogramme geht besser optimieren auf größe/schnelligkeit (beides kann man prioritäten zuweisen) als du mit deinem Assemblerhype.
Assembler ist nur noch was für das OS-Dev oder Höhere Optimierungen mit SSE oder andere SIMD-Techniken. Das was du machst ist definitiver Schwachsinn!
-
todo@work schrieb:
Der VC++7.1 kann wenn es um Fensterprogramme geht besser optimieren auf größe/schnelligkeit (beides kann man prioritäten zuweisen) als du mit deinem Assemblerhype.
Das ein neuer Compiler nicht schaden kann, stimme ich dir zu, doch kann der Compiler nicht besser optimieren, als er programmiert wurde. So kann man mit Assembler noch mehr rausholen.
mfg A-lex
-
"Man" schon, aber das trifft auf ca. 99% der ASM-Programmierer nicht zu. Außerdem kann man C/C++-Code mal eben für einen anderen Prozessor optimieren, indem man einfach mit anderen Compileroptionen compiliert.
-
A-lex schrieb:
todo@work schrieb:
Der VC++7.1 kann wenn es um Fensterprogramme geht besser optimieren auf größe/schnelligkeit (beides kann man prioritäten zuweisen) als du mit deinem Assemblerhype.
Das ein neuer Compiler nicht schaden kann, stimme ich dir zu, doch kann der Compiler nicht besser optimieren, als er programmiert wurde. So kann man mit Assembler noch mehr rausholen.
mfg A-lex
Was laberst du da für einen Unsinn? Das ist echt das Lächerlichste, was ich seit Jahren gehört habe!
Was kommt als nächstes für ein Unsinn? Der Mensch wurde von Gott erschaffen und die Evolutionstheorie wird über'n Haufen geworfen? Also bitte, so naiv kann nicht mal jemand wie du sein!
[edit]Wenn du hier weiter mitreden willst, moechte ich dich bitten, deine Ausdrucksweise nochmal gruendlich zu ueberdenken. Ansonsten wird hier gleich auch mal aufgeraeumt und deine Beitraege gesellen sich zu ihren bereits verschwundenen Kumpanen.[/edit]
-
A-lex schrieb:
Das ein neuer Compiler nicht schaden kann, stimme ich dir zu, doch kann der Compiler nicht besser optimieren, als er programmiert wurde. So kann man mit Assembler noch mehr rausholen.
ähm..., berichtigt mich wenn ich mich irre...
Ich glaube schon, dass diese Aussage zutrifft. Schliesslich stellt der Compiler denn ganzen code aus allgemein gehaltenen "Bausteinen" zusammen.
Jedoch ist asm-codeoptimierung nur bei rechenintensiven Routinen sinvoll.
Ich bezweifle jedoch, ob man bei Windowsprogrammierung mit asm sich alzugroße Vorteile beschafft. Schließlich läuft da so ziemlich viel über die WIN-API.
Und die wird ja überallmit gleich aufgeruffen
-
Ringding schrieb:
das trifft auf ca. 99% der ASM-Programmierer nicht zu.
Du meinst doch eher 99% aller Fälle, oder? Meiner Meinung nach würde ich die Prozentzahl weiter runterdrehen.
@linu(x)bie
Ja, z.B. bei der Graphik- und Spielprogrammierung, wo man mit Assembler (ich meine auch Inline-Assembler) etwas mehr rausholen kann.Ringding schrieb:
Außerdem kann man C/C++-Code mal eben für einen anderen Prozessor optimieren, indem man einfach mit anderen Compileroptionen compiliert.
Wenn wir jetzt von Windowsprogrammierung ausgehen, sind die Prozessoren von denen du redes die Pendium-compatiblen d.h. da muss man nirgendwo gans schnell für einen anderen Prozessor schreiben. Der einzige neue Prozessor wäre der 64-Bit Prozessor. Bei dem werden warscheinlich auch noch "alten" 32-Bit akzeptabel. Wenn man jetzt eine 64-Bit exe neuecompeliert, muss kann man da auch nicht sagen, einfach umstellen, denn du musst andere libs und header-dateien einfügen (nämlich die für 64-Bit) nicht viel anders ist es bei Assembler.. Vielleicht ein paar kompatibilitätsproblemme, die bei C/C++ auch aufträten könnten.
mfg A-lex
-
wieder die itaniums vergessen! :p naja, und theoretisch alphas... falls sich noch jemand an win NT erinnert.
-
@A-Lex
Sie glauben ja selbst nicht, was Sie da sagen. Muten Sie mir also bitte auch nicht zu, saß ich das dann glaube. Sie sind viel zu intelligent, um nicht zu wissen, dass Sie jetzt im Unrecht sind. Lassen Sie doch diese Mätzchen. Sie reden sich im Moment um Kopf und Kragen und merken es offenbar nicht einmal. (Bezug auf Ihre "Allround-Sinnlos-Basic-Assembler-Fragen")
-
LOL
ich kann mir schon vorstellen wer hier unter "anderem" Namen wider solche äusserungen von sich gibt