Array zur Laufzeit

Kannst du mir ein Beispiel zeigen

mfg A-lex

A-lex schrieb:

Kannst du mir ein Beispiel zeigen

mfg A-lex

[...insert "unsinnige Provokation" here...] und evtl. dir mal C++ ansehen um zu gucken was dein Compiler ausspuckt? [...tut ebenfalls nichts zur Sache...]

Der Compiler meint bei erzeugen u.a.
call operator new (00401060)
Was soll den das heißen?

mfg A-lex

linu*x*bie

; 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

Ringding

Ein push ebp davor wär auch nicht schlecht...

linu*x*bie

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?

Ringding

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.

CDW

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

Ringding

"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]

linu*x*bie

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

camper

wieder die itaniums vergessen! :p naja, und theoretisch alphas... falls sich noch jemand an win NT erinnert.