ALGORITHMEN TEIL XII: Cogito errare est

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Information: Wir verlosen 9 Kinderbüchlein von Microsoft Mein Papa arbeitet bei Microsoft. Und ich darf mit!

    Unsere Datenschutzerklärung wurde aktualisiert. Mit der Nutzung unseres Forums akzeptierst Du unsere Datenschutzerklärung. Du bestätigst zudem, dass Du mindestens 16 Jahre alt bist.

    • Abt. INTEL Prozessoren seit 2015
      =====================
      Link zum "Intel CPUs Cheat Sheet"

      Link zum "AMD Cheat sheet" (etwas älter)

      Link zu einer guten Anfänger-Befehlsübersicht

      Gruss

      P.S.: Zit. aus einem Forumsbeitrag von Japhet, dem früheren Entwickler des Freeware-Assembler-Clones JWASM: Learning assembly with Masm64 - which is only capable to create binaries for Win64 - sounds like a fairly odd idea. You do not only have to struggle with assembly language, but also with the complex Win64 API and the peculiarities of the Win64 register calling convention and alignment requirements. JWASM has a few more features than Microsoft´s Masm64, but it's not supposed to be used by newbies in assembly language.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von p. specht ()

    • Abt. Experiment: Index aufsetzen per xpia-Assembler
      =================================
      Beim nachstehenden Experimentalprogramm geht es ausschließlich um STATISCHE EINDIMENSIONALE ARRAYS des Typs M&[size&]. Erste Ergebnisse zeigen, daß so 2 Mio Elemente mit einstellbarem Startwert, Endwert, Inkrement und Startindex binnen 16 ms linear vorladbar sind.

      Wo man das braucht? Wer je Daten nach mehreren Kriterien rasch durchsuchen mußte, lernt mitsortierte Indexdateien schätzen, weil damit eine enorme Beschleunigung des Suchprozesses möglich wird.
      Gruss

      P.S.: Nochmals: Achtung, rein zu Experimentalzwecken!
      (Anm: xpia ist der PreProzessor für XProfan von unserem Kollegen Frank Abbing, der allerdings selten anwesend ist)

      Quellcode

      1. $MAKE CLE
      2. 'Schnelles Index-aufsetzen statischer (eindimensionaler) Long-Arrays
      3. '(X) Experimentalware/Versuchscode mit XPIA 2017-03 by P.Specht, Vienna/Austria
      4. 'Nicht geeignet für Echtbetrieb!!! Keine wie auch immer geartete Gewähr!
      5. cls:font 2
      6. declare Adr&,STATUS&, abWert&,bisWert&,Inkrement&, StartNdx&
      7. var size&=2000000
      8. declare m&[size&],tm&
      9. m&[0]=999:m&[1]=888
      10. Adr&=addr(m&[0]) : Size&=sizeof(m&[])
      11. AbWert&=0 : BisWert&=0 : Inkrement&=10 : StartNdx&=4
      12. tm&=&Gettickcount
      13. Status&=NDX()
      14. tm&=&Gettickcount-tm&
      15. print "\n Status: ";Status&
      16. print " Werte indexiert in ";tm&;" ms\n"
      17. if size&<=15
      18. whileloop 0,size&-1
      19. print " m&[";&loop;"]= ";m&[&Loop]
      20. endwhile
      21. else
      22. print " m&[";0;"]= ";m&[0]
      23. print " m&[";1;"]= ";m&[1]
      24. print " m&[";2;"]= ";m&[2]
      25. print " m&[";3;"]= ";m&[3]
      26. print " m&[";4;"]= ";m&[4]
      27. print " m&[";5;"]= ";m&[5]
      28. print " ... "
      29. print " m&[";int(size&-5);"]= ";m&[size&-5]
      30. print " m&[";int(size&-4);"]= ";m&[size&-4]
      31. print " m&[";int(size&-3);"]= ";m&[size&-3]
      32. print " m&[";int(size&-2);"]= ";m&[size&-2]
      33. print " m&[";int(size&-1);"]= ";m&[size&-1]
      34. endif
      35. waitinput
      36. end
      37. proc NDX
      38. AsmStart indx (Adr&,Size&,Abwert&,Biswert&,Inkrement&,StartNdx&)
      39. .data
      40. step dd 0
      41. startndx dd 0
      42. .code
      43. mov ebx,para1 ;basis
      44. mov edx,para2 ;grösse
      45. mov eax,para3 ;ab
      46. mov edi,para4 ;bis
      47. mov esi,para6 ;startndx
      48. mov startndx,esi
      49. mov esi,para5 ;step
      50. mov step,esi
      51. JZ weiter
      52. mov esi,1
      53. mov step,esi
      54. weiter:
      55. mov ecx,startndx
      56. .while ecx < edx
      57. mov [ebx+4*ecx],eax
      58. inc ecx
      59. add eax,step
      60. .if edi>0
      61. .if eax>edi
      62. mov eax,-1
      63. .BREAK
      64. .endif
      65. .endif
      66. .endw
      67. AsmEnd (status&)
      68. return status&
      69. endproc
      Alles anzeigen

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von p. specht ()

    • Abt. Assembler-Erinnerungschart
      =====================
      Wir waren schon mal besser in Assembler. Die wichtigesten Befehls-´Mnemonics´ ohne weite Erläuterungen. An xpia´s AsmStart name1 (parameterliste) ...mov eax,para1 ... AsmEnd (status&) und die Masm-kompatiblen JWasm-Assemblermakros .data ;varname db/dw/dd/dq wert1,wert2, ... ;comment, .code, .while .endw und .repeat .until mit .break .continue sowie .if .ifelse .else .endif und nicht zu vergessen label: und Jmp label, sowie @@: @B @N sei auch noch kurz erinnert (Der Konkurrent xpse kann die nicht!).
      Gruss

      Quellcode

      1. X86 Reminder
      2. MOV NEG AND OR
      3. XCHG NOT {op=0-op} XOR
      4. LEA
      5. CALL label
      6. STC CLC CMC label: RET JMP
      7. PUSH PUSHF PUSHA
      8. POP POPF POPA JE = JZ JNE = JNZ
      9. JP = JPE JNP = JPO
      10. CBW CWD CWDE
      11. JA = JNBE sig: JG = JNLE
      12. CMP op1,op2 JAE = JNB = JNC JGE = JNL
      13. SAL RCL ROL JB = JNAE = JC JL = JNGE
      14. SAR RCR ROR JC = JNC JLE = JNG
      15. ADD SUB MUL {EDX:EAX=EAX*op} IMUL JO JS {msb}
      16. DIV {EDX=0:EAX=EAX/op Rest:EDX} IDIV JNO JNS
      Alles anzeigen

      P.S.: Vollständige Beschreibung der Makros gibts HIER.

      PPS: Wer mit Single Precision Floatingpoint (XProfans Komma-Werten) in Assembler arbeiten will, hier meine Zusammenstellung entsprechender Befehle
      Für die Floating Point Unit Programmierung gibts wieder "Simply FPU", dort auch als Download!

      Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von p. specht ()

    • so ein kleiner Mini-Assembler in XProfan wäre ja nicht schlecht.
      Den xpia möchte ich jetzt nicht installieren.
      Kann man aus der Proc und den Mnemonics einen Bytecode
      bzw. Hex-Code generieren ?

      Wenn man diese in einen Bereich schreibt, könnte man
      dann mit Call die Proc mit Parametern aufrufen.

      Wäre ja auch mal eine Idee, solche kleinen Assembler
      codes bzw- Bytefolgen zu sammeln, um sie bei Bedarf
      einzubinden. Gerade dort, wo XProfan zu langsam ist.
    • Tja, an einen Miniassembler in XProfan habe ich auch schon gedacht. Dieser sollte dann ohne externen bereits installierten Assembler auskommen und daher auch nur einen eingeschränkten Befehlssatz unterstützen. Ich müsste da mal tief in meinen Archiven kramen. Ich hatte seinerzeit, noch vor der Profan-Entwicklung in TurboPascal (IDE) und TurboBasic (Mini-Assembler) einen "RGH-Mini-Assembler" geschrieben, der in der Lage war die damals üblichen *.COM-Programme (Vorläufer der *.EXE Programme mit max. 64 kB Code + Daten) zu erzeugen. Vielleicht kann ich Teile des TurboBasic-Codes nach Delphi übertragen und den Asssembler von 16 auf 32 Bit bringen.

      BTW: Die Vorberlegung von Arrays wird mit "MAT Var&[] < n" in der nächsten XProfan-Version funktionieren und MAT wird vermutlich auch mit dynamischen Arrays funktionieren. (Und die neuen Befehle ZIP und UNZIP wird es auch geben.)

      Gruß
      Roland
      Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD / ATI Radeon HD4770 512 MB / Windows 7(32) - XProfan X4
      AMD Athlon II X2 2,9 GHz / 3 GB RAM / 500 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


      http://www.xprofan.de
    • RGH schrieb:

      Ich hatte seinerzeit, noch vor der Profan-Entwicklung in TurboPascal (IDE) und TurboBasic (Mini-Assembler) einen "RGH-Mini-Assembler" geschrieben, der in der Lage war die damals üblichen *.COM-Programme (Vorläufer der *.EXE Programme mit max. 64 kB Code + Daten) zu erzeugen.
      Das sollte reichen. Es sollen ja keine richtigen Programme erzeugt werden, sondern nur einzelne Prozeduren, deren Bytecode dann in einer Bereichsvariable in das Programm eingebaut wird.

      Gruß Volkmar
    • Skepsis scheint angebracht! Ihr wollt wirklich einen Formel-1 Boliden auf Trabbi quälen?

      Das aktuelle Intel x86-64 Manual kennt 11.244 addressierungsarten-kombinierende Befehlscodes. Die Hardware eines QuadCore i7 (ein CISC-emulierender RISC-Prozessor mit bis zu 80 GHz internem Takt) entspricht in ihren Blöcken den Gebäuden einer mittelgroßen Stadt, und nur ein modernes, komplexes Assemblerprogramm wie MASM oder JWASM kann diese OpCodes (bzw. den geplanten "kleinen Ausschnitt" davon) zur korrekten Zusammenarbeit und Optimierung bringen (Und das viel besser als ein Mensch es je könnte!). Die Zeiten eines 6502 oder 8086, wo wir Einzelkämpfer noch eine Chance hatten, sind leider vorbei. Viel interessanter wären meines Erachtens Befehle für OpenGPU-Computing! OpenGL in XProfan zu integrieren war jedenfalls ein guter erster Ansatz...

      Gruss

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von p. specht ()

    • Der Inlineassembler braucht ja auch nur rudimentär zu sein :
      - Parameter in Register schieben
      - Operationen ausführen (Rechenbefehle und vor allem Stringfunktionen)
      - Rückgabe von Werten.
      Das andere Gedöns wie While - Schleifen usw. braucht man ja nicht unbedingt.
      So, wie ich das von früher weiß, hatte man die auch nicht. Das kam alles mit dem
      MASM ab einer bestimmten Version. Wer einmal auf alte Listings schaut, sieht, daß
      das mit wiederholten Sprüngen zu Labels früher auch ging.

      Das ganze GUI- Zeugs usw. braucht man auch nicht unbedingt.
      Damals hatte man auch mit ca. 80 Befehlen genug Potential.

      Wir wollen ja immer noch mit XProfan programmieren und halt nur einige Sachen
      etwas beschleunigen.
    • ... nur daß damit das Problem erst beginnt: Es gibt ja absolute und relative Adressierung. Beim Schaffen eines Bereiches# im Memory wird dieser von Windows irgendwo geschaffen, wo gerade frei ist. Will man dann dort Maschinencode laufen lassen, stimmen alle Relativ addressierenen Befehle zwar noch, aber die Absolut-addressierenden müssen erst neu berechnet werden.

      Gerne kann ich euch zeigen, was Xpia zusammen mit JWasm aus meinen obigen .while - Schleifen gemacht hat. Aber laufen lassen kann man das noch lange nicht, denn so führt das zu einer saftigen Schutzverletzung (- im günstigste Fall !).

      Der XPIA-Precompiler ruft deshalb voher einen Rattenschwanz von Umrechnungs- und Speicher-Verschiebungs-Aktionen per Profan-API Calls auf, um das hinzukriegen. In meinem Falle waren das 345 weitere, von XPIA generierte XProfan-Sourcecode-Zeilen!
      Gruss

      P.S.: Hier der Teil, der dann erst von diesen 345 anderen Zeilen bearbeitet wird, bevor irgend etwas damit anzufangen ist. NICHT AUSFÜHREN!
      Spoiler anzeigen

      '______________________________________________________________
      ' Generiert mit XPIA © Frank Abbing (frabbing.net)
      ' ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
      ' Hier nur der Datenteil aus dem vom XPIA behandelten Sourcecode, (C) Frank Abbing
      Declare xpia_#
      Dim xpia_#,2048
      Clear xpia_#
      Long xpia_#,0=9460301,3,4,65535,184
      Long xpia_#,24=64
      Long xpia_#,60=192,247078670,-855002112,1275181089,1750344141,1881174889,1919381362,1663069537,1869508193,1700929652,1853190688,544106784,542330692,1701080941,168627502,36
      Long xpia_#,128=-618982791,-2005568707,-2005568707,-2005568707,-2005568707,-2005568708,-2006553421,-2005568708,1751345490,-2005568707
      Long xpia_#,192=17744,131404,1489338102
      Long xpia_#,212=554565856,201654539,512,512
      Long xpia_#,232=4104,4096,8192,268435456,4096,512,4
      Long xpia_#,264=4
      Long xpia_#,272=12288,1024
      Long xpia_#,284=2,1048576,4096,1048576,4096
      Long xpia_#,308=16,4224,78
      Long xpia_#,352=8192,20
      Long xpia_#,440=1297301837,12851,206,4096,512,1024
      Long xpia_#,476=-536870880,1818587694,25455,20,8192,512,1536
      Long xpia_#,516=1107296320
      Long xpia_#,1032=-1192457387,1,836297,1408011093,1569412695,206932744,-1961867893,1972049021,70617372,-1961885680,898177141,268439552,29231988,-1996488704,1048629,67996432,-351272944,-1962637030,328513,-2096103408,192282879,125224763
      Long xpia_#,1120=-72,990178303,1591898826,-1026991265,-859045864,-858993460,-858993460,-858993460
      Long xpia_#,1156=1489338102
      Long xpia_#,1164=4274,1,1,1,4264,4268,4272,4116,4297,1886912512,1230987625,2019910766,1819438934,1852138593,1819042862,1684957440,120
      Long xpia_#,1536=4096,20,808726571,809971777,12371

      PPS: Es gibt gerüchteweise einen einzigen Assembler, der es erlaubt, ausschließlich relative Sprünge zu verwenden: TASM. Und der ist uralt...

      Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von p. specht ()

    • Den obigen Spoiler-Teil kann man nach "Hex in C-Style" konvertieren mit nachstehender Sequenz:

      Quellcode

      1. ' an obiges Spoiler-Machwerk anhängen, dann aus Zwischenablage kopieren
      2. cls
      3. Declare w&
      4. clearclip
      5. print chr$(34);
      6. putclip chr$(34)
      7. Whileloop 0,1552/4
      8. w&=long(xpia_#,&Loop*4) ':print w&,
      9. print "\\x"+lower$(right$("00000000"+hex$(w&),8));
      10. putclip "\\x"+lower$(right$("00000000"+hex$(w&),8));
      11. if %pos>55:print chr$(34);"\n";chr$(34);
      12. putclip chr$(34)+"\n"+chr$(34)
      13. endif
      14. endwhile:print chr$(34):putclip chr$(34)+"\n"
      15. waitinput:end
      Alles anzeigen
      Der Code enthält Long-Einheiten und wird von dem von Kollegen Heinz Brill oben angegebenen ONLINE-DISASSEMBLER zwar korrekt in C-Bytecode gewandelt, aber dann nicht korrekt erkannt (Vermutlich weil der Beginn des Codes nicht immer erwischt wird und daher Daten als Befehle dargestellt werden. Vielleicht aber auch, weil es Probleme mit Intel´s Little Endian Darstellung gibt. Sonst dürfen dort nämlich nicht so viele OUTs-Befehle und INT3 Interrupt-Sprünge auftauchen. Die haben in einem Profan-Programm nix verloren).

      Sorry, hat nicht geklappt.
      Gruss

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von p. specht ()

    • Daran hatte ich auch nicht gedacht.

      Hatte mir das einfacher vorgestellt :
      -3dimensionales Array mit den Mnenonics,
      Hexcode, und Register, die beteiligt sind.
      -Hecode raussuchen und in Bereich schreiben
      - ausführen lassen.

      Gut, das mit den Sprüngen usw. müßte noch extra rein.
      Das andere müßte sowieso Roland machen.
      Ich stelle mir da eine Art Proc vor. Da müßten
      dann noch die Adressen der Parameter und einem
      Rückgabewert in den Opcode eingebaut werden.

      Sonst würde es sowieso keinen Sinn machen.
      Das kriegt man als XProfan-User nicht so ohne
      weiteres hin, da muß Roland ran.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von H.Brill ()

    • Ich könnte mir folgende Syntax vorstelle:

      Quellcode

      1. Declare mem MeineFunktion
      2. Dim MeineFunktion, 1024 ' Größe des Asssemblercodes in Bytes
      3. ASM MeineFunktion
      4. push ebp
      5. mov ebp,esp
      6. mov eax, [ebp + 8] // 1. Parameter nach eax
      7. mov ebx, [ebp + 12] // 2. Parameter nach ebx
      8. <Weiterer Code, Ergebnis nach eax>
      9. mov esp,ebp
      10. pop ebp
      11. ret 8
      12. ENDASM
      13. Var Long Ergebnis = Call(MeineFunktion, 34, 87)
      14. Print Ergebnis
      15. WaitInput
      Alles anzeigen
      Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD / ATI Radeon HD4770 512 MB / Windows 7(32) - XProfan X4
      AMD Athlon II X2 2,9 GHz / 3 GB RAM / 500 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


      http://www.xprofan.de

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von RGH ()

    • Ich fände es besser, wenn du den Bereich selber erstellst.
      Wenn es dann beim Reinschieben des Hexcodes eng wird,
      kannst du immer noch vergrößern. Wenn wir das nämlich
      machen, mußt du sicherstellen, daß der Hexcode auch
      reinpaßt, bzw. eine Fehlermeldung auswerfen. Warum
      denn nicht gleich den Bereich selbst erstellen und verwalten ?

      Warum nicht eine Proc dazu verwenden ?

      Quellcode

      1. PROC MeineFunktion
      2. Parameters Int x, y
      3. ASM
      4. push ebp
      5. mov ebp,esp
      6. mov eax, [ebp + 8] // 1. Parameter nach eax
      7. mov ebx, [ebp + 12] // 2. Parameter nach ebx
      8. <Weiterer Code, Ergebnis nach eax>
      9. mov esp,ebp
      10. pop ebp
      11. ret 8
      12. ENDASM
      13. RETURN <WERT (EAX)>
      14. ENDPROC
      15. Var Long Ergebnis = MeineFunktion(34, 87)
      16. Print Ergebnis
      17. WaitInput
      Alles anzeigen
      Wenn PROC nicht geht, wegen XProfans Procs, vielleicht ASMPROC...ENDPROC oder sowas.
      Den Call() könntest du dann übernehmen und die Rückgabe geschieht für uns gleichermaßen
      wie bei einer Proc.

      Was die Mnemonics und die Hexcodes angeht :
      Falls diese als Tabelle geführt werden, wäre es von Vorteil, sie als Resource im Interpreter
      und Profrun32.exe zu hinterlegen. Das wäre so eine Art Grundstock. Wer dann Lust und Laune hat,
      kann dann weitere bzw. Prozessorspezifische Mnemonics und deren Hexcode mit dem Reshacker o.ä.
      einfügen, um sie später nutzen zu können.

      Ist nur mal so ein Gedanke, kenne mich nicht so sonderlich aus.

      Kommt natürlich drauf an, was am leichtesten oder überhaupt machbar wäre.
    • Das mit dem automatischen Erzeugen des Bereichs hatte ich mir auch schon überlegt. Man könnte also erinfach das DIM weglassen und ASM erwartet eine ungeDIMte Bereichsvariable.

      Aber so wie Du die Syntax beschreibst, würde ja die Funktion bei jedem Aufruf der Prozedur neu assembliert und der Zeitvorteil ginge flöten. Nach meiner Syntax wird die Funktion nur einmal assembliert und in der Speichervariablen abgelegt und kann dann von überall im Programm mit CALL() aufgerufen werden.

      Denkbar wäre auch, dass man keine Bereichsvariable deklarieren muss und die Funktion unter Ihrem Namen zur Verfügung steht. (Das Erstellen des Bereiches und der Eintrag der Funktion unter den benutzerdefinierten Funktion liefe dann intern ab.)

      Quellcode

      1. ASM MeineFunktion
      2. push ebp
      3. mov ebp,esp
      4. mov eax, [ebp + 8] // 1. Parameter nach eax
      5. mov ebx, [ebp + 12] // 2. Parameter nach ebx
      6. <Weiterer Code, Ergebnis nach eax>
      7. mov esp,ebp
      8. pop ebp
      9. ret 8
      10. ENDASM
      11. Var Long Ergebnis = MeineFunktion(34, 87)
      12. Print Ergebnis
      13. WaitInput
      Alles anzeigen
      Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD / ATI Radeon HD4770 512 MB / Windows 7(32) - XProfan X4
      AMD Athlon II X2 2,9 GHz / 3 GB RAM / 500 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


      http://www.xprofan.de
    • Und so funktioniert es schon jetzt: (Ich habe die Zeile "add eax,ebx" eingefügt, damit die Funktion auch wirklich was tut.)

      Quellcode

      1. Declare mem MeineFunktion
      2. Dim MeineFunktion, 17 ' Größe des Asssemblercodes in Bytes
      3. BYTE MeineFunktion, 0 = $55, \ ' push ebp
      4. $89, $E5, \ ' mov ebp,esp
      5. $8B, $45, $08, \ ' mov eax, [ebp+8]
      6. $8B, $5D, $0C, \ ' mov ebx, [ebp+12]
      7. $01, $d8, \ ' add eax,ebx
      8. $89, $EC, \ ' mov esp,ebp
      9. $5D, \ ' pop ebp
      10. $C2, $08, $00 ' ret 8
      11. Var Long Ergebnis = Call(MeineFunktion, 34, 87)
      12. Print Ergebnis
      13. WaitInput
      Alles anzeigen
      (Leicht abgewandeltes Beispiel aus der XProfan-Hilfe)
      Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD / ATI Radeon HD4770 512 MB / Windows 7(32) - XProfan X4
      AMD Athlon II X2 2,9 GHz / 3 GB RAM / 500 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


      http://www.xprofan.de

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von RGH ()

    • Ja, das ginge auch.

      Ich weiß ja nicht, wie das intern mit deinen eingebauten Funtkionen
      läuft. Werden die bei jedem Aufruf auch immer wieder neu durchlaufen ?

      Vielleicht wäre es ja auch für dich leichter, wenn man seine Procs vorher
      definieren würde, so etwa wie bei Visual Basic.

      Declare Function blabla(Parameter....)
      ....
      Function blabla
      ....
      EndFunktion

      Function ist das gleiche wie Proc.

      Damit wüßte der Interpreter/Compiler schon im voraus welche und wieviele
      solcher Funktionen vorhanden sind und könnte schon vor dem Start alle
      assemblieren. Das andere so, wie du schriebst :

      (Das Erstellen des Bereiches und der Eintrag der Funktion unter den benutzerdefinierten Funktion liefe dann intern ab.)

      Da wäre dann intern ein Array von Bereichen zur Verwaltung vorteilhaft.

      Aber, wie dem auch ist : wenn, mach es so, wie du am besten klar kommst.
      Ich habe ja nur Vorschläge gemacht.
    • Wow! Das ist ja ein tolles Ding! Gleich auch für XProfan-11 adaptiert:

      Quellcode

      1. Cls
      2. Declare MeineFunktion#
      3. Dim MeineFunktion#,17 'Größe des Asssemblercodes in Bytes
      4. BYTE MeineFunktion#,0 = \
      5. $55, \'push ebp
      6. $89,$E5, \'mov ebp,esp
      7. $8B,$45,$08,\'mov eax,[ebp+8]
      8. $8B,$5D,$0C,\'mov ebx,[ebp+12]
      9. \
      10. $01,$d8, \'add eax,ebx
      11. \
      12. $89,$EC, \'mov esp,ebp
      13. $5D, \'pop ebp
      14. $C2,$08,$00 'ret 8
      15. Var Ergebnis& = Call(MeineFunktion#,34,87)
      16. Print Ergebnis&
      17. WaitInput
      18. end
      Alles anzeigen
      OK, nur mit Registern arbeitend: Alles relative Bezüge, dann klappt das natürlich.
    • Ja, das ginge auch.
      Sowas ähnliches steht ja auch schon seit Jahren in der Profanhilfe.

      Die Kernfrage ist ja immer noch, wie man die geschriebenen Assembler-
      befehle anständig als Bytefolge in einen Bereich bekommt. Bei kleinen
      Additionen oder sonst. Rechenbefehlen ist es ja noch kein Problem. Auch
      der einfachste Assembler entfaltet Geschwindigkeit bei Schleifen oder halt
      Labels. Diese Sachen müßten umzusetzen sein :

      Quellcode

      1. move eax, param1 ' statt [ebp+8]
      2. move ebx, param2 ' statt [ebp+12]
      3. jz Label1:
      4. ....
      5. Label1:
      6. ....
      Dazu zählen auch Variablen (oder auch Hilfsvariablen), die in ASM mit
      db oder dd definiert werden :

      text db 'Hallo'
      zahl dd 100

      Ich weiß ja nicht, wie das intern mit deinen eingebauten Funtkionen
      läuft. Werden die bei jedem Aufruf auch immer wieder neu durchlaufen ?



      PS:
      Es wird wohl kaum jemand hierfür richtig Assembler lernen wollen. So ein paar
      Grundkentnnisse sollte man schon haben, um den Code einigermaßen zu verstehen
      oder kurze Sequenzen zu schreiben.
      Es wird wohl so sein, daß man auch von verschieden Quellen (z.B. der Output von PureBasic ->
      ja, man kann man per Kommandozeile seinen Purebaisc-quelltext als ASM-Befehle ausgeben) ein
      einen Code hat, den man in XProfan einbinden möchte. Ziel sollte es sein, wenig Änderungen
      wie möglich am Code machen zu müssen. Immer unter der Berücksichtung, daß es normale
      Anweisungen sind und keine exotischen Prozessorbefehle.