| |
|
|
- Seite 1 - |
|
|
if 0
{$cleq}
endif
declare bereich#, y&, z&
dim bereich#,16
print
print "Erster Test zum Umgang mit Bereichsvariablen# und einfachen Bereichen in XPIA"
print " (In diesem Teil geht es ausschließlich um long&-Werte mit 4 Byte = 32 bit)"
print
z& = 1234567899
y& = 1212
print "------ Profan-Teil ------"
print "An Position 0 von bereich# wird zugewiesen",z&
long bereich#,0 = z&
print "An Position 4 von bereich# wird zugewiesen",y&
long bereich#,4 = y&
print "Probe: An Position 0 des Bereiches steht tatsächlich", @long(bereich#,0)
print " An Position 4 des Bereiches steht tatsächlich", @long(bereich#,4)
print
print "Die Variable ´bereich#´ zeigt den Wert",bereich#
set("decimals",0)
print "Die Funktion Addr( bereich# ) liefert ebenfalls", Addr( bereich# )
print "Addr( bereich# ) liefert also den Inhalt des Zeigers ´bereich#´"
print "Aber worauf zeigt er?"
print
print "---- Assemblerteil ----"
AsmStart Alig1( bereich# )
MOV EAX, para1
AsmEnd (z&)
Print "Der Inhalt von ´bereich#´, wird mit MOV EAX eingelesen als", z&
AsmStart Alig3( bereich# )
MOV EBX,para1
LEA EAX, [EBX]
AsmEnd (z&)
Print "Test: Para1 zeigt auf Speicherstelle", z&
AsmStart Alig2( bereich# )
LEA EAX, para1
AsmEnd (z&)
Print "An Speicherstelle ´bereich#´ steht ein 32bit-Zeiger, der auf", z&,"zeigt."
print "----------------------"
print "Der 16-byte-alignment-Versatz des Bereichsbeginns ist ", z& mod 16
print "Ergebnis NULL ist SEHR wichtig für schnelle SSE/SIMD-Algorithmen!"
print "----------------------"
AsmStart Alig4( bereich# )
LEA EBX, para1
LEA EAX, [EBX]
AsmEnd (z&)
Print "Probe: para1 verweist indirekt auf", z&
AsmStart Alig5( bereich# )
MOV EBX, para1
MOV EAX, [EBX]
AsmEnd (z&)
Print "Und dort wiederum steht = ", z&
AsmStart Alig6( bereich# )
MOV EBX, para1
MOV EAX, [EBX + 4]
AsmEnd (z&)
Print "Und 4 Byte weiter steht = ", z&
Print "----- Meine Schlussfolgerung -----"
print "´Der Inhalt von bereich#´ stellt also ein interner Zeiger dar, in dem "
print "der Beginn des reservierten Speicherbereiches vermerkt ist!"
print
print "Garantie gibts natürlich keine! Aber dafür herzliche Grüße von Specht ;-)"
WaitInput
dispose bereich#
End
Edit von Jörg: Das mit den Code-Tags scheint echt schwer zu sein! Stimmt, woher sollen Anfänger auch wissen, daß das # was mit Code zu tun hat? |
|
|
| |
|
|
|
| |
|
- Seite 1 - |
|
| @Peter: Kompileranweisungen des XPSE musst Du nicht in eine Blockanweisung ablegen - diese wird XProfan sowieso nicht erreichen wenn XPSE vorgeschaltet ist.
Wenn Du dennoch die Anweisung beibehalten möchtest, ohne XPSE zu nutzen, dann gibt es hierfür einen undokumentierten Trick: Das Ausklammern von XPSE-Kompileranweisungen kann man z.B. mit dem Remtyp und dem Remtyp //, verwendest Du jedoch zweimal das Zeichen , also , dann wird der Schalter von XProfan (natürlich) dank Rem übersehen - aber XPSE krallt sich den Schalter trotzdem. Die Ausnahme gilt aber nur für 2 x vor der Anweisung.
|
|
|
| |
|
|
|
Jörg Sellmeyer | Wenn Du einen Speicherbereich benötigst, der sich zur Laufzeit nicht ändert (außer durch Dein Programm), brauchst Du ihn einfach nur am Anfang des Programms deklarieren und noch gewünschter Größe dimensionieren. Der Bereich wird solange reserviert, bis er mit Dispose Var# wieder freigegeben wird. Früher waren nur solche nicht-dynamische Bereichsvariablen möglich. Ob die dann in Windows tatsächlich an physikalisch aufeinanderfolgenden Adressen beschrieben werden, wage ich zu bezweifeln. Das dürfte vom Defragmentierungszustand des Rams abhängen. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 28.08.2008 ▲ |
|
|
|
|
Jörg Sellmeyer | iF
@Peter: Kompileranweisungen des XPSE musst Du nicht in eine Blockanweisung ablegen - diese wird XProfan sowieso nicht erreichen wenn XPSE vorgeschaltet ist. Wenn Du dennoch die Anweisung beibehalten möchtest, ohne XPSE zu nutzen, dann gibt es hierfür einen undokumentierten Trick: Das Ausklammern von XPSE-Kompileranweisungen kann man z.B. mit dem Remtyp und dem Remtyp //, verwendest Du jedoch zweimal das Zeichen , also , dann wird der Schalter von XProfan (natürlich) dank Rem übersehen - aber XPSE krallt sich den Schalter trotzdem. Die Ausnahme gilt aber nur für 2 x vor der Anweisung.
Das hast Du nicht dokumentiert? Das ist das beste Feature überhaupt an XPSE! Schön, das auch mal zu erfahren. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 28.08.2008 ▲ |
|
|
|
|
|
Ob die dann in Windows tatsächlich an physikalisch aufeinanderfolgenden Adressen beschrieben werden, wage ich zu bezweifeln.
Da bin ich mir sicher. Sonst könnten wir uns ja die mühe sparen , solch kurze Befehle auszudenken. Weil beim starten eines Programmes (hier Profan) dieser Raum nur noch für das eine Programm Profan vorhanden ist. Wenn du ein 2. Profan startest und probehalber die gleiche Adresszahl eingibst, wirst du nicht auf den Speicher zugreifen können von Profan beim 1. Start, obwohl beim 2. Programm die Adresse auch vorhanden ist, du bekommst einen anderen Wert. Wenn dein Ram an der Stelle defekt ist wist du die Zahl nicht mehr finden.
Wenn man die Programm.exe von Profan natürlich hergestellt, mit einem Disassembler bearbeitet, wirst du es feststellen.
mf peter |
|
|
| |
|
|
|
Jörg Sellmeyer | Defekter Ram sollte dabei eine untergeordnete Rolle spielen. Angenommen Dein Ram sieht so aus:
Daten|Daten|Daten|Daten|Daten| |Daten| |Daten|Daten| |Daten| | | | | | | | | Und Du startest Dein Programm, dann glaube ich nicht, daß der Speicher hiterher so aussieht:
Daten|Daten|Daten|Daten|Daten| |Daten| |Daten|Daten| |Daten|Profan|Profan|Profan|Profan|Profan| | | | Sondern so:
Daten|Daten|Daten|Daten|Daten|Profan|Daten|Profan|Daten|Daten|Profan|Daten|Profan|Profan| | | | | | | |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 28.08.2008 ▲ |
|
|
|
|
| Jörg Sellmeyer
Ob die dann in Windows tatsächlich an physikalisch aufeinanderfolgenden Adressen beschrieben werden, wage ich zu bezweifeln. Das dürfte vom Defragmentierungszustand des Rams abhängen.
Die physikalische Adresse erhält man eh nie, nur eine Zuordnungsadresse (welche oft fälschlich als phy Addr verkannt wird) und diese ändert sich - (aber) je nach Reservierungsmethode - normalerweise bis zu eine möglichen Redimensionierung nicht.
Ge DIM ter Speicher behält also seine Adresse bis er wieder mit Dim redimensioniert wird oder gar freigegeben. |
|
|
| |
|
|
|
| Peter Bierbachh
Weil beim starten eines Programmes (hier Profan) dieser Raum nur noch für das eine Programm Profan vorhanden ist.
Das ist aus einem anderen Grund falsch. Jeder Prozess hat so wie so seinen eigenen Adressbereich - reden wir hier aber mal nur von NT. (und nicht von älteren Windowsversionen wie z.B. 98 wo das Speichergeschehen noch nicht so organisiert (sicher) war.)
Du kannst natürlich auch Speicher reservieren welcher für alle Prozesse verfügbar ist - halt eine Frage der Art der Reservierung.
Dim reserviert unbeweglichen Speicher der für gewöhnlich nur im erzeugenden Prozess verfügbar ist, und natürlich auf übergeordneten Leveln z.B. wenn das eigene Programm den UserMode verlässt. (wie z.B. Treiber) |
|
|
| |
|
|
|
| @Peter: Hast Du Dir noch einen zweiten Account zugelegt? (mit 2 h am Ende des Nachnamen?) |
|
|
| |
|
|
|
| Es gibt nur der mit dem 2h. Das eine h kriege ich nicht weg. Wollte ich schon überberschreiben, dann kam ich nicht mehr dran.
mfg |
|
|
| |
|
|
|
| Wer was im Computer macht, ist mir eigentlich wurscht.
Mit dem Speichergedöns sollen sich die selbsternannten Fachleute rumschlagen. ist nicht meine Welt. Und wenn Windows den Speicher von Aldi holt, Hauptsache det Programm läuft.
mfg peter |
|
|
| |
|
|
| |
|
- Seite 2 - |
|
|
| @Peter: Äh, ich dachte zu hast dazu den 2. Beitrag geschrieben? Oder gibt es zwei Peter B. ? Bitte wie bist du zu dem Eingabewert "von Hand" gekommen?
Ich dachte eigentlich, mein Progi ganz oben zeigt, daß da ein Zeiger auf den eigentlichen Datenbereich dazwischengeschaltet ist. Auf XP scheint das jedenfalls so zu sein, oder was hab ich nicht kapiert?
Gruß P. Specht (Zwecks Unterscheidung der Peters bitte einfach mit Specht anreden, bins gewohnt!) |
|
|
| |
|
|
|
| Peter Bierbachh
Es gibt nur der mit dem 2h. Das eine h kriege ich nicht weg. mfg
Es gibt ein Mitglied mit dem Namen ohne 2 h am Ende, beide aus Lünebrug. |
|
|
| |
|
|