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 3 x das Buch "Nur noch dieses Level!" Spiel mit!

    • Roland wollte ja auch nur normale Befehle übersetzt haben.
      Wenn er dann wirklich mit Bereichen arbeitet, kann er ja
      seine eigenen (inneren) Schleifen etc. benutzen.

      Es wird ja darauf hinführen, daß mit Call + Parameter die
      mit Opcodes befüllten Bereiche aufgerufen werden. Wenn
      die Geschichte mit den Opcodes und Parametern jetzt
      schon funktionieren würden, könnte man das schon mit
      XProfanen Mitteln selber erledigen. Bloß, wenn Roland
      das intern regelt, wird's vermutlich noch schneller. So,
      wie ich es sehe, sind die Schleifen (die wir nutzen) von
      XProfan die Bremsklötze. Darum wäre intern besser.

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

    • Ich glaube die Liste im Link der Antwort 96 von P.Specht ist schon sehr vielversprechend. Da sind ja schon die 32-Bit-Geschichten mit drin. In vielen Einführungen in Assembler wird nicht über 16 Bit hinausgegangen. Und das reicht hier natürlich nicht. Ich habe jetzt genug Infos, um am nächsten freien Wochenende anzufangen!

      Danke für Eure Hilfe!

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


      http://www.xprofan.de
    • Abt. Kurznachrichten
      =============
      Sunnyvale, Kalifornien: Fa. AMD gab am 8. März 2017 bekannt, daß die neue “Naples” Server-CPU im 2. Quartal 2017 zur Auslieferung kommt. AMD verbindet damit die Hoffnung, Intels Vormachtstellung im Servermarkt zu brechen. Der angekündigte AMD-Chip scheint erstmals ein echter Herausforderer von Intels XEON Cpu für Datacenters seit nun bald 10 Jahren zu sein. Doch was liest man betreffend Intel?:

      Santa Clara, Kalifornien: Fa. Intel: Der neue Intel Skylake Xeon Processors gibt sein Debut auf Google Cloud! Google gab bekannt, seinen Cloud-Kunden die Möglichkeit zu eröffnen, mit Intels nächster XEON-Generation namens “Skylake” processor zu arbeiten. Dabei zielt Google auf den HPC (= High Performance Computing) Markt im Gesundheitswesen, Multimedia und Unterhaltung, bei Finanzdienstleistungen und anderen Industriezweigen.

      Fa. AppliedMicro, Kalifornien, zielt mit seinen ARM Chips der dritten Generation auf den derzeit von Intel Xeon dominierten Markt. Der in Musterstückzahlen verfügbare "X-Gene 3" ARM zielt auf SoC (System on a chip) Serversysteme. Nach Studien von dritter Seite wird diese neue Plattform Leistung bieten, die Intels Xeon-Serie nahekommt, aber deutlich weniger kostet.

      Redmont (Seattle), Washington State: Microsoft und (Menlo Park, Kalifornien:) Facebook Inc. einigten sich kürzlich auf einen gemeinsamen "Open Standard" für GPU Servers für Cloud Computing Beschleunigung. Das war eigentlich nur eine Frage der Zeit: Das "Open Compute Project (OCP) design" für standalone-GPU Beschleuniger liegt nun vor.

      Burnaby (British Columbia), Kanada: Fa. D-Wave Sytems, Hersteller des ersten "Quantencomputers mit Verschränkungslatenz" liefert nun seine jüngsten 2000-Qubit Systeme an Virginia Tech aus, währen gleichzeitig die Systeme von Google, NASA und der Universities Space Research Association (USRA) von 1000 auf 2000Qbit aufgerüstet werden.

      Fa. IBM gab die Absicht bekannt, in den Quantencomputing-Markt in einigen Monaten mit seinem 5 QuBit "echt vollverschränktem" Quantencomputer einsteigen zu wollen. Im Labor funktionierte das System zuverlässig und löst - zumindest theoretisch - bisher nahezu unlösbare Aufgaben.
      ----
      Gruss
    • H.Brill schrieb:

      Hab hier noch was online gefunden.
      Ist evtl. mal zum Probieren nützlich :
      defuse.ca/online-x86-assembler.htm#disassembly

      Da bekommt man die Hexcodes schon fertig als String
      oder Array geliefert.
      Danke! Sehr nützlich zum Testen, ob mein Inline-Assembler alles richtig macht!

      Gruß
      Roland

      PS: Der Inlineassembler wird in XProfan X4 kommen!
      Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD / ATI Radeon HD4770 512 MB / Windows 7(32) - XProfan X3
      AMD Athlon II X2 2,9 GHz / 3 GB RAM / 500 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X3


      http://www.xprofan.de
    • PS: Da ist mir noch eine weitere Idee gekommen.
      Vielleicht kann Roland ja auch den Output (Hexcode), der vom Inlineassembler
      generiert wird, zugänglich machen. Da die Unterprogramme ja nicht riesengroß
      werden, vielleicht in einer Systemvariablen, z.B. $ASM. Die anderen User könnten
      den ja mit CALL aufrufen.
      Der Gedanke kam mir, als ich eben das Kapitel mit den Units nochmals durchgelesen
      hatte. Da ist ja auch die Rede, daß der Entwickler seinen Quellcode nicht weitergeben
      braucht und dieser somit geschützt ist. Das gleiche könnte ich mir beim Inlineassembler
      auch vorstellen.
      Wäre sicher leicht machbar, zumal der Hexcode-Output ja sowieso
      vorhanden ist. Praktisch gesehen wäre es ein Nebenprodukt.
    • Vielleicht zum besseren Verständnis ein Beispiel :

      Quellcode

      1. Declare String zeile
      2. DEF $ASM "\q$01,$00,$10,$CC,$00,$00,$00,$00,$6C,$00,$00,$00,$01,$E6,$50,$72,|\
      3. $6F,$66,$61,$6E,$00,$10,$8E,$52,$65,$67,$45,$78,$70,$72,$00,$0C,|\
      4. $4B,$57,$69,$6E,$64,$6F,$77,$73,$00,$10,$55,$54,$79,$70,$65,$73,|\
      5. $00,$00,$81,$53,$79,$73,$49,$6E,$69,$74,$00,$00,$C7,$53,$79,$73,|\
      6. $74,$65,$6D,$00,$00,$02,$53,$79,$73,$55,$74,$69,$6C,$73,$00,$10,|\
      7. $B4,$49,$6D,$61,$67,$65,$48,$6C,$70,$00,$10,$9D,$53,$79,$73,$43,|\
      8. $6F,$6E,$73,$74,$00,$10,$46,$62,$6C,$63,$6B,$73,$6F,$63,$6B,$00,|\
      9. $10,$24,$73,$79,$6E,$61,$69,$70,$00,$10,$73,$73,$79,$6E,$61,$75,|\
      10. $74,$69,$6C,$00,$10,$26,$73,$79,$6E,$61,$66,$70,$63,$00,$00,$5E,|\
      11. $43,$6C,$61,$73,$73,$65,$73,$00,$10,$22,$52,$54,$4C,$43,$6F,$6E\q|"
      12. ClearList
      13. AddString(0, "Declare Memory Bereich")
      14. AddString(0, "Dim Bereich, " + Str$(Len($ASM, ",")))
      15. AddString(0, "Byte Bereich, 0 = \")
      16. Move("StrToList", $ASM, "|")
      17. WhileLoop 3, GetCount(0) - 3
      18. zeile = GetString$(0, &LOOP) + "\"
      19. ReplaceString(0, &LOOP, zeile)
      20. EndWhile
      21. AddString(0, "'Hier können Parameter - Infos stehen'")
      22. AddString(0, "'CALL(Bereich(P[1]...P[N])")
      23. /*
      24. ' Hier einfach in eine Datei speichern
      25. Move("ListToFile", "H:\PrfHex.txt")
      26. */
      27. Listbox$("Quellcode für XProfan", 2)
      28. End
      Alles anzeigen
      Wäre ja für den Autor der ASM-Routine nicht viel Arbeit.
    • Wäre schön, so lange sichergestellt ist, daß die bisherigen Voll-Lösungen (xpia, xpse etc.) weiter funktionieren. Ich möchte meine Matrizen-Kreuzprodukte nämlich privat weiterhin mit der vollen Macht moderner Floatingpoint-fähiger CPUs beschleunigen können ((Für "Deep learning" ist das elementar wichtig; GPU-rechnen wäre mir da noch lieber)). Für X3 sind da aber bereits einige Tricks wie {$PUSHKEYWORD} und der JRPC Pre-Präkompiler von Jens-Arne Reumschüssel nötig.
      Gruss

      P.S.: Da sich beide Programmierer, sowohl der von xpia als auch der von xpse, aus ihren Projekten zurückgezogen haben, ja geradezu verschollen sind, besteht meines Erachtens kein Grund mehr, Links auf gute Beiträge in deren Foren gegenseitig zu blockieren.
    • RGH schrieb:

      Danke! Sehr nützlich zum Testen, ob mein Inline-Assembler alles richtig macht!
      Hab hier noch ne DLL gefunden.
      Bekomme das aber nicht richtig zum Laufen :

      board.flatassembler.net/topic.php?t=6239


      Quellcode

      1. Declare String ASM[9], zeile, err, Handle dll
      2. Declare Memory Bereich
      3. Dim Bereich, 1024
      4. Cls
      5. dll = ImportDLL("H:\\Temp\\fasm-DLL\\fasmdll\\FASM.DLL", "")
      6. ASM[0] = "push ebp"
      7. ASM[1] = "mov ebp,esp"
      8. ASM[2] = "mov eax, [ebp+8]"
      9. ASM[3] = "mov ebx, [ebp+12]"
      10. ASM[4] = "add eax,ebx"
      11. ASM[5] = "add eax,ebx"
      12. ASM[6] = "mov esp,ebp"
      13. ASM[7] = "pop ebp"
      14. ASM[8] = "ret 8"
      15. WhileLoop 0, 8
      16. err = fasm_Assemble(ASM[0], Bereich, SizeOf(Bereich), 100, 0)
      17. Print err
      18. EndWhile
      19. Move("MemToList", Bereich, "")
      20. Listbox$("", 2)
      21. WaitKey
      22. Dispose Bereich
      23. FreeDll dll
      24. End
      Alles anzeigen
      err bringt mir zwar 0 (FASM_OK), habe aber keinen Output.

      Wäre evtl. auch eine Möglichkeit zum Testen, wenn es mit der DLL klappt.
    • H.Brill schrieb:

      Bekomme das aber nicht richtig zum Laufen :
      Kann so auch nicht funktionieren. Der Quellcode kann nicht in einem Array stehen und dann der Assembler für jedes Element des Arrays aufgerufen werden. Der will einen Quelltext komplett am Stück übersetzen, also ein Text mit Zeilenschaltungen Chr$(13) + Chr$(10) und zusätzlich mit Chr$(0) abgeschlossen. Anders könnte der ja auch keine Sprünge verarbeiten. Das Ergebnis kann nicht so einfach in eine Listboxliste übertragen werden, es ist ein Bytecode, kein String. Der Bytecode beginnt auch nicht an Bereich, an dieser Position steht eine Struktur

      FASMDLL.TXT schrieb:

      The lpMemory should be a pointer to the memory block and cbMemorySize
      should contain its size. In the beginning of this memory block the
      FASM_STATE structure will reside (as defined in FASM.ASH).

      FASM.ASH schrieb:

      struct FASM_STATE
      condition dd ?
      union
      output_length dd ?
      error_code dd ?
      ends
      union
      output_data dd ?
      error_line dd ?
      ends
      ends
      Die Struktur will ausgewertet sein, dort findet sich dann auch ein Zeiger auf den eigentlichen Bytecode sowie die Anzahl Bytes der Codelänge.
      Der reservierte Speicher für die Ausgabe ist letztendlich auch zu klein, es hat erst ab 1026 Byte funktioniert. Der sollte also mehr als ausreichend groß dimensioniert sein.

      Der Code mal schnell "umgeschmiert"

      Quellcode

      1. Declare String Zeile, err, Handle DLLDeclare Memory BereichDeclare Pointer StartDeclare Int ZahlDim Bereich, 1026
      2. Cls
      3. DLL = ImportDLL("C:\Users\Volkmar\AppData\Roaming\\FASM.DLL", "")
      4. Zeile = "push ebp" + chr$(13) + chr$(10) + "mov ebp, esp" + chr$(13) + chr$(10) + "mov eax, [ebp + 8]" + chr$(13) + chr$(10) + "mov ebx, [ebp + 12]" + chr$(13) + chr$(10) + "add eax, ebx" + chr$(13) + chr$(10) + "add eax, ebx" + chr$(13) + chr$(10) + "mov esp, ebp" + chr$(13) + chr$(10) + "pop ebp" + chr$(13) + chr$(10) + "ret 8\z"
      5. err = fasm_Assemble(Zeile, Bereich, SizeOf(Bereich), 100, 0)Print err
      6. Start = long(Bereich, 8)Zahl = long(Bereich, 4)Print:Print "Code:", Zahl, "Bytes"While Zahl WhileLoop 8 Print Right$("00" + Hex$(Byte(Start,0)), 2), Inc Start Dec Zahl CaseNot Zahl : Break EndWhile PrintEndWhile
      7. WaitInputDispose BereichFreeDll DLLEnd
      Alles anzeigen
      Das Ergebnis könnte so stimmen ;-)


      Gruß Volkmar
    • Irgendetwas scheint da noch nicht zu stimmen (abgesehen von den fehlenden Zeilenumbrüchen ;-) ): Im Ergebnis tauchen zwischen den korrekt übersetzen Befehlen immer 66 oder 67 und 66 auf, die da nicht hingehören. Es könnte sich hier um ein anderes Speichermodell handeln. Wenn ich im Online-Assember etwa MOV AX, BX (16-Bit-Register) eingebe wird da ein hex 66 vor dem code für MOV EAX, EBX (32-Bit-Register) gesetzt.

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


      http://www.xprofan.de

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

    • Welche fehlenden Zeilenumbrüche? Im Binärcode gibt es keine. Ich habe die Ausgabe einfach so gruppiert, wie das meist gemacht wird, 8 Byte je Zeile. Wenn ich das "e" vor den Registerbezeichnungen wegnehme, also 16-Bit-Code angebe, dann verschwinden diese überflüssigen Bytes. Habe mich jetzt noch nicht mit dem Befehlssatz auseinander gesetzt und hielt das für einen Prefix für 32 Bit.

      Gruß Volkmar
    • Ich meine die Zeilenumbrüche in Deinem Quellcode, z.B. "Declare String Zeile, err, Handle DLLDeclare Memory BereichDeclare Pointer StartDeclare Int ZahlDim Bereich, 1026". Oder macht da mein Browser Mist?

      In einem 32-Bit Programm brauchen 32-Bit-Befehle keinen Prefix! Da haben die 16-Bit-Befehle so etwas.

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


      http://www.xprofan.de