Danke, war klar daß große Unterschiede bestehen. Masm64 ist derzeit auch lediglich im Alpha-Stadium. Beispielsweise hat Microsoft bisher kein INVOKE eingebaut, und auch andere Pseudobefehle fehlen schmerzlich (Einige Amateure bemühen sich um Workarounds). Wen´s dennoch interessiert, findet das zusammengetragene Ding hier, die "Arbeitsgruppe" besteht aus diesen Teilnehmern.
XPIA - Compilierfehler ?
-
-
-
Ich bemerkte gerade, daß beim Demo-Programm "Andere_Funktionen_aufrufen.prf" die Schalter $MAKE CLE gleich 5 Debugfenster öffnen: Vier leere und eines mit den Variablendaten. Gehört das so? (Aktueller XPIA unter Win7-64).
EDIT: Bei neuen Starts werden es immer mehr: Beim weiteren mal waren es schon Neun, jetzt 12 !!
OMG,was läuft da schief?EDIT2: Effekt stellt sich nur dann ein, wenn man den Editor zwischen den Compiliervorgängen nicht schließt. Sonst beim allerersten mal xpia: 1 Debugfenster, beim 2. mal 3, wobei das 1. Fenster Param1, das zweite Param2 zeigt, das Dritte den Rest der Variablen. Weitere Starts bringen dann leere Debugfenster plus eines, wo wieder alle Variablen drin sind: "Södsaum södsaum" (seltsam), wie der Wiener sagt...
-
Das kann eigentlich nur am Debugger liegen, Peter. Welchen benutzt du denn?
-
"Debugger für XProfan 2.02a" prfdebug.exe vom 26.07.2008 738 kiB
-
Den benutze ich quasi nie. Hab dem Teil auch noch nie recht getraut.
-
.. äh... sondern?
Die Situation mit den Fenstern wird etwas besser, wenn man nur $MAKE CL verwendet.
$MAKE E funktioniert auch, aber nur wenn der .prf-Quelltext im XProfan-Rootverzeichnis liegt,
sonst gibt es die Meldebox ".prc-Datei nicht gefunden". Im Moment bleibt es also bei "södsom...". -
Keine Ahnung, wie der Debugger funktioniert. Ich verwende selber VKDebug, da sind mir keine Seltsamkeiten bekannt.
-
Ich will eine der Konstanten der FPU ausgeben (hier: Pi), es kommt aber immer bloß Null raus...
Bitte kann mir jemand sagen, wo mein Denkfehler liegt?Code
Alles anzeigenCase 0 $MAKE C CLS set("decimals",18) Declare pia&,pi&,pi# Dim pi#,10 pia&=addr(pi#) Byte pi#,0 = 123 ' Falschwert, um Fehler erkennen zu können AsmStart GetFPU_Pi(pia&) mov ebx,para1 ; Pointer auf Profan-Bereichsvariable, in der FPU-Pi zu liegen kommen soll jmp Weiter ; Datenbereich überspringen lbl: Pi dq 0,0 Weiter: FNINIT FLDPI ; Ladet Pi gerundet auf 10 Byte Extended Precision Floating Point in SP(0) FST Pi ; SP(0) gerundet als DoublePrecision FP in Quadword-Variable Pi (nach lbl: da oben) FWAIT ; angeblich wichtig (wartet auf löschen des FPU-Busy Flags?) mov eax, lbl ;erste 4 Byte aus Bereich ab lbl: holen mov [ebx],eax ; und in die Profan-Bereichsvariable übertragen mov eax, lbl + 4 ; nächste 4 Byte ... mov [ebx]+4,eax ; übertragen, fertig. Theoretisch zumindest... AsmEnd print Float(pi#,0) ' Als 8byte Profan-Floatingpointwert ausgeben... Tuts aber nicht WaitInput
-
Geklärt. Mir war u.a. entfallen, daß Intel-Prozessoren und Windows ja beide Little-Endian arbeiten, die Bytefolge daher von rechts nach links zu lesen sind... und daß das auch für Float-Variablen gilt! Hier ein Beispiel, wie richtig zu interpretieren ist: An der Bereichsadresse liegt das Least Significant Bit (LSB), Werte im Memory werden sozusagen "vom Schwanz her" aufwärts adressiert (anders als am Stack, dort geht´s vom MSB her abwärts):
Code
Alles anzeigenCls:Set("Decimals",18) Declare Bereich# Dim Bereich#,8 'Byte Float Bereich#,0 = pi() Print "Bereichsadresse: ";Int(addr(Bereich#)) Print "Inhalt: ";Float(Bereich#,0) Print "\nSpeicherdarstellung ab",Bereich# WhileLoop 7,0,-1 Print int(addr(Bereich#)+&Loop);":",right$("00000000"+bin$(byte(Bereich#,&Loop)),8) EndWhile print Print "Als 4Byte-Integers (Typ Long) sieht das dann so aus:" Print "Höherwertiges LongInt: "; Long(Bereich#,4) Print "Niederwertiges LongInt: "; Long(Bereich#,0) WaitInput
Folgende Demo "entsteißgeburtet" der FPU nun tatsächlich das MSB-enthaltende 4-Byte-LongInt:
Code
Alles anzeigenif 0 $MAKE C endif declare eax& AsmStart GetPi() jmp weiter buff: wert dq 0 weiter: fninit fldpi fst wert fwait mov ebx,buff mov eax,[ebx]+4 AsmEnd(eax&) ClearClip print eax& PutClip eax& WaitInput
...und so gelingt endlich auch die Übertragung in eine Profan-Floatvariable:
Code
Alles anzeigenif 0 $MAKE C endif WindowTitle "FPU-Konstanten auslesen" CLS:set("decimals",20):Declare pi! AsmStart GetPi(addr(pi!)) mov ecx,para1 jmp Weiter Buff: Wert dq 0 Weiter: fninit fldpi fst Wert mov ebx,Buff ; Buff steht für die Speicheradresse des Buffers, nicht den Wert dort! mov eax,[ebx] mov [ecx],eax mov eax,[ebx]+4 mov [ecx]+4,eax AsmEnd print "Sollwert: 3.141592653589793238462643383279502884197..." print "FPU fldPi: ";pi! print "ProfanPi: ";pi() print "FormelPi: ";4*arctan(1) WaitInput
... also auf 15 Kommastellen genau, was eben der Double precision Darstellung mit 53 bit-Mantissen entspricht. Die FPU selbst rechnet intern aber mit 66 bit-Mantisse, erst beim speichern in eine SinglePrecision 4-Byte oder Double precision 8-Byte Floatvariable wird entsprechend gerundet. -
Halloween-Bug (kein Schwerz):
Nebenwirkung eines FPU-Befehls, erkennbar bei Betriebsart Font 2
===========================================
Da verwendet man ganz unschuldig einen FPU-Ladebefehl, und in Profan
wird ein String mittendrin mit 7 Nullbytes(" ") + 1x 80h ("€") überschrieben ?
Sehr merkwürdig!Anmerkung: Beitrag gelöscht, da in falschen Händen gefährlich.
-
Wenn man ASM in einer Hochsprache nutzt, sollte man auch Wissen, welche
Register zu sichern sind, bevor man sie nutzt -
Nein, Thomas. Mit XPIA kannst du alle Register verwenden, gibt da keine Einschränkungen wie in Inline-Assemblern anderer Hochsprachen, weil XPIA Dll-basierend arbeitet. Natürlich ist aber der User für den Stack zuständig und verantwortlich.
Register sichern bei API-Benutzung bleibt natürlich. -
FNINIT am Ende schafft (vermute ich mal) Abhilfe - zumindest war danach Ruhe. Solange mir aber nicht wirklich jemand Berufener erklären kann, was da genau vor sich geht, werde ich künftig einfach IMMER zwei Zeilenlange Strings hinter AsmEnd an Variable zuweisen. Da kann dann drin zu liegen kommen was will - es stört keinen mehr, wenn man die Variablen nicht verwendet.
Problem erledigt.
GrussP.S.: Es sind 7 x Chr$(0) und 1 x Chr$(128), die entsprechende Zeichen überschreiben, also sowas:
%00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %10000000
bzw. 00 00 00 80h. Und die sind wirklich IM string, nicht bei der Ausgabe drübergeschrieben. -
FLDPI arbeitet intern mit 10-Byte-Floats und nutzt den Stack als Speicher. Du musst vor Verwendung halt Platz schaffen, sonst überschreibt es dir evt. den Speicher einer Variablen oder wie geschehen eines Strings. Am Ende ist auch eine Profan-Exe ein natives Delphi-Compilat...
Mit fst, fstp, fist, fistp, und fbstp müsstest du dein Pi wieder vom Stack holen können oder eben mit finit neu initieren.Das alles hat aber nichts mit XPIA und Compilerfehlern zu tun und hat hier im Thread eigentlich nichts zu suchen. Darum bitte nächstes Mal einen neuen Thread erstellen.
-
Naja, das stimmt schon... Laut Beschreibung arbeitet der Barrel-Stack des 80x87-Teils mit 80 bit (10Byte bzw. TByte). Das sind jene Speicherstellen, die andererseits auch für SSE als mmx0 - mmx7 verwendet werden.
Gemäß Beschreibung rundet und speichert die FPU aber stets angepasst an das Zielformat, hier als Double precision FloatingPoint in 8 Byte. Und die drei TOP bits des ControlWords sind bei Verlassen der Routine 0, der Hardware-FPU-Stack also leer. Ich verstehe Eure Argumente so: Ihr meint, daß die FPU vielleicht hier DOCH 10 Byte abspeichert, OBWOHL richtig gerundet wurde - werde das testen!Mit jenem Stack, wo z.B. Variablenübergaben stattfinden, hat das m.E. aber nix zu tun. Den hätte ich aber für Effekte NACH Abschluß mit AsmEnd eher in Verdacht.
GrussP.S.: Bzgl. Einhaltung des Thread-Themas gelobe ich baldige Besserung.
-
Nach sehr langer Zeit komme ich wieder dazu, mich intensiver mit dem Proggen zu beschäftigen. Und hatte nun gleich auch das Problem, daß XPIA unter Profan 8 nicht so wollte, wie gewünscht. Bisher war mir das nie aufgefallen, weil ich eigentlich fast nie mit Memory-Modul, sondern ausschließlich mit DLLs gearbeitet hatte. Ich habe mal die von Frank schon 'teil-modifizierte' memods.inc noch etwas geändert. Somit sollten nun auch unter Profan v8.0 keine unerwarteten Fehlermeldungen mehr auftreten...
Gruß Matthias
p.s. Frank, bin von Deinem XPIA nach wie vor begeistert - Danke!
-
Prima.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!